正文
TiDB的简单介绍以及进行资源限制的方式与方法
TiDB的简介
TiDB是一个分布式数据库, 简介为:
TiDB 是一个开源的分布式关系型数据库，它兼具了分布式数据库的水平扩展性和传统关系型数据库的 ACID 事务特性。
TiDB 最初由 PingCAP 公司开发，并于 2015 年开源发布。创始人自己开发发布过 codis redis分布式中间件. 在redis cluster发布之前非常流行.
TiDB 的设计目标是解决传统关系型数据库在大规模数据集、高并发读写和高可用性方面的挑战。
它采用了分布式架构，通过将数据水平分片存储在多个节点上，以支持数据的水平扩展。
同时，TiDB 采用了分布式事务协议以保证 ACID 事务的一致性和可靠性。
与传统数据库不同的是，TiDB 采用了分布式共享存储架构，其中包括了三个核心组件：
TiDB Server：负责接收和处理 SQL 请求，处理连接管理、查询优化、执行计划等任务。
TiKV：是一种分布式 Key-Value 存储引擎，负责存储数据和处理事务。它以水平分片的方式存储数据，并提供高度可用性和一致性的保证。
PD（Placement Driver）：是 TiDB 中的元数据管理模块，负责集群的拓扑管理、数据的分片调度和故障自动处理等。
TiDB 还提供了一些高级特性，如分布式 SQL 查询优化器、自动化水平扩展、副本数据自动修复、在线数据迁移等。
此外，TiDB 还支持使用一些常见的 SQL 方言（如 MySQL、PostgreSQL）的语法和协议，以便现有应用可以无缝迁移到 TiDB 上。
总的来说，TiDB 是一个以分布式架构为基础的开源关系型数据库，具备可水平扩展、高性能、高可用性和 ACID 事务特性等优势，
适用于大规模数据存储和高并发读写的场景。
另外TiDB还有一个 TiFlash 的组件作为OLAP的扩展特性.
TiFlash fork了 ClickHouse 的代码, 并且与TiKV的raft 日志深度集成
可以自己从TiKV里面获取数据库变化数据, 然后从行存转换为列存.
TiDB的部署方式
TiDB建议较高的硬件配置进行部署.
并且TiDB-TiKV-TiFlash 不建议混布,会出现比较严重的资源争用.
建议至少3个PD, 三个TiDB, 三个TiKV 并且最小的副本数建议设置为3
不建议单副本运行 会出现很严重的数据丢失的风险.
TiFlash 可以部署单节点, 并且使用单副本.
TiFlash 的数据都是来自于TiKV, 副本丢失后可以从Tikv中再次读取
非常不建议 TiKV和TiFlash以及他们互相部署到同一块硬盘上面
建议至少部署到不同的硬盘, 一方面保证性能, 另一方面保证数据安全性.
混布时的资源限制
TiDB默认是单服务器单独部署一个role一个node
所以他会最大化的使用机器的资源
如果是混布, 会导致非常严重的资源争用,大查询时会立即导致系统宕机.
所以需要进行一下资源限制.
建议方式:
tiup cluster edit-config xxxxtidb
建议在
server_configs: 下面进行全局修改. 一个范例为:
server_configs:
tidb:
performance.max-procs: 32
tikv:
raftstore.apply-pool-size: 16
readpool.unified.max-thread-count: 16
storage.block-cache.capacity: 64G
pd:
replication.enable-placement-rules: true
replication.location-labels:
- host
tidb_dashboard: {}
tiflash:
performance.max-procs: 24
performance.memory-quota: 128G
结果也比较简单, 可以明确看出来
max-procs 限制CPU的多少
memory 后者是block-cache 限制内存的大小.
TiKV通过
raftstore.apply-pool-size: 16
readpool.unified.max-thread-count: 16
方式限制CPU的使用.
