Бесплатное хранилище данных - Infobright, Hadoop / Hive или что? - PullRequest
5 голосов
/ 11 марта 2010

Мне нужно хранить большое количество небольших объектов данных (миллионы строк в месяц). Как только они спасены, они не изменятся. Мне нужно:

  • надежно храните их
  • использовать их для анализа (в основном ориентированных на время)
  • иногда извлекает необработанные данные
  • Было бы неплохо, если бы его можно было использовать с JasperReports или BIRT

Моим первым выстрелом был Infobright Community - просто ориентированный на столбцы механизм хранения только для чтения для MySQL

С другой стороны, люди говорят, что NoSQL-подход мог бы быть лучше. Hadoop + Hive выглядит многообещающе, но документация выглядит плохо и номер версии меньше 1.0.

Я слышал о Hypertable, Pentaho, MongoDB ....

Есть ли у вас какие-либо рекомендации?

(Да, я нашел некоторые темы здесь, но это было год или два назад)

Edit: Другие решения: MonetDB, InfiniDB, LucidDB - что вы думаете?

Ответы [ 3 ]

3 голосов
/ 06 мая 2011

У меня возникла та же проблема, и я провел исследования; Два типа хранилищ для БИ:

  • ориентированный на столбцы. Свободно и известно: monetDB, LucidDb, Infobright. InfiniDB
  • Распределено: hTable, Cassandra (также теоретически ориентировано на столбцы)
  • Ориентированный на документ / MongoDb, CouchDB

Ответ зависит от того, что вам действительно нужно:

  • Если ваши миллионы строк загружаются за один раз (почти в одном пакете или около того), InfiniDB или другая столбцово-ориентированная БД являются лучшими; Они имеют отличную производительность и ориентированы на BI. http://www.d1solutions.ch/papers/d1_2010_hauenstein_real_life_performance_database.pdf И им не потребуется настройка «узлов», «шардинга» и других вещей, которые поставляются с распределенными / «NoSQL» БД.

http://www.mysqlperformanceblog.com/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/

  • Если строки добавляются в режиме реального времени .. тогда БД, ориентированные на столбцы, плохие. Вы можете выбрать два с двумя отдельными БД (это мой выбор: один noSQL для реальной подачи статистики фронтом и статистики в реальном времени. Другой БД, ориентированный на столбцы для BI). Или поверните к чему-то, что смешивает ориентированные на столбцы (для запросов) и распределения (для записей) / как Cassandra.

Документно-ориентированные БД не подходят для BI, они более полезны для проблем CRM / CMS, когда вам необходим частый доступ к определенной строке

Что касается точного выбора внутри категории, я все еще не определился. Кассандра в распределении, и Моне или InfiniDB для CODB, являются лидерами. Сообщается, что у Моне проблемы с загрузкой очень больших таблиц, потому что он запускает индексы в памяти.

2 голосов
/ 18 марта 2010

Вы также можете рассмотреть GridSQL. Даже для одного сервера вы можете создать несколько логических «узлов» для использования нескольких ядер при обработке запросов.

GridSQL использует PostgreSQL, поэтому вы также можете использовать преимущества разделения таблиц на подтаблицы для более быстрой оценки запросов. Вы упомянули, что данные ориентированы на время, поэтому это хороший кандидат для создания подтаблиц.

0 голосов
/ 12 марта 2010

Если вы ищете совместимость с инструментами отчетности, то что-то на основе MySQL может быть вашим лучшим выбором. Что касается того, что будет работать для вас, Infobright может работать. Есть также несколько других решений, однако вы можете также взглянуть на старый MySQL и таблицу Archive. Каждая запись сжимается и сохраняется, и, IIRC, она разработана для вашего типа рабочей нагрузки, однако я думаю, что Infobright должен получить лучшее сжатие. Я тоже на самом деле не использовал, так что я не уверен, что будет работать лучше для вас.

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

Моя единственная проблема с вашим набором данных заключается в том, что, поскольку вы упомянули время, вы можете убедиться, что любое используемое вами решение позволит вам архивировать данные за определенное время. Обычная практика хранения данных - хранить только N месяцев данных в сети и архивировать остальные. Вот где разделение, реализованное в СУБД, оказывается очень полезным.

...