Лучшее хранилище данных с полнотекстовым поиском для множества мелких документов?(например, Splunk-подобная система)

Question

Мы определяем систему, которая будет индексировать и хранить миллионы сообщений Syslog. Это текстовые сообщения с несколькими атрибутами (имя системы, дата / время, тип сообщения, тело сообщения), которые обычно имеют размер от 100 до 1500 байт каждое.

Мы генерируем от 2 до 10 ГБ этих сообщений в день, и нам нужно хранить их не менее 30 дней.

Система Spunk имеет действительно великолепную систему индексации и сжатия документов.

Что использовать?

Я подумал о mongodb, но он кажется неуместным для документов такого маленького размера.

SQL Server возможен, но, возможно, не очень эффективен для этой цели.

Текстовые файлы с lucene? - Файловая система Windows не всегда любит директории с миллионами файлов

Предложения?

Спасибо!

Answer 1

Я думал о mongodb, но он кажется неуместным для документов такого маленького размера

Есть компания под названием Boxed Ice , которая на самом деле строит систему мониторинга серверов с использованием MongoDB. Я бы сказал, что это определенно уместно.

Это текстовые сообщения с несколькими атрибутами (имя системы, дата / время, тип сообщения, тело сообщения), которые обычно имеют размер от 100 до 1500 байтов каждое.

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

1. Может беспрепятственно обрабатывать изменения атрибутов.
2. Он будет гибко обрабатывать различные типы.

Мы генерируем от 2 до 10 ГБ этих сообщений в день, и нам нужно хранить их не менее 30 дней.

Это вполне соответствует типу диапазона данных, который может обрабатывать MongoDB. Существует несколько различных методов обработки 30-дневных периодов хранения. Это будет зависеть от ваших потребностей в отчетности. Я бы покопался в группах для идей здесь.

Основанный на людях, с которыми я работал, этот тип ведения тяжелой записи является одним из мест, где Mongo, как правило, очень хорошо подходит.

Answer 2

Похоже, вы захотите что-то наподобие сервера полнотекстового поиска mongodb, который позволит вам выполнять поиск по различным атрибутам без потери производительности.Вы можете попробовать MongoLantern: http://sourceforge.net/projects/mongolantern/. Хотя он находится в альфа-стадии, но дает мне наилучший результат для записей 5M.

Дайте мне знать, служит ли это вашей цели.

Answer 3

Graylog2 - это инструмент управления журналами с открытым исходным кодом, который построен на основе MongoDB. Я полагаю, что Loggy, поставщик услуг регистрации, также использует MongoDB в качестве своего внутреннего хранилища. Так что есть несколько продуктов, использующих MongoDB для регистрации.

Должна быть возможность хранить нграммы, возвращаемые анализатором Lucene, для лучшего поиска текста. Не уверен насчет осуществимости, хотя учитывая большое количество документов. Что такое основной вариант использования отчетности?

Answer 4

Я думаю, что вам следует развернуть свой собственный (для всей интрасети) стек Grafana, Logstash + ElasticSearch

При установке, когда у вас есть схема flexibel, сохранение и прекрасный интерфейс для ваших данных с Grafana.*

Answer 5

Я бы настоятельно рекомендовал использовать что-то Lucene или Solr .

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

Они не хранят файл для каждой записи, поэтому вам не нужно сильно беспокоиться о миллионах файлов.

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