TiDB

本文由 红凤凰粉凤凰粉红凤凰队 的成员主笔，他们的项目 TiDB Lab 在本届 TiDB Hackathon 2018 中获得了二等奖。TiDB Lab 为 TiDB 培训体系增加了一个可以动态观测 TiDB / TiKV / PD 细节的动画教学 Lab，让用户可以一边进行真实操作一边观察组件之间的变化，例如 SQL 的解析，Region 的变更等等，从而生动地理解 TiDB 的工作原理。 项目简介 简介 TiDB Lab，全称 TiDB Laboratory ，是一个集 TiDB 集群状态的在线实时可视化与交互式教学的平台。用户可以一边对 TiDB 集群各个组件 TiKV、TiDB、PD 进行各种操作，包括上下线、启动关闭、迁移数据、插入查询数据等，一边在 TiDB Lab 上以动画形式观察操作对集群的影响，例如数据是怎么流动的，Region 副本在什么情况下发生了变更等等。通过 TiDB Lab 这种对操作进行可视化反馈的交互模式，用户可以快速且生动地理解 TiDB 内部原理。 功能 实时动态展示 TiDB、TiKV 节点的新增、启动与关闭。 实时动态展示 TiDB 收到 SQL 后，物理算子将具体请求发送给某些 TiKV Region Leader 并获取数据的过程。 实时动态展示各个 TiKV 实例上 Region 副本状态的变化，例如新增、删除、分裂。

作者：吴雪莲 背景知识 SQL 语句发送到 TiDB 后经过 parser 生成 AST（抽象语法树），再经过 Query Optimizer 生成执行计划，执行计划切分成很多子任务，这些子任务以表达式的方式最后下推到底层的各个 TiKV 来执行。 <center>图 1</center> 如图 1，当 TiDB 收到来自客户端的查询请求 select count(*) from t where a + b > 5 时，执行顺序如下： TiDB 对 SQL 进行解析，组织成对应的表达式，下推给 TiKV TiKV 收到请求后，循环以下过程 获取下一行完整数据，并按列解析 使用参数中的 where 表达式对数据进行过滤 若上一条件符合，进行聚合计算 TiKV 向 TiDB 返回聚合计算结果 TiDB 对所有涉及的结果进行二次聚合，返回给客户端 这里的 where 条件便是以表达式树的形式下推给 TiKV。在此之前 TiDB 只会向 TiKV 下推一小部分简单的表达式，比如取出某一个列的某个数据类型的值，简单数据类型的比较操作，算术运算等。为了充分利用分布式集群的资源，进一步提升 SQL 在整个集群的执行速度，我们需要将更多种类的表达式下推到 TiKV 来运行，其中的一大类就是 MySQL built-in 函数。 目前，由于 TiKV 的 built-in 函数尚未全部实现

最近我们扩展了 TiDB 表达式计算框架，增加了向量化计算接口，初期的性能测试显示，多数表达式计算性能可大幅提升，部分甚至可提升 1~2 个数量级。为了让所有的表达式都能受益，我们需要为所有内建函数实现向量化计算。 TiDB 的向量化计算是在经典 Volcano 模型上的进行改进，尽可能利用 CPU Cache，SIMD Instructions，Pipeline，Branch Predicatation 等硬件特性提升计算性能，同时降低执行框架的迭代开销，这里提供一些参考文献，供感兴趣的同学阅读和研究： MonetDB/X100: Hyper-Pipelining Query Execution Balancing Vectorized Query Execution with Bandwidth-Optimized Storage The Design and Implementation of Modern Column-Oriented Database Systems 在这篇文章中，我们将描述： 如何在计算框架下实现某个函数的向量化计算； 如何在测试框架下做正确性和性能测试； 如何参与进来成为 TiDB Contributor。 表达式向量化 1. 如何访问和修改一个向量 在 TiDB 中，数据按列在内存中连续存在 Column 内，Column 详细介绍请看： TiDB

作者：Yuanjia Zhang 在 上篇文章 中，我们介绍了 TiDB 如何实现表达式的向量化优化，以及社区同学如何参与这项工程。两周过去了，我们收到了很多来自社区小伙伴们的建议和反馈，今天在这里和大家分享一下活动进展和这些建议及反馈。 活动进展 先来看看这两周的活动进展吧。截至 9 月 30 日中午，所有 Issue 中需要向量化的函数签名总共有 517 个，目前已完成 89 个，占总体的 17%。其中绝大多数的函数签名向量化都是由社区开发者们完成的，感谢大家的贡献！ 各类型函数签名的完成度如下，我们通过这几个 Issue 来追踪向量化的工作进展，欢迎大家去里面挑选感兴趣的，还未被其他人认领的函数签名去实现： Date/Time builtin functions (7/65) Decimal builtin functions (7/31) Int builtin functions (22/187) JSON builtin functions (1/27) Real builtin functions (28/49) String builtin functions (19/113) Duration builtin functions (5/45) FAQ Q1：前期开发过程中，PR 很容易和主干代码冲突，如何解决？ A1：在前期的开发过程中，我们发现大家的 PR

为什么需要分库分表？ 互联网电商系统创业初期，一般都会采用mysql数据库，可以简单、快速、可靠的实现业务需求。但随着业务的快速发展，数据量越来越多，单个库和单个表就会达到瓶颈，这时候就需要分库分表。分库分表包括分库和分表两个部分，主要有垂直分表、垂直分库、水平分表、水平分库四种方式。 垂直分表 将一个表按照字段分成多表，每个表存储其中一部分字段。 通常我们按以下原则进行垂直拆分: 1. 把不常用的字段单独放在一张表; 2. 把text，blob等大字段拆分出来放在附表中; 3. 经常组合查询的列放在一张表中; 比如下面的商品信息拆成了spu和spu_detail两张表，将大字段description拆分到spu_detail表里。这样做的好处就是我查询spu这类信息的时候不会被商品描述的低效率所拖累。 CREATE TABLE `spu` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'spu id', `title` varchar(255) NOT NULL DEFAULT '' COMMENT '标题', `cid1` int(11) NOT NULL COMMENT '1级类目id', `cid2` int(11) NOT NULL COMMENT '2级类目id', `cid3` int(11) NOT NULL

1、汇总 1.1、问题 多套tidb集群的pd 部署在同样的机器，pd的服务相同，导致pd无法启动 版本：2.1.2 1.2、问题及解决 修改相关文件的端口部分解决 2、具体 2.1、具体问题 2.1.1、系统服务 /etc/systemd/system pd.service 2.1.2、pd的启停脚本 【${deploy_dir}/scripts/start_pd.sh】 #!/bin/bash set -e # WARNING: This file was auto-generated. Do not edit! # All your edit might be overwritten! sudo systemctl start pd.service 【 ${deploy_dir} /scripts/stop_pd.sh】 #!/bin/bash set -e # WARNING: This file was auto-generated. Do not edit! # All your edit might be overwritten! sudo systemctl stop pd.service 郑州冶疗男性不孕不育医院哪家好:http://byby.zztjyy.com/ 2.2、修复 tidb中控机： 【1、更改部署的】 /work/tidb/tidb-ansible

十一长假倒计时 6 天！如果你「没安排、只能宅」，这里有件好玩又 Hack 的事情，你来不来？ TiDB Hackathon 2019 将在 10 月 26 - 27 日举办，比赛主题为「Improve」，参赛选手可以为 TiDB 性能、易用性、稳定性、功能等各方面做出提升，当然也可以围绕 TiDB 生态做一些周边工具提升效率。不仅有大咖导师现场带教，奖金也非常丰厚哦～ 7 天长假备战一场黑客马拉松绰绰有余呀，在家睡觉不如 Hack，约起来吧盆友们！ 学习资料 前序阅读： 深入学习之前，大家需要对 TiDB 的架构和基本原理有一定的了解，请先阅读以下几篇文章： TiDB 架构 说存储 说计算 谈调度 TiDB 源码阅读系列文章（二）初识 TiDB 源码 TiDB 源码阅读系列文章（三）SQL 的一生 TiDB 是集群的 SQL 层，承担了与客户端通讯（协议层）、语法解析（SQL Parser）、查询优化（Optimizer）、执行查询计划等工作。 TiKV 是分布式存储层，内部结构可分为多层，每层有各自的功能，从底向上分别为：RocksDB、Raft、Raft KV、MVCC、TXN KV、Coprocessor。 PD 在集群中的地位是一个逻辑上的单点，类似于很多系统中都有的 master server 或者 meta server 之类的组件，PD

一、概述 本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 二、基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 1、分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 2、高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 3、集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 4、负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 5、正向代理和反向代理 系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问

一、 ElasticSearch 是什么 • 搜索引擎 ： 一切设计都是为了提高搜索的性能 • 分布式，高可用，易扩展 • Lucence ：最 先进、性能 最好、 功能最全的搜索引擎库 二、 Why not DB? • Redis ：是一个高性能的 key-value 数据库。 • HBase ： HBase 是一个分布式的、面向列的开源数据库。 • Tidb ：开源分布式 NewSQL 数据库。 • MySQL ： MySQL 是一个关系型 数据库管理系统。 • Elasticsearch ：是 一个分布式、可扩展、实时的 搜索引擎 • 全索引 三、核心概念 四、 行存储？列存储？ 参考链接： https://blog.csdn.net/genghaihua/article/details/88946228 es 的底层存储使用 lucene ，主要包含行存储（ storefiled ），列存储（ docvalues ）和倒排索引 ( invertindex ) 。 大多数使用场景中，没有必要同时存储这三个部分，可以通过下面的参数来做适当调整 1 mapping type index 设置 "_source": { "enabled": false } StoreFiled： 行存，其中占比最大的是_source字段，它控制doc原始数据的存储。在写入数据时

本文作者是来自 CC 组的兰海同学，他们的项目《让 TiDB 访问多种数据源》在本届 TiDB Hackathon 2018 中获得了二等奖。该项目可以让 TiDB 支持多种外部数据源的访问，针对不同数据源的特点会不同的下推工作，使 TiDB 成为一个更加通用的数据库查询优化和计算平台。 我们队伍是由武汉大学在校学生组成。我们选择的课题是让 TiDB 接入若干外部的数据源，使得 TiDB 称为一个更加通用的查询优化和计算平台。 为什么选这个课题 刚开始我们选择课题是 TiDB 执行计划的实时动态可视化。但是填了报名单后，TiDB Robot 回复我们说做可视化的人太多了。我们担心和别人太多冲突，所以咨询了导师的意见，改成了 TiDB 外部数据源访问。这期间也阅读了 F1 Query 和 Calcite 论文，看了东旭哥（PingCAP CTO）在 PingCAP 内部的论文阅读的分享视频。感觉写一个简单 Demo，还是可行的。 系统架构和效果展示 如上图所示，TiDB 通过 RPC 接入多个不同的数据源。TiDB 发送利用 RPC 发送请求给远端数据源，远端数据源收到请求后，进行查询处理，返回结果。TiDB 拿到返回结果进一步的进行计算处理。 我们通过定义一张系统表 foreign_register(table_name,source_type,rpc_info)