共计 1362 个字符，预计需要花费 4 分钟才能阅读完成。
上章节介绍了昆仑分布式数据库的架构，这章节接着介绍昆仑分布式数据库的技术特点！
一、高可用性（HA）
兼容多种强一致性，高可用性计划 (strong consistency,high availability)
1.1 存储 shard: 默认应用 MySQLGroupReplication 保障数据库服务高可用
1.2 2*N+ 1 个节点的 shard，每个已提交的事务都复制到了至多 N 个备机
1.3 兼容基于 mysqlrowbasedreplication 的半同步同步的高可用技术 (*)
1.4 兼容基于共享存储实现高可用的 mysql 存储集群 (*)
二、齐备的容灾能力
齐备的容灾能力 (crash safety&fault tolerance)
2.1 存储集群主备强统一
2.2 GTP: 全局事务容灾能力
- 分布式事务两阶段提交
- 节点 / 网络故障时能够保障分布式事务 ACID
2.3 GMR:DDL 与集群全局元数据一致性
- DDL 事务波及计算节点，元数据集群，存储集群
2.4 GMR: 计算节点之间的元数据语句复制及其一致性保障
- 复制过程随时可能中断
2.5 GTP: 计算节点主动切换存储集群主节点 (auto failover)
- 元数据集群，存储集群
2.6 GTP:cluster_mgr: 主动保护各 shard 的存储集群复制状态
三、程度扩大能力
高可扩展性 (high scalability): 计算能力，存储空间，资源利用率
3.1 IAP: 灵便的 sharding 形式
- 用户对 sharding 形式领有全副管制
* sharding 形式:hash/range/list，将来 mirror(*)
* 抉择 sharding 列: 任意若干个列
* 用户最了解本人的数据及其拜访模式 - 定制分区选项达到最优性能
业余模式 VS 傻瓜模式
- 依据数据表的规模定制 sharding 计划
* 不须要预估全局的固定的分区数目，也不把所有表等分为固定数量的分区
* 能够为每个表按需减少分区，各表分区数量各异
* 起码化两阶段提交的事务数量
- 计算节点主动为每个分片抉择适合的存储集群
3.2 ESO: 主动按需扩大 (*)
- 主动通明地散布数据表到新退出的存储集群
- 业务和最终用户无感知
3.3 GPQP: 全局并行查询处理: 后摩尔时代，利用更多的计算资源
- 计算节点层的并行
- 计算节点与存储节点之间的并行
- 存储节点层的并行 (*)
3.4 多点读写
- 按需减少 / 缩小计算节点
- 按需减少 / 缩小存储 shard(*)
- 存储集群反对多点写入 (*)
- 备机读 (*)
四、查询处理
4.1 充沛了解用户数据
- 本地存储齐备的元数据和数据字典
- 本地存储齐备的全局数据统计信息
- 有条件产生最优的分布式查问打算和查问执行性能
4.2 残缺的查询处理过程
- parser->resolver->optimizer->executer
- 能够解决任意 SQL 查问
反对多表连贯，子查问，汇集查问，CTE，window function，存储过程，视图，物化视图 - 残缺的查询处理性能: 真 prepared statement
4.3 完满反对 OLAP 查问
- 查询处理能力完满反对大数据分析工作
- 间接应用本地数据，无需数据搬迁，无需 spark/hadoop 生态
4.4 能够调用 MySQL 零碎函数和用户定义的存储过程 / 函数
*KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END
