绵阳网站改版,深圳海外医疗网站建设,去年做那个网站致富,阳江营销网站开发1.TIDB和MySQL对比 对比内容MySQLTiDB架构设计一个传统的单机数据库系统#xff0c;采用主从复制和分区表等方式来实现水平扩展一个分布式的 NewSQL 数据库#xff0c;采用分布式存储和分布式事务等技术#xff0c;支持水平扩展和高可用性事务支持 InnoDB 存储引擎来支持事…1.TIDB和MySQL对比 对比内容MySQLTiDB架构设计一个传统的单机数据库系统采用主从复制和分区表等方式来实现水平扩展一个分布式的 NewSQL 数据库采用分布式存储和分布式事务等技术支持水平扩展和高可用性事务支持 InnoDB 存储引擎来支持事务处理支持 ACID 特性支持 ACID 特性并在分布式环境下提供了分布式事务的支持水平扩展水平扩展能力较弱通常通过主从复制和分区表等方式进行扩展通过简单地增加节点来实现水平扩展支持自动数据分片和负载均衡适合大规模数据存储和处理一致性一致性依赖于配置和复制机制可能存在数据同步延迟或数据不一致的情况基于 Raft 算法实现了多副本之间的强一致性确保数据的一致性和可靠性SQL兼容性关系型数据库的代表支持标准的 SQL 语法兼容 MySQL 协议和 SQL 语法使得迁移和使用更加方便自动化运维TiDB Ansible 工具和 TiDB Lightning 等工具支持快速部署、备份恢复和在线迁移等功能简化了运维管理借助第三方工具或脚本来实现自动化运维存储引擎支持多种数据存储引擎如InnoDB、MyISAM等使用TiKV作为默认的数据存储引擎TiKV是一种基于RocksDB的分布式键值存储引擎 小结TiDB 是一种分布式的 NewSQL 数据库具有水平扩展、高可用性和分布式事务支持等特点适合处理大规模数据和高并发的场景。而 MySQL 则是一种传统的关系型数据库系统适用于中小型应用和对事务一致性要求不是特别高的场景。选择使用哪种数据库取决于具体的业务需求和技术架构 2.什么是TiKV TiKV 是一个分布式事务型的键值数据库提供了满足 ACID 约束的分布式事务接口并且通过 Raft 协议 保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层为用户写入 TiDB 的数据提供了持久化以及读写服务同时还存储了 TiDB 的统计信息数据。 2.1 TiKV整体架构 与传统的整节点备份方式不同TiKV 参考 Spanner 设计了 multi-raft-group 的副本机制。将数据按照 key 的范围划分成大致相等的切片下文统称为 Region每一个切片会有多个副本通常是 3 个其中一个副本是 Leader提供读写服务。TiKV 通过 PD 对这些 Region 以及副本进行调度以保证数据和读写负载都均匀地分散在各个 TiKV 上这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。 2.2 Region 与 RocksDB 虽然 TiKV 将数据按照范围切割成了多个 Region但是同一个节点的所有 Region 数据仍然是不加区分地存储于同一个 RocksDB 实例上而用于 Raft 协议复制所需要的日志则存储于另一个 RocksDB 实例。这样设计的原因是因为随机 I/O 的性能远低于顺序 I/O所以 TiKV 使用同一个 RocksDB 实例来存储这些数据以便不同 Region 的写入可以合并在一次 I/O 中。 2.3Region 与 Raft 协议 Region 与副本之间通过 Raft 协议来维持数据一致性任何写请求都只能在 Leader 上写入并且需要写入多数副本后默认配置为 3 副本即所有请求必须至少写入两个副本成功才会返回客户端写入成功。 当某个 Region 的大小超过一定限制默认是 144MB后TiKV 会将它分裂为两个或者更多个 Region以保证各个 Region 的大小是大致接近的这样更有利于 PD 进行调度决策。同样当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时TiKV 会将比较小的两个相邻 Region 合并为一个。 当 PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本虽然会复制 Leader 的数据但是不会计入写请求的多数副本中。当这个 Learner 副本的进度大致追上 Leader 副本时Leader 会将它变更为 Follower之后再移除操作节点的 Follower 副本这样就完成了 Region 副本的一次调度。 Leader 副本的调度原理也类似不过需要在目标节点的 Learner 副本变为 Follower 副本后再执行一次 Leader Transfer让该 Follower 主动发起一次选举成为新 Leader之后新 Leader 负责删除旧 Leader 这个副本。 2.4 分布式事务 TiKV 支持分布式事务用户或者 TiDB可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上TiKV 通过两阶段提交保证了这些读写请求的 ACID 约束详见 TiDB 乐观事务模型。 2.5 计算加速 TiKV 通过协处理器 (Coprocessor) 可以为 TiDB 分担一部分计算TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiKV 是否可以支持相关下推。计算单元仍然是以 Region 为单位即 TiKV 的一个 Coprocessor 计算请求中不会计算超过一个 Region 的数据。 参考TiKV 简介 | PingCAP 归档文档站 3.什么是RocksDB RocksDB是一个高性能、可扩展、嵌入式、持久化、可靠、易用和可定制的键值存储库。它采用LSM树数据结构支持高吞吐量的写入和快速的范围查询可被嵌入到应用程序中实现持久化存储支持水平扩展可以在多台服务器上部署实现集群化存储具有高度的可靠性和稳定性易于使用并可以根据需求进行定制和优化。它广泛应用于互联网公司和数据密集型应用中。RocksDB使用了许多技术来实现其高性能和可靠性。 3.1 RocksDB主要的技术点 3.1.2 LSM树  LSM树Log-Structured Merge Tree是一种基于日志结构的数据结构能够高效地存储和更新键值数据。它将数据分为多个层每一层都是一个有序的键值存储文件其中较旧的数据位于较低的层较新的数据位于较高的层。当数据被写入时它首先被写入到一个内存中的结构称为内存表MemTable然后在后台异步地将内存表与磁盘上的某个层合并最终生成新的文件。这种设计使得RocksDB能够高效地处理大量写入操作并支持快速的范围查询。 3.1.2 压缩 RocksDB使用了多种压缩算法来压缩数据文件减小了磁盘空间的占用提高了存储效率。压缩算法包括LZ4、Snappy、Zlib等。 3.1.3 并发控制 RocksDB使用多种技术来实现并发控制以支持高并发读写操作。例如它使用锁、读写锁、CAS等机制来保证多线程并发的正确性和一致性。 3.1.4 内存管理 RocksDB使用了多种技术来管理内存以保证高效的内存使用和低延迟的响应。例如它使用了对象池、内存池等技术来减少内存分配和释放的开销使用了缓存技术来缓存热点数据使用了内存映射技术来快速加载数据文件等。 3.1.5 日志系统 RocksDB使用了可插拔的日志系统可以将日志输出到不同的目标例如文件、控制台、网络等以支持不同的日志需求。 3.1.6 文件格式 RocksDB使用了一种自定义的文件格式可以高效地存储键值数据并支持快速的数据访问和查询。这种格式将数据划分为多个块每个块包含多个键值对每个块都有一个索引来支持快速的查找和范围查询。 参考深入RocksDB原理 - 知乎