Я не думаю, что есть какая-либо СУБД, которая будет делать то, что вы хотите, и позволит использовать готовый инструмент отчетности. Аналитические системы с малой задержкой не быстры и просты в создании. Низкая задержка неструктурированных данных довольно амбициозна.
Вы должны будете сохранить данные в какой-то базе данных.
Я думаю, что вам, возможно, придется присмотреться к вашей проблемной области. Пытаетесь ли вы создавать аналитические отчеты с низкой задержкой или оперативный отчет, который побуждает к каким-либо действиям в бизнесе при возникновении определенных событий? Для систем с малой задержкой вы должны быть совершенно безжалостны в отношении того, что составляет операционную отчетность, а что составляет аналитику.
Редактировать: Обескуражить «потенциально оба» мышления, если бизнес не готовы платить. Инвестиционные банки и хедж-фонды тратят большие деньги и покупают суперкомпьютеры для проведения «аналитики в реальном времени». Это не тривиальное начинание. Это даже менее тривиально, когда вы пытаетесь создать такую систему и собрать ее для больших простоев.
Даже в таких приложениях, как SMS-сервисы премиум-класса и .com-приложения, бизнес часто отступает, когда вы анализируете проблему в реалистичном объеме и по стоимости. Я не могу сказать этого достаточно. Будьте действительно, действительно безжалостными о требованиях в режиме реального времени.
Если бизнес действительно нуждается в аналитике в реальном времени, то вы можете создать гибридную архитектуру OLAP, в которой у вас есть шаг впереди в таблице фактов. Это архитектура, в которой таблица фактов или куб полностью индексируются для исторических данных, но имеют небольшой начальный раздел, который не индексируется и, следовательно, относительно быстро вставляет данные.
Аналитические запросы будут сканировать таблицы относительно небольших ведущих разделов данных и использовать более эффективные методы в других разделах. Это дает вам данные с низкой задержкой и возможность выполнять эффективные аналитические запросы к историческим данным.
Ночной запуск процесса, который переносится на новый ведущий раздел и консолидирует / индексирует предыдущий ведущий раздел.
Это хорошо работает, когда у вас есть такие элементы, как растровые индексы (в базах данных) или материализованные агрегаты (в кубах), которые стоят дорого для вставок. Ведущий раздел сравнительно небольшой и дешевый для сканирования таблиц, но эффективен для вставки. Процесс пролонгации постепенно объединяет этот ведущий раздел в индексированные исторические данные, что позволяет эффективно запрашивать его для отчетов.
Редактировать 2: Общие поля могут быть кандидатами для настройки в качестве измерений в таблице фактов (например, вызывающая сторона, время). Менее распространенными полями являются (предположительно) кодирование. Для эффективной схемы вы можете переместить необязательное кодирование в одно или несколько «ненужных» измерений. .
Вкратце, измерение мусора - это измерение, представляющее каждую существующую комбинацию двух или более кодов. Строка в таблице относится не к одному объекту системы, а к уникальной комбинации кодирования. Каждая строка в таблице измерений соответствует определенной комбинации, встречающейся в необработанных данных.
Чтобы иметь какое-либо аналитическое значение, вам все равно придется упорядочить данные таким образом, чтобы столбцы в измерении нежелательной почты содержали нечто постоянно значимое. Это восходит к некоторым требованиям работы, чтобы убедиться, что сопоставления из исходных данных имеют смысл. Вы можете иметь дело с элементами, которые не всегда записываются, используя значение заполнителя, например строку нулевой длины (''), которая, вероятно, лучше, чем нули.