Какая база данных наиболее эффективна для простых групп по запросам на тоннах данных?

Question

Для каждой учетной записи у меня есть миллионы элементов данных (строк в журналах аналитики), каждый с 20-50 числовыми свойствами (они тоже могут быть нулевыми).Мне нужно показать им статистику, которая в основном включает такие запросы, как SELECT SUM(f1), f2, f3 WHERE f4>f5 GROUP BY f2, f3.Функции агрегирования иногда более сложны, чем SUM (), а GROUP BY иногда включает простые функции, такие как ROUND ().Проблема заключается в том, что такие запросы встроены в пользовательский интерфейс и могут выполняться с любой комбинацией этих свойств (хотя, конечно, существуют и некоторые популярные комбинации).

Попав в базу данных, данные, скорее всего, не будутбыть изменены, только читать.Должна быть возможность легко добавлять / удалять свойства - не обязательно в реальном времени в терминах базы данных, но это не должно требовать полных блоков таблиц, как в MySQL.

Какие базы данных SQL или NoSQL будут лучше всего обрабатывать запросы такого типа?Я думал о PostgreSQL или MongoDB, хотя в последнем мне, скорее всего, придется использовать MapReduce, а не функцию Group из-за его ограничений.

Есть еще какие-нибудь советы по выполнению таких запросов?Возможно ли это сделать вообще, или мне абсолютно необходимо попросить пользователей заранее определить, какие именно запросы они хотят выполнить?

Любые идеи будут высоко оценены.

Answer 1

Вы можете создать приложение такого типа в СУБД или в базе данных NoSQL (например, Berkeley DB , имеет как API пары ключ-значение, так и API SQL). API пары ключ-значение является хорошим вариантом, поскольку он поддерживает некоторые довольно низкоуровневые оптимизации, которые могут помочь при взгляде на то, как настроить производительность в соответствии с потребностями вашего приложения.

Другой вариант - заглянуть в хранилище столбчатых данных, но даже продукт такого типа должен будет извлекать данные из нескольких столбцов (что медленно в таких базах данных), чтобы разрешать типы запросов, которые вы список.

В конечном итоге проблема сводится к кешу дискового ввода-вывода и организации данных. Чем больше данных вы можете поместить в память, тем меньше операций ввода-вывода вам придется выполнять, и это приведет к снижению производительности. Чем компактнее вы можете сделать данные, тем больше строк уместится в вашей памяти. Я бы посоветовал заглянуть в Berkeley DB, особенно API пары ключ-значение. Затем вы можете создать одну или несколько таблиц со свойствами, организованными таким образом, чтобы оптимизировать наиболее частые виды доступа. Кроме того, если вы используете API пары ключ-значение, обратите внимание на функции группового получения - это позволяет вам извлекать и обрабатывать целые группы записей одновременно.

Возможно, вы также захотите создать и поддерживать некоторые «хорошо известные» статистические результаты (в памяти и / или сохраненные на диске), которые позволяют вам использовать «горячие клавиши», когда пользователь запрашивает значение, которое уже было вычислено.

Удачи в ваших исследованиях.

Answer 2

То, что вы описали - по сути, специальные агрегированные запросы к данным, которые не обязательно должны быть в реальном времени - это то, что решения OLAP очень хороши.В дополнение к другим предложениям, которые вы видели, вам следует выяснить, имеет ли для вас смысл решение OLAP.

Answer 3

Какую производительность запросов вы ищете?Как часто он будет запрашиваться?

Если вы в порядке с быстродействием запросов в низкие минуты и у вас такая же низкая частота запросов, то вы можете использовать реляционную таблицу с основной таблицей для элементов данных, итаблица соединений для свойств.Обязательно поместите комбинированный индекс во вторую таблицу комбинации (property_type, data_item_id, property_value), чтобы гарантировать хорошую производительность запроса.На самом деле вам не нужно указывать значение свойства_значения, но если оно у вас есть, тогда запросы могут извлекать свои данные из индекса высокоэффективным способом, что значительно упрощает объединения.Вы можете сделать это с любой реляционной базой данных.Мне нравится PostgreSQL, но MySQL также может работать.(Но менее эффективно для сложных запросов.)

Если вы следуете этой стратегии, то для каждого свойства, которое вы хотите, потребуется добавить еще одно объединение.Но соединения будут довольно эффективными.