Topic: Сохранить стакан в базе (Read 1804 times)

а причем тут гит?

Вопрос еще в том, насколько глубокий стакан целесообразно хранить. При вызове стакана с глубиной в 2000 с того-же бтс-е в обе стороны (бид/аск), процентов 70% его остается актуальным в течении 2-2 дней.
Кэш не прогретый, поэтому вытащил из базы все. Запрос через минуту дает следующую картинуПри глубине 150 видна уже более менее адекватная картина, а вот при 50 начинает становится видна непосредственно активность на бирже. Поэтому пока пришел к выводу, запрос 50 пар с частотой раз в минуту дает более чем актуальную картинку.

А какой смысл делать 10 проектов, чтобы потом дольше было в них разбираться?..

Имеет смысл работать над одним опенсорсным проектом, который потом за одно и мт4 потеснит.


PS  мт4 хорош не тем что он чем-то лучше, а тем что он более распостранен.  Так что нужен проект
сильно круче чтобы его потеснить - но если делать один большой опенсорс то это вполне реально,
думаю "сервис" метаквотов уже многие ДЦ достал и раскрутить их на поддержку будет не сложно...
(но что-то уже должно быть готовое к тому времени - легче получить поддержку на уже работающий проект,
чем финансирование того что еще не известно получиться или нет)

Я и предложил открытые средства
@tvv, у вас наверное проблемы с удержанием нити беседы, вы забываете свои же слова, вопросы, ответы собеседника?

Любой, в котором разбираешься - то бишь свой, или найти _нормальный_ опенсорс и продолжить.

Стакан на форексе не проблема - его там нет по другой причине - он там просто не нужен, посмотрите что из этого выходит на дельтастоке если не верите, потому его никто больше и делать даже не стал.  Там наперстки по сути - стакан для игры в напестки не нужен...  (ну в смысле в электронных наперстках не нужен, а в настоящих как раз нужен )


PS  похоже проще пойти другим путем - с нуля раскручивать новую систему которая постепенно вытеснит форекс - настоящие ордера из рейтера и EBS вам конечно никто никогда не покажет же...

Какой инструментарий посоветуешь? Если учесть что в forex мире просто то актуальная информация - роскошь, а уж история стакана - вообще миф.

Охота вам велосипеды изобретать...

PS  это проще делать через открытые проекты, к тому-же есть вероятность потом продавать платформу ДЦ...

более чем хорошо.

Для данной задачи нет разницы в виде БД, запросы все примитивные, уровня получить запись по идентификатору, при этом очень редкие записи без необходимости серьезно блокировать базу на их момент.. в общем не стоит ездить в булочную на танке, поставленном в ангар грузового авиалайнера.

Если появляются такие вопросы, странно, неужели задача и реализация не ясна? она же капитанская вся из себя:
1. несколько таблиц, каждая для своего интервала (минутные, пятиминутные, часовые, суточные, недельные,..)
2. идентификатор - время
3. пара полей asks/bids в которые складываются значения в стакане для изменившихся цен (нет смысла складывать дельту), исключение - таблица с самыми большими интервалами (не вижу смысла больше недельных что то городить), в нее складываются полные стаканы.

Записывается первое значение, остальные вычисляются на основе первого. Через каждые 1024 записи опять записывается текущий стакан (первое значение).

Про  MS SQL  что скажете ?

Да, sqlite, она очень хороша по скорости запросов на чтение и проста в обслуживании.
По уму тут пойдет абсолютна любая key-value база данных.

Вы использовали для этого какую СУБД ? Или как ?

Многоуровневые дифы, тоже самое что вы делаете, только добавить хранение разницы не только для каждой загрузки, но и периодические - раз 5 мин, раз в час, раз в сутки, а дальше хранить уже недельные и дампы всего стакана (я имею в виду что брать разницу между стаканами через этот интервал)

Таким образом запрос стакана на любую дату будет восстановлен за почти логарифм (точнее константа) запросов - 1 запрос на нужную неделю + максимум 7 запросов на сутки + макс. 24 запроса на час + макс. 12 запросов на 5-тиминутку + макс. 5 запросов постоянных дифов (я делал минутные, давно правда, теперь делать часто запросы на гокс нельзя, не чаще чем раз в 5 мин).

Конечно грамотнее было выбирать не 'красивые интервалы' а степень какого либо числа, к примеру 4 или 8, но мне было лень переделывать, основная нагрузка в аналитики приходится не на получение данных да и даже если хранить не дифы а тупо копии json (только не то что возвращает сервер а подчистить), занимаемое место не критично (кстати такая база неплохо пакуется файловыми системами или даже встроенными средствами базы данных, для readonly части это оправдано).

Хранить в базе в виде сериализованных массива массивов из целых чисел (asks и bids - разные поля) - [ [price,amount],.. ] так как массивы заметно шустрее десериализуются и обрабатываются чем объекты.

Так же метод в коде должен уметь кешировать стакан в памяти, в пределах какого-либо интервала. Вообще кешировать рекомендуется все.. данные, вычисляемые значения и т.п.

Появилась задача оптимизировать сохранение и хранение стакана заявок. На текущий момент все это дело конвертится в JSON и хранится полностью, был вариант, когда записывается только первое значение, а дальнейшие вычисляются на основе первого. То есть такая заявка убрана из стакана, такая добавлена. На малых объемах данных все круто, а вот на больших начинаются проблемы. Приходится фоном постоянно пересчитывать данные, что не есть хорошо. Быть может кто-нибудь из присутствующих тут сталкивался с подобным? каким образом можно все это дело сохранять, чтобы в любой момент можно было вытащить данные на конкретный момент времени, как на текущий момент, так и на прошедший. Буду очень благодарен за помощь.