Redis 适合我的需要吗
，用户可以在其中提交短信，非常简单的数据结构...
- 名称 <-- 少于 20 个字符
- 消息 <-- 最多 150 个字符
- 时间戳
- IP
- 隐藏 <-- 布尔值（True 或 False）
我有一个网站 网站的早期版本它们存储在 MySQL 数据库中，该数据库非常大，有很多表，我想简化数据库。所以我听说 Redis 适合简单的数据结构和非关系信息...
Redis 对于此类数据来说是一个不错的选择吗？当谈论每年超过 100,000 条记录时，它的性能如何，以及内存使用情况和读取时间。 。
I have a website where users can submit text messages, dead simple data structure...
- Name <-- Less than 20 characters
- Message <-- Max 150 characters
- Timestamp
- IP
- Hidden <-- Bool (True or False)
On the previous version of the website they are stored in MySQL database which is very big, lots of tables, and am wanting to simplify the database. So I heard Redis is good for simple data structures and non relational information...
Would Redis be a good option for this kind of data and how would it perform, with memory usage and read times when talking about 100,000+ records a year...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
redis 实际上只适用于内存中的问题集。它确实具有页面到磁盘的功能 - 但随后你就会受到操作系统交换器的摆布 - 也就是说，你的 RAM 将与系统缓存竞争。另外，我认为按键必须始终适合 RAM。所以你不会想要存储 1G+ 的日志记录 - mysql-archive-table 对此要好得多。
redis具有主从功能，类似于mysql。因此，您可以执行各种技巧，例如对从站进行排序以保持主站响应。虽然我还没有使用过它，但我推测对于内存数据库来说，mysql-cluster 可能要先进得多 - 但也会有相应的额外复杂性/资源成本。
如果您的键值集有很大的值，则可以执行客户端压缩/解压缩。无论如何，服务器无法执行太多操作来搜索这些“blob”的值。
解决 RAM 限制的一种常见方法是执行客户端分片（分区）。也就是说，如果你知道你的上限，并且由于某种原因你没有足够的 RAM 来解决这个问题（假设你已经有 64GB 的 RAM），那么你可以根据主键进行“分片”。一个序列计数器，您可以取底部 3 位（或一些散列函数 + 分区函数），并分布在 4、8、16 等服务器节点之间。这是线性扩展的，但如果您需要重新分区，那可能会很痛苦。您可以利用 redis 中的“插槽”来从更少的机器开始。假设一台机器有 16 个插槽。然后，转储插槽 7-15 并在另一台机器上恢复，并重新映射所有客户端以指向两台机器（具有相同的槽号）。等等到 16 路分片。此时，您需要重新映射所有数据以转至 32 路。
显然，首先评估 redis 的命令集，看看是否可以满足您所有的数据存储和报告需求。有相当于“select * from foo for update”的东西，但它们并不明显。并非所有 RDBMS 查询都可以通过键值存储有效地重现。但对于简单的自然主键记录结构来说，它应该做得很好。
此外，应该很容易扩展 redis 命令集来执行自定义操作。请记住，它是围绕无暂停单线程执行而设计的（避免锁定/上下文切换开销）。
但我真正喜欢的是 FIFO、发布/订阅、数据超时、原子突变（inc/dec）、惰性排序（例如在具有只读节点的客户端上）、映射的映射。这很简单，您只需在不同的端口/UNIX 套接字上启动单独的 redis 进程（如果可能的话，我的偏好），而不是使用名称空间。
它的目的是取代 memcached 最重要的是，但有一个非常好的后台持久框架。
redis is really only good for in-memory problem sets. It DOES have a page-to-disk capability - but then you're at the mercy of the OS swapper - namely you're RAM will be in competition with system-caches. Also, I think the keys always have to fit in RAM. So you're NOT going to want to store 1G+ log records - mysql-archive-table is MUCH better for that.
redis has a master-slave functionality, similar to mysql. So you can perform various tricks such as sorting on a slave to keep the master responsive. While I haven't used it, I'd speculate that for in-memory databases, mysql-cluster is probably far more advanced - but with corresponding extra complexity / resource-costs.
If you have large values for your key-value set, you can perform client-side compression/decompression. There isn't much the server can do to search on the values of those 'blobs' anyway.
One common way to get around the RAM limitation is to perform client-side sharding (partitioning). Namely, if you KNOW your upper bounds, and you don't have enough RAM to throw at the problem for some reason (say you already have 64GB of RAM), then you could 'shard' based on the primary key.. If it's a sequence counter, you could take the bottom 3 bits (or some hashing function + partition function), and distribute amongst 4,8,16, etc server nodes. That scales linearly, though if you need to re-partition, that could be painful. You COULD take advantage of the 'slots' in redis to start off with fewer machines.. Say 1 machine with 16 slots.. Then later, dump slots 7-15 and restore on a different machine and remap all the clients to point to the two machines (with the same slot numbers). And so forth to 16-way sharding. At which point, you'd need to remap ALL your data to go to 32-way.
Obviously first evaluate the command-set of redis to see if ALL your data-storage and reporting needs can be met. There are equivalents to "select * from foo for update", but they're not obvious. Not all RDBMS queries can be reproduced efficiently with key-value stores. But for simple natural-primary-key record-structures it should do fine.
Additionally, it should be easy to extend the redis command-set to perform custom operations.. Just keep in mind, it's designed around no-pause single-threaded execution (avoids locking /context-switching overhead).
But things I really like are the FIFOs, pub/sub, data-time-outs, atomic-mutations (inc/dec), lazy-sorting (e.g. on client with read-only nodes), maps of maps. It's simple enough that instead of using name-spaces, you just launch separate redis processes on different ports / UNIX-sockets (my preference if possible).
It's meant to replace memcached more than anything else, but has a very nice background persistent framework.