说的是NoSQL但不是Redis的那些技术方案，别搞混了啊

当我们谈论“说的是NoSQL但不是Redis”的技术方案时，首先要明确一点：NoSQL是一个非常大的概念，它指的是“非关系型数据库”，而Redis只是这个大家族里一个非常著名的成员，它以内存存储和极快的速度著称，主要用于缓存、消息队列等场景，但世界上还有很多其他类型的NoSQL数据库，它们解决的问题和Redis完全不一样，下面就来聊聊这些“不是Redis”的技术方案，主要参考了各类技术社区和数据库官方文档中对NoSQL的分类和介绍。

首先一大类是面向文档的数据库，这类数据库的想法很简单，它存储的数据单位是一个个的“文档”，这个文档不是指Word或PDF文件，而是一种结构化的数据格式，比如类似JSON的样子，你可以把它想象成一个文件夹，里面可以随意地放各种文件（数据），每个文件夹的结构可以完全不同，非常灵活，最典型的代表就是MongoDB和Couchbase，你要开发一个博客系统，每一篇博客文章包含标题、正文、作者、标签、评论，评论下面还有人回复，这种层层嵌套的数据结构，如果用传统的关系型数据库（比如MySQL）来存，得拆分成好几张表（文章表、评论表、回复表），查询的时候还要把它们拼起来，很麻烦，但用MongoDB这样的文档数据库，你可以直接把一整篇博客文章，包括它的所有评论和回复，当作一个完整的文档存起来，查询的时候，直接把这个文档拿出来就行了，非常方便，文档数据库特别适合内容管理系统、用户配置文件、产品目录这些数据模型经常变化、结构不固定的应用。

第二大类是宽列存储数据库，这个名字听起来有点技术化，但我们可以换个方式理解，你可以把它想象成一个超级大的、可以无限扩展的表格，这个表格的行数可以非常多，而且每一行可以有自己的列，不同行的列可以完全不一样，这和关系型数据库里所有行都必须有相同的列截然不同，这方面的佼佼者是Apache Cassandra和HBase，它们的设计目标主要是为了处理海量数据，并且能在很多台普通的电脑上运行，保证即使某台电脑坏了，系统照样能工作（高可用性），像物联网应用，有成千上万个传感器每秒钟都在发送数据，或者像社交网络要记录数十亿用户的行为日志，这些数据的写入量非常巨大，宽列存储数据库就特别擅长处理这种“写多读少”的海量数据场景，它们通常被大型互联网公司用于后台的数据分析和服务。

第三大类是图数据库，这种数据库非常特别，它的核心不是文档也不是表格，而是“关系”，它用“节点”来代表实体（比如人、地点、产品），用“边”来代表实体之间的关系（比如朋友关系、购买关系、居住关系），它的强大之处在于，能够极其高效地查询实体之间复杂、深层的关系网络，最出名的图数据库是Neo4j，举个例子，在反欺诈调查中，你需要分析一个可疑账户和成千上万个其他账户之间的资金往来，找出其中隐藏的环路或特定模式；或者在社交网络中，要找出某个用户的朋友的朋友的朋友中，有哪些是潜在的推荐对象，这类查询如果让关系型数据库来做，需要写非常复杂的、多层嵌套的SQL语句，而且速度会随着关系层数的增加变得极慢，但图数据库是专门为这种场景设计的，遍历关系就像在公路上开车一样直接和快速，图数据库在社交网络、推荐系统、欺诈检测、知识图谱等领域非常有用。

还有一类是键值数据库，这其实是Redis所属的类别，但为了说明“不是Redis”，我们可以提一下同类别下的其他选择，比如Amazon DynamoDB，它是一个完全托管的键值数据库，你不需要自己操心服务器， AWS会帮你处理一切扩展和维护问题，它更适合在云环境下构建大规模应用，还有etcd，它是一个强一致性的键值存储，通常不直接用于业务数据存储，而是作为分布式系统的配置中心和服务发现的基础，比如著名的容器编排工具Kubernetes就用它来存储整个集群的状态。

NoSQL的世界远不止Redis,当你需要极快速度的缓存和简单数据结构时，Redis是王者，但当你的需求是处理灵活变动的文档结构、海量的时序数据、错综复杂的关联关系，或者需要在云上轻松管理巨量简单数据时，MongoDB、Cassandra、Neo4j、DynamoDB这些“不是Redis”的技术方案就会各显神通了，选择哪个，完全取决于你要解决的具体问题是什么。