механизм хранения: как быстро найти, что ключ не существует

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

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

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

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

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


distributed-system memcached rocksdb leveldb distributed-caching
person Tongxuan Liu    schedule 11.04.2016    source источник
comment
Возможно, вы хотите записывать доступ пользователя в день. Если это так, то вы можете скрыть, что этот ключ не существует, чтобы ключ существовал, но значение не содержало указанный элемент.   -  person sel-fish    schedule 13.04.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

person sel-fish    schedule 11.04.2016
comment
Спасибо рекомендации. Для первого решения это невозможно, потому что наши ключи генерируются каждый день (ключ = идентификатор пользователя + дата), невозможно пометить все ключи как ложные. Для второго решения кеш таблиц не может помочь, потому что мы не можем найти из кеша таблиц все еще нужно запрашивать ввод-вывод; размер блока мало поможет также потому, что существует ложное срабатывание фильтра Блума, увеличение размера блока только увеличивает количество ключей, что означает меньшее количество блоков поиска, но меня беспокоит то, что есть какие-либо способы значительно избежать доступа к вводу-выводу. - person Tongxuan Liu; 12.04.2016
comment
Я не могу найти лучшую идею в этой архитектуре. На самом деле, если я столкнусь с таким сценарием, я просто буду использовать систему кэширования RAM, которая может выдержать одиночный сбой и предоставить достаточно места для хранения. - person sel-fish; 13.04.2016