思维导图：数据库选型决策

思维导图：数据库选型决策

MySQL、ElasticSearch、MondoDB、Redis、HBase、Cassandra、ScyllaDB，以及Spark和Flink的简单对比

文字版：

数据库选型决策
	作者
		路飞的纯白世界
	MySQL
		引擎
			种类
				InnoDB
					支持事务
					支持外键
					聚集索引
						必须有主键
						辅助索引绑定在主键索引的叶子索引上
							根据主键索引查询最快，只需一次检索
							根据辅助索引查询需要两次检索
					不记录表的总行数，需要全表扫描才可知总行数
					最小的锁粒度是行锁
				MyISAM
					不支持事务
					不支持外键
					非聚集索引
						主键索引和辅助索引各自独立
					会记录表的总行数
					最小的锁粒度是表锁
			选择
				默认且推荐使用InnoDB
				不需要事务的表可考虑MyISAM
		适用场景
			严格事务需求
		优势
			CAP的CA
				强一致性
				可用性
			局部查询性能优越
			索引和分区能解决大部分查询性能问题
			InnoDB对事务支持好
		性能瓶颈
			全表扫描性能差
			多表关联查询性能差
		原理
			索引
				B+树
					只有叶子节点具有data
					非叶子节点没有data，一次IO可读出更多的索引值，利于减少IO次数
					利于范围查询
					时间复杂度O(log n)
				B-树
					所有节点都有data
					最快一次命中索引
	ElasticSearch（8）
		适用场景
			OLAP
			全文搜索
			人类自然语言
			地理位置搜索和计算
			通常作为其他数据库的辅助（数据主要存储在其他数据库上）
		优势
			天生分布式
				扩容方便
				集群自动增删索引或节点
			强大的聚合和分析能力
		常见问题
			冲突问题
				重要的文档需要并发控制，通常使用version比对的乐观控制机制
			分页问题
				from越大，协调节点的整体排序越耗时
		原理
			倒排索引
				通常情况下，是对文档id建索引，要找到关键词所在的文档，需要将每个文档内容都检索一遍
				而倒排索引是根据关键词建索引，通过关键词直接查询到所在文档以及出现次数
			分布式检索
				分片查询阶段
					分别查询排序、再整体排序
				分片取回阶段
					取回完整文档并返回
			格式类型
				类json文档型
		使用方式
			Restful API
	MongoDB（5）
		适用场景
			满足1个以上就可以使用，满足越多越适用
				无事务？
				需求在变？
				数据模型不确定？想快速迭代开发？
				需要2000或更高的QPS？
				需要TB甚至PB级别的数据存储？
				快速水平扩展？
		优势
			灵活文档类型
			高可用复制集
			可扩展分片集群
			性能极高
			复杂查询
			位置查询
			数据可冷热分离
	Redis
		适用场景
			缓存
			队列
			访问统计
			分布式session
			分布式锁
		优势
			快！
				纯内存访问
			数据类型丰富
		内存优化
			内存回收策略
				定时删除
				惰性删除
			内存优化
				缩短键值对象的长度
				共享对象池
				字符串优化
				控制键的数量
		原理
			分布式方案
				集群方案
					Redis Cluster
						集群内节点互相通讯
						支持16384个虚拟槽分区
				分片方案
					客户端分片
						一致性哈希算法
					中间件分片
						CodisProxy
							集群内节点无需相互通讯
							支持1024个虚拟槽分区
						TwemProxy
			数据持久化
				RDB
					快照方式
					恢复快
					持久化效率高
					存在数据丢失风险
				AOF
					实时追加日志方式
					实时安全
					持久化效率低
	HBase（23）
		适用场景
			建立在HDFS上
				通常由大数据部门维护
			快速随机读写
			大数据容量
			强一致性
		优势
			CAP中的CP
				强一致性和分区容错性
	Cassandra（11）
		适用场景
			轻松运维和扩容
			快速随机读写
				更像数据库
					通常由dba维护
			高并发读写
			写多读少
				为写吞吐做了优化
			大数据容量
		优势
			CAP中的AP
				可用性和分区容错性
				可配置为最终一致性
			对比HBase
				性能比HBase好，因为直接存取磁盘，而不是通过HDFS文件系统
				功能比HBase丰富，如CQL、类型
				Cassandra是无中心架构，没有单点故障
					线性扩容、运维简单
					可用率100%
				HBase是主从架构，主挂了需要重新选举
			灵活的数据存储
				结构化
				半结构化
				非结构化
			事务支持
				原子性
				一致性
				隔离
				持久性
			快速写入
				被设计成可在廉价机器上运行
				存储数百T数据，而不牺牲读取效率
	ScyllaDB（102）
		Cassandra的C++版本
		优势
			性能是Cassandra的十倍
				意味着成本也降低了十倍
			亚毫秒级
		劣势
			不稳定
			重启耗时超长，或启动失败
				https://www.zhihu.com/question/35956679/answer/418001368
			数据丢失风险
	Spark和Flink
		Spark
			适用场景
				离线
				批处理
				简单机器学习
			优势
				批处理
				模拟流处理
					通过微批模拟
				内置机器学习库
				支持丰富的数据源
			劣势
				实时性不及Flink
				窗口支持不及Flink
				只支持处理时间
				不支持精确一次
					故障恢复会重复处理
		Flink
			适用场景
				实时
				流处理
				数据管道
				ETL
				事件驱动型应用
			优势
				实时
				流处理
				模拟批处理
				低延时
				高吞吐量
				容错和精确一次计算保证
					状态快照是异步获取和存储的
					发生故障时可通过状态快照恢复
				窗口方式
					滑动
					滚动
					会话
				窗口优势
					支持窗口种类多
						支持时间窗口
						支持消息数量窗口
					支持时间种类多
						事件时间
							产生这个消息的时间、或者消息的某某时间字段
						处理时间
							flink算子处理到这个消息的系统时间
						注入时间
							刚进入flink source的时间
				时间类型优势
					事件时间
						事件本身自带的时间
						能保证结果的准确性和一致性
					处理时间
						处理时引擎时钟的时间
						适合低延时，能容忍近似结果的流处理应用
					读取时间
						读取到事件时记录的时间
					事件时间和自由度极高的定制化窗口逻辑
			应用场景
				事件驱动型应用
					提供的支持有
						事件时间和自由度极高的定制化窗口逻辑
						内置ProcessFunction支持细粒度时间控制
						复杂事件处理库（CEP）
						savepoint
							一致性的状态印象
								完成一次savepoint后，可放心对应用升级或扩容
								还可启动多个版本进行a/b测试
					典型事件驱动型场景
						反欺诈
						异常检测
						基于规则的预警
						业务流程监控
						web应用
				数据分析应用
					类型
						流式分析
						批量分析
					方式
						提供统一的高级SQL语义
						也可做更低层的控制
							flink DataStream api
							flink DataSet api
					典型数据分析场景
						电信网络质量监控
						消费者技术中的数据实时即席分析
						大规模图分析
						电信故障关联强度分析
				数据管道应用
					数据管道和ETL
					典型数据管道场景
						实时查询索引构建
						持续ETL