percona的什么白皮书，我看就是一堆吐槽

关系型数据库不是万金油，用错反而是瓶颈

数据模型万金油，反而限制了扩展能力

sql好用但是不够灵活，json人人爱

ACID很重要，但是代价也很大，这也是关系型数据库的采用点

由于保证事务可靠，也就限制了扩展能力，数据模型简单不要求事务，上内存kv数据库

mysql也能存大数据，但是能存不能用，没啥意义，所以去掉索引，去掉关系限制，列式数据库诞生了

KV数据库

最开始的目的是做个数据库前端无状态缓存

要快，一般都是hashtable。不是为了替代关系型数据库，只是一项中间件技术

后来KV数据库发展成有简单协议的有命令有状态的服务了。不得不提redis

个人认为 redis能打败memcache，社区好，功能性强，memcache就是单纯的做无状态中间件。这种东西mysql内部也做小型cache，比如2Q啥的。不如一个组件强。但是组件本身也要考虑淘汰以及热点击穿的问题。这就是另一个话题了

典型代表redis提供了一些很好的特性，能让业务更简化，比如TTL, list，比如lua支持，LRU淘汰策略，多key事务，阻塞命令等等

做mysql前端最好不过，做个纯粹的数据库也可以（不落盘不停机）

文档数据库

最早来自邮件存储需求

json对象，sparse index 不存在的key就不要，非常灵活

灵活模式不等于没有模式

典型代表 mongodb 不止提供文档接口，还提供了分片管理，方便水平扩展，加钱上机器就行了

还有一些牛逼特性，比如聚合动作方便map-reduce ，geo相关功能，以及可插拔引擎（wiretiger/rocksdb）

劣势

嵌套表效率低

多表join查询

多表事务

列式存储

只要几列数据为什么不用覆盖索引？

  • 查询灵活难道要每一列都建索引吗？不现实
  • 插入要改动索引，复杂度爆炸延迟爆炸

作者没用Cassandra和hbase举例，而是用了clickhouse

  • 兼容大多数SQL
  • 也有索引，针对MergeTree引擎，支持主键，支持range查
  • Dictionaries 查表不用join
  • 低延迟，查询不用担心阻塞
  • 近似估计等等特殊特性

对于读敏感的大数据集，十分好用

OLTP

ref
  1. https://learn.percona.com/hubfs/ExpertOpinion/Beyond%20Relational%20Databases.pdf