关系代数的RDB，发展了很多年，很多成熟的产品和技术；K-V的redis，现在到了3.x，支持lua脚本、订阅、集群等；图形的neo4j，还有支持分布式的titan；文档数据库mongodb，换装wt引擎后更强劲；
还有hbase、cassandra等列式数据库，在大数据方向蛮火；最后，别忘了文件系统，nfs、fastdfs、gridfs等，好多东东，整吧，你已经上了贼船。
来张redis的图：
其实redis的核心就是内存存储、以及大量应用了map这种数据结构，虽说达不到O(1)，但内存会肯快，相比网络IO；
数据结构，比memcache丰富得多，list、map、set、有序set、bitmap，而且具体的数据结构实现有linkedlist、ziplist、intset、skiplist、hashtable等，你可以兼顾内存消耗与效率。
日志：RDB一次性dump，AOF缓冲区，按策刷盘，高并发还是用aof的；
事务：redis引擎虽说是单线程的，但不保证ACID事务，当然lua脚本很灵活；
主从：主动复制模式，支持树状结构，全量复制和部分复制；
高可用：主客观下线、哨兵选举、故障转移，那个sentinel选举就是paxos的简化版；
集群：gossip协议配置更新，支持集群的伸缩，就是槽位的变化，当然最好配合smart客户端。
有观点认为redis支持事务，但你muti的命令，执行出错也不会回滚，日志也不一定是及时写入，个人感觉没必要当RDB来看。
简单事务，redis支持watch，乐观并发那种锁，其实redis、mongodb虽然不严格支持RDB那种事务，但是也提供一些原子性的操作，别说你没用过。
那个哨兵选举，确实是paxos的实现，但是主节点选举，以及集群高可用，个人认为，不能保证数据最新，比如只有从节点A节点的数据最新，但发起的投票请求，因为阻塞、丢包，没到达哨兵||集群主节点，其他的从节点发起的投票到达，然后当选了，这种情况不能保证数据的最新。
详见redis设计与实现。
来源：oschina
链接：https://my.oschina.net/u/2428106/blog/757888