Какова лучшая технология базы данных для хранения исторических цен OHLC? - PullRequest
4 голосов
/ 22 ноября 2010

Только для данных на конец дня будет миллиарды строк. Каков наилучший способ хранить все эти данные. SQL Server 2008 достаточно хорош для этого или я должен смотреть на решение NoSQL, как MongoDB. Есть предложения?

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

Эти данные затем будут передаваться в торговую платформу на компьютерах клиентов.

Ответы [ 2 ]

4 голосов
/ 13 февраля 2011

Вы должны рассмотреть Oracle Berkeley DB , который находится в производстве и делает это в рамках инфраструктуры нескольких известных бирж.Berkeley DB позволит вам записывать информацию на ведущем устройстве в виде простых пар ключ / значение, в вашем случае я бы представил временную метку для ключа и закодированный OHLC-набор для значения.Berkeley DB поддерживает репликацию одной главной реплики с несколькими репликами (называемую «HA» для высокой доступности), чтобы поддерживать именно то, что вы обрисовали в общих чертах - масштабируемость чтения.Berkeley DB HA автоматически переключится на новый мастер, если / когда это необходимо.Используя простое сжатие и другие базовые функции Berkeley DB, вы сможете достичь своих целей масштабируемости и объема данных (миллиарды строк, десятки тысяч транзакций в секунду - в зависимости от вашего оборудования, ОС и конфигурации BDB - см. 3n + 1 тест с BDB для справки) без проблем.

Когда вы начинаете работать с доступом к этим данным OHLC, рассмотрите поддержку Berkeley DB для массового получения и убедитесь, что вы используете B-Метод доступа к дереву (поскольку ваши данные имеют порядок и локальность, что обеспечит гораздо более быстрый доступ).Также рассмотрите API разделения Berkeley DB для разделения ваших данных (возможно, на основе символов или даже на основе времени).Наконец, поскольку вы будете реплицировать данные, вы можете ослабить ограничения долговечности до DB_TXN_WRITE_NOSYNC, если ваша политика подтверждения репликации требует кворума репликов ACK на запись, прежде чем считать его долговечным.В этом случае вы обнаружите, что быстрая сеть превосходит быстрый диск.Кроме того, чтобы разгрузить некоторую работу от вашего мастера, включите одноранговое распределение реплик журнала.

Но сначала прочтите руководство по началу работы с диспетчером репликации и просмотрите пример цитаты представителя - которыйуже реализует кое-что из того, что вы пытаетесь сделать (удобно, а?).

Просто для сведения, полное раскрытие информации Я работаю менеджером по продуктам в Oracle по продуктам Berkeley DB.Я в течение последних девяти лет, поэтому я немного предвзятый.Я предполагаю, что другие решения - основанные на SQL или нет - могут в конечном итоге дать вам работающую систему, но я уверен, что Berkeley DB сможет без особых усилий.


0 голосов
/ 22 ноября 2010

Если вы действительно говорите миллиардов новых строк в день (хранилище данных Federal Express не так уж велико), то вам нужна база данных SQL, которая может распределяться по нескольким компьютерам, таким как Oracle илиIBM DB2.

Другой альтернативой может быть управляемое хранилище для тяжелых систем, такое как IBM DFSMS .

.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...