分布式数据库选型_数据库相关

PPT 内容

1. 数据存储的分类与对比类型成熟度特点缺点适用场景通用性使用成本传统关系数据库很成熟从几千到几千万的记录规模都能存储，支持事务，周边开发语言、框架和平台都有完毕的支持，是企业应用必不可少的基础设施之一存在并发性和实时性的瓶颈、数据规模达到一定程度，则系统响应能力明显下降，难以平滑扩容几乎可以用于任何企业应用的开发很通用用户可以自主选择：使用开源的数据库成本很低，包括硬件要求。使用商业版本则性能和容量方面可以超越开源的。内存数据库较成熟千万级以上的记录规模支持的SQL有限制，API有特殊性，系统对硬件通常有特殊要求一些实时性要求很高的系统不通用较高NoSQL较成熟数据模型简单，通常为Key-Value模式，基于键值的操作非常快，通常具备分布式能力不支持事务范围查询是瓶颈周边工具少对运维有一定要求使用Key-Value模型来访问数据的，对存储和事务要求不高的系统较通用低缓存系统较成熟利用内存来做数据缓存，可以集中或分布式缓存，访问性能很高具有NoSQL的缺点，另外数据通常不会持久化某些数据访问很频繁，而变动很少的场景较通用低分布式数据库较成熟利用软件技术，将单机的传统数据组合为分布式的数据存储系统，通常基于开源的数据库构建，具备传统数据库的优点的同时，又在一定程度上解决了单机数据库的缺点相对于传统单机数据库，增加了一定的复杂度，同时部分SQL在分布式情况下难以很好的实现，比如跨库JOIN，事务问题也是一个突出问题需要存储超越千万级到百亿级别的记录规模的场景较通用低
2. 分布式数据库的两种主要模型客户端（Driver）模式：改造数据库的驱动，分片分表等在客户端实现中间件（Proxy）模式：实现某个数据的通信协议，模拟为Server，将客户端的SQL发往后端具体的数据库，实现分片分表
3. 客户端模式Or中间件模式客户端模式：面向开发人员，因此从运维角度来看，缺乏透明度，数据排查等任务比较复杂，由于少了中间环节，因此SQL时延最低中间件模式：模拟一个数据库Server，因此对于使用者来说就好象一个真实的数据库服务器，运维和数据排查比较容易，管理调整方便，并且可以搭建集群，增加吞吐量，另外中间件模式可以实现更多高级功能，比如后端数据库资源共享、数据缓存、SQL拦截等保护机制，从整个平台的角度来看，整体收益要更好，但因为存在一个中间环节，因此带来SQL时延和一定的单机性能损耗，经测评，这个损耗在5%-10%之间，基本感知不到。在平台+应用的分布式云应用环境下，从业务与技术分离、降低应用技术门槛、管控等角度看，“中间件模式”更符合我们的能力目标。
4. 分布式数据库的核心：数据分片和路由将一个单表拆分为多个数据库服务器上的多个小表这种数据分片思想，实现千万级别甚至100亿级别的“大表”，通过数据路由以及并行算法，来避免数据规模膨胀导致的性能问题。Table A (逻辑表)路由模块Db1.A (物理表)Db2.A (物理表)Db3.A (物理表)Db1.A (物理表)Db2.A (物理表)Db3.A (物理表)server1server2分片规则SQL解析客户端Select * from a where cola=‘xxx’Hash(cola)对于跨分片的查询SQL，则还要合并结果集并返回客户端
5. 分布式数据库的几个热点和难点问题，及解决思路分布式事务：目前理想做法是用数据库本身的XA分布式事务的能力，将涉及到的分片上的操作纳入到全局事务中，两阶段提交，但XA两阶段提交遇到意外情况导致失败后，数据的修复和回滚可能存在操作上的困难，特别是在主从复制的模型下，因此，实际上建议的是程序业务中的补偿机制，即将失败的SQL重新再执行或者撤销，由业务逻辑控制读写分离：分布式数据库中，读写分离是一个基本需求点，一般做法是由客户端指定某个查询语句是否进行读写分离，然后数据库中间件根据指令将符合条件的查询SQL发到后端从节点上执行，前提条件是后端数据库做了主从同步复制机制关于读写分离过程中的数据时延问题，这个目前没有很好的办法，只能是监控主从同步的时延，忍受一个预定义的延迟时间阀值，超过阀值，则不走从节点，对于持续大量写入数据的表来说，基本上延迟始终有，因此程序端需要判断，哪些表的查询可以走从节点跨分片JOIN：若表A在分片host1主机的1，2，3上，B在host2的1，2，3上，则为了完成A与B的JOIN查询，需要搬迁大量数据到本地，进行编程JOIN，无论是时间消耗还是算法的的复杂度都很高，除了能支持很有限的SQL之外，通常这个处理也很难满足实时性要求。因此，避免跨分片JOIN，成了分片设计的第一原则结果集缓存：对于复杂的SQL，可能消耗数据库服务器很多资源，这类SQL的结果集由中间件缓存下来，对应用透明，会是一个很好的改进，但查询结果集的缓存远比K-V缓存复杂，实现有难度
6. 分布式数据库选型要点支持MySQL，MySQL是目前是使用最为广泛的开源数据库的先锋，由于分布式数据库往往要部署几十个数据库实例，因此采用商业版本数据库代价太大，而其他开源数据库的接受程度则没有MySQL广泛支持基于数据库实例而非Database的连接池共享机制，对于一个表分片为30个物理表的情况，则一次跨分片查询需要同时占用30个后端数据库连接，100并发就是3000个，因此特性很关键支持分布式事务XA，虽然我们建议尽量避免跨分片事务，但个别场景仍然需要，因此必须要支持分布式XA事务分片规则支持自定义，很多时候，应用需要根据不同的表的数据模式和访问模式来制定最优的分片规则。支持负载均衡，避免单点故障支持弹性动态扩展，增加数据库节点或扩容分片表支持读写分离支持服务端的分片SQL基本汇聚功能，如Count，SUM，Group ，Order，Limit等具备基本的管理监控子系统
7. 数据库分片的实施经验和指导分片数量：一个表的分片数量不建议太多，一开始尽量数量少，当低于可接受的性能指标之后，再扩展分片规则：建议的分片规则为范围分片，比如ID，比如数据的时间，范围分片的好处是容易扩容，数据无需移动分片查询：查询SQL尽量能增加分片字段的查询条件，避免跨分片查询，跨分片的SQL导致性能和并发性问题数据热点：频繁访问的数据，与非频频访问的数据交叉在每一个数据库实例上，使得系统负载总体比较均匀，避免数据访问热点分片与分区：分片与分区结合使用，使得单分片的可接受容量最大化，结合合适的数据库索引，提升SQL性能监控：做好系统监控和运维工作，分布式情况下，节点出现故障的概率增大，要及时修复，避免系统无法服务。
8. MySQL分布式数据库的开源项目项目历史成熟度案例社区活跃度特性fabric <1年不成熟少高客户端模式，客户端Driver中实现分片功能Amoeba6年较成熟中等低中间件方式，模拟MySQL Server,实现分片和数据库主从切换Cobar2年成熟多（已经关闭）从Amoeba改造而来，大范围部署使用，稳定性各方面比较好MyCAT1年成熟多很活跃Cobar被阿里放弃之后，在Cobar源码上修复缺陷和引入新特性Cobar被放弃继续发展的一个重要原因是阿里推广其收费云服务RDS,RDS的代码则来自Cobar和TDDL（后者从未公开核心代码，并且与Cobar有关
9. 开源项目MyCAT与Cobar的对比Cobar是目前已知的MySQL分表分片功能做的最好的一个，阿里内部大量使用过，其稳定性和功能经过考验，业界也有广泛使用，但后来不再开源，转向RDS收费产品 Cobar的最终开源版本存在一些深层次的问题，包括数据汇聚、分页等都未能实现，更深层的问题有后端连接的复用问题、阻塞IO导致系统假死和无法支撑更大规模Mysql实例等 MyCAT则是深入研究和分析了Cobar的优缺点以后，针对Cobar的问题作了很多优化，并且考虑了传统业务中关系模型的问题，创新的实现了ER关系分片，以及设计了全局表，用于解决跨节点JOIN的难题目前MyCAT社区有很多用户和开发者，来自不同的公司，持续改进和发展，很活跃，这也是其他几个类似的开源项目所不具备的优势。功能项CobarMyCAT水平分表支持支持分表规则Hash分片Hash分片、范围分片、ER分片后端连接池复用只能Database级别实现Mysql实例级别最大复用读写分离不支持支持存储过程不支持支持数据集合并不支持（select count(*)会返回N条记录，N为表的分片个数支持，count,sum,group by ,以及order by limit等
10. MyCAT公开的性能报告相对直连MySQL，程序连接MyCAT后的性能为85-95%左右多个分片在多个独立的物理机上，总体吞吐性能接近N倍，即单台MYSQL插入的TPS为1万，则5台机器的MYSQL分片集群，TPS接近5万（同时5台机器都插入数据）目前测试过的最大分片表的数据为150亿，5台X86服务器，单表分片1000万，共计1000个分片，一万个网关同时插入数据，吞吐量为2000条/秒，20个用户并发查询1万条记录的时间为1.4s左右（含Web展现），完全符合预计。初步估计，11台高性能X86服务器，每个存储为10T磁盘，万兆交换机，可以实现1000亿单表分片规模数据支持（每个机器分片400个，每个分片1000万数据。
11. 建议采纳基于MyCAT的分布式数据库架构架构客户端程序MyCAT ServerMySQL 实例群组
12. MyCAT分布、集群和高可用方案HA Proxy做负载均衡多台MyCAT Server可以同时工作后端MySQL可以主从搭配，故障自动切换
13. MyCAT的分片规则Hash分片：数据均匀分片在N个后端节点上，优点是数据按主键操作的时候，没有热点问题，缺点是安装范围查询往往会产生跨节点的请求，资源占用多，性能低，另外，分片范围调整和扩容，都比较困难，比较适合类似枚举字段的分片，比如固定的省份分片。范围分片：可以根据时间范围和整数范围分片，连续的数据存放在同一个节点上，是建议的一种分片方式，这种方式，分片范围容易根据业务数据规模进行调整，比如开始是3个分片，当数据量增加，响应变慢，再分裂和增加新分片，为了避免热点问题，可以是不同的表交叉搭配，使得总体上各个MySQL分片的访问都比较均匀 ER关系分片：遵循关系数据库的ER设计，从表的记录跟随主表放在同一个分片上，这样的好处是，每个分片都可以在数据库层面完成JOIN，然后MyCAT可以合并各个分片的JOIN结果，这样就实现了最高效的JOIN结果，对于一些业务来说很有用处。
14. 基于MyCAT的分布式数据库服务架构数据库订购服务MyCAT 集群App1App2多租户管理MyCAT配置管理MyCAT监控MySQL监控App3MySQL Pool分布式数据库能力架构分布式数据库管控功能

分布式数据库选型

quyf

贡献于2016-07-28

分布式数据库选型

PPT 内容

PPT 图集

相关PPT