Java Redis - 将数据存储到 Redis 的方法 :: JSON String OR Serialized pojo
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19872795/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Redis - Approach for Storing Data Into Redis :: JSON String OR Serialized pojo
提问by Santosh Joshi
I have a class like below:
我有一个像下面这样的课程：
public class Person
{
public String name;
public String age;
}
I am a bit confused over the approach of saving a Map of Perons into Redis:
我对将 Perons 的 Map 保存到 Redis 的方法有些困惑：
Should I go for java serialized/deserialized object approach or should i try converting to JSON and then storing and vice versa.
我应该采用 java 序列化/反序列化对象方法，还是应该尝试转换为 JSON 然后存储，反之亦然。
Any thoughts on below mentioned points:
关于以下几点的任何想法：
- Cost of serialization and deserialization VS cost of mapping to Java and to JSON
- memory Requirement for JSON and serialized object for Redis
Compression : Stream vs Data
Which compression should we go for Though DATA compression seems a bit difficult(not much benificial) as we are using Redish Hash
- 序列化和反序列化的成本 VS 映射到 Java 和 JSON 的成本
- JSON 和 Redis 序列化对象的内存要求
压缩：流与数据
我们应该采用哪种压缩方式虽然数据压缩似乎有点困难（没有多大好处），因为我们正在使用 Redish Hash
Some of the assumptions are:
一些假设是：
- The pojo contain many instancd variables
- will be using Redis hash to store object
- pojo 包含许多实例变量
- 将使用 Redis 哈希来存储对象
回答by Andrey Chaschev
The answer is you should measure it for your use cases and environment. I would first try JSON at it's more versatile and less problematic - i.e. easier to debug and restore corrupted data.
答案是您应该针对您的用例和环境对其进行衡量。我会首先尝试 JSON，因为它更通用且问题更少 - 即更容易调试和恢复损坏的数据。
Performance.JSON serialization is fast, so in many scenarios it won't be your bottleneck. Most probably it is disk or network IO: java serialization benchmarking. Avoid using default Java serialization as it is slow. Kryois an option for binary output. If you need miltiple platforms for binary format consider DB's internal format or i.e. Google Protobuffers.
表现。JSON 序列化速度很快，因此在许多情况下它不会成为您的瓶颈。很可能是磁盘或网络 IO: java serialization benchmarking。避免使用默认的 Java 序列化，因为它很慢。Kryo是二进制输出的一个选项。如果您需要二进制格式的多种平台，请考虑 DB 的内部格式或即 Google Protobuffers。
Compression.In Google they use Snappyfor less-cpu-demanding compression. Snappy is also used in Cassandra, Hadoop and Hypertable. Some benchmarks for JVM compressors: Compression test using Calgary corpus data set.
压缩。在 Google 中，他们使用Snappy进行对 CPU 要求较低的压缩。Snappy 也用于 Cassandra、Hadoop 和 Hypertable。JVM 压缩器的一些基准测试：使用卡尔加里语料库数据集的压缩测试。
回答by zenbeni
You should consider using MessagePack as it is full compatible with Redis and Lua, it is a great compression on JSON: http://msgpack.org/
您应该考虑使用 MessagePack，因为它与 Redis 和 Lua 完全兼容，它对 JSON 进行了很好的压缩：http: //msgpack.org/
It implies some Lua code to compress and uncompress, but the cost should be small. Here is an example: http://gists.fritzy.io/2013/11/06/store-json-as-msgpack
这意味着需要一些Lua代码来压缩和解压缩，但成本应该很小。这是一个例子：http: //gists.fritzy.io/2013/11/06/store-json-as-msgpack
There is a small benchmark which lacks data: https://gist.github.com/muga/1119814
有一个缺少数据的小基准：https: //gist.github.com/muga/1119814
Still it should be a great option for you, as you can use it in different languages, fully supported on redis, and it is based on JSON.
它仍然对您来说应该是一个不错的选择，因为您可以在不同的语言中使用它，在 redis 上完全支持，并且它基于 JSON。
