NoSQL的本质定位是针对关系数据库四大缺陷的补充方案

关系数据库凭借强大的SQL能力和ACID特性广泛应用，但并不完美，存在四个具体缺陷。其一，只能存储行记录，无法直接存储数据结构——比如微博”我关注的人”本质是一个用户ID列表，关系数据库只能把它拆成多行分别存储，再查询组装还原成列表，无法原生存一个列表。其二，表结构schema是强约束，业务变化时扩充列要执行DDL语句（CREATE、ALTER等），而且修改时可能长时间锁表（如MySQL某些场景下可能锁表长达1小时）。其三，大数据统计场景下I/O偏高——即使只对某一列做运算，关系数据库也会把整行数据从磁盘读入内存，造成明显的读取浪费。其四，全文搜索能力弱——只能用like做整表模糊扫描，性能很低，无法满足互联网场景下复杂的搜索需求。针对这四个缺陷，业界分别演化出四类NoSQL方案：K-V存储（以Redis为代表）解决数据结构存储问题；文档数据库（以MongoDB为代表）解决schema强约束问题；列式数据库（以HBase为代表）解决大数据I/O问题；全文搜索引擎（以Elasticsearch为代表）解决全文搜索性能问题。但NoSQL带来的优势本质上是靠牺牲ACID中的某个或某几个特性换来的，天下没有免费的午餐，因此不能把NoSQL当成万能银弹去替代关系数据库，而应该把它理解为SQL的有力补充——这也是”NoSQL”这个词真正的含义：不是No SQL（没有SQL），而是Not Only SQL（不仅仅是SQL）。

结构图：

flowchart TB
  A["关系数据库的四大缺陷"]
  A --> B["无法存储数据结构<br/>如微博关注列表只能拆成多行"]
  A --> C["schema强约束，扩展不便<br/>DDL修改可能长时间锁表"]
  A --> D["大数据场景I/O高<br/>只用一列也要读整行"]
  A --> E["全文搜索弱<br/>只能用like整表扫描"]
  B --> F["对应方案：K-V存储<br/>代表：Redis"]
  C --> G["对应方案：文档数据库<br/>代表：MongoDB"]
  D --> H["对应方案：列式数据库<br/>代表：HBase"]
  E --> I["对应方案：全文搜索引擎<br/>代表：Elasticsearch"]
  F --> J["NoSQL本质：Not Only SQL<br/>牺牲部分ACID换取优势，是SQL的补充而非替代"]
  G --> J
  H --> J
  I --> J