Сохранить стакан в базе

[SonkoDmitry]

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

[rPman]

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

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

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

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

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

[hazarun]

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

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

[rPman]

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

[hazarun]

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

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

[Come-from-Beyond]

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

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

[rPman]

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

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

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

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

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

[tvv]

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

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

[rPman]

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

[tvv]

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

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


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

[rPman]

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

[tvv]

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

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


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

[SonkoDmitry]

git

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

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

1) Buy BTC (Bitcoin) with USD (United States Dollar) on "BTC-E" stock
2) Buy BTC (Bitcoin) with RUB (Russian rouble) on "BTC-E" stock
3) Buy BTC (Bitcoin) with EUR (Euro) on "BTC-E" stock

Total get from stock: 6000 records
Total finded: 1525 records
Finded in cache: 0 records
Finded in db: 1525 records
Inserted in db: 4475 records

Скрипт выполнялся 175.7487 сек.

Кэш не прогретый, поэтому вытащил из базы все. Запрос через минуту дает следующую картину

1) Buy BTC (Bitcoin) with USD (United States Dollar) on "BTC-E" stock
2) Buy BTC (Bitcoin) with RUB (Russian rouble) on "BTC-E" stock
3) Buy BTC (Bitcoin) with EUR (Euro) on "BTC-E" stock

Total get from stock: 6000 records
Total finded: 5991 records
Finded in cache: 5991 records
Finded in db: 0 records
Inserted in db: 9 records

Скрипт выполнялся 3.8341 сек.

При глубине 150 видна уже более менее адекватная картина, а вот при 50 начинает становится видна непосредственно активность на бирже. Поэтому пока пришел к выводу, запрос 50 пар с частотой раз в минуту дает более чем актуальную картинку.