Действительно ли документные базы данных хороши для хранения большого объема Тиковых данных Запаса? [закрытый]
3 ответа
Здесь ответ будет зависят от объема.
MongoDB - отличный способ получить данные «вовнутрь», и он очень быстро запрашивает отдельные части. Это также приятно, поскольку он построен для горизонтального масштабирования.
Однако вы должны помнить, что все ваши важные «запросы» на самом деле будут результатом «вывода пакетного задания».
Например, Gilt Groupe создала систему под названием Hummingbird , которую они используют для аналитики в реальном времени на своем веб-сайте. Презентация здесь . По сути, они динамически отрисовывают страницы на основе собранных данных о производительности с небольшими интервалами (15 минут).
В их случае у них есть простой цикл: отправить данные в mongo -> запустить map-reduce -> отправить данные в веб для оптимизации в реальном времени -> промыть / повторить.
Честно говоря, это довольно близко к тому, чем вы, вероятно, хотите заниматься. Однако здесь есть некоторые ограничения:
- Map-reduce впервые для многих. Если вы знакомы с SQL, вам придется принять кривую обучения Map-reduce.
- Если вы накачиваете много данных, ваши сокращения карты будут медленнее на этих блоках. Вы, вероятно, захотите взглянуть на пары подчиненный / реплика, если время отклика имеет большое значение.
С другой стороны, вы столкнетесь с различными вариантами этих проблем с SQL.
Конечно, здесь есть некоторые преимущества:
- Горизонтальная масштабируемость. Если у вас много ящиков, вы можете разделить их на части и получить несколько линейное повышение производительности на заданиях Map / Reduce (вот как они работают). Построение такого «кластера» с базами данных SQL намного дороже и дороже.
- Действительно высокая скорость, и, как и в пункте №1, вы получаете возможность добавлять ОЗУ по горизонтали, чтобы поддерживать скорость.
Однако, как упоминалось другими, вы потеряете доступ к ETL и другим распространенным инструментам анализа. Вы определенно будете готовы написать множество собственных инструментов анализа.
Вот моя оговорка с идеей - и я собираюсь открыто признать, что мои практические знания о базах данных документов слабы. Я предполагаю, что вы хотите, чтобы все эти данные хранились, чтобы вы могли выполнять на их основе агрегирование или анализ тенденций.
Если вы используете базу данных на основе документа в качестве источника, загрузка и управление каждой строкой данных (операции CRUD) очень просты. Очень эффективный, очень простой, в основном прекрасный.
Что отстой, так это то, что существует очень мало вариантов, если они вообще есть, для извлечения этих данных и их втискивания в структуру, более подходящую для статистического анализа, например столбчатая база данных или куб. Если вы загрузите его в базовую реляционную базу данных, появится множество инструментов, как коммерческих, так и с открытым исходным кодом, таких как pentaho , которые очень хорошо приспособят ETL и анализ.
Однако, в конечном счете, вы хотите иметь в виду, что каждая финансовая компания в мире имеет приложение для анализа акций / автотрейдера; они только что вызвали серьезный обвал фондового рынка США, и они не игрушки. :)
Простое хранилище данных, такое как база данных «ключ-значение» или база данных документов, также полезно в случаях, когда выполнение аналитики значительно превышает возможности отдельной системы. (Или потребуется исключительно большая машина для обработки нагрузки.) В этих случаях имеет смысл использовать простое хранилище, поскольку аналитика в любом случае требует пакетной обработки. Я бы лично посмотрел на поиск метода обработки с горизонтальным масштабированием, чтобы получить необходимую аналитику единиц / времени.
Я бы хотел изучить возможность использования чего-то, построенного на Hadoop для параллельной обработки. Либо используйте фреймворк изначально на Java / C ++, либо какую-либо абстракцию более высокого уровня: Pig, Wukong, двоичные исполняемые файлы через потоковый интерфейс и т. Д. Amazon предлагает достаточно дешевое время обработки и хранилище, если этот маршрут представляет интерес. (У меня нет личного опыта, но многие используют его в своем бизнесе и зависят от него.)