Как вы обходите ограничения ключа / значения memcached?

Question

Memcached имеет ограничения по длине для ключей (250?) И значений (примерно 1 МБ), а также некоторые (насколько мне известно) не очень четко определенные ограничения символов для ключей. Какой, по вашему мнению, лучший способ обойти этих? Я использую Perl API Cache :: Memcached.

В настоящее время я сохраняю специальную строку для значения основного ключа, если исходное значение было слишком большим ("parts: "), и в этом случае я сохраняю частей с ключами с именем 1+ < main key>, 2+

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

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

Кто-нибудь придумал более элегантный способ или даже Perl API, который прозрачно обрабатывает произвольные размеры данных (и значения ключей)? Кто-нибудь взламывал сервер memcached для поддержки произвольных ключей / значений?

Answer 1

Сервер уже позволяет вам указать любой размер, который вы хотите:

-I            Override the size of each slab page. Adjusts max item size
              (default: 1mb, min: 1k, max: 128m)

Однако, в большинстве случаев, когда люди хотят кэшировать большие объекты, они делают что-то не так. Вам действительно нужно столько данных в одном ключе кэша? Несжатый

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

Это зависит от ваших потребностей, и я не могу сказать вам, что лучше для вас, не зная больше о том, что вы делаете. Если вам действительно нужно что-то больше 1 МБ, поэтому мы добавили -I.

Answer 2

$ ключ = абс (crc32 ($ long_key))

Таким образом, вы получаете уникальный ключ для запросы и другие длинные ключи, которые могут есть изменения за 250 символов Memcache видит.

Вау ... осторожно. Хороший совет, но без важного предостережения. Это может вызвать столкновения. Конечно, это невероятно, но это случается только один раз, чтобы вызвать потрясающую ошибку. Вы все еще, вероятно, захотите сохранить длинный ключ с memcached и всегда перепроверять наличие коллизий на ключе. Лучший способ справиться с ними - хранить простой список пар long_key / value.

Answer 3

Не относится к первоначальному вопросу, но если вы думаете о переходе на APC: его макс. лен для ключей составляет 9727 символов. (проверено на PHP 5.3.2)

Answer 4

$key=abs(crc32($long_key))

Таким образом, вы получаете уникальный ключ для запросов и другие длинные ключи, которые могут иметь изменения, превышающие 250 символов, которые видит memcache.

Answer 5

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

Мы написали весь этот код прямо поверх клиента memcached (мы использовали Python), поэтому на более высоком уровне все было прозрачно.