1

Наш распределенный проект хранения с использованием LevelDB в качестве механизма хранения и memcached в качестве уровня кэша, у нас есть один сценарий: 95% запросов с ключами не существует в движке хранения.хранилище двигателя: как быстро найти этот ключ не существует

В слое memcached, если не удается найти ключ, затем запросите LevelDB.

В LevelDB мы используем фильтр цветения по умолчанию, чтобы выяснить, существует или нет ключ, но все еще имеют 1% ложноположительную скорость. Из-за 1% -ного процента мы должны запрашивать стоимость через IO, что не может быть терпимо к клиенту. (95% ключей не существует)

Есть ли лучшее решение узнать, существует ли ключ?

Обновление: 1. Ключи генерируются каждый день (userid + date), один раз не может получить ключ, а затем клиент будет помещать значение в уровень хранения. 2. Клиент хотите прочитать латентность (TP99) < х мс (клиент чувствительных к задержкам)

+0

Возможно, вы хотите записать доступ пользователей в день. Если это так, то вы можете скрывать эту проблему «ключ не существует», чтобы «ключ существовал, но значение не содержит указанный элемент». –

ответ

1

Я думаю, что есть два способа, которые могут быть использованы для улучшения вашего решения:
1. Предположим, что все ключи, которые могут запросить находятся в ограниченном наборе. Возможно, вы можете поместить все ключи в набор, те, которые не существуют со значением типа «FALSE».
2. улучшите производительность leveldb. отрегулируйте размер кеша таблицы и размер блока или используйте ssd в качестве носителя.
Мы используем leveldb как постоянное хранилище kv в продуктивной среде и поддерживаем такие приложения, как черный список, который похож на ваш сценарий.

+0

Спасибо за рекомендации. Для первого решения это невозможно сделать, потому что наши ключи генерируются каждый день (key = userid + date), невозможно пометить все ключи false. Для второго решения кеш таблицы не может помочь, потому что мы не можем найти из кэша таблицы, все еще нужно запросить IO; размер блока мало помог бы и потому, что там был установлен ложный положительный фильтр цветения, увеличение размера блока только увеличивает количество ключей, что означает меньше блоков поиска, но я беспокоюсь, что есть какие-то способы значительно избежать доступа к IO. –

+0

Я не могу понять лучшую идею под этой архитектурой. На самом деле, если я столкнулся с таким сценарием, я просто использую систему кэширования ОЗУ, которая может терпеть один отказ и обеспечивать достаточное количество хранилища. –

 Смежные вопросы

  • Нет связанных вопросов^_^