индексирование нескольких ключей для случайных запросов в различных комбинациях ключей - PullRequest
0 голосов
/ 08 февраля 2012

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

Что-то вроде журнала запросов, поэтому предположим, что у вас есть следующие поля для каждой записи:

customer_id
date
hostname
environment
pid
ip
user_agent
account_id
user_id
module
action
id
response code
response time (range)

и, возможно, еще немного.

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

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

Но проблема в том, что я не совсем уверен, как эффективно индексировать данные.

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

В настоящее время мы создаем прототип этого с помощью монго.Есть ли способ сделать это эффективно в монго (хранилище / процессор / стоимость)?

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

PS Я также открыт для предложений об альтернативах БД.

Ответы [ 2 ]

1 голос
/ 09 февраля 2012

Я думаю, ваши требования не очень хорошо сочетаются друг с другом.У вас не может быть много данных и мгновенных специальных запросов.

Если вы используете много индексов, тогда ваши записи будут медленными, и вам потребуется много больше оперативной памяти.

Могу ли я предложить следующее:

Сохраняйте свой индекс по идентификатору и дате клиента, чтобы предоставлять последние данные пользователям и смягчать ваши требования к своевременности или точности совокупных запросов.

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

Если вы жертвуете скоростью, то вы будете каждый раз запускать уменьшение карты (сейчас это единственный разумный способ).вычисления агрегатов в кластере mongodb).

Надеюсь, это поможет:)

1 голос
/ 08 февраля 2012

с этим ограниченным количеством полей, вы могли бы просто иметь индекс для каждого из них, или, возможно, в сочетании с customer_id. MongoDB достаточно умен, чтобы выбрать самый быстрый индекс для каждого случая. Если вы можете поместить весь свой набор данных в память (несколько ГБ - это не много данных!), То все это действительно не имеет значения.

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

веселит, Дерик

...