因此，如果我试图实现看起来像Facebook的Graph API，需要非常快速并支持数百万用户，那么使用Redis而不是RDBMS会有什么不利之处？
谢谢！ 乔纳森
答案 0 :(得分：34)
使用Redis而不是传统的RDBMS有很多潜在的好处和潜在的缺点。他们确实是非常不同的野兽。
只关注潜在的缺点：
Redis是一个内存存储：您的所有数据都必须适合内存。 RDBMS通常将数据存储在磁盘上，并将部分数据缓存在内存中。使用RDBMS，您可以管理比内存更多的数据。使用Redis，你不能。
Redis是一个数据结构服务器。没有查询语言（仅命令），也不支持关系代数。您无法提交即席查询（就像您可以在RDBMS上使用SQL一样）。开发人员应该预期所有数据访问，并且必须设计适当的数据访问路径。失去了很多灵活性。
Redis提供了两种持久性选项：常规快照和仅附加文件。它们都不像提供重做/撤消日志记录，块检查，时间点恢复，闪回功能等的真实事务服务器那样安全......
Redis仅在实例级别提供基本安全性（在访问权限方面）。 RDBMS都提供细粒度的每对象访问控制列表（或角色管理）。
唯一的Redis实例不可扩展。它仅在单线程模式下在一个CPU内核上运行。要获得可伸缩性，必须部署并启动多个Redis实例。分发和分片是在客户端完成的（即开发人员必须处理它们）。如果将它们与唯一的Redis实例进行比较，大多数RDBMS都提供更高的可伸缩性（通常在连接级别提供并行性）。它们是多处理的（Oracle，PostgreSQL，...）或多线程（MySQL，Microsoft SQL Server，...），它们受益于多核机器。
在这里，我只描述了主要的缺点，但请记住，使用Redis也有很多好处（非常快，良好的并发支持，低延迟，协议流水线，很好地轻松实现乐观的并发模式，良好的可用性/复杂性比率，Salvatore和Pieter的出色支持，务实的严肃方法，......）
对于您的具体问题（图表），我建议您查看neo4J或OrientDB，它们专门用于存储面向图形的数据。
答案 1 :(得分：0)
我有一些补充： Redis有一个值长度限制。使用redis时，您总是会考虑自己的redis K，V大小，尤其是在redis集群中