Хорошее хранилище данных для миллионов событий?

Question

У нас есть несколько систем, которые ежедневно генерируют около 5 миллионов событий.В настоящее время мы сохраняем их в течение примерно 10 дней на общую сумму около 40-50 миллионов событий.В настоящее время мы используем СУБД в качестве слоя персистентности, к которому подключен веб-интерфейс, но у нас возникают определенные проблемы с производительностью.

Событие состоит из 20-30 полей, состоящих из следующих элементов:

• поля, представляющие само событие (например, OrderReceived)
• поля, представляющие систему, которая сгенерировала событие (например, система ERP)
• поля, представляющие бизнес-контекст, в котором событие былосгенерированные (например, OrderManagement)
• поля, представляющие другие подробности, которые мы считаем важными / важными

Примерно 5-6 полей являются идентификаторами, большинство из которых уникальны и представляют само событие,бизнес-объект / объект, контекст и тому подобное.Используя эти идентификаторы, мы также можем связывать события друг с другом, связывая их вместе.Разница во времени в цепочке событий может составлять часы или в редких случаях даже дни.

В настоящее время мы используем решение для анализа отдельных цепочек событий, в основном для анализа ошибок и выбросов (куда делся мой заказ?).В будущем мы также можем собирать статистику о событиях и цепочках событий (сколько заказов в день? Сколько заказов обрабатывается системой X?).Если возможно, решение также должно быть способно увеличиваться, по крайней мере, вдвое по сравнению с текущим размером (мы прогнозируем увеличение количества событий при включении новых систем).Сегодня анализ выполняется людьми, поэтому поиск должен быть терпимым (поиск цепочки событий должен занимать секунды, а не минуты).Хранилище данных также должно разрешать очистку устаревших событий.

Как уже упоминалось в начале, для этого мы используем стандартную СУБД.Мы использовали довольно нормализованную структуру, которую сейчас начали денормализовать, чтобы попытаться повысить производительность.Я не могу не задаться вопросом, может ли какое-то другое решение быть лучше, хотя.Я начал изучать разные базы данных NoSQL (и, по моему мнению, MongoDB выглядит многообещающе), но также пытался собрать информацию о поисковых системах и тому подобное (например, Solr и ElasticSearch).

Вопрос в том, какой типхранилище данных / решение было бы хорошо подходит для этих событий?Должны ли мы отправиться в пространство NoSQL, возможно, нам нужен поисковый движок, или мы лаем неправильное дерево, когда нам действительно нужно найти кого-то, кто действительно хорош в оптимизации СУБД: s?

Answer 1

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

Бэкэнд SQL сохраняет ваши параметры открытыми на будущее (OLAP ?? и т. Д.), А также предоставляет стандартный, масштабируемый и многопользовательский способ приема данных измир через библиотеки dbconnection и пользовательский интерфейс.Короче говоря, если ваши данные хранятся в SQL, вы не можете быть потеряны ...

Уровень Lucene обеспечивает исключительную производительность запросов, если его возможностей достаточно.(В двух словах: поиск значений поля по числам, датам, строкам и т. Д., Поиск по диапазону, поиск по нескольким значениям поля (фактически поле является массивом), все с логическими операторами и логическими двоичными выражениями, сортировка и разбиение на страницы. ОДНАКО!группировки и сумма, средние и т. д. агрегирующие функции).

ОБНОВЛЕНИЕ: прошло несколько лет.Solr теперь обладает статистическими возможностями, такими как sum, avg и т. Д. *

Производительность запроса: в базе данных элементов 100M выбор пары сотен элементов с предикатом многополюсного запроса меньше 100 мс.

ЗаполнениеИндекс занимает постоянное время (без увеличения по размеру) из-за внутренней реализации splitfile.Можно создать 5-миллионный индекс строк за минуты, 20 вершин, в зависимости, в основном, от вашего контроллера хранения.Однако Lucence поддерживает обновление индекса в реальном времени, что мы успешно использовали на сайтах с высокой нагрузкой.

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

Эта архитектура может быть реализована без особых усилий в Java и .NET, и в ней есть отличная поддержка SQL и Lucene