TiDB

TiDB

https://blog.csdn.net/D_Guco/article/details/80641236

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。
一 TiDb简介
　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点：
1 高度兼容 MySQL
　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
2水平弹性扩展
　通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3分布式事务
　TiDB 100% 支持标准的 ACID 事务。
4 真正金融级高可用
　相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
5 一站式 HTAP 解决方案
　TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程。
6云原生 SQL 数据库
　TiDB 是为云而设计的数据库，同 Kubernetes （十分钟带你理解Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
　TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力.

二 TiDb 整体架构
这里写图片描述
　TiDB 集群主要分为三个组件：
１TiDB Server
　TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或F5）对外提供统一的接入地址。
２PD Server
　Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader的迁移等）；三是分配全局唯一且递增的事务 ID。 　　
　PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
　TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
三 核心特性
1 水平扩展
　无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。
2 高可用
　高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
　TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
　PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
　TiKV 是一个集群，通过 Raft 协议（raft一致性哈算法以及Raft 为什么是更易理解的分布式一致性算法 ）保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。
四 TiDb技术内幕
　1 保存数据 TiDB 技术内幕 - 说存储
　2 计算（很关键如何做sql运算） TiDB 技术内幕 - 说计算
　3 调度(Tidb集群管理) TiDB 技术内幕 - 谈调度
五 安装部署
　tidb安装部署，可能比较麻烦，一步步照着做，如果公司有专门的运维，这个工作可以由运维来搞，但是大多数的中小公司是没有的，都是开发者兼职运维，所以作为一个开发者，还是了解下比较好。 安装部署
声明
　以上只是对tidb资料的简单整理和对tidb的一个基本了解，更详细的资料可以转至tidb的官方文档，注意里面的常见问题和解答，很有用：PingCAP Tidb官方文档

SQL 、 NoSQL 和 NewSQL 的优缺点比较

SQL作为主要的数据存储方式已经超过40年，并且经历了至少两个指数扩张期：20世纪90年代Web应用程序崛起之后，以及在过去十年中由于移动设备爆炸引起的扩张。 因此，越来越小的公司开始发现使用数据库的好处，而像Google这样的互联网巨头则已经将数据单位上升到PB或甚至EB。

在SQL 的发展过程中，产生了许多迭代产品，其中最重要的是SQL，NoSQL和NewSQL — 它们一起负责绝大部分的数据库市场。

所以，如果你要选择一个数据库工具，你应该选择哪一个？ 其实，没有明确的答案。 不同的人和公司选择不同，这更多地取决于他们对每个特定项目的偏好和相对优势，而不是其中一个对其他所有的直接优势。 那么，这些优点和缺点是什么？ 让我们来看一下。

SQL

SQL是关系型数据库管理系统（RDBMS），顾名思义，它是围绕关系代数和元组关系演算构建的。 70年代以来，它一直是主要的数据库解决方案，只是最近才有了其他产品的空间。 不管有些人说什么，这意味着它一直能出色地执行广泛的任务。 其主要优点如下：

第 2 段（可获 1.66 积分）

0
solowolf
2年前
•不同的角色（开发者，用户，数据库管理员）使用相同的语言。
•不同的RDBMS使用统一标准的语言。
•SQL使用一种高级的非结构化查询语言。.
•它坚持 ACID 准则 (原子性，一致性，隔离性，持久性),，这些准则保证了数据库尤其是每个事务的稳定性，安全性和可预测性。

如你所见，许多SQL的好处来源于它的统一性，舒适性和易用性。 即使你只有非常有限的SQL知识（或完全没有，如果需要），你可以在像 online SQL Query Builder 这样的特殊工具帮助下使用它。

第 3 段（可获 1.33 积分）

0
solowolf
2年前

然而，它的缺点使得它非常不适合某些类型的项目。 SQL的主要问题是它难以扩展，因为它的性能随着数据库的变大而快速下降。 分布式也是有问题的。

NoSQL和NewSQL出现的原因之一是，以前的RDBMS的设计不能满足现代数据库每秒处理的事务数量。 像亚马逊或阿里巴巴等需要处理惊人数据量的巨头，以前的RDBMS会在几分钟内出现问题。

第 4 段（可获 1.18 积分）

0
solowolf
2年前

NoSQL (Not Only SQL)

NoSQL越来越受欢迎，其中最重要的实现是Apache Cassandra，MongoDB等产品。 它主要用于解决SQL的可扩展性问题。 因此，它是没有架构的并且建立在分布式系统上，这使得它易于扩展和分片。

然而，这些好处是以放宽ACID原则为代价的：NoSQL采取最终一致性原则，而不是所有四个参数在每个事务中保持一致。 这意味着如果在特定时间段内没有特定数据项的更新，则最终对其所有的访问都将返回最后更新的值。 这就是这样的系统通常被描述为提供基本保证的原因（基本可用，软状态，最终一致性） — 而不是ACID。

第 5 段（可获 1.76 积分）

0
solowolf
2年前

虽然这个方案极大地增加了可用时间和伸缩性,它也会导致数据丢失----这个问题的严重程度取决于数据库服务器的支持情况和应用代码质量.在某些情况下,这个问题十分严重.

另一个NoSQL出现的问题是现在有很多类型的NoSQL系统,但它们之间却几乎没有一致性.诸如灵活性,性能,复杂性,伸缩性等等特性在不同系统间差别巨大,这使得甚至是专家在他们之间都很难选择.不过,当你根据项目特点作出了合适的选择,NoSQL可以在不显著丢失稳定性的情况下提供一个远比SQL系统更高效的解决方案.

第 6 段（可获 1.48 积分）

0
KeYIKeYI
2年前

NewSQL

NewSQL是一种相对较新的形式，旨在使用现有的编程语言和以前不可用的技术来结合SQL和NoSQL中最好的部分。 NewSQL目标是将SQL的ACID保证与NoSQL的可扩展性和高性能相结合。

显然，因为结合了过去仅单独存在的优点，NewSQL看起来很有前途; 或许，在未来的某个时候，它将成为大多数人使用的标准。 不幸的是，目前大多数NewSQL数据库都是专有软件或仅适用于特定场景，这显然限制了新技术的普及和应用。

第 7 段（可获 1.3 积分）

0
solowolf
2年前

除此之外，NewSQL在每个方面比较均匀，每个解决方案都有自己的缺点和优势。 例如，SAP HANA可以轻松处理低到中等的事务性工作负载，但不使用本机集群，MemSQL对于集群分析很有用，但在ACID事务上表现出较差的一致性，等等。 因此，在这些解决方案变得真正普及之前，可能还需要一段时间。

结论

围绕SQL有许多谬见和误解：例如，SQL已过时，应该尽可能替换为NoSQL或New SQL。 当然，这不是真的。 目前，在三种基本替代方案中没有明确的领导者 - 每一种都有更适合的项目，而在其他情况下不太适合（或完全不适合）。 因此，没有普遍的理想选择。 例如，如果你主要考虑数据库应始终可用于接受新的内容，则应考虑最终一致性解决方案，如Cassandra或Riak。 如果你追求高速缓存SQL，新的缓存数据库比如VoltDB似乎是明智的选择; 等等。