vs进行网站建设建设自己网站的流程

vs进行网站建设,建设自己网站的流程,合肥php网站开发,wordpress模板首页是哪个文件一、TiDB引入 1.1、数据库技术发展简史 数据库技术的形成过程和发展可分为如下三个阶段#xff1a;层次和网状数据库管理系统-可以理解为使用指针来表示数据之间的联系关系数据库管理系统(RDBMS)-可以理解为理解为使用二维表来表示维护数据间的关系新一代数据库技术的研究和发…一、TiDB引入1.1、数据库技术发展简史数据库技术的形成过程和发展可分为如下三个阶段层次和网状数据库管理系统-可以理解为使用指针来表示数据之间的联系关系数据库管理系统(RDBMS)-可以理解为理解为使用二维表来表示维护数据间的关系新一代数据库技术的研究和发展-针对关系型数据库存在数据模型性能扩展性伸缩性等方面的缺点出现了ORDBMS:面向对象数据库技术。如PostGreSQLNoSQL:非结构化数据库技术。如键值存储数据库Redis列式储数数据库HBase文档型数据库MongoDB图形数据库Neo4JNewSQL:这类数据库不仅具有NoSQL对海量数据的存储管理能力还保持了传统数据库支持ACID和SQL等特性。如TiDB1.2、从MySQL到TiDB1.2.1 场景引入假设现在有一个核心业务库MySQL的数据量已经近亿行,且还在不断增长中,所有数据要求多副本保存至少5年,且除了有对历史数据进行统计分析的离线报表业务外,还有一些针对用户数据实时查询的需求,如用户历史订单实时查询1.2.2 问题分析MySQL能否满足上述场景需求?根据以往的MySQL使用经验MySQL单表在 5000 万行以内时性能较好单表超过5000万行后数据库性能、可维护性都会极剧下降。当然这时候可以做MySQL分库分表,如使用Mycat或Sharding-jdbc分库分表的能否解决问题?分库分表的优点非常明显如将大表拆分成小表单表数据量控制在 5000 万行以内使 MySQL 性能稳定可控。将单张大表拆分成小表后能水平扩展通过部署到多台服务器提升整个集群的性能。但是此方案的缺点也非常明显分表跨实例后产生分布式事务管理难题一旦数据库服务器宕机有事务不一致风险。分表后需要维护的对象呈指数增长MySQL实例数、需要执行的 SQL 变更数量等。分表后汇总查询等跨分片场景较难实现1.2.3 问题解决基于以上核心痛点调研市场上的各大数据库,我们可以考虑选用NewSQL技术来解决,因为NewSQL技术有如下显著特点:无限水平扩展能力分布式强一致性确保数据 100% 安全完整的分布式事务处理能力与 ACID 特性而TiDB数据库 GitHub的活跃度及社区贡献者方面都可以算得上是国际化的开源项目,是NewSQL技术中的代表性产品,所以我们可以选择使用TiDB数据库!1.3、TiDB概述1.3.1 官网https://pingcap.com/index.htmlTiDB可以理解为是MySQL的加强版/分布式MySQL/MySQLPlus1.3.2 简介TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL支持无限的水平扩展具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。TiDB 对业务没有任何侵入性能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题专注于业务开发极大的提升研发的生产力。1.3.3 OLTP和OLAPOLTP 在线事务处理。强调支持短时间内大量并发的事务操作增删改查能力每个操作涉及的数据量都很小比如几十到几百字节。强调事务的强一致性想想银行转账交易容不得差错OLAP 在线分析处理。偏向于复杂的只读查询读取海量数据进行分析计算查询时间往往很长。举例“双十一”结束淘宝的运营人员对订单进行分析挖掘找出一些市场规律等等。 这种分析可能需要读取所有的历史订单进行计算耗时几十秒甚至几十分钟都有可能。二、TiDB架构特性2.1、TiDB 整体架构TiDB 集群主要包括三个核心组件TiDB ServerPD Server 和 TiKV Server此外还有用于解决用户复杂 OLAP 需求的TiSpark 组件和简化云上部署管理的TiDB Operator 组件。以一条插入数据的SQL语句为例SQL到达TiDB Cluster后会先请求PD Cluster拿到TSO事务操作时间戳同样请求PD Cluster拿到数据要存入到TIKV Cluster的哪个位置即图上的Data Location然后将数据组长成Key-Value的形式存入到TIKV Cluster上面。注意保存在TIKV Cluster上面的数据为了数据安全会形成多副本写入数据的时候会写入其中一个TIKV Cluster的region它就是leader身份然后leader向其他follower同步数据。leader与follower之间有心跳检测如果检测到leader心跳消失了follower就会重新推选leader2.1.1 TiDB ClusterTiDB Cluster负责接收 SQL 请求处理 SQL 相关的逻辑并通过 PD 找到存储计算所需数据的 TiKV 地址与 TiKV 交互获取数据最终返回结果。TiDB Server 是无状态的其本身并不存储数据只负责计算可以无限水平扩展可以通过负载均衡组件如LVS、HAProxy 或 F5对外提供统一的接入地址。2.1.2 PD ClusterPlacement Driver (简称 PD) 是整个集群的管理模块大脑其主要工作有三个一是存储集群的元信息某个 Key 存储在哪个 TiKV 节点二是对 TiKV 集群进行调度和负载均衡三是分配全局唯一且递增的事务 ID。上图画了三个PD Cluster有一个是leader另外两个是follower2.1.3 TiKV ClusterTiKV Server 负责存储数据从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。2.1.4 region的作用TiKV Map是一个非常大的Map里面存储了所有的key-value键值对。数据会先写入TiKV Map然后写入TiKV Cluster通常是先写入Leader然后由Leader向Follower进行数据同步。如果是来一条数据就做一次同步就会非常频繁显然效率是不高的。如果是将TiKV Map进行同步它太大了也不合适。于是region就出现了它的默认大小是96M。Leader和Follower进行同步的单位就是region。TiKV Map会根据字节的顺序进行排序划分到不同的region。2.1.5 分布式SQL的执行逻辑现在要从t1表里面查询category_id为1的数据条数。category_id为1的数据会分布到多个TiKV上面。首先会从每个TiKV上面读取行数据然后进行过滤和求和。然后将求和结果上传给TiDB进行最终的求和。2.1.6 TiSparkTiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件将 Spark SQL 直接运行在 TiDB 存储层上同时融合 TiKV 分布式集群的优势并融入大数据社区生态。至此TiDB 可以通过一套系统同时支持 OLTP 与 OLAP免除用户数据同步的烦恼。2.1.7 TiDB OperatorTiDB Operator 提供在主流云基础设施Kubernetes上部署管理 TiDB 集群的能力。它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识集成一键部署、多集群混部、自动运维、故障自愈等能力极大地降低了用户使用和管理 TiDB 的门槛与成本。2.1.8 与传统数据库的对比TiDB的强项不在于轻量的简单SQL的响应速度。对于这种场景传统数据库的性能已经很好了如果使用TiDB由于它分了TiDB Server、TiKV Server、PD Server它们之间要进行网络通信效率肯定是不如传统数据库的。TiDB的强项在于大量高并发SQL的吞吐。横向扩展传统的关系型数据库使用分库分表。以上图的水平分片为例使用Sharding-JDBC将一张客户表根据主键拆分比如说根据主键与数据库实例取模到多个数据库多张表下面这样一张大表的数据就被打散到多张表查询效率就会提高。但是如果要根据主键进行范围查询那这种需求数据库层面是没法实现的就需要在应用层面指定这一次查询要查询哪个数据库这无疑会带来开发维护成本。TiDB天生就解决了上面的问题。数据是存到了TiKV的regionregion就像分片策略的一个分片单位解决了分片的问题。在查询时不需要在业务层面做特别的定制TiDB会向PD Server询问这些数据在哪个region下面。2.2 TiDB 核心特性TiDB 具备如下众多特性,其中两大核心特性为水平扩展与高可用高度兼容 MySQL大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。对于用户使用的时候可以透明地从MySQL切换到TiDB 中只是“新MySQL”的后端是存储“无限的”不再受制于Local的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中。分布式事务TiDB 100% 支持标准的 ACID 事务。一站式 HTAP 解决方案HTAP: Hybrid Transactional/Analytical ProcessingTiDB 作为典型的 OLTP 行存数据库同时兼具强大的 OLAP 性能配合 TiSpark可提供一站式 HTAP 解决方案一份存储同时处理 OLTP OLAP无需传统繁琐的 ETL 过程。云原生 SQL 数据库TiDB 是为云而设计的数据库支持公有云、私有云和混合云配合 TiDB Operator 项目 可实现自动化运维使部署、配置和维护变得十分简单水平弹性扩展通过简单地增加新节点即可实现 TiDB 的水平扩展按需扩展吞吐或存储轻松应对高并发、海量数据场景。真正金融级高可用相比于传统主从 (M-S) 复制方案基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证且在不丢失大多数副本的前提下可以实现故障的自动恢复 (auto-failover)无需人工介入。2.2.1 水平扩展无限水平扩展是 TiDB 的一大特点这里说的水平扩展包括两方面计算能力(TiDB)和存储能力(TiKV)。TiDB Server 负责处理 SQL 请求随着业务的增长可以简单的添加 TiDB Server 节点提高整体的处理能力提供更高的吞吐。TiKV 负责存储数据随着数据量的增长可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度将部分数据迁移到新加的节点上。所以在业务的早期可以只部署少量的服务实例推荐至少部署 3 个 TiKV 3 个 PD2 个 TiDB随着业务量的增长按照需求添加 TiKV 或者 TiDB 实例。2.2.2 高可用高可用是 TiDB 的另一大特点TiDB/TiKV/PD 这三个组件都能容忍部分实例失效不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。1、TiDBTiDB 是无状态的推荐至少部署两个实例前端通过负载均衡组件对外提供服务。当单个实例失效时会影响正在这个实例上进行的 Session从应用的角度看会出现单次请求失败的情况重新连接后即可继续获得服务。单个实例失效后可以重启这个实例或者部署一个新的实例。2、PDPD 是一个集群通过 Raft 协议保持数据的一致性单个实例失效时如果这个实例不是 Raft 的 leader那么服务完全不受影响如果这个实例是 Raft 的 leader会重新选出新的 Raft leader自动恢复服务。PD 在选举的过程中无法对外提供服务这个时间大约是3秒钟。推荐至少部署三个 PD 实例单个实例失效后重启这个实例或者添加新的实例。3、TiKVTiKV 是一个集群通过 Raft 协议保持数据的一致性副本数量可配置默认保存三副本并通过 PD 做负载均衡调度。单个节点失效时会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点会中断服务等待重新选举对于 Region 中的 Follower 节点不会影响服务。当某个 TiKV 节点失效并且在一段时间内默认 30 分钟无法恢复PD 会将其上的数据迁移到其他的 TiKV 节点上。2.2.3 TiDB 存储和计算能力2.2.3.1 存储能力-TiKV-LSMTiKV Server通常是3的TiDB每份数据缺省为3副本这一点与HDFS有些相似但是通过Raft协议进行数据复制TiKV Server上的数据的是以Region为单位进行由PD Server集群进行统一调度类似HBASE的Region调度。TiKV集群存储的数据格式是KV的在TiDB中并不是将数据直接存储在 HDD/SSD中而是通过RocksDB实现了TB级别的本地化存储方案着重提的一点是RocksDB和HBASE一样都是通过 LSM树作为存储方案避免了B树叶子节点膨胀带来的大量随机读写。从何提升了整体的吞吐量。2.2.3.2 计算能力-TiDB ServerTiDB Server本身是无状态的意味着当计算能力成为瓶颈的时候可以直接扩容机器对用户是透明的。理论上TiDB Server的数量并没有上限限制。三、TiDB安装部署https://pingcap.com/docs-cn/stable/overview/#部署方式3.1 TiDB-Local单机版1、下载安装包wgethttp://download.pingcap.org/tidb-latest-linux-amd64.tar.gz2、解压文件tar-zxvftidb-latest-linux-amd64.tar.gz-C/usr/local/src/tidb/3、启动cd/usr/local/src/tidb/tidb-latest-linux-amd64#启动PD./bin/pd-server --data-dirpd --log-filepd.log#启动tikv./bin/tikv-server--pd127.0.0.1:2379--data-dirtikv --log-filetikv.log#启动tidb-server./bin/tidb-server--storetikv--path127.0.0.1:2379--log-filetidb.log4、登录mysql-h192.168.52.111-P4000-u root3.2 TiDB-Docker集群版略四、快速开始4.1 没有主键的表如何存数据如上图由1.3节我们知道一条数据会映射为TiDB的key-value格式value就是数组的内容而key的格式是t[tid]_r[主键id]。如果这个表就没有主键那key是什么呢对于没有主键的表tidb会给一个隐藏字段_tidb_rowid作为表的ID4.2 聚簇索引和非聚簇索引传统关系型数据库聚簇索引主键就是聚簇索引索引和数据保存在一起非聚簇索引索引和数据分开存TiDB聚簇索引TiDB的数据是存储在TiKV上面格式是key-value聚簇索引可以理解为主键就对应这里的key非聚簇索引主键不直接直接对应数据而是主键对应rowidrowid再指向数据TiDB的主键具有如下约束唯一标识表中的行不允许为NULL每个表只允许一个主键如果声明的主键不是INTEGER数据类型TiDB会字段为表创建非聚簇索引如果没有声明主键TiDB会为表创建一个隐式主键_tidb_rowid即主键不一定是聚簇索引五、Java连接TiDB和连接MySQL类似略。六、TiDB技术内幕6.1 Key-Value作为保存数据的系统首先要决定的是数据的存储模型也就是数据以什么样的形式保存下来。TiKV 的选择是 Key-Value 模型并且提供有序遍历方法。简单来讲可以将 TiKV 看做一个巨大的 Map其中 Key 和 Value 都是原始的 Byte 数组在这个 Map 中Key 按照 Byte 数组中的原始二进制比特位比较顺序排列。这是一个巨大的 Map也就是存储的是 Key-Value pair这个 Map 中的 Key-Value pair 按照 Key 的二进制顺序有序也就是我们可以 Seek 到某一个 Key 的位置然后不断的调用 Next 方法以递增的顺序获取比这个 Key 大的 Key-Value6.2 RocksDB任何持久化的存储引擎数据终归要保存在磁盘上TiKV 也不例外。但是 TiKV 没有选择直接向磁盘上写数据而是把数据保存在 RocksDB 中具体的数据落地由 RocksDB 负责。6.3 Raft我们需要想办法把数据复制到多台机器上这样一台机器挂了我们还有其他的机器上的副本复杂来说我们还需要这个复制方案是可靠、高效并且能处理副本失效的情况。听上去比较难但是好在我们有 Raft 协议。6.4 Region对于一个 KV 系统将数据分散在多台机器上有两种比较典型的方案一种是按照 Key 做 Hash根据 Hash 值选择对应的存储节点另一种是分 Range某一段连续的 Key 都保存在一个存储节点上。TiKV 选择了第二种方式将整个 Key-Value 空间分成很多段每一段是一系列连续的 Key我们将每一段叫做一个Region并且我们会尽量保持每个 Region 中保存的数据不超过一定的大小(这个大小可以配置目前默认是 64mb)。每一个 Region 都可以用 StartKey 到 EndKey 这样一个左闭右开区间来描述。6.5 MVCC很多数据库都会实现多版本控制MVCCTiKV 也不例外。6.6 事务TiKV 的事务采用乐观锁