Эффективный поиск по убыванию времени создания в Raik

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

Поиск на основе ключа в Riak позволяет напрямую идентифицировать разделы, содержащие данные, и координирующий узел может напрямую запрашивать эти разделы. При запросе дополнительного индекса Riak не знает, в каких разделах данные который может соответствовать индексу, будет находиться. Поэтому потребуется отправить запрос в большое количество разделов, чтобы убедиться, что все соответствующие объекты могут быть найдены. Это известно как «запрос покрытия» и означает, что при условии, что n_val, равное 3, используется для корзины, необходимо запросить как минимум 1/3 всех разделов. Как правило, это приводит к более высокой нагрузке на кластер и не масштабируется так же хорошо, как прямой поиск ключей. Задержки также имеют тенденцию быть выше.

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

Если ваши сообщения/сообщения можно как-то сгруппировать, например. пользователем или разговором, может иметь смысл хранить их в одном объекте, представляющем эту группу, а не в виде отдельных объектов.

Если предположить, что ваши сообщения могут состоять из текста или изображений и связаны с веткой беседы, вы можете создать объект, представляющий ветку беседы. Это будет содержать информацию о разговоре, а также список сообщений. Этот список сообщений может, например. содержат идентификатор постера, отметку времени и ключ записи, содержащей пост. Если пост представляет собой достаточно короткое текстовое сообщение, он может даже содержать весь пост, уменьшая количество записей, которые необходимо будет извлечь.

По мере поступления сообщений в этот разговор запись обновляется, а список сообщений увеличивается. Может быть целесообразно установить для allow_mult значение true, чтобы включить братьев и сестер, так как это позволит вам обрабатывать параллельные записи. Этот подход позволяет вам всегда получать разговор, а также последние сообщения с помощью единого прямого поиска по ключу.

Riak работает лучше всего, когда размер объектов не превышает пару МБ. Поэтому в какой-то момент вам нужно будет переместить самые старые сообщения в отдельный объект, чтобы контролировать размер. Если вы храните список этих связанных объектов в основном объекте беседы, возможно, вместе с некоторой информацией об интервале времени, который они охватывают, вы также можете легко получить к ним доступ с помощью прямого поиска по ключу, если вам нужно прокрутить старые сообщения.

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

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

Я знаю, что, вероятно, уже слишком поздно, чтобы помочь вам, но я нашел этот пост, задаваясь вопросом о том же. Обходной путь, который я придумал и успешно использовал, заключается в создании двух вторичных индексов, один с реальной меткой времени, а другой (MAX_DATE - метка времени). Выполнение поиска по первому запросу дает восходящие результаты, а выполнение поиска по второму запросу — нисходящие результаты (после того, как вы выполните математические операции, чтобы превратить его обратно в реальную дату). Максимальное значение даты можно найти в спецификации Javascript, например, в MDN, то есть 8640000000000000. Я не могу сказать, насколько он эффективен при очень большой нагрузке, но могу сказать вам, что для моих целей он был невероятно быстрым, и я очень доволен. Я просто пришел сюда в надежде найти менее хакерский способ сделать это.