所以，如果比如我想实现一些类似Facebook的Graph API的东西，需要非常快，并且支持数百万用户，那么只用Redis而不是RDBMS有什么缺点？
谢谢！Jonathan
使用Redis而不是经典的RDBMS有很多潜在的好处和潜在的缺点。它们确实是非常不同的野兽。
只关注潜在的缺点。
Redis是一个内存存储：所有的数据都必须放在内存中。RDBMS通常将数据存储在磁盘上，并将部分数据缓存在内存中。使用RDBMS，你可以管理的数据比你的内存多。使用Redis，你就不能。
Redis是一个数据结构服务器。没有查询语言（只有命令），也不支持关系代数。你不能提交临时查询（就像你在RDBMS上使用SQL一样）。所有的数据访问都应该由开发人员来预测，必须设计适当的数据访问路径。失去了很多灵活性。
Redis为持久化提供了2种选择：定期快照和仅附加文件。它们都不像真正的事务性服务器那样安全，提供redoundo日志、块校验、时间点恢复、闪回功能等......。
Redis只在实例级别提供基本的安全（在访问权限方面）。RDBMS都提供了细粒度的每个对象的访问控制列表（或角色管理）。
一个独特的Redis实例是不可扩展的。它只能在一个CPU核上以单线程模式运行。为了获得可扩展性，必须部署和启动多个Redis实例。分发和分片是在客户端完成的（即开发者必须照顾它们）。如果将它们与唯一的Redis实例进行比较，大多数RDBMS提供了更多的可扩展性（通常在连接级别提供并行性）。它们是多处理的（Oracle，PostgreSQL，......）或多线程的（MySQL，Microsoft SQL Server，......），利用多核机的优势。
在这里，我只描述了主要的缺点，但请记住，使用Redis也有很多好处（速度非常快，良好的并发支持，低延迟，协议管道化，易于实现乐观的并发模式，良好的可用性和复杂度比，来自Salvatore和Pieter的出色支持，务实的无厘头方法，......）。
对于你的具体问题（图），我建议你看看neo4J或OrientDB，它们是专门为存储面向图的数据而设计的。
我有一些补充：redis有一个值的长度限制。在使用redis的时候，你一定要考虑你的redis的K,V大小，特别是在redis集群中