TiDB

TiDB 是一个开源的 MySQL 兼容的 NewSQL 混合事务/分析处理（ HTAP）数据库，本文深入探讨TiDB如何在大量的数据上保持毫秒级的查询响应时间，以及 如何为知乎提供支持获得对数据的实时洞察。 墨天轮平台（modb.pro）开设了 TiDB数据库专栏 ，欢迎大家订阅： https://www.modb.pro/db?dbType=7（复制到网站中打开或者点击“阅读原文”）即可查看。 知乎，在古典中文中意为“你知道吗？”，它是中国的 Quora，一个问答网站，其中各种问题由用户社区创建，回答，编辑和组织。 作为中国最大的知识共享平台，我们目前拥有 2.2 亿注册用户，3000 万个问题，网站答案超过 1.3 亿。 随着用户群的增长，我们的应用程序的数据大小无法实现。我们的 Moneta 应用程序中存储了大约 1.3 万亿行数据（存储用户已经阅读过的帖子）。 由于每月累计产生大约 1000 亿行数据且不断增长，这一数字将在两年内达到 3 万亿。在保持良好用户体验的同时，我们在扩展后端方面面临严峻挑战。 在这篇文章中，我将深入探讨如何在如此大量的数据上保持毫秒级的查询响应时间，以及 TiDB 是一个开源的 MySQL 兼容的 NewSQL 混合事务/分析处理（ HTAP）数据库，如何为我们提供支持获得对我们数据的实时洞察。 此文将介绍为什么我们选择 TiDB

docker compose测试环境部署 官方文档:https://pingcap.com/docs-cn/stable/how-to/get-started/deploy-tidb-from-docker-compose/ 要求： Docker（17.06.0 及以上版本） Docker Compose Git #关闭防火墙 systemctl stop firewalld systemctl disable firewalld #centos默认装1.13的docker，卸载原来的docker13 yum -y remove docker* rm -rf /var/lib/docker/ #安装最新的docker,使用阿里云 yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo yum list docker-ce --showduplicates #查询新的docker版本 yum install docker-ce #不指定默认拉取最新的docker systemctl start docker docker version

作者：孙玄，转转公司首席架构师；陈东，转转公司资深工程师；冀浩东，转转公司资深 DBA。 公司及业务架构介绍 转转二手交易网 —— 把家里不用的东西卖了变成钱，一个帮你赚钱的网站。由腾讯与 58 集团共同投资。为海量用户提供一个有担保、便捷的二手交易平台。转转是 2015 年 11 月 12 日正式推出的 APP，遵循“用户第一”的核心价值观，以“让资源重新配置，让人与人更信任”为企业愿景，提倡真实个人交易。 转转二手交易涵盖手机、3C 数码、母婴用品等三十余个品类。在系统设计上，转转整体架构采用微服务架构，首先按照业务领域模型垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元（商品等），继续进行水平拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品 DB / Cache，如下图所示： 项目背景 面临的问题 转转后端业务现阶段主要使用 MySQL 数据库存储数据，还有少部分业务使用 MongoDB。虽然目前情况下使用这两种存储基本可以满足我们的需求，但随着业务的增长，公司的数据规模逐渐变大，为了应对大数据量下业务服务访问的性能问题，MySQL 数据库常用的分库、分表方案会随着 MySQL Sharding（分片）的增多，业务访问数据库逻辑会越来越复杂。而且对于某些有多维度查询需求的表，我们总需要引入额外的存储或牺牲性能来满足我们的查询需求

作者：夏锐航 本文由逊馁队的成员夏锐航同学主笔，介绍 Unified Thread Pool 项目的设计与实现过程。该项目实现了在 TiKV 中使用一个统一的自适应线程池处理读请求，能够显著提升性能，并可预测性地限制大查询对小请求的干扰，最终在 TiDB Hackathon 2019 中斩获一等奖。 距离 TiDB Hackathon 落幕已经过去了半个多月，回忆这次比赛、获奖的经历，依然让我感到非常兴奋。我目前是华南理工大学大三的学生，我和正在 PingCAP 实习的学长奕霖一起组队参加了这次 TiDB Hackathon，比赛的主题为 “Improve”，即提升 TiDB 及相关项目的性能、易用性等。我们项目设计的切入点是： TiKV 现有的线程池在大小查询混合场景下的表现不太优秀。 需要针对不同的环境、场景配置线程池数量，使用和学习成本较高。 于是我和奕霖尝试为 TiKV 重新实现一个线程池来解决这个问题，以达到 Improve 整体表现的效果。除了优化读请求的线程池外，我们计划将这个线程池来代替 TiKV 中其他线程池，最后就产生了我们本次的参赛作品 Unified Thread Pool。 项目设计 在 TiKV 现行的线程池方案中有 Coprocessor、Storage 和 Scheduler 三套线程池。这些线程池原本是设计来分隔不同的任务，减少它们之间的相互影响

作者：Ti-Cool 上周我们推送了《 让数据库运行在浏览器里？TiDB + WebAssembly 告诉你答案 》，向大家展示了 TiDB-Wasm 的魅力：TiDB-Wasm 项目是 TiDB Hackathon 2019 中诞生的二等奖项目，实现了将 TiDB 编译成 Wasm 运行在浏览器里，让用户无需安装就可以使用 TiDB。 本文由 Ti-Cool 队成员主笔，为大家详细介绍 TiDB-Wasm 设计与实现细节。 10 月 27 日，为期两天的 Hackathon 落下帷幕，我们用一枚二等奖为此次上海之行画上了圆满的句号，不枉我们风尘仆仆跑去异地参赛（强烈期待明年杭州能作为赛场，主办方也该鼓励鼓励杭州当地的小伙伴呀 :D ）。 我们几个 PingCAP 的小伙伴找到了 Tony 同学一起组队，组队之后找了一个周末进行了“秘密会晤”——Hackathon kick off。想了 N 个 idea，包括使用 unikernel 技术将 TiDB 直接跑在裸机上，或者将网络协议栈做到用户态以提升 TiDB 集群性能，亦或是使用异步 io 技术提升 TiKV 的读写能力，这些都被一一否决，原因是这些 idea 不是和 Tony 的工作内容相关，就是和我们 PingCAP 小伙伴的日常工作相关，做这些相当于我们在 Hackathon 加了两天班，这一点都不酷。本着「与工作无关

作者：wish 上周我们正式宣布了 TiDB 性能挑战赛 。在赛季内，通过向 TiDB、TiKV、PD 贡献代码完成指定类别任务的方式，你可以获得相应的积分，最终你可以使用积分兑换礼品或奖金。在性能挑战赛中，你首先需要完成几道 Easy 的题目，积累一定量积分后，才能开始挑战 Medium / Hard 难度的题目。 活动发布后，大家向我们反馈 TiKV 任务的资料比较少，上手难度比较高。因此本文以 TiKV 性能挑战赛 Easy 级别任务 PCP: Migrate functions from TiDB 为例，教大家如何快速又正确地完成这个任务，从而玩转“TiDB 性能挑战赛”。这个任务中每项完成后均可以获得 50 分，是积累分数从而挑战更高难度任务的好机会。既能改进 TiKV 为性能提升添砖加瓦、又能参与比赛得到积分，还能成为 Contributor，感兴趣的小伙伴们一起来“打怪”吧！ 背景知识 TiKV Coprocessor（协处理）模块为 TiDB 提供了在存储引擎侧直接进行部分 SQL 计算的功能，支持按表达式进行过滤、聚合等，这样不仅利用起了 TiKV 机器的 CPU 资源，还能显著减少网络传输及相应的 RPC 开销，显著提升性能。大家可以阅读 《TiKV 源码解析系列文章（十四）Coprocessor 概览》 一文进一步了解 Coprocessor 模块。

tidb安装 简介:此教程为不满足硬件条件下的部署(无法用ansible自动部署) 1 下载相应包 tidb-v2.1.16-linux-amd64 版本号自选 2 将响应包拷贝到各个服务器 3 启动相应服务 小提示:启动命令会在当前路径下创建相应文件夹 pd-server启动 nohup /usr/local/tidb/bin/pd-server -initial-cluster="http://host1:2380" -client-urls="http://host1:2379" --data-dir=pd --log-file=pd.log & server启动 tikv启动 nohup /usr/local/tidb/bin/tikv-server --pd="host1:2379" --addr="host2:27011" --store=tikv --log-file=tikv.log & tidb-server启动 nohup /usr/local/tidb/bin/tidb-server --store=tikv --path="host1:2379" --log-file=tidb.log & 4 访问测试 默认端口4000 mysql -uroot -P4000 -h127.0.0.1 第一次需要本机登录 创建用户 grant all privileges

众所周知，在对可用性要求极高的行业领域（比如金融、通信），分布式数据库需要跨地域的在多个数据中心之间建立容灾以及多活的系统架构，同时需要保持数据完整可用。但这种方式同时也带来了一些问题： 跨地域的网络延迟非常高，通常在几十毫秒左右，洲际间更能达到几百毫秒。 跨地域的网络专线带宽昂贵、有限，且难于扩展。 在今年 TiDB Hackathon 的比赛过程中，我们针对以上问题做了一些有趣的事情，并获得如下优化成果： 跨地域 SQL 查询，延迟下降 50%（图 1）。 跨节点消息数减半，即网络流量减半（图 2）。 <center>图 1 延迟对比</center> <center>图 2 网络流量对比</center> “Google Spanner 高性能事务和强一致特性（跨区域甚至跨洲），是每一个做多数据中心架构设计的工程师心中所向往的目标。虽然当前 TiDB 在多数据中心部署时的表现同 Google Spanner 还有明显的差距，但我们很高兴的看到“多数据中心读写优化”项目让 TiDB 向 Spanner 级别多数据中心能力迈出了坚实的一步。相信在社区小伙伴们的共同努力下，假以时日 TiDB 一定能够为大家带来 Google Spanner 级别的体验。” —— 孙晓光（知乎｜技术平台负责人） “在官方推荐的具备同城多活能力的同城三中心五副本，以及两地三中心五副本的部署方案中

28 日，在 2017 易观 A10 大数据应用峰会上，针对“有序漏斗”难题进行行业攻坚的“2017 易观 OLAP 算法大赛”公布了最终结果。PingCAP 参赛组以超过原始基准测试近 30 倍的成绩，获得了商业组的冠军，并作为优秀案例在大会进行了解题思路分享。 PingCAP 作为本次算法大赛商业组参赛队，借助 TiDB 的算法引擎，展现了强大的复杂 OLAP 处理能力。 作为 PingCAP 的核心产品 TiDB 受 Google/F1 启发，具备强大的水平扩展，强一致性的多副本数据安全，分布式事务，实时 OLAP 等特性。依托这些特性，TiDB 彻底改变以往数据库弹性扩容与事务处理不可兼具的境况，将在线事务处理和在线分析处理融为一体，完美适配大数据背景下各行业的数据存储、计算需求。 作为 TiDB 项目中针对解决用户复杂 OLAP 需求的重要组件，TiSpark 将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步烦恼。 本次 2017 易观 OLAP 算法大赛以攻坚“有序漏斗”为考题，TiDB 的算法引擎在处理时将性能作为首要目标，运用多种存储布局和索引手段，对数据进行快速扫描和有效过滤，大量使用 SIMD 技术的向量化计算

全球服游戏如今正在成为出海游戏的主要考虑模式，跨国对战、全球通服打破国界的限制，将不同地区不同语言的玩家放在一起合作/竞技，成功吸引了大量玩家的关注，并逐渐成为主流的游戏玩法。 游戏厂商们也在尝试采用一地部署多地覆盖、全球逐步宣发的模式进行第一款全球服游戏的发行试点及成本控制。文章主要针对全球服和出海游戏的特性优势、架构布局、网络规划、实用技术等几个方面进行探讨。 本文主要观点： (1) 微服务是主流，模块化架构易于扩容以及维护，微服务+自动化的业务架构对于全球服游戏来说几乎是必然的选择； (2) 架构高度自动化，自动注册/剔除保证可用性； (3) 帧同步+UDP特性，高性能传输和带宽成本控制（对战类游戏要求较为突出）； (4) 核心架构集中部署为主，全球网络优化覆盖玩家； (5) 游戏代码的关键帧及预判设计关系到游戏对网络延迟的兼容性。 为什么要微服务和自动化？ 原因一：全球服游戏多为逻辑服或无区服概念的通服、对战类游戏。为了保证游戏性和全球化的特点，保证匹配和游戏世界玩家的多元化，传统意义上的区服架构和跨服对战模式并不适配，以皇室战争、列王纷争等为例的一众匹配对战游戏便是其中的代表。 原因二：全球服游戏要求承载全球玩家的涌入，及时发现负载瓶颈并扩容是一个必然的要求，模块化拆分架构之后可以灵活的针对不同活动、玩家特性增加对应的业务服务器，并通过自动注册机制实现快速扩容。