阅读DDIA 《数据密集型应用系统设计》 之后，关于6大主流数据库一些思考
根据DDIA：目前的应用大部分都是IO密集型系统，所以对于数据库存储要求更为重要。瓶颈往往发生在存储上
1.有状态服务和无状态服务：网络和应用层服务是没有服务，任何时候执行的代码的逻辑都是不变的。但是无状态
2.CPU密集型和IO密集型
3.短板效应
互联网无万能的解决方式
1.算力取舍：空间与时间如何取舍
2.一致性取舍：CAP和BASE理论
3.管理模式取舍：中心化和去中心化设计
除了CRUD注重什么
1.什么场景下使用什么数据库解决方案
2.瓶颈问题的解决“分布式拓展”
3.分布式一致性
数据库比较
MySQL：
关系型数据库，SQL标准，可用性方案完备，适合需要ACID和数据稳定性的场景。
劣势：高并发大数据支持弱，表结构固定拓展难变，可能锁表。
配置优化：(1)设置最大连接数1000，默认为100 (2)设置缓存池和日志缓冲区(设计redo，undolog，事务回滚写操作)大小 （3）优化事务刷盘时机，减少刷盘延迟
Redis：
缓存非关系型数据库，适合需要高性能KV读取而且容忍数据丢失场景，O1，单线程，分布式策略好
劣势：持久化能力差没有办法保证事务性，吃内存value不能太大，雪崩穿透的问题
ES：搜索非关系型数据库，适合全文搜索场景，查询复杂聚合以及groupby。有分布式解决方案
劣势：倒排索引对缓存要求大，数据延迟性
分布式：raft协议leader控制节点，
Neo4j:图非关系型数据库，适合需要图形关联存储，实体间构建多维度关联关系的场景
劣势：只适合图形场景，分片局限性
HBASE：
列示非关系型数据库，适合大数据量半结构化/非结构化，数据读写查询维度单一场景。聚合分析能力高
劣势：条件查询能力弱
适用场景：对未来预估有大规模增长量的场景。
MongoDB：
文档式非关系型数据库，适合大数据量半结构/非结构化。数据写强且查询维度单一场景，表字段可以拓展
劣势：内存消耗大，不支持join。
点赞场景可以用。内存对象最自然的持久化方式，甚至没有对象模型的简单或复杂场景也可以很舒服的存取数据。复杂查询能力非常强，且复杂查询语句和代码 比同等情况的sql要简单简洁很多 可维护性高好几个级别。
数据量大了也不用担心，自带了分表Sharding机制。
