tidb开源吗_认识TiDB：开源的NewSQL数据库

tidb开源吗

随着企业采用云原生架构，对话自然会导致我们可以做的事情来使数据库水平扩展。答案可能是仔细研究TiDB 。

TiDB是根据Apache 2.0许可发布的开源NewSQL数据库。因为它说的是MySQL协议，所以您现有的应用程序将能够使用任何MySQL连接器连接到它，并且大多数SQL功能仍然相同（联接，子查询，事务等）。

但是，请掩盖所有步骤，并且有所不同。如果您的体系结构基于带有只读副本MySQL，则您会发现TiDB的工作方式略有不同。在这篇文章中，我将介绍TiDB和MySQL之间发现的五个主要关键区别。

1. TiDB本地分发查询执行和存储

使用MySQL，通常会通过复制进行横向扩展。通常，您将拥有一个MySQL主服务器，其中包含许多从服务器，每个从服务器均具有完整的数据副本。使用应用程序逻辑或ProxySQL之类的技术，查询将被路由到适当的服务器（只要安全可以将查询从主服务器卸载到从服务器）。

TiDB的工作方式略有不同：

查询执行是通过TiDB服务器层处理的。通过添加新的TiDB服务器，可以向外扩展SQL处理，这很容易使用Kubernetes ReplicaSets进行。这是因为TiDB服务器是无状态的；其TiKV存储层负责所有数据持久性。
表的数据会自动分割成小块，并分配到TiKV服务器之间。每个数据区域的三个副本（碎片的TiKV名称）保留在TiKV集群中，但是没有TiKV服务器需要数据的完整副本。要使用MySQL术语：每个TiKV服务器同时是主服务器和从服务器，因为对于某些数据区域，它将包含主副本，而对于其他数据区域，它将是辅助副本。
TiDB支持跨数据区域的查询，或者用MySQL术语支持跨分片查询。有关放置不同区域的位置的元数据由放置驱动程序（任何TiDB群集的管理服务器组件）维护。所有操作都完全符合ACID ，并且跨两个区域修改数据的操作使用两阶段提交。

对于学习TiDBMySQL用户，一个简单的解释是TiDB服务器就像一个智能代理，它将SQL转换为成批的键值请求以发送到TiKV。 TiKV服务器使用基于范围的分区存储表。范围会自动平衡，以使每个分区保持96MB（默认情况下，但可配置），并且每个范围可以存储在不同的TiKV服务器上。 Placement Driver服务器跟踪哪些范围位于何处，如果范围太大或太热，则会自动重新平衡范围。

此设计具有横向扩展复制的几个优点：

它独立地扩展了SQL处理和数据存储层。对于许多工作负载，您将首先遇到一个瓶颈。
它通过添加节点（针对SQL和数据存储）来逐步扩展。
它更好地利用了硬件。要将MySQL扩展到一个主副本和四个副本，您将拥有五个数据副本。 TiDB将仅使用三个副本，并通过“放置驱动程序”自动重新平衡热点。

2. TiDB的存储引擎是RocksDB

自2010年以来，MySQL的默认存储引擎一直是InnoDB。在内部，InnoDB使用B + tree数据结构，类似于传统的商业数据库使用的数据结构。

相比之下，TiDB使用RocksDB作为TiKV的存储引擎。 RocksDB对于大型数据集具有优势，因为它可以更有效地压缩数据，并且当索引不再适合内存时插入性能不会降低。

请注意，MySQL和TiDB均支持允许新存储引擎可用的API。例如，Percona Server和MariaDB都支持RocksDB作为选项。

3. TiDB在Prometheus / Grafana中收集指标

跟踪关键指标是维护数据库运行状况的重要部分。 MySQL将这些快速变化的指标集中在Performance Schema中。性能架构是一组内存表，可以通过常规SQL查询来查询它们。

使用TiDB，而不是将指标保留在服务器内部，而是做出了战略选择，将信息运送到同类最佳服务中。 Prometheus + Grafana是当今运营团队中常用的技术堆栈，其中包含的图表使创建自己的警报或配置警报阈值变得容易。

4. TiDB可以更好地处理DDL

如果我们暂时忽略了并非MySQL中的所有数据定义语言（DDL）更改都在线的情况，那么在运行分布式MySQL系统时，更大的挑战就是同时对所有节点上的架构更改进行外部化。考虑一个场景，其中您有10个分片并添加一列，但是每个分片花费不同的时间来完成修改。没有副本就仍然存在这一挑战，因为副本将在主服务器之后处理DDL。

TiDB使用Google F1论文介绍的协议来实现在线DDL。简而言之，DDL更改分为较小的过渡阶段，因此它们可以防止出现数据损坏的情况，并且系统可以一次容忍单个节点落后于一个DDL版本。