数据库中间件的优缺点
优点：
缺点：
- 只适用于简单业务，同时对业务有侵入性，需要改造业务
- 很难支撑跨分片的高性能复杂查询
- 分布式事务性能损失，一般是在单机的事务之上增加一层分布式事务（如事务管理器,TCC）
- 水平扩展能力差，只能按照选定的分配规则横向扩展
- 大型集群运维困难
- 表结构变更(DDL)操作困难，容易出现失误
- 只能按照分片进行维护（备份、恢复等操作）
NoSQL Not Only SQL
- 放弃高级SQL能力，追求强水平扩展能力（反过来意味着业务兼容的成本高）
- 放弃复杂SQL查询
- 放弃分布式事务（ACID）
- 通常的数据访问模型：
- 键值对
- 文档型
- 代表系统：
- mongoDB
- CouchBase
- Cassandra
- HBase
为什么是 HTAP？
在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构，所有的线上请求 (OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。
随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量限制制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求，OLTP、OLAP 在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：
-
OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。
- 企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。
因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。在此背景下，由 Gartner 提出的 HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）成为希望。基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
目前，实现 HTAP 的数据库不多，主要有 PingCAP 的 TiDB、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是国内首家开源的 HTAP 分布式数据库，接下来，本文将以此例进行深入分析。