Stockdb - БД на эрланге для трейдинговых тиков

Aug 29, 2012 15:48

Хочу немного рассказать про нашу базу данных stockdb которую пришлось написать для хранения биржевых данных ( Read more... )

stockdb, erlang

Leave a comment

Comments 53

antilamer August 29 2012, 17:04:56 UTC
Ты мог бы поподробнее рассказать про требования? Я, например, со стоками никогда не имел дела, но я заинтригован.

У тебя одна поясняющая строчка для невеж вроде меня - "Они представляют из себя список пар (цена,объём) одинаковой длины, приходящий до нескольких раз в секунду. Длина списка составляет от 2 до 40 элементов." - этого недостаточно :)

Reply

levgem August 29 2012, 17:30:58 UTC
Давай подетальнее расскажу.

По сети приходит пакет, в котором (условно) закодированы такие штуки:

{market_data, Stock, Timestamp, Bid = [{Price1,Volume1},{Price2,Volume2},...], Ask = [{Price1,Volume1},{Price2,Volume2}]}

Bid - это те предложения участников рынка, по которым они готовы купить инструмент.
Ask - это предложения участников рынка, по которым они готовы продать.

Bid всегда (за исключением мутных случаев) больше чем Ask.

Эта штука называется стакан.

Соответственно строчку представляем в таком виде:

[Timestamp, BidPrice1*100,BidVolume1,BidPrice2*100,BidVolume2,...AskPrice1*100,BidVolume2,...]

Задача сводится к упаковке такой строки.

<<0:1,0:1, BitFlags:N/bitstring,TimestampDelta/binary,Delta1/binary, Delta2/binary,... >>

Так попонятнее?

Reply

antilamer August 29 2012, 17:38:18 UTC
Итак: для каждого значения Stock надо хранить упорядоченный по Timestamp список рядов вида (Bid, Ask) где Bid и Ask - списки пар (price:num,volume:num) произвольной длины - но в пределах одного Stock длина всех Bid одинаковая и длина всех Ask тоже.

Выигрыш в хранении достигается за счет того, что списки Bid и списки Ask обладают локальностью, т.е. многие элементы списка совпадают у соседних timestamps.

Правильно?

И еще вопрос - какого рода запросы делаются?

Reply

levgem August 29 2012, 17:41:02 UTC
Совершенно верно.

Запросы такие:
1) создать курсор, перебрать последовательно все элементы
2) получить информацию о том, когда писалось, когда нет
3) получить курсор из п1, но ограниченный по времени
4) построить свечку, т.е. за период берется цена открытия, закрытия, максимальная, минимальная что бы отобразить график.

Reply


sgdreamer7 August 29 2012, 17:57:38 UTC
Для levgem - вот мой репозиторий для хранилища временных последовательностей:

https://github.com/sgdreamer7/tss

Reply


antilamer August 29 2012, 18:06:50 UTC
См. тж. TempoDB, кстати. Но они более узкие и технология не открытая.

Reply

lionet August 29 2012, 19:17:37 UTC
OpenTSDB есть ещё.

Reply

levgem August 29 2012, 19:20:29 UTC
Если честно, то я не понял, как её приделать. Ну и морочиться в джавой хочется меньше всего.

Reply

lionet August 29 2012, 19:24:09 UTC
Зато у тебя данные надёжно лежат, а не на одной машине. Ну это я так.

Reply


ext_154663 August 29 2012, 21:44:44 UTC
зачем такое извращение с сжатием, почему недостаточно блочного gzip?

Reply

levgem August 29 2012, 21:45:55 UTC
Что бы была возможность по строчке добавлять в конец файла.

Reply

ext_154663 August 29 2012, 21:49:09 UTC
а последний блок оставить несжатым, например ?

Reply

levgem August 29 2012, 21:51:29 UTC
Значит перезаписывать файл. Значит иметь нехреновый шанс разломать вообще всё.

Не, нафиг. У нас весь контент append only, только индекс апдейтим. gzip означает огромный рост сложности вместе с необходимостью на каждом шагу думать: а вдруг выключат компьютер!

Reply


dlebedev8 August 30 2012, 04:11:23 UTC
Неплохо, совсем неплохо. Единственное, что смущает, это очень уж узкая заточенность.

Reply

levgem August 30 2012, 05:59:57 UTC
В смысле, узкая заточенность?

Reply


Leave a comment

Up