Выбор бэкэнда Riak: bitcask vs leveldb

Question

Я планирую использовать Riak в качестве бэкэнд для службы, которая хранит данные сеанса пользователя. Основной ключ, используемый для извлечения данных (двоичный blob), называется UUID и фактически является uuid, но иногда данные могут быть получены с использованием одного или двух других ключей (например, электронной почты пользователя).

Естественным вариантом было бы выбрать бэкэнд leveldb с возможностью использования вторичных индексов для такого сценария, но поскольку вторичный поиск индекса не очень распространен (около 10% - 20% запросов), мне было интересно, не будет ли это лучше иметь отдельный ведро индексов, где будет храниться такое сопоставление email-> uuid.

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

Зная, что биткаска гораздо более предсказуема, когда дело доходит до латентности и, возможно, быстрее, вы бы рекомендовали такую ​​конструкцию, или я должен придерживаться leveldb и вторичных индексов?

Answer 1

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

Если вы идете по этому пути, вам придется очистить ведро метаданных (в eleveldb), которое вы используете для вторичных индексов. Это можно сделать легко, также имея индекс последней модификации ключей метаданных. Затем вы запускаете пакет для выполнения запроса 2i для извлечения старых метаданных и их удаления. Убедитесь, что вы используете новейший Riak, который поддерживает агрессивное удаление и восстановление дискового пространства в leveldb.

Сказанное, может быть, вы можете иметь все в биткаске и вообще избегать вторичных индексов. Рассмотрим конструкцию данных:

один «данные» ковшеобразные: ключи UUID, значение сеанса один «mapping_email» ведро: ключи электронной почты, значения UUID один «mapping_otherstuff» ведро: то же самое для других свойств

Это прекрасно работает, если:

• большую часть времени вы позволяете данные истекают. Это означает, что у вас нет бухгалтерии, чтобы делать
• у вас нет слишком большого количества картографических данных, так как это громоздко, чтобы добавить больше
• вы готовы правильно реализовать клиентскую библиотеку, которая будет управлять 3-мя ковшими, например, при создании/обновлении/удаление новых значений

Вы можете начать с этого, потому что это проще при администрировании, бухгалтерском учете, создании пакетов (нет) и производительности (вторичные запросы индекса могут быть дорогими).

Затем, если вам нужно, вы можете добавить маршрут leveldb. Убедитесь, что вы используете multi_backend с самого начала.