Подходят ли базы данных документов для хранения больших объемов данных Stock Tick?

Ответ здесь будет зависеть от масштаба.

MongoDB — отличный способ получить данные «внутри», и он очень быстро запрашивает отдельные фрагменты. Это также приятно, поскольку он построен для горизонтального масштабирования.

Однако вы должны помнить, что все ваши важные «запросы» на самом деле будут результатом «пакетного вывода заданий».

Например, Gilt Groupe создала систему под названием Hummingbird, которую они используют для аналитики в реальном времени на их веб-сайт. Презентация здесь. По сути, они динамически отображают страницы на основе собранных данных о производительности через короткие промежутки времени (15 минут).

В их случае у них есть простой цикл: отправить данные в монго -> запустить map-reduce -> отправить данные в сеть для оптимизации в реальном времени -> промыть/повторить.

Честно говоря, это довольно близко к тому, что вы, вероятно, хотите сделать. Однако здесь есть некоторые ограничения:

1. Map-reduce является новым для многих людей. Если вы знакомы с SQL, вам придется смириться с кривой обучения Map-reduce.
2. Если вы загружаете много данных, ваши карты будут медленнее работать с этими ящиками. Вы, вероятно, захотите взглянуть на пары ведомых / реплик, если время отклика имеет большое значение.

С другой стороны, вы столкнетесь с различными вариантами этих проблем с SQL.

Конечно, здесь есть некоторые преимущества:

1. Горизонтальная масштабируемость. Если у вас много ящиков, вы можете разбить их и получить линейное увеличение производительности в заданиях Map/Reduce (так они работают). Построение такого «кластера» с базами данных SQL намного дороже и дороже.
2. Действительно высокая скорость, и, как и в случае с пунктом № 1, вы получаете возможность добавлять оперативную память горизонтально, чтобы поддерживать скорость.

Однако, как упоминалось другими, вы потеряете доступ к ETL и другим распространенным инструментам анализа. Вы определенно будете на крючке, чтобы написать много собственных инструментов анализа.

С тех пор, как этот вопрос был задан в 2010 году, было выпущено несколько механизмов баз данных или были разработаны функции, которые специально обрабатывают временные ряды, такие как данные биржевых тиков:

• InfluxDB - см. мой другой ответ
• Кассандра

С MongoDB или другими базами данных, ориентированными на документы, если вы нацелены на производительность, рекомендуется исказите свою схему, чтобы упорядочить тики в объекте с секундами (или объекте минут, где каждая минута представляет собой другой объект с 60 секундами). Со специализированной базой данных временных рядов вы можете запросить данные просто с помощью

SELECT open, close FROM market_data
WHERE symbol = 'AAPL' AND time > '2016-09-14' AND time < '2016-09-21'

Я также думал, что могу суммировать/минимальные/максимальные строки данных по минутам/часам/дням/неделям/месяцам и т. д. для еще более быстрых вычислений.

С InfluxDB это очень просто. Вот как получить дневные минимумы и максимумы:

SELECT MIN("close"), MAX("close") FROM "market_data" WHERE WHERE symbol = 'AAPL'
GROUP BY time(1d)

Вы можете группировать по временным интервалам, которые могут быть в микросекундах (u), секундах (s), минутах (m), часах (h), днях (d) или неделях (w).

TL;DR

Базы данных временных рядов являются лучшим выбором, чем базы данных, ориентированные на документы, для хранения и запроса больших объемов биржевых данных.

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

Если вы используете базу данных на основе документов в качестве источника, загрузка и манипулирование каждой строкой данных (операции CRUD) очень просты. Очень эффективный, очень прямой, в основном прекрасный.

Что отстойно, так это то, что очень мало, если вообще есть, вариантов извлечения этих данных и втискивания их в структуру, более подходящую для статистического анализа, например. столбчатая база данных или куб. Если вы загрузите его в базовую реляционную базу данных, вы найдете множество инструментов, как коммерческих, так и с открытым исходным кодом, таких как pentaho, который очень хорошо подходит для ETL и анализа.

В конечном счете, вы должны иметь в виду, что каждая финансовая фирма в мире имеет приложение для анализа акций/автоматического трейдера; они только что вызвали сильное падение фондового рынка США, и они не игрушки. :)

Простое хранилище данных, такое как база данных «ключ-значение» или база данных документов, также полезно в тех случаях, когда выполнение аналитики разумно превышает возможности одной системы. (Или для обработки нагрузки потребуется исключительно большая машина.) В этих случаях имеет смысл использовать простое хранилище, поскольку аналитика в любом случае требует пакетной обработки. Я бы лично посмотрел на поиск метода обработки с горизонтальным масштабированием, чтобы придумать необходимую аналитику единиц/времени.

Я бы исследовал использование чего-то, построенного на Hadoop, для параллельной обработки. Либо используйте фреймворк изначально на Java/C++, либо какую-либо абстракцию более высокого уровня: Pig, Wukong, бинарные исполняемые файлы через потоковый интерфейс и т. д. Amazon предлагает достаточно дешевое время обработки и хранения, если этот маршрут представляет интерес. (У меня нет личного опыта, но многие делают это и зависят от него в своем бизнесе.)