TiDB

主要的需求 针对大体量表的OLAP统计查询，需要找到一个稳定，高性能的大数据数据库，具体使用 数据可以实时的写入和查询，并发的tps不是很高 建立数据仓库，模式上主要采用星星模型、雪花模型，或者宽表 前端展示 分为3类 saiku、granafa、c#代码开发 数据体量：事实表在3-5亿、维度表大的在500万左右 数据集成：可以和现在使用的kettle进行无缝集成 基于以上需求，前期使用tidb，但是在大体量表的olap查询性能不是很好，使用tipark 离线计算还可，但是时间上无法满足系统需求，初步了解到mpp架构的greenplum。因此先期进行了简单比较 基础测试数据表说明 数据表 订单宽表，数据表字段为300个左右 基本的测试结果 --不包含并发测试 集群基本配置 ： Greenplum 4台8核56G，9个segments 表：列存，无索引 tidb ：6台8核56G，ssd tpc-ds tpc-h 其余测试 -- 小结 针对OLAP的查询，greenplum 的分析统计性能要优于tidb 在greenplum不使用索引的情况下，点差要比tidb 差不少，增加对应的索引之后，性能差不多，但是greenplum 不建议使用索引 greenplum在列存的场景下，查询的列的个数对性能影响较大。 下一步验证 1.星星模型 下的性能，考虑事实表 3亿，维度表 500万， 2

作者介绍 ：刘春雷，58 集团高级 DBA，负责 MySQL 和 TiDB 的运维工作，TUG Ambassador。 58 集团业务种类繁多，目前包括的业务有 58 同城、赶集网、安居客、58 金融公司、中华英才网、驾校一点通等，数据库种类包括 MySQL、Redis、MongoDB、ES、TiDB。我们自己构建了“58 云 DB 平台”，整合了所有数据库的一体化运维。 本文将重点从运维的角度，介绍 TiDB 在 58 集团应用实践及后续计划。 一、TiDB 在 58 集团的使用概况 我们目前使用 TiDB 的服务器为 50+ 台，服务器的配置为 24 核的 CPU，128G 内存，用的是宝存的闪存卡。部署 TiKV 实例 88 个，集群共 7 套，每个业务一套集群，涉及到 TiDB 多个版本。由于是单集群多个库，目前库的数量大概是 21 个左右。磁盘目前数据量并不算大，在 10T 左右。涵盖的业务线大概目前有 7 条，包括 58 招聘、TEG、安居客、用户增长、信息安全、金融公司还有车业务，后续还会有比较多的业务推进。 二、业务需求及解决方案 <center>图 1 业务及需求</center> 业务需求目前有 4 点： 有大容量、需要长期保留的数据 目前 MySQL 都是单机存储，物理机容量有限，大约是 3T 的单机容量，由于磁盘空间瓶颈，MySQL 扩容比较麻烦。

作者：瞿锴，同程艺龙资深 DBA 背景介绍 随着互联网的飞速发展，业务量可能在短短的时间内爆发式地增长，对应的数据量可能快速地从几百 GB 涨到几百个 TB，传统的单机数据库提供的服务，在系统的可扩展性、性价比方面已经不再适用。为了应对大数据量下业务服务访问的性能问题，MySQL 数据库常用的分库、分表方案会随着 MySQL Sharding（分片）的增多，业务访问数据库逻辑会越来越复杂。而且对于某些有多维度查询需求的表，需要引入额外的存储或牺牲性能来满足查询需求，这样会使业务逻辑越来越重，不利于产品的快速迭代。 TiDB 的架构 TiDB 作为 PingCAP 旗下开源的分布式数据库产品，具有多副本强一致性的同时能够根据业务需求非常方便的进行弹性伸缩，并且扩缩容期间对上层业务无感知。TiDB 包括三大核心组件：TiDB/TiKV/PD。 TiDB Server：主要负责 SQL 的解析器和优化器，它相当于计算执行层，同时也负责客户端接入和交互。 TiKV Server：是一套分布式的 Key-Value 存储引擎，它承担整个数据库的存储层，数据的水平扩展和多副本高可用特性都是在这一层实现。 PD Server：相当于分布式数据库的大脑，一方面负责收集和维护数据在各个 TiKV 节点的分布情况，另一方面 PD 承担调度器的角色

作者：RickyHuo 本文转载自公众号「大道至简bigdata」 原文链接 ： 优秀的数据工程师，怎么用 Spark 在 TiDB 上做 OLAP 分析 TiDB 是一款定位于在线事务处理/在线分析处理的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 OLAP 等重要特性。 TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它借助 Spark 平台，同时融合 TiKV 分布式集群的优势。直接使用 TiSpark 完成 OLAP 操作需要了解 Spark，还需要一些开发工作。那么，有没有一些开箱即用的工具能帮我们更快速地使用 TiSpark 在 TiDB 上完成 OLAP 分析呢？ 目前开源社区上有一款工具 Waterdrop，可以基于 Spark，在 TiSpark 的基础上快速实现 TiDB 数据读取和 OLAP 分析。项目地址： https://github.com/InterestingLab/waterdrop 使用 Waterdrop 操作 TiDB 在我们线上有这么一个需求，从 TiDB 中读取某一天的网站访问数据，统计每个域名以及服务返回状态码的访问次数，最后将统计结果写入 TiDB 另外一个表中。 我们来看看 Waterdrop 是如何实现这么一个功能的。 Waterdrop Waterdrop

前言： 又好久没写博客了，估计又要水一篇了，先写写看吧。 介绍： 数据现阶段大致分为三种，sql数据库，nosql数据库，newsql数据库，sql数据库最具代表就是我们常用的mysql数据库，这种数据库是关系型数据库，表，主外键关联，nosql数据库我们常用的如mongdb数据库，他以文档形式存储，每个类似json字符串的存储方式，发展到最近又出现了newsql数据库，简单的来说newsql数据库既有nosql数据库存储大数据的特性，又有sql数据库关系表，能用sql语句查询，事物等特性，TiDB数据库就是newsql数据库。 特性： 分布式，支持水平扩展 高可用，机器挂了部分不影响服务 ACID ，强一致 sql特性，关系型数据库 架构： 三大核心组件 TiDB TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展。 PD Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

一 创建nfs（maste节点操作，两个node节点也需要安装） 1 首先安装一个nfs服务器，配置共享目录, [yx@tidb-tidb-02 ~]$ cat /etc/exports /home/yx/hnf *(rw,no_root_squash) 然后启动nfs 2 然后在master上面创建一个nfs pv的动态供给，需要三个文件class.yaml deployment.yaml rbac.yaml 这三个文件去网上下载 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy rbac是让nfs有权限访问apiserver，其中需要更改的地方是deploynment.yaml里面的nfsip地址和nfs所共享的目录 kubectl create -f rbac.yaml kubectl create -f class.yaml kubectl create -f deployment.yaml #第一次创建的时候回提示存在，不知道什么原因，然后删除，再次创建即可 最后查看是否创建成功 [yx@tidb-tidb-03 nfs]$ kubectl get pods NAME READY STATUS RESTARTS AGE nfs-client

作者：Yao Wei 11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果： 过去一个月共吸引了来自社区的 156 位贡献者，包括： 14 支参赛队伍。 110 位个人参赛者。 参赛选手们总共完成了 147 个挑战任务，这些成果已经逐步落地到 TiDB 产品中： TiDB 表达式框架中完成了 70+ 个函数的向量化。 TiKV 协处理器中完成了 40+ 个函数的向量化，其中 34 个已在 TiDB 侧新开启了下推，让下推的函数计算速度大幅上升。 截至发稿时积分排行榜前五名的参赛选手 / Team 分别是：. team、ekalinin、mmyj、AerysNan、js00070。 * 其中 .* team 表现尤为优异，他们已经拿到了 4150 积分，在排行榜上遥遥领先。而来自俄罗斯的个人参赛者 ekalinin 获得了 1450 积分，是目前积分最高的个人参赛者，他共提交了 17 个任务，目前完成了 12 个，其中包含一个 Medium 难度的任务。​ <center>积分排行榜</center> “因为对 Rust 感兴趣参加了这次 PCP

作者介绍：我和我的 SQL 队（成员：杜沁园、韩玉博、黄宝灵、满俊朋），他们的项目「基于路径统计的 sql bug root cause 分析」获得了 TiDB Hackathon 2019 的三等奖。 曾在 Hacker News 上看到过一个 Oracle 工程师处理 bug 的 日常 ： 先花两周左右时间来理解 20 个参数如何通过神奇的组合引发 bug。 改了几行代码，尝试对 bug 进行修复，提交测试集群开始跑近百万个测试 case，通常要 20~30 小时。 运气好的话会有 100 多个 case 没过，有时候上千个也有可能，只好挑选几个来看，发现还有 10 个参数之前没有注意到。 又过了两周，终于找到了引起 bug 的真正参数组合，并跑通了所有测试。并增加 100 多个测试 case 确保覆盖他的修改。 经过一个多月的代码 review，他的修改终于合并了，开始处理下一个 bug…… 后来这个工程师感慨说：“I don't work for Oracle anymore. Will never work for Oracle again!” Oracle 12.2 有将近 2500 万行 C 代码，复杂系统的测试是一件艰难、艰苦和艰巨的事情。而测试一个分布式数据库的情况就更复杂了，我们永远不知道用户可能写出什么样的 SQL，表结构和索引有多少种组合