MC支持的key的最大长度是250个字节，推荐使用使用较短的key，因为可以节省内存和带宽。支持的Value的最大上限为1M字节（具体可查看拙作MC不能写入超过1M项实践），但太大的对象，会占用较大的内存和带宽，导致较小的QPS，所以通常情况下建议value的大小在10K以下为宜。这要求应用在存储数据的时候，需要更多地考虑数据结构的设计，比如不存储实际的业务数据，改为存储索引数据等。
说明一点，这里的value大小是针对用户传入MC时序列化以后的大小，而不是在MC中实际存储的value大小，因此业务方只需对传入数据大小进行预估即可。
那么当所存的业务数据确实无法再精简时，要怎么处理已获取更好的性能呢？以下总结几种常用的优化方式：
1. 实现轻量级序列化方式
这种方式从根本上减小了value的大小，但是从实现角度上来说会复杂一些，需要应用方自己做序列化和反序列化。java客户端对基本数据类型采用java默认的序列化方式，占用空间较大。因此可以选择轻量级的数据存储方式做序列化，比如使用json或者google protocal buffer进行序列化和反序列化。序列化后，数据bytes[]数组，然后写入MC。读出时，得到byte[]数组，然后再反序列化。
2. 拆分数据
这种方式主要从业务逻辑上去考虑，对大value进行拆分。假设一个key对应了多项业务数据，就可以把这个key拆分成多个key。这里key的名称可以通过加前缀来标识。拆分后如果需要读取这些数据，可以用批量读取接口完成（比如mget）。这样拆分后虽然增多了网络交互，可以把key的访问压力分散到多台机器上，总体性能上会优于单key存储。
如果这些数据不需要每次都全部取出的时候，也可以用prefix的方式存储，把业务数据分多类来存储，但是一个prefix下所有数据都存储在一台机器上，压力还是会集中在单机上。
3. 压缩数据
在数据传入MC之前，先使用压缩算法进行数据压缩，减小数据大小。当使用压缩算法的方式时，建议用户可以先对数据进行测试，避免用压缩算法后反而增大了数据的大小。
