问题描述
Memcached 对键(250?)和值(大约1MB)也有长度限制.据我所知，对于键的字符限制有些定义不明确.解决您认为的最佳方法是什么?我使用Perl API Cache :: Memcached.
Memcached has length limitations for keys (250?) and values (roughtly 1MB), as well as some (to my knowledge) not very well defined character restrictions for keys. What is the best way to work around those in your opinion? I use the Perl API Cache::Memcached.
我当前要做的是，如果原始值太大("parts:< number>")，则为主键的值存储一个特殊的字符串，在这种情况下，我将存储名为的键的< number>部分+<主键>，2 +<主键>等.在某些情况下似乎确定"(但很凌乱)，对其他情况则不太好，并且存在一个固有的问题，即某些部分可能会丢失任何时间(这样就浪费了空间来保留其他人，而浪费了阅读时间).
What I do currently is store a special string for the main key's value if the original value was too big ("parts:<number>") and in that case, I store <number> parts with keys named 1+<main key>, 2+<main key> etc.. This seems "OK" (but messy) for some cases, not so good for others and it has the intrinsic problem that some of the parts might be missing at any time (so space is wasted for keeping the others and time is wasted reading them).
关于密钥限制，可能可以实现哈希并在值中存储完整密钥(以解决冲突)，但是我还不需要这样做.
As for the key limitations, one could probably implement hashing and store the full key (to work around collisions) in the value, but I haven't needed to do this yet.
有没有人想出一种更优雅的方法，甚至是透明地处理任意数据大小(和键值)的Perl API?有没有人入侵过内存缓存服务器以支持任意键/值?
Has anyone come up with a more elegant way, or even a Perl API that handles arbitrary data sizes (and key values) transparently? Has anyone hacked the memcached server to support arbitrary keys/values?
推荐答案
服务器已经允许您指定所需的大小:
The server does already allow you to specify whatever size you want:
-I Override the size of each slab page. Adjusts max item size
(default: 1mb, min: 1k, max: 128m)
但是，在大多数情况下，当人们想要缓存较大的对象时，他们在做错事.您真的在一个缓存键中需要那么多数据吗?未压缩?
However, most of the time, when people are wanting to cache larger objects, they're doing something wrong. Do you really need that much data in one cache key? Uncompressed?
如果您有足够大的任务，那么实际传输数据所需的时间将使低延迟访问的优势相形见.或者，您发现用同一个键来扔掉所有内容意味着您的前端最终不得不做很多工作来反序列化他们想要的一些数据.
If you have sufficiently large tasks, the benefit of low-latency access is dwarfed by the time it takes you to actually transfer the data. Or you find that tossing everything in the same key means your frontend ends up having to do a lot of work to deserialize a bit of data they want.
这取决于您的需求，而我不知道您在做什么，就无法告诉您什么是最适合您的.如果您确实确实需要大于1MB的内容，那就是为什么我们添加了-I.
It depends on your needs, and I can't tell you what's best for you without knowing more of what you're doing. If you truly do need something bigger than 1MB, that's why we added -I, though.
这篇关于您如何解决memcached的键/值限制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！