tidb 学习

TiDB 简介
分布式数据库——TiDB的介绍和基本原理

NewSQL

在NewSql之前，我们接触了Sql，NoSql（Not only Sql）,NewSql。NewSql 被定义为下一代数据的发展方向，他是对各种新的可扩展/高性能数据库的简称，兼具Nosql数据库的海量存储管理能力和关系数据库的ACID特性和SQL便利性。简单的来说：SQL+NoSQL＝NewSQL。NewSQL系统虽然在的内部结构变化很大，但是它们有三个显着的共同特点

它们都支持关系数据模型
它们都使用 SQL作为其主要的接口
满足分布式数据库特点

CAP

CAP & BASE理论

• Consistency(一致性)： 数据一致更新，所有数据变动都是同步的
• Availability(可用性)： 好的响应性能
• Partition tolerance(分区耐受性)： 可靠性

上面的解释可能显得太过抽象，举例来说在高可用的网站架构中，对于数据基础提出了以下的要求：

• 分区耐受性
分布式系统出现网络分区的时候，仍然能够对外提供服务

• 数据一致性
保证数据可持久存储，在各种情况下都不会出现数据丢失的问题。
为了实现数据的持久性，不但需要在写入的时候保证数据能够持久存储
还需要能够将数据备份一个或多个副本，存放在不同的物理设备上，防止某个存储设备发生故障时，数据不会丢失。
在数据有多份副本的情况下，如果网络、服务器、软件出现了故障，会导致部分副本写入失败。
这就造成了多个副本之间的数据不一致，数据内容冲突。

• 数据可用性
多个副本分别存储于不同的物理设备的情况下
如果某个设备损坏，就需要从另一个数据存储设备上访问数据。
如果这个过程不能很快完成，或者在完成的过程中需要停止终端用户访问数据，那么在切换存储设备的这段时间内，数据就是不可访问的。

CAP原理认为，一个提供数据服务的存储系统无法同时完美的满足一致性（Consistency）、数据可用性（Availability）、分区耐受性（Partition Tolerance）这三个条件

关系型数据库和非关系型数据库

关系型数据库（MySQL、PostgreSQL等）问题：
满足CP，但A不完美

非关系型数据库（Redis、MongoDB、HBase等）问题：
满足AP，但C不完美

NewSQL

可以同时满足CAP

理想下能做到：

支持标准SQL
水平扩容，自动容灾
库表权限控制（读写分离）
资源限额

其他

TiDB 适合的场景：
(1) 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时，可以考虑使用 TiDB 无缝替换 MySQL。TiDB 可以提供如下特性：
	吞吐量、存储和计算能力的水平扩展
	水平伸缩时不停服务
	强一致性分布式 ACID 事务
	
(2) 大数据量下，MySQL 复杂查询很慢。
(3) 大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。
(4) 大数据量下，有高并发实时写入、实时查询、实时统计分析的需求。
(5) 有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求。



TiDB 不适合的场景：
(1) 单机 MySQL 能满足的场景也用不到 TiDB。
(2) 数据条数少于 5000w 的场景下通常用不到 TiDB，TiDB 是为大规模的数据场景设计的。
(3)如果你的应用数据量小（所有数据千万级别行以下），且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合使用 TiDB。