{
    "componentChunkName": "component---src-templates-blog-blog-tsx",
    "path": "/blog/categories/公司动态",
    "result": {"pageContext":{"allBlogsCount":494,"category":{"name":"公司动态"},"blogs":[{"id":"Blogs_516","title":"TiDB 7.4 发版：正式兼容 MySQL 8.0","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"从项目初期开始，TiDB 坚持拥抱 MySQL 生态的产品战略一直延续至今。TiDB v7.4.0 版本发布了对 MySQL 8.0 常用功能的支持，这使得平滑迁移 MySQL 8.0 的应用变得轻而易举。","body":"![tidb7.4-banner.jpeg](https://img1.www.pingcap.com/prod/tidb7_4_banner_52d79a9f67.jpeg)\n\nMySQL 是全球最受欢迎的开源数据库，长期位于 DB-Engines Ranking 排行榜第二名，在世界范围内拥有数量庞大的企业用户和开发者。然而，随着时间的推移，MySQL 用户正面临新挑战。Oracle 官宣将在 2023 年 10 月终止 MySQL 5.7 版本的官方技术支持。据第三方统计显示，目前仍有超过一半的 MySQL 服务器运行在 5.7 版本。在未来几个月，大量的 MySQL 实例必须升级至 8.0 及更高版本，否则将无法享受 Oracle 提供的技术支持和重要补丁更新，企业级用户将面临重大考验。\n\nTiDB 作为新一代分布式关系型数据库，从诞生第一天起拥抱 MySQL 生态，不断地兼容 MySQL 5.7 和 MySQL 8.0，为用户带来更加顺畅的迁移和使用体验。本文将介绍 TiDB 7.4 DMR 在 MySQL 8.0 兼容方面的新进展，探讨 TiDB 如何从根本上解决 MySQL 用户面临的各种挑战。\n\n## MySQL 用户的五大挑战\n\n- 升级影响业务连续性。单实例或 \"主从模式\" 运行的 MySQL 升级时会造成数据库服务的停机，可能会对业务运营造成冲击。运行着大量 MySQL 实例的企业级用户，为了应对升级存在的潜在风险，需要投入大量的人力、物力进行测试和演练。\n- 业务规模扩展困难。随着业务规模的扩大和数据使用场景的增多，用户通常需要在单机容量限制和分片管理复杂度之间进行权衡，数据库扩展的难度制约了业务规模和发展速度。\n- 缺乏极致高可用方案。对于支撑核心业务场景的 MySQL 数据库来说，如果遇到不可预测的宕机事件，恢复业务变得复杂，达成极低的恢复时间目标（RTO）成为数据库管理员的挑战。\n- 实时分析能力不足。MySQL 在处理大规模数据实时分析时性能不如在 OLTP（联机事务处理）场景下出色。这对于需要进行复杂查询和数据分析的业务是一个挑战。\n- 原厂托管服务受限。虽然云服务商都会提供 MySQL 托管服务，但大多缺乏 Oracle 原厂的官方支持。这意味着在处理深层次的产品问题和发现通用功能需求时，用户无法获得来自数据库原厂的快速反馈和支持。\n\n因此，迁移到一个成熟的产品并一举解决上述难题，无疑是明智之举。TiDB 就是 MySQL 全面升级的理想之选。选择 TiDB，不仅可以摆脱 MySQL 升级和扩展性的困境，还能够享受 HTAP、数据库整合等多方面的额外收益。  \n\n## 高度兼容 MySQL 的分布式关系型数据库 TiDB\n\nTiDB 是由 PingCAP 自主研发的企业级分布式关系型数据库，具备水平扩缩容、金融级高可用、实时 HTAP、云原生、兼容 MySQL 5.7 协议和生态等重要特性。TiDB 采用原生分布式架构设计，具备灵活的弹性伸缩能力，整个过程对业务透明，无需人工干预。TiDB 的多副本存储和 Multi-Raft 协议确保数据的强一致性和高可用性，在部分副本发生故障时不影响数据的可用性。TiDB 通过滚动升级的方式使得版本更新的影响降至最低，此外可采用增加临时节点的方式，确保 TiDB 在升级过程中的性能波动和连接闪断控制在 5% 以内，大幅降低升级对业务的影响。  \n\n另外，作为 TiDB 的缔造者，PingCAP 基于全球领先云服务商推出数据库托管服务 TiDB Cloud，服务支持涵盖复杂问题诊断、升级支持、紧急救援等，充分体现了原厂服务的优势。\n\n## 自 TiDB 7.4 DMR 开始，TiDB 正式兼容 MySQL 8.0\n\n从项目初期开始，TiDB 坚持拥抱 MySQL 生态的产品战略一直延续至今。TiDB 兼容 MySQL 的 wire protocol 和语法命令，这意味着 MySQL 客户端、MySQL 驱动程序以及部分 MySQL 工具可以直接在 TiDB 上运行。对于绝大多数在 MySQL 上运行的应用程序来说，几乎不需要修改任何代码。  \n\n随着 MySQL 8.0 的发布，TiDB 在兼容 MySQL 5.7 的基础之上，积极扩展了对 MySQL 8.0 的兼容。TiDB v7.4.0 版本发布了对 MySQL 8.0 常用功能的支持，这使得平滑迁移 MySQL 8.0 的应用变得轻而易举。本文列举了部分功能：  \n\n### 公共表表达式（CTE）  \n\n作为 MySQL 8.0 引入的重要能力， TiDB 从 5.1 版本开始支持 ANSI SQL 99 标准的 CTE 及其递归的写法。在编写复杂查询的时候，利用公共表表达式 (CTE) 可以构建一个临时的中间结果集，在 SQL 语句中引用多次，提高 SQL 语句编写效率，可读性，执行效率。目前版本中，TiFlash 也同样支持 CTE。  \n\n比如表 `authers` 保存了作家的信息，`book_authors` 记录了作家 id 与其所编写书籍 id 的对应关系。  \n  \n```\nmysql> desc authors;\n+------------+--------------+------+------+---------+-------+\n| Field      | Type         | Null | Key  | Default | Extra |\n+------------+--------------+------+------+---------+-------+\n| id         | bigint(20)   | NO   | PRI  | NULL    |       |\n| name       | varchar(100) | NO   |      | NULL    |       |\n| gender     | tinyint(1)   | YES  |      | NULL    |       |\n| birth_year | smallint(6)  | YES  |      | NULL    |       |\n| death_year | smallint(6)  | YES  |      | NULL    |       |\n+------------+--------------+------+------+---------+-------+\n\nmysql> desc book_authors;\n+-----------+------------+------+------+---------+-------+\n| Field     | Type       | Null | Key  | Default | Extra |\n+-----------+------------+------+------+---------+-------+\n| book_id   | bigint(20) | NO   | PRI  | NULL    |       |\n| author_id | bigint(20) | NO   | PRI  | NULL    |       |\n+-----------+------------+------+------+---------+-------+  \n```\n\n利用 CTE， 能够很容易编写出 SQL，列出最年长的 50 位作家分别编写过多少书籍。  \n\n```\nmysql> WITH top_50_eldest_authors_cte AS (\n    ->     SELECT a.id, a.name, (IFNULL(a.death_year, YEAR(NOW())) - a.birth_year) AS age\n    ->     FROM authors a\n    ->     ORDER BY age DESC\n    ->     LIMIT 50\n    -> )\n    -> SELECT\n    ->     ANY_VALUE(ta.id) AS author_id,\n    ->     ANY_VALUE(ta.age) AS author_age,\n    ->     ANY_VALUE(ta.name) AS author_name,\n    ->     COUNT(*) AS books\n    -> FROM top_50_eldest_authors_cte ta\n    -> LEFT JOIN book_authors ba ON ta.id = ba.author_id\n    -> GROUP BY ta.id;\n+-----------+------------+----------------------+-------+\n| author_id | author_age | author_name          | books |\n+-----------+------------+----------------------+-------+\n| 524470241 |         80 | Alexie Kirlin        |     7 |\n|  67511645 |         80 | Bridgette Tromp      |     9 |\n...\n|  48355494 |         80 | Audrey Mayert        |     7 |\n+-----------+------------+----------------------+-------+\n50 rows in set (0.23 sec)  \n```\n \n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/dev-guide-use-common-table-expression \n\n### 窗口函数 (window function)\n\n窗口函数(Window Function)，又被叫做分析函数， 在对数据进行分析、汇总、排序时会被用到。窗口函数能够以 SQL 形式的写法，来完成一些复杂的数据整理工作，协助用户发掘数据价值。例如，数据分组排序， 变化趋势分析等。  \n\nTiDB 目前已经完整支持了 MySQL 8.0 提供的窗口函数，大部分可以下推到 TiFlash 运行。\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/window-functions\n\n### 资源管控\n\nTiDB 在 7.1 版本引入了资源管控，目的是能够对集群资源做合理分配，提升数据库的稳定性，并降低数据库的使用成本。在多个应用共享一个 TiDB 集群的场景下， 资源隔离可以有效降低应用负载变化对其他应用产生的影响， 资源管理还能解决批量作业及后台任务对核心业务的影响，以及突发的 SQL 性能问题拖慢整个集群，是提升大集群稳定性的重要能力。  \n\n尽管和 MySQL 的实现方式有差别，TiDB 兼容了 MySQL 指定资源组的语法以及 hint，降低用户学习成本和迁移成本。另外，TiDB 的资源隔离能够更有效地对最重要的 I/O 资源进行管控，达到和 MySQL 同等甚至更好的效果。  \n\n下面展示了利用资源管控，将 `usr1` 使用的所有资源控制在每秒 500 RU 以内。  \n\n- 预估集群容量\n  \n```\nmysql> CALIBRATE RESOURCE\n``` \n\n- 创建 app1 资源组，限额是每秒 500 RU\n\n```  \nmysql> CREATE RESOURCE GROUP IF NOT EXISTS app1 RU_PER_SEC = 500;\n```\n\n- 将用户与资源组关联， usr1 的会话自动关联到资源组 app1\n\n```\nmysql> ALTER USER usr1 RESOURCE GROUP app1;\n```\n\n- 也可以修改会话所属的资源组\n\n```\nmysql> SET RESOURCE GROUP `app1`;\n```\n\n- 或者利用 hint RESOURCE_GROUP() 指定语句所属的资源组  \n\n```\nmysql> SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control\n\n\n### 基于角色的权限管理\n\nTiDB 支持 MySQL 兼容的角色管理。基于角色的授权，可以简化权限管理的工作，并降低了出错的风险。通过将权限与角色相关联，可以更好地控制数据库的访问。客户可以将不同场景的工作进行分类，创建对应角色，并把角色授予有权限的数据库用户， 数据库用户在实际操作时，根据场景不同，切换角色，降低误操作的可能。  \n\n这里举一个利用角色拆分权限场景的例子。用户 `dev_adm_usr` 作为应用管理员，要操作数据库 `app_db` 的数据，多数情况下只是查询，偶尔在需要做数据修正的时候才会做修改。为了防止 `dev_adm_usr` 的误操作，我们将两部分权限利用角色拆开，只有必要的时候，才给自己赋予读写的角色。  \n\n- 创建角色 app_read_role 和 app_write_role\n\n```\nmysql> CREATE ROLE 'app_read_role', 'app_write_role';\n```\n\n- 为角色授予对应的权限，这里为两个角色分别授予 `app_db` 的读和写的权限  \n\n```\nmysql> GRANT SELECT ON app_db.* TO 'app_read_role'@'%';\nmysql> GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write_role'@'%';\n```\n\n- 将两个角色授予用户 `dev_adm_usr`\n\n```\nmysql> GRANT 'app_read_role','app_write_role' TO 'dev_adm_usr'@'localhost';\n```\n\n- 把 `app_read_role` 设为 `dev_adm_usr` 的默认角色，这样用户 `dev_adm_usr` 登录时默认是只读权限\n\n```\nmysql> SET DEFAULT ROLE 'app_read_role' TO 'dev_adm_usr'@'localhost';\n```\n\n- 当 `dev_adm_usr` 需要修改数据时，启用角色 `app_write_role`\n\n```\nmysql> SET ROLE app_read_role,app_write_role;\n```\n\n或者启用所有角色\n\n```\nmysql> SET ROLE ALL;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/role-based-access-control\n\n\n### 增强 uft8mb4 字符集  \n\nMySQL 8.0 的一个重要变化是默认字符集变成了更通用的 `uft8mb4`，默认排序方式变为 `utf8mb4_0900_ai_ci`。TiDB 在新版本里也加入了 `utf8mb4_0900_ai_ci` 的排序方式，以便更轻松地进行系统迁移。  \n\n为了同时兼容 MySQL 5.7 和 MySQL 8.0，TiDB 支持了 MySQL 兼容的变量 `default_collation_for_utf8mb4`。允许用户调整 `utf8mb4` 字符集的默认排序方式。这个方式确保了 TiDB 在不同 MySQL 版本之间的平滑过渡，并能够适应不同应用程序的需求。  \n\n如果从 MySQL 8.0 迁移，设为 8.0 默认排序 `utf8mb4_0900_ai_ci`\n\n```\nset global default_collation_for_utf8mb4='utf8mb4_0900_ai_ci';\n```\n\n如果从 MySQL 5.7 迁移，设为 5.7 为 `utf8mb4` 的默认排序 `utf8mb4_general_ci`  \n\n```\nset global default_collation_for_utf8mb4='utf8mb4_general_ci';\n```\n\n### JSON 多值索引 (Multi-valued Index)  \n\n在支持了 MySQL 5.7 的完整函数之后，TiDB 在不断添加对 MySQL 8.0 新发布功能的支持。最近的版本支持了\"多值索引\"，允许对 JSON 类型中的某个\"数组\"进行索引，从而提高了对 JSON 数据的检索效率。与 MySQL 用法完全相同，这意味着在迁移过程中，无需修改数据建模或应用程序，用户可以继续按照熟悉的方式操作 JSON 数据。  \n\n多值索引是对普通索引结构的延伸。不同于普通索引与表 1:1 的对应关系， 多值索引与表的对应是 N:1。与 MySQL 相同， 条件中利用 `MEMBER OF()`，`JSON_CONTAINS()`，`JSON_OVERLAPS() `这几个函数检索时，都可能会选择到多值索引。  \n\n比如，我们假定有一张客户信息表，所有详细信息以 JSON 格式编入一个 JSON 类型的列中， 其中有一个数组结构保存客户所在的几个城市。  \n\n![客户信息表示意.png](https://img1.www.pingcap.com/prod/_2cc07b7ff4.png)\n\n当我们需要检索哪些客户在北京时，如果没有多值索引，这个查询需要扫描整张表。  \n\n```\nSELECT name FROM customer\nWHERE 'beijing' MEMBER OF $.city;\n```\n\n这时我们可以针对 `city` 这个数组创建多值索引，上述查询就可以利用索引检索符合的记录，大幅提升查询性能。  \n\n```\nALTER TABLE customers add index idx_city (name, (CAST(custinfo->'$.city' AS char(20) ARRAY)));\n```\n\n和普通索引一样， 当优化器没有选择到多值索引时，可以利用优化器提示 `USE_INDEX()`或 `USE_INDEX_MERGE()` 强制优化器做选择。  \n\n> 相关文档：https://docs.pingcap.com/zh/tidb/stable/choose-index#%E4%BD%BF%E7%94%A8%E5%A4%9A%E5%80%BC%E7%B4%A2%E5%BC%95\n\n### 修改会话变量的 hint ( SET_VAR())  \n\nMySQL 8.0 引入了一个特殊的 hint `SET_VAR()`。利用这个 hint，可以在语句运行期间修改某个会话级系统变量。TiDB 在 v7.4.0 也支持了这个 hint，提升了系统变量设置的灵活度， 能够针对 SQL 语句做“定制”。包括优化器相关的，执行时相关的多个变量都支持用 hint 修改。  \n\n比如，针对大表的分析处理，适当增加 SQL 的执行并行度。  \n\n```\nSELECT /*+ set_var(tidb_executor_concurrency=20) */\n    l_orderkey,\n    SUM(\n        l_extendedprice * (1 - l_discount)\n    ) AS revenue,\n    o_orderdate,\n    o_shippriority\nFROM\n    customer,\n    orders,\n    lineitem\nWHERE\n    c_mktsegment = 'BUILDING'\nAND c_custkey = o_custkey\nAND l_orderkey = o_orderkey\nAND o_orderdate < DATE '1996-01-01'\nAND l_shipdate > DATE '1996-02-01'\nGROUP BY\n    l_orderkey,\n    o_orderdate,\n    o_shippriority\nORDER BY\n    revenue DESC,\n    o_orderdate\nlimit 10;\n```\n\n你也可以利用这个 hint 强制刚才的查询选择 TiFlash，而其他查询保持不变。  \n\n```\nSELECT /*+ set_var(tidb_isolation_read_engines='tidb,tiflash') */\n    l_orderkey,\n    SUM(\n        l_extendedprice * (1 - l_discount)\n    ) AS revenue,\n    o_orderdate,\n    o_shippriority\nFROM\n    customer,\n    orders,\n    lineitem\nWHERE\n    c_mktsegment = 'BUILDING'\nAND c_custkey = o_custkey\nAND l_orderkey = o_orderkey\nAND o_orderdate < DATE '1996-01-01'\nAND l_shipdate > DATE '1996-02-01'\nGROUP BY\n    l_orderkey,\n    o_orderdate,\n    o_shippriority\nORDER BY\n    revenue DESC,\n    o_orderdate\nlimit 10;\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/v7.4/optimizer-hints#set_varvar_namevar_value\n\n### CHECK 约束  \n\n`CHECK 约束` 是一致性约束检查的一种，用来维护数据的准确性。`CHECK 约束`可以用于限制表中某个字段的值必须满足指定条件。当为表添加 CHECK 约束后，在插入或者更新数据时，TiDB 会检查约束条件是否满足，如果不满足，则会报错。  \n\nMySQL 在 8.0 之前只支持 CHECK 约束的语法，在实际运行中并不会真正去检查， 在 8.0 之后才全面支持。TiDB 在新版本中也添加了这个功能， 为了防止客户的 DDL 中有残存的 CHECK 条件，可能会因为这个特性产生问题，TiDB 默认并不会开启 CHECK 约束的检查，而是通过变量 `tidb_enable_check_constraint` 手工开启， 这充分体现了 TiDB 同时兼容 MySQL 5.7 和 8.0 的产品策略。  \n\n```\nmysql> set global tidb_enable_check_constraint=on;\n\nmysql> CREATE TABLE t\n    -> ( a INT CHECK(a > 10) NOT ENFORCED, -- 不生效 check\n    ->   b INT,\n    ->   c INT,\n    ->   CONSTRAINT c1 CHECK (b > c)\n    -> );\n\nmysql> insert into t values (20,20,20);\nERROR 3819 (HY000): Check constraint 'c1' is violated.\n```\n\n> 相关文档：https://docs.pingcap.com/zh/tidb/dev/constraints#check-%E7%BA%A6%E6%9D%9F\n\n## TiDB 工具生态提供平滑迁移体验  \n\n为了降低用户数据迁移的复杂度，TiDB 推出了一款工具 TiDB Data Migration (DM) 。它能够协助用户从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量数据迁移和增量数据同步。DM 支持 DDL 同步，分库分表合并，并内置多种过滤器以灵活适应不同场景，切实地提升了数据迁移的效率。  \n\n## 写在最后  \n\nTiDB 7.4 将是 TiDB 7 系列最后一个 DMR 版本，针对 MySQL 8.0 做出了诸多优化。作为 MySQL 的全面升级，TiDB 的技术领先性帮助用户应对不断变化的业务数据挑战，实现业务的持续增长和创新。TiDB 在高度兼容 MySQL 5.7 和 MySQL 8.0 特性的同时，也将持续提供技术支持，确保用户能够平滑地迁移各类业务应用程序，从而减少迁移过程中的工作量和风险。\n\n浏览 [TiDB 7.4 Release Notes](https://docs.pingcap.com/zh/tidb/v7.4/release-7.4.0)，了解更多新增和优化特性。","date":"2023-10-12","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.4-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"关系型数据库管理系统（RDBMS）的世界正在发生变化，分布式架构和大数据规模下的一致性比以往任何时候都更加必要。分布式SQL引擎的创造者和维护者面临着提供易用性的新范式。虽然 PingCAP 一直将此作为首要任务，但 TiDB 7.2 则直接致力于使 TiDB 数据的管理更加容易。\n\n*版本 7.2 是一个开发里程碑版本（DMR），旨在引入实验性功能，因此不适用于生产环境。对于生产部署，请参考我们最新的稳定版本（LTS）7.1，以及[相应的博客](/blog/tidb-7.1-release)。*\n\n与所有 TiDB 发布博客一样，本文专注于版本发布的主要功能亮点。有关版本的更全面信息，请参阅文档中的官方[发布说明](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。\n\n## 暂停和恢复 DDL 以优先处理关键流量\n\n在前序版本中，TiDB 极大提高了 DDL 尤其是添加索引的速度。即便如此，构建索引仍然是数据库相对最为昂贵的操作之一。在线 Schema 变更使得 TiDB 的用户可以不用因此暂停业务，但数据重组的在线性质可能会对前台工作负载产生影响，尤其是对延迟和抖动敏感度高的在线业务：数据规模越大，耗时越长，您的在线流量暴露的风险就越高。虽然用户可以通过限制并发度来减少对前台流量的干扰。然而，即使如此，仍然可能会出现资源干扰的情况。\n\n为了解决这类问题，TiDB 7.2 引入了在 DDL 操作暂停能力：用户可以暂停正在进行的 DDL 操作，并在合适的时机恢复操作。\n\n总体而言，这使 DDL 操作能够在大规模数据重组对性能的影响提供了手动干预的手段，并且无需重新启动操作而因此丢失 DDL 操作进度。\n\n## 通过资源组控制不良查询的影响\n\n在最新的[稳定版本 7.1 ](/blog/tidb-7.1-release)中，通过资源组实现资源控制的功能正式 GA。该功能的目的是在同一集群上保持多个独立工作负载的性能稳定。该功能的底层机制也正好适用于一些可操作性的增强。\n\nTiDB 7.2 基于执行时间引入了基于[资源组](https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control)的全局查询超时概念，并将该控制功能提升到资源组的层面，使其更加细粒度。现在，归类为业务逻辑组的查询可以拥有自己的超时设置，避免了在集群中为所有工作负载和查询组确定“一刀切”的超时时间的需求。\n\n## 从远程对象存储中导入到 TiDB\n\n如果您是当前的 TiDB 用户，您可能已经熟悉导入服务 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview)。它是一个独立的服务，具备完整的导入功能，可以通过事务层逻辑方式和通过文件系统直接进行物理导入数据。\n\n为了使从其他来源加载数据更简单，并且避免用户需要部署这个独立的服务，TiDB 7.2 将 Lightning 的物理导入服务整合到 TiDB 本身中。通过直接整合到 TiDB 中，不仅部署变得更简单，而且还为管理数据加载提供了一个 SQL 接口。在这里包含 Lightning 的功能还意味着可以直接从 AWS S3 和 Google Cloud Storage (GCS) 加载数据。\n\n有关更多信息，请[参考文档](https://docs.pingcap.com/zh/tidb/v7.2/release-7.2.0)。","author":"PingCAP","category":1,"customUrl":"tidb-7.2-release","fillInMethod":"writeDirectly","id":494,"summary":"TiDB 7.2 致力于简化数据管理，引入了暂停和恢复 DDL 操作、资源组控制查询影响以及将 TiDB Lightning 导入服务整合到 TiDB 中的功能。","tags":["TiDB","Release"],"title":"TiDB 7.2 - 更平滑的操作体验"}},{"relatedBlog":{"body":"![活动 banner.jpeg](https://img1.www.pingcap.com/prod/banner_8a580af0b8.jpeg)\n\nTiDB 7.1 是 2023 年度发布的首个 LTS（Long Term Support） 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本（TCO）。用户可在生产环境中使用 TiDB 7.1。\n\n## 半年版本回顾\n\nTiDB 7.1 LTS 距离上一个 LTS 版本 6.5 已经过去了整半年，在这期间，我们对产品的关键能力做了大量的增强和优化，其中最重要的特性有：\n\n- TiDB 7.0 提供了基于资源组的资源管控（Resource Control）：这使得 TiDB 在针对多租户场景有了很好的应对。事实上，经常有用户希望借助 TiDB 的可伸缩特性将多套业务系统归一到一个集群中，从而使得集群管理、资源利用都能得到有效的改进。资源管控特性提供了对多租户的支持，并解决了不同租户间资源争抢的问题。在新版本中，用户可以很方便地借助这个功能完善数据库整合的使用场景。\n- Multi-RocksDB 特性：借助将单一 TiKV 实例中的 RocksDB 拆成多份，TiKV 的写吞吐提升近三倍；此外，在新架构中数据分片（Region）大小将变得更大，由此减小维护分片所带来的开销，减少单位存储所需的固定 CPU 消耗，更节省成本。这使得大写入吞吐，或者需要大量存放温数据的 Data Serving 场景下，TiDB 的表现得到了本质的提升。\n\n对于这些重要的重量级特性，在新版本中也将持续得到打磨和加强。这半年中，TiDB 在一些关键场景的性能也得到长足提升：\n\n- 数据导入 Lightning 性能提升近 30%；\n- 真实业务测试下，Analyze Table 性能提升 42%+；\n- 标准测试 TPC-H 和真实业务测试下，TiDB 分析能力分别提升 15% 和 25%；\n- TiCDC 针对大型单表复制性能提升可达 90%+。\n\n## TiDB 7.1 介绍\n\nTiDB 7.1 是我们计划在 2023 年发布的两个长期可支持（LTS）版本中的第一个，它为您提供了一个面向未来的数据库，可以为各种关键业务应用程序提供动力。TiDB 7.1 为您带来：\n\n- 更稳定地支持关键业务负载，为 DBA 提供多工作负载稳定性控制，并显著改善尾部延迟；\n- 以更少的资源提供更佳的性能，通过架构增强实现更高的吞吐以及更快的在线 DDL。\n\n此外，TiDB 7.1 企业版增强了数据库审计功能，通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式以及审计日志的生命周期管理，大幅提升系统的审计能力。\n\n### 更稳定地支持关键业务负载\n\n本节中的功能增强都属于集群稳定性的主题。更具体地说，即使在工作负载较大的情况下，TiDB 也可以保障稳定运行，并稳定处理具有特殊情况的工作负载的延迟。\n\n#### 通过资源组改进资源管控的用户体验，提供更好的隔离性\n\n我们在[文章（TiDB 7.0）](/blog/tidb-7.0-release)中介绍了通过资源组进行资源管控的功能，为 TiDB database consolidation （数据库整合）方案奠定了基础，具有里程碑的意义。多个业务可共享同一个 TiDB 集群，DBA 可为不同的工作负载设置资源配额和优先级，例如为关键业务分配更高的优先级，确保其能够优先获得资源，避免受到其他工作负载的干扰。\n\n在 TiDB 7.1 中，资源管控特性正式 GA 了，并加入了两个特性增强：\n\n- 降低了在重写入密集型工作负载中出现的尾延迟：资源组通过资源配额和优先级控制工作负载。优先级由存储级别控制。当工作负载写入繁重时，基于优先级重新调度机制有时会造成更高的尾延迟（Tail Latency）。在 7.1 版本中，尾延迟被修正到预期水准。\n- 增加原生负载校准工具，帮助用户设置更准确的资源资源分配：资源分配的基础是用户对负载的资源使用量有所了解。新增的校准工具将很好的帮助您评估相关信息，以合理配置资源组。最快的方法是从 SQL 接口运行校准命令来估计基准测试（如 TPC-C 和 sysbench）的资源使用情况。\n\n#### 多个热点场景下性能和稳定性提升\n\n对 TiDB 的底层行存储 TiKV 有三个关键增强，以降低延迟提升稳定性（通过 p99 延迟衡量）。新版本引入了三项优化，分别针对三个级别热点进行处理：Key 级别、分片（Region）级别和节点级别：\n\n- Key 级热点：锁冲突优化\n- Region 级热点：TiKV 子任务的批处理化\n- 节点级热点：引入了基于负载的副本读取\n\n**锁冲突优化（GA）**\n\nTiDB 引入了处理 Key 级热点的优化。在遇到许多单点悲观锁冲突的负载中，唤醒等待请求的算法在新版本中将表现得更稳定，最大限度地减少了重试的资源浪费，从而节省了整个集群的资源并降低了尾延迟。测试表明，当启用锁冲突优化时，如果吞吐量相对较小，即使在冲突最严重的工作负载中，新版本的尾延迟也将降低 40-60%。\n\n![QPS.png](https://img1.www.pingcap.com/prod/QPS_08931bca5b.png)\n\n![99 Latency.png](https://img1.www.pingcap.com/prod/99_Latency_b8134dcf7c.png)\n\n**批处理 TiKV 子任务（GA）**\n\n选择性较差的查询可能会导致需要读取许多数据。在 TiDB 的分布式存算分离架构中，这样的查询可能会带来数万或数十万个 RPC 请求用于获取数据，如果使用索引读取则将更进一步加重这一负担。\n\nTiDB 服务器作为 TiKV 客户端，现在可以识别针对同一分片的批处理任务，并将这些批量发送到对应的存储节点。这大大减少了网络的 RPC 开销，使得这些查询更稳定。这个增强可以将相应场景中的延迟减少多达 50%。\n\n**基于负载的副本读取（GA）**\n\n这个特性用于优化节点级读热点。当大批量查询以不均匀的方式发起读取，可能会出现节点热点。注入 Index Lookup JOIN 这类常见的事情都可能会导致这种情况。一旦发生，读取请求会排队，当队列塞满时，一些请求可能会等待相当长时间。我们希望通过更均匀地分配工作来减少延迟。\n\n新版本中，TiDB 引入了基于负载的副本读取来实现这一点。它为队列提供了一个可配置的持续时间阈值，当超过该阈值时，它会告诉 TiDB 开始优先考虑副本读取。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。\n\n有关此优化的更多信息，请[参阅文档](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#scatter-read-hotspots)。\n\n### 更少的资源，更佳的性能\n\n本节中的功能和改进，提升了 TiDB 读、写以及管理操作的性能，以提供更好的用户体验。新版本中，TiDB 增加了多值索引以提供对 JSON 的查询效率。此外，在写入吞吐、分析查询速度和后台任务效率方面也进行了大量的改进和优化。\n\n#### 多值索引（GA）以增加速度和灵活性\n\n多值索引也称为“JSON 索引”，这种新型辅助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引记录到数据记录的 N:1 映射，使得查询可以快速检查存储在 JSON 数组中的特定值。\n\n例如，假设您将这样的数据存储在列中：\n\n```\n{\n\n    \"user\":\"Bob\",\n\n    \"user_id\":31,\n\n    \"zipcode\":[94477,94536]\n\n}\n```\n\n无论该数据存储为 blob，还是邮政编码直接存储为 zip 数组，用户都可以创建多值索引来定位特定邮政编码存在于哪一行。\n\n索引是使用表达式创建的，该表达式将 JSON 数据逻辑解析为生成列（Generated Column）和该列上的二级索引。如果您将 JSON 存储为 blob，并且需要支持遍历多层嵌套的查询，您只需创建一个索引以检索。\n\n有关用法和注意事项的更多详细信息，请参阅[多值索引文档](https://docs.pingcap.com/tidb/dev/sql-statement-create-index/#multi-valued-index)。\n\n#### 更快的 TTL（GA）\n\nTTL (Time to live) 在我们的 [TiDB 6.5 发布的文章](/blog/tidb-6.5-release)中作为一个实验特性进行了介绍，而在 7.1 中这个特性 GA 了。此外在新版本中，TiDB 节点可以共享 TTL 相关任务并并发执行，从而拥有了更好的性能和资源利用率。\n\n#### 延迟物化加速分析查询（GA）\n\nTiFlash 是 TiDB 的列式存储引擎，在 7.1 版本中延迟物化特性 GA。当表扫描拥有高过滤性的时候，TiDB 优化器可选择让 TiFlash 启用延迟物化。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。\n\n此功能的影响取决于实际负载和数据分布。在某些情况下，它可以显著减少延迟（在我们的测试中延迟最高可降低 70%）。TiDB 的查询优化器可以决定是否使用它，默认情况下打开是安全的。\n\n#### Multi-RocksDB 存储引擎带来巨大性能提升\n\n在 TiDB 6.6 中，我们引入了对 TiKV 存储架构的重大更改。虽然这个架构仍然是实验性的（默认关闭，并且只能在新集群中启用），但在这个 LTS 版本中，该特性获得重大加强，并在预生产环境中收到了很好的测试反馈。\n\n在 TiDB 6.6 之前，单一 TiKV 节点所有 Region 共享一个 RockDB 存储引擎。新架构则将不同 Region 分别存放在不同 RocksDB。新架构的好处是显著的：\n\n- 减少 RocksDB 对应的 LSM 负担，增加了吞吐量，测试结果显示写入吞吐量增加了 200%。\n- 使用不同 RocksDB 也会减少 Compaction 带来的写放大，降低资源消耗。\n- 更好的写入吞吐使集群的扩展速度提高 500%。\n- 在测试一些真实的客户工作负载时，我们观察到尾部延迟减少了近 50%。\n- 更小的单位存储消耗，使得集群可扩展性进一步增强。\n\n在 TiDB 7.1 中，我们进一步提高了该特性的性能和稳定性，并添加了网络带宽优化。当前仍然缺失的是 TiCDC、BR 等生态工具的支持，当这些完成后我们将宣布这个特性 GA。\n\n有关更多详细信息，请[参阅产品文档](https://docs.pingcap.com/tidb/dev/partitioned-raft-kv)。\n\n#### Online DDL 的大幅提升（实验特性）\n\n在《[天下武功唯快不破：TiDB 在线 DDL 性能提升 10 倍](/blog/10-times-online-ddl-performance-improvement)》中，我们介绍了 TiDB 索引构建操作性能的提高方式，并在 7.0 版本 GA。在 TiDB 7.1 中，类似于前述 TTL 改进，我们引入了跨 TiDB 节点分配 DDL 作业的框架，以进一步提高性能。\n\n## 立即体验 TiDB 7.1\n\n浏览 [TiDB 7.1 Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-7.1.0)，下载 TiDB [社区版](/product-community/)，了解更多新增和优化特性。\n\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.1-release","fillInMethod":"writeDirectly","id":492,"summary":"TiDB 7.1 是 2023 年度发布的首个 LTS 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本。","tags":["TiDB","Release"],"title":"TiDB 7.1 LTS 发版：为关键业务提供业务稳定性和多租户场景支持"}},{"relatedBlog":{"body":"![TiDB 7.0发版.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_7_0_dd0bec1e31.jpeg)\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。  \n\n资源管控适用于以下场景：  \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况：  \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示：  \n\n![TPC-H 基准测试工具测试结果.png](https://img1.www.pingcap.com/prod/TPC_H_54be3f1f7f.png)\n\n## 自动计划缓存减少查询延迟  \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。  \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。  \n\n![TiFlash 存算分离架构.png](https://img1.www.pingcap.com/prod/Ti_Flash_4db2295760.png)\n<center>图：TiFlash 存算分离架构</center>\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。  \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。  \n\n## 使用 Key 分区提高可扩展性  \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求  \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。  \n\n## 使用 LOAD DATA 从远程存储导入数据  \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。  \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.0-release","fillInMethod":"writeDirectly","id":473,"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","tags":["TiDB","Release"],"title":"TiDB 7.0 发版"}}]},{"id":"Blogs_501","title":"TiDB Serverless 正式商用，全托管的云服务带来数据管理和应用程序开发的全新体验","tags":["TiDB Serverless"],"category":{"name":"公司动态"},"summary":"TiDB Serverless 已经正式商用。作为一款完全托管的 DBaaS 服务，TiDB Serverless 提供了一种功能强大、高性价比的数据管理方案，它可以根据你的需求自动扩展，消除了预设集群规模、资源负载平衡和资源闲置造成的麻烦和浪费，赋能全球企业和开发者。","body":"![Serverless GA.jpeg](https://img1.www.pingcap.com/prod/Serverless_GA_cdc1a046ed.jpeg)\n\n八年前，我们构建了 TiDB，一个开源分布式关系型数据库。我们的目标是重新定义开发者和企业处理数据的方式，满足不断增长的可扩展性、灵活性和性能需求。从那时起，PingCAP 便致力于为开发者和企业提供快速、灵活和规模化的数据库服务，并提供最优秀的用户体验。\n\n去年 11 月，TiDB Serverless beta 版发布，也标志着我们达到了旅程中的一个重要的里程碑。之后的数月里，我们吸引了数以万计的用户，收集到了宝贵的意见和建议，并不断迭代、优化我们的产品。\n\n今天，我们非常高兴地宣布 TiDB Serverless 已经正式商用。作为一款完全托管的 DBaaS 服务，TiDB Serverless 提供了一种功能强大、高性价比的数据管理方案，它可以根据你的需求自动扩展，消除了预设集群规模、资源负载平衡和资源闲置造成的麻烦和浪费，赋能全球企业和开发者。\n\n## 极大简化数据库操作\n\nTiDB Serverless 重新定义了数据库的操作，使其比以往更简单。通过 TiDB Serverless：  \n\n- 例行任务（如配置、管理和维护）将成为过去。\n- 复杂任务（如高可用性配置和扩展）将实现无缝自动化处理。\n- 无停机的自动升级和每日备份，支持基于时间点的恢复（Point-in-Time Recovery, PiTR）。\n- 基于 OpenAI 技术的 TiDB Bot 提供最佳实践建议。\n\n## 自动化弹性伸缩，极低成本\n\nTiDB Serverless 的按需付费机制，保障您只为自己正在使用的资源付费：  \n\n- 轻松应对需求峰值，自动进行扩展，同时在闲置时自动缩减资源到零。\n- 不再需要选择服务器大小，无需过度配置和为未使用的资源付费。\n- 设置每月资源限制，避免计划外的费用。\n- 透明的定价模型，详细了解每月账单情况。\n\n## 最大化开发效率\n\n无论是原型设计还是生产阶段，TiDB Serverless 的以下特性都可以帮你提高开发效率：  \n\n- 与 MySQL 兼容，无需对代码进行调整。\n- 能够与 MySQL 丰富的工具、ORM 和驱动程序生态系统集成。\n- 同时满足交易和分析的需求（HTAP），实现实时洞察。\n- 利用 AI 增强功能，如 Chat2Query，通过自然语言生成和运行 SQL 查询。\n- 借助 TiDB Cloud Admin API、TiCloud CLI 或 Terraform 等工具实现自动化运维管控。\n\n## 安全合规保障\n\n- TiDB Serverless 将数据安全、隐私和合规性作为首要任务：\n- TiDB Serverless 获得了 SOC 2 Type II 认证，满足安全性、可用性、数据处理完整性和保密性等行业标准。\n- 默认满足 GDPR、HIPAA、PCI DSS 等隐私和合规标准。\n- 访问 Serverless 集群时始终需要 TLS 连接。\n- 基于角色的访问控制保证对数据访问的精确管控。\n- 多因素身份验证增加了额外的安全防护。\n- 全面的日志记录和监控系统，确保系统的可观测性。\n\n## TiDB Serverless 的实际应用\n\n[Chaintool](https://chaintool.ai/) 是一家 Web3 技术公司，构建基础设施以支持区块链交易数据，并利用这些数据开发链上风险管理解决方案。他们在 TiDB Serverless 上部署了他们的链下 API，摆脱了传统数据库解决方案所带来的人工运维挑战，TiDB Serverless 让他们能够专注于构建 Web3 开发者和分析师的数据平台。  \n\n在过去的六个月里，TiDB Serverless 为 Chaintool 提供了许多便利，显著改善了他们的业务运营。这些便利包括：  \n\n- 低门槛项目上手和协作：TiDB Serverless 的易用性能让更多合作伙伴快速参与到项目中，极大降低了协作和沟通成本，并确保了敏捷的项目开发。\n- 优化成本：随着公司项目的扩大和业务需求的演变，TiDB Serverless 的按使用量计费显著降低了成本，同时能够根据项目进展，适应敏捷和波动的需求。\n- 面向未来可扩展的数据库：TiDB Serverless 提供了弹性和混合工作负载的处理能力，能够支持 Chaintool 不断增长的数据存储需求，同时也为未来的业务发展做好了准备。\n\nChaintool 的创始人、CEO、CTO Zhang Yi 表示：“在竞争激烈的 Web3 世界中，TiDB Serverless 显著提升了我们产品上市的速度，并降低了成本。它不仅易于使用，而且其内置的行存和列存引擎使我们能够在单个数据库中处理事务和分析工作负载。”  \n\nChaintool 计划在不久的将来探索更多 TiDB Serverless 的用例，下一步也有计划使用 TiFlash 的能力。\n\n## 立即体验 TiDB Serverless\n\nPingCAP 始终致力于探索数据管理和应用程序开发的可能性，希望帮助开发者和企业管理者轻松自信地应对不断演变的数字化环境。TiDB Serverless 正式发布是一个重要的里程碑，也是一个全新的开始。您的反馈是我们改进和也创新的动力来源，我们也希望在未来的旅程里与您携手通行，共同打造产品。\n\n[立即体验](https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-serverless-ga) TiDB Serverless，零成本起步，开启数据管理和应用程序开发的全新体验！","date":"2023-07-27","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-serverless-is-ga","file":null,"relatedBlogs":[{"relatedBlog":{"body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n![1.png](https://img1.www.pingcap.com/prod/1_93f0db213c.png)\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n![2.png](https://img1.www.pingcap.com/prod/2_81894f8cfc.png)\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n![3.png](https://img1.www.pingcap.com/prod/3_7b2415a552.png)\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n![4.png](https://img1.www.pingcap.com/prod/4_4c3a3da5dc.png)\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n![5.png](https://img1.www.pingcap.com/prod/5_f5295269ca.png)\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n![6.png](https://img1.www.pingcap.com/prod/6_0bed9de7a1.png)\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n![7.png](https://img1.www.pingcap.com/prod/7_c761db6eb7.png)\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n![8.jpg](https://img1.www.pingcap.com/prod/8_923cb0c9a2.jpg)\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n![9.png](https://img1.www.pingcap.com/prod/9_f8a1a72329.png)\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n![10.png](https://img1.www.pingcap.com/prod/10_8a00437db7.png)\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到  Serverless HTAP ，这到底是什么东西？意味着什么？\n\n![11.png](https://img1.www.pingcap.com/prod/11_cc3ffe56c2.png)\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n![12.jpg](https://img1.www.pingcap.com/prod/12_28a125c2bd.jpg)\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n![13.png](https://img1.www.pingcap.com/prod/13_d375c3dd69.png)\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n![14.png](https://img1.www.pingcap.com/prod/14_9c843d72cd.png)\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n![15.png](https://img1.www.pingcap.com/prod/15_c8ed753a77.png)\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n![16.png](https://img1.www.pingcap.com/prod/16_a008ec4dc8.png)\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n![17.png](https://img1.www.pingcap.com/prod/17_63cfa346cc.png)\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n![18.png](https://img1.www.pingcap.com/prod/18_dbfc30531d.png)\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","author":"黄东旭","category":2,"customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","fillInMethod":"writeDirectly","id":440,"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","tags":["HTAP","Serverless"],"title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022"}},{"relatedBlog":{"body":"> 本文基于 TiDB Cloud 生态服务团队负责人张翔在 PingCAP DevCon 2022 的演讲内容整理而成。\n\n\n数据库不是单一软件，而是一个生态体系。成为一款好用的数据库，除了产品自身的能力外，繁荣的技术生态体系也至关重要，既可以提升使用体验，又可以降低使用门槛。\n\nPingCAP 在 2022 年 11 月 1 日正式发布了 TiDB Cloud Serverless Tier，本次分享在介绍 Serverless Tier 的技术细节之余，全面解析 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。  \n\n## 云时代开发者面临的机遇和挑战\n\n现在云已经不再是一个新鲜的事物，我们已经处在云的时代，与之前相比，云时代的开发者面临着与之前不同的机遇和挑战。在云时代，我们有着新的技术设施，我这里举几个例子，每个云厂商都会提供块存储服务、对象存储服务和弹性计算服务。块存储服务有高吞吐、低时延和高持久的特性。对象存储服务，比如 AWS 的 S3、国内阿里云的 OSS，提供了低成本的海量存储空间，并且这些存储还有着超高的可用性，甚至可以跨地域复制来进行容灾。而弹性计算服务，可以给我们提供多种规格的计算实力，而且还提供了不同的计费模式，当然，根据用户的诉求进行弹性伸缩，也是一个基本的能力。\n\n![云上基础设施.png](https://img1.www.pingcap.com/prod/_e855917813.png)\n\n有了新的基础设施，当然也有新的挑战。云厂商给我们提供了许多的云服务，并且云的初衷之一，就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云，仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散，没法完全专注于业务本身。除了运维工作之外，如何使用好云也是一门学问，前不久我刚刚参加了 AWS 的架构师培训，其实如何多快好省地用好云，不是一件简单的事儿。云服务的使用者，很容易就会造成云上资源的浪费，产生不必要的高额费用，特别是在现在许多的云服务，仍然是按时间来收费的情况下。对于有多套环境需求的场景，比如说公司内部有多个团队，不同的业务有各自的环境诉求，或者在 CICD 的场景下，我们可能会有 preview、stage、product 的多套环境需求，购买多套的云服务会产生高额的费用，但是共享一套云服务则可能会产生资源的竞争，甚至出现测试环境影响生产业务的情况。云上的服务，比如说云上的数据库服务，现在的使用方式仍然是提前规划容量，然后始终按照购买的时候的容量进行工作和计费，如果后期需要调整，仍然需要人工介入，手动去进行扩缩容。\n\n![新基础设施新挑战.png](https://img1.www.pingcap.com/prod/_ec4e75048b.png)\n\n这个是我们目前在使用云的时候，遇到的一些挑战。那么为了解决这些挑战，PingCAP 推出了 TiDB Cloud Serverless Tier。Serverless Tier 是世界上首款的 Serverless HTAP 数据库，PingCAP 推出它，希望能够帮助开发者解决刚才所说的那些挑战，成为云时代的新的 HTAP 数据库解决方案。TiDB Cloud Serverless Tier 目前是一个 Beta 的状态。下面，我就给大家介绍一下 TiDB Cloud Serverless Tier。\n\n## TiDB Cloud Serverless Tier(Beta) 世界上首款 Serverless HTAP 数据库\n\n当然在之前，我们还是先来看一下传统的TiDB集群。这是一个经典的 TiDB 集群架构，可以看到这是一个非常典型的分层架构，计算层是 TiDB Server，每个 TiDB Server 都是一个无状态的计算节点，可以非常容易的进行横向扩容，存储层是 TiKV 和 TiFlash。TiKV 是我们的分布式行存储引擎，TiFlash 是列存储引擎，整个存储层通过分布式协议实现了一致分布式存储。在计算层和存储层之外，我们还有一个调度单元 PD，这里存储了整个 TiDB 集群的元信息。在这样的一个架构下面， TiDB 已经有了很好的表现。比如 TiDB 有着非常好的扩展性，无论是计算还是存储，能力都可以随节点数线性扩展。\n\n![经典的 TiDB 集群架构.png](https://img1.www.pingcap.com/prod/Ti_DB_9c8347d384.png)\n\nTiDB 已经在生产场景经历了数百 TB 规模的数据和百万级 QPS 的流量的考验。TiDB 还有着非常好的弹性，系统规模可以随着业务的需求进行伸缩。而且伸缩是完全在线进行的，不会影响已有的数据和请求。同时，对于系统中的热点，TiDB 也有能力自动发现，自动调度。TiDB 也有着非常好的容灾和高可用的能力，如果节点出现故障，上面的数据可以自动的进行转移，并且配合 PingCAP 推出的 TiCDC 工具，还能够做到实时的 CDC 同步，实现异地容灾。\n\n![TiDB 的特性.png](https://img1.www.pingcap.com/prod/Ti_DB_4d614cab43.png)\n\n但是这样的一个经典架构在云的时代，面对着完全不同的基础设施，存在一些问题。第一，share-nothing，刚才我们提到云厂商提供的基础设施，无论是块存储，还是对象存储，天然就有着高可用，高持久的特性，云厂商已经帮我们做了数据复制，但是 TiKV，TiDB 的存储层，仍然做的自己的数据复制。这在云上其实是多余的，数据的复制不仅仅是存储资源的浪费，同时还需要消耗大量的带宽，在云上，网络也是会造成非常高额的费用。第二，存储层状态重。这是因为每个存储节点，其实都存储着一些数据的副本，扩容转移一个故障节点都需要对这些副本进行同步，导致横向扩展的速度仍然不够快，也进一步导致难以利用云厂商提供的竞价实例，从而能够进一步的去降低成本。第三，TiDB 之前是一个非常经典的计算、存储、调度分离的架构。但是在云时代，这样划分的颗粒度仍然过大，每一个节点承担的责任过多，导致 TiDB 整体的弹性仍然不够，其实我们可以在云上，将更多的功能拆分出来形成单独的微服务，这些微服务可以独立的去进行扩容和部署，甚至这些微服务可以被多个集群去共享。如果拆分出更多的微服务，TiDB 集群整体的弹性会进一步上升。\n\n![TiDB 经典架构在云时代面临的挑战.png](https://img1.www.pingcap.com/prod/Ti_DB_320d177f6b.png)\n\n基于这些问题，其实 PingCAP 做了很多的努力，也都做了相应的改进，大家可以看到这是现在 TiDB Cloud Serverless Tier 的一个新架构。首先在存储层开发了 Cloud Storage Engine 一个新的存储引擎，图中 Shared Storage Layer 和 Shared Storage Pool 这两层组合起来就是新的 Cloud Storage Engine。现在新的存储引擎融合使用了云上的块存储和对象存储，并且消除了原来存储层冗余的数据复制，彻底的解决了之前所说的 share-nothing 和状态重的问题。这样的改造使得存储层的节点扩展非常容易，而且非常迅速，而且大幅度地降低了成本。\n\n![TiDB Cloud Serverless Tier 的一个新架构.png](https://img1.www.pingcap.com/prod/Ti_DB_Cloud_Serverless_Tier_0842be8424.png)\n\n在计算层我们进一步地拆分了 TiFlash，TiFlash 现在它的计算存储已经可以去分离，TiFlash 的计算部分可以像 TiDB Server 一样，作为一个独立的组件去进行管理，去扩容。第二，我们引入了新的一层，叫做 Gateway。Gateway 代替了 TiDB Server 与用户去进行交互，它负责诸如连接管理、唤醒节点，这样的功能。它的出现使得我们所说的多租户成为一个可能。第三，我们池化了计算节点，在图上右边的部分，有多个 TiDB 和 TiFlash。我们将计算节点进行了池化，这样的设计进一步降低了计算层的成本，以及提升了计算节点唤醒的速度。计算层和存储层的改动，使得 TiDB Cloud Serverless Tier 支持了多租户。现在一套 TiDB Cloud Serverless Tier 集群，可以支持多个租户，每个租户都是完全隔离的。在用户看来，他们拥有的就是一套独立的 TiDB 集群。\n\n最后，我们还拆分了一些相对独立的功能，做成微服务，比如数据压缩服务，降低了计算节点以及存储节点的复杂性，提升了 TiDB Cloud Serverless Tier 的整体的弹性，后续我们还会继续对更多的微服务进行拆分。\n\n![TiDB Cloud Serverless Tier 的一个新架构优势.png](https://img1.www.pingcap.com/prod/Ti_DB_Cloud_Serverless_Tier_4e2105769e.png)\n\n做完相应的改进，新的架构解决了之前所说的传统架构在云上的问题，更好地适应了云上的基础设施。这边总结一下，一是推出了 Cloud Storage Engine，可以融合地使用块存储和对象存储，并且消除了多余的复制，解决了两类问题，一是冗余的复制，二是高额的网络费用。第二，拆分出了更多的微服务，更好地使用了云上的弹性算力。整体的改动使得 TiDB Cloud 可以支持多租户。\n\n技术上的努力使得 TiDB Cloud Serverless Tier 拥有了非常新颖的能力。TiDB Cloud Serverless Tier 拥有全部的 TiDB 的 HTAP 能力，是世界上第一款 Serverless HTAP 数据库。我们优化了 TiFlash 的架构，使其更好地适应了云上多租户的场景。从刚才介绍的 TiDB Cloud Serverless Tier 的架构上可以看到，我们对计算节点进行了池化，多租户也共享了存储。所以，TiDB Cloud Serverless Tier 目前可以做到秒级创建一个 TiDB 集群，并且如果你长时间不使用，再次连接的时候也仅需数百毫秒的时间就可以恢复完整的集群。这个操作对于用户来说，是完全透明的，用户甚至感知不到。未来，我们会进一步优化这个时间，集群创建时间会持续缩短，唤醒时间也会从数百毫秒缩短到数十毫秒。\n\n作为一款真正的 Serverless 云数据库，当然，TiDB Cloud Serverless Tier 是完全无需用户去运维的。在使用方式上，不需要像传统的云数据库那样，提前去规划容量，在需要的时候进行扩缩容，TiDB Cloud Serverless Tier 会根据流量自动地进行伸缩，无需任何手动的操作。具备了这么强大的能力，TiDB Cloud Serverless Tier 的计费方式也是真正的按使用量付费，用户只需要为自己真正使用的资源进行付费，不使用，即使这些集群仍然在运行当中，你也无需支付任何的费用，这也是 TiDB Cloud Serverless Tier 区别于传统云数据库甚至于其他 Serverless 数据库的不同之处，这些数据库即使你不使用，但只要集群被创建出来，仍然会按照创建时的规格进行收费，这其实会造成极大的资源浪费。\n\n同时 TiDB Cloud 是支持多云厂商的，Serverless Tier 也将会继承这一点。目前 TiDB Cloud Serverless Tier 仅支持在 AWS 上创建，但未来一定会支持更多的云厂商，同时 Serverless Tier 还支持多个区域，满足用户时延和数据存储区域选择的诉求。\n\n![Serverless Tier 多云厂商支持.png](https://img1.www.pingcap.com/prod/Serverless_Tier_c1f90aa92d.png)\n\n讲了这么多，接下来我们来展示一个 Demo，这个 Demo 就是我们从无到有来创建一个 TiDB Cloud Serverless Tier 集群，这个其实也是基本上是所有用户唯一需要与 TiDB Cloud Serverless Tier 打交道的一个动作，因为刚才我们说了，一旦创建之后其实你不需要去运维，你也不需要去进行手动扩缩容，TiDB Cloud Serverless Tier 会根据你的流量自动进行扩缩容，我们开始看一下集群创建的过程。\n\n![TiDB Clous Serverless Tier 启动.mp4](https://img1.www.pingcap.com/prod/Ti_DB_Clous_Serverless_Tier_890d517246.mp4)\n<center>Demo 视频</center>\n\n我们只需要点击创建，如果你需要可以选择名字以及供应商以及 region，这里我们都是使用默认的。然后就进入了创建的一个过程，可以看到大概在 20 秒的时候整个集群其实就已经从 creating 的状态变成了 avaliable 的状态，TiDB Cloud Serverless Tier 现在整个创建时间大概就是在 20 秒左右，可能会上下有一定波动，基本是在这样一个量级。只需要 20 秒你就可以拥有一个完全工作的 HTAP 云数据库，并且后续不需要你进行任何操作以及与它有任何运维上的交互。\n\n![Serverless Tier 服务每个人.png](https://img1.www.pingcap.com/prod/Serverless_Tier_ac44924166.png)\n\n希望经过我们的努力，TiDB Cloud Serverless Tier 可以成为一个服务于每个人的 HTAP 数据库，TiDB Cloud Serverless Tier 现在拥有了完整的 HTAP 能力，可以处理复杂的工作负载，并且真正地按使用量付费，对于任何人都只需要为自己使用的计算资源和存储资源付费，不存在资源浪费的情况，具有非常高的性价比。对于个人开发者，TiDB Cloud Serverless Tier 每个月其实都提供了一定量免费的 Quota，只要不超过这个 Quota，对于个人开发者而言，TiDB Cloud Serverless Tier 就是一个完全免费的触手可及的 HTAP 数据库，对于 Startup 来说，TiDB Cloud Serverless Tier 可以跟随业务增长自动进行扩容，而且这个扩容完全是自动的，不需要手动介入。Startup 可以专注于他的业务本身去发展自己的业务，不需要为数据基础设施去操心。对于大公司而言，因为 TiDB Cloud Serverless Tier 超高的性价比以及非常迅速的创建恢复时间，使得云上资源不再成为一个限制，每个部门、每个环境都可以拥有自己独立的数据库，未来我们还会推出 data branching 更好地帮助企业客户，当然如果公司有跨云部署的诉求，TiDB Cloud Serverless Tier 也是一个非常完美的选择。\n\n## 数据库不是单一软件，而是一个生态体系，除了产品自身的能力，繁荣的技术生态体系也至关重要\n\n当然，对于任何一个数据库的使用者不可能仅仅与数据库软件本身打交道，同时需要使用大量的数据库生态软件，TiDB Cloud Serverless Tier 拥有非常丰富的生态，接下来我们就来看一下 TiDB 的生态。数据库不是单一软件，而是一个生态体系，除了产品自身的能力，繁荣的技术生态体系也至关重要。TiDB 从出生起就非常重视生态，所以选择了与 MySQL 兼容，并且在这个上面做了许多努力。\n\n因为 TiDB 是 100% 兼容 MySQL 协议的，所以 TiDB 与所有的主流语言都是兼容的，比如 Go、Ruby、Java 、Python、JavaScript 等等，还有更多。TiDB 兼容的远远不只这些语言，这里列了一些比较流行的语言，只要一个语言拥有 MySQL driver，它就可以使用 TiDB，使用 TiDB Cloud Serverless Tier，不管这个语言多么小众。\n\n![TiDB 与所有主流语言兼容.png](https://img1.www.pingcap.com/prod/Ti_DB_554d8a4168.png)\n\n在语言之上，TiDB 还与基本上所有的流行的 ORM 框架兼容，与语言的 driver 不同，除了协议层的兼容之外，ORM 往往在功能上对 MySQL 的兼容性有着更高的要求，TiDB 的一些扩展能力也需要去进行补齐。TiDB 在这个方面做了很多努力，首先针对一些 ORM 开发了自己的插件，比如对于 django 和HIBERNATE，我们开发了django-tidb 和 hibernate-tidb 插件。TiDB 也在产品本身的 MySQL 兼容性的能力上做了很多增强，比如，可能在应用中我们可以不用，但是对于许多 ORM 框架都非常重要的两个功能 savepoint 和外键。这两个功能对于很多的 ORM 框架来说都非常重要，很多 ORM 框架对他的依赖都非常重。在最近两个 TiDB 的版本中发布了savepoint 功能和实验版本的外键功能，这使得 TiDB 进一步提升了与许多 ORM 框架的兼容性。\n\n![TiDB 与基本上所有的流行的 ORM 框架兼容.png](https://img1.www.pingcap.com/prod/Ti_DB_ORM_4d492a6de4.png)\n\n除了语言的 driver 和 ORM 框架之外，TiDB 以及 TiDB Cloud 还可以集成许多流行的平台，我们这里罗列了一些主要的，比如在数据处理领域，TiDB 可以与 Spark、Flink、Databricks 这些流行的大数据处理框架以及平台结合使用，来构建企业的 ETL pipeline，形成统一的数据处理平台。同时除了传统的 ELT 平台，TiDB 还可以与海外非常流行的 modern data stack 体系进行集成，我们给 Airbyte 贡献了 tidb-source-connector 和 tidb-destination-connector，开发了 dbt-tidb adapter，使得 TiDB、TiDB cloud 可以完美地与 Airbyte、dbt 进行集成。\n\n当然 TiDB 还支持类似于 Metabase 这样的 BI 平台，分析 TiDB 中存储的数据。在 CDC 的领域 TiCDC 支持了 avro 格式以及 kafka sink，使得 TiCDC 可以支持将数据导出到 confluent 平台，同时我们还测试了与 arcion 平台的兼容性，可以使用 arcion 平台来做 TiDB 或者 TiDB Cloud 的 CDC。\n\n![TiDB 以及 TiDB Cloud 可以集成许多流行的平台.png](https://img1.www.pingcap.com/prod/Ti_DB_Ti_DB_Cloud_d9cebec8ae.png)\n\nTiDB 和 TiDB Cloud 很早就支持了使用 prometheus 和 grafana 作为监控平台，我们还支持将监控的 metrics 导出到 datadog 平台，还可以实现与 Serverless 部署平台 Vercel、Netlify 的集成，以及与 no-code workflow automation 平台，像 zapier、n8n 的集成，以及与 IaC 工具 Terraform 的集成等等。接下来深入到一些领域来仔细看下。\n\n首先来看 modern data stack 领域也就是我们所说的 ELT pipeline，注意，这里不是传统的 ETL pipeline，是 ELT pipeline。首先介绍一下 Airbyte 和 dbt，Airbyte 是一个 data pipeline 平台，它可以连接数百种数据源和数据汇，将数据源中的数据导出到数据汇中，然后在数据汇中对数据进行整理。基于此，用户可以通过 Airbyte 实现任意的数据迁移，它的口号就是 data from any source to any destination。dbt 是一个 data transformation 工具，借助 dbt 用户可以非常灵活地在数据库或者数据仓库中操作数据，进行数据变换。结合使用 Airbyte、dbt 和 TiDB Cloud，用户可以将任意数据源中的数据，比如在 salesforce 中的 CRM 数据，google sheets 中的表格数据，甚至是像 Instagram 这样 2C 应用中的企业运营数据导入到 TiDB Cloud 中。有了数据，我们可以利用 BI 工具进行数据分析，因为 TiDB 以及 TiDB Cloud Serverless Tier 是一个 HTAP 数据库，在面对分析型负载的时候，有着更好的表现。甚至，如果说用户有数据归档的诉求，可以继续将 TiDB 作为 Airbyte 的数据源，将数据导入到像 Snowflake、Databricks、Google Big Query 这样的数据仓库或者说数据湖中去。\n\n![ELT pipeline.png](https://img1.www.pingcap.com/prod/ELT_pipeline_1d6f0c2b6a.png)\n\n总的来说，用户如果结合使用 TiDB Cloud、Airbyte 和 dbt 建立一条 ELT data pipeline，一是可以使自己的数据设施 all in Cloud，整条流水线都可以拥有非常好的弹性，可以满足业务增长的诉求。同时云上的基础设施拥有很高的性价比，可以降低数据基础设施的成本，而且因为 all in Cloud，你无需运维，降低了数据集成的技术、费用门槛。二是可以加速企业内业务数据的流动，Airbyte 拥有上百种的数据连接器，用户可以直接去使用，无需自己设计、开发，从而企业内的数据分析师可以更快地进行数据分析，帮助企业发现新的商业机会，而不是把精力浪费在基础设施的重复建设当中。\n\n接下来看 Vercel，Vercel 是海外领先的前端部署平台。使用 Vercel 开发者可以非常迅速地将自己的 web 应用进行部署、分发给全球的访问者，在这个过程当中 Vercel 还可以加入到开发者的 CICD 流程当中，使开发者可以轻松地预览效果。同时借助 Vercel 遍布全球的边端网络，访问者可以以极低的时延访问 web 应用，获得极佳的用户体验。\n\n![TiDB Cloud 与 Vercel集成.png](https://img1.www.pingcap.com/prod/Ti_DB_Cloud_Vercel_621504a689.png)\n\nVercel 本身作为一个 Serverless Frontend Infrastructure，它不具备持久化数据存储的能力，这也就意味着如果仅仅使用 Vercel 的能力，没办法去开发一个复杂的 web 应用。所以我们可以结合 Vercel 和TiDB Cloud Serverless Tier，从而获得一套完整的 web 开发的 Fullstack Serverless Infrastructure，和前面的 all in Cloud 的 data pipeline 一样，这套 Web App Develop Infrastructure 也是 all in Cloud，用户无需运维，基础设施可以自动扩展，并且具有很高的性价比。\n\n为了让用户更好地使用 Vercel 和 TiDB Cloud Serverless Tier，我们开发了 TiDB Cloud Vercel Integration ，你可以在 Vercel 的 Integration 市场中找到它，通过这个 integration，只需要简单的几次点击就可以连接 TiDB Cloud Serverless Tier 集群和 Vercel 项目。同时我们还开发了 TiDB Cloud Starter 模板，这个模板可以让用户通过几次点击和几分钟的等待，就从无到有地构建一个全球可访问的 web 应用。以下是一个简单的 demo 让大家来体验这套 Fullstack Serverless Infrastructure。\n\n![TiDB Cloud 与 Vercel 集成.mp4](https://img1.www.pingcap.com/prod/Ti_DB_Cloud_Vercel_fe6ecc3d20.mp4)\n<center>Vercel Demo 视频</center>\n\n> 这是 Vercel 的 template 列表，先找到我们的 TiDB Cloud Starter 模板，进入模板的详情页，点击 deploy 进到一个流程页。首先因为这是一个模板，所以我们要基于这个模板来创建一个我们自己应用的代码仓库，这里选择 starter，你只要简单的一次点击就可以。  \n> 在这个过程当中集成了 TiDB Cloud Vercel Integration，这个页面就是 integration 的页面。这里选择我们想要的 Vercel 项目以及想要的 TiDB Cloud Serverless Tier 的集群，选择之后点击 integrate，这个 integrate 的过程就结束了。到这里我们需要操作的过程已经完全结束了，现在处在等待 Vercel 帮你构建项目以及部署项目的一个阶段。大家可以看到，创建我们自己的代码仓库点击了一次，进行 integrate 点击了大概一到两次，我们就完成了所有的操作。  \n> 接下来稍微等待一下，大家可以看到现在大概过了两分钟，整个部署和构建过程就完成了。我们到 Vercel 项目的详情页去点击 visit，可以看到这时候这里展示的页面就是通过模板构建出来的一个项目的主页，大家可以看到这上面的 URL 是一个所有人都可以访问的 URL，现在这个项目已经对全球可以访问了。任何人在地球上的任何角落现在都可以来访问 bookstore 这个项目，整个的耗时也就大概两三分钟。这个项目前端整个的代码应用逻辑是部署在 Vercel 的 Serverless 的架构上面，后端数据存储是存储在 TiDB Cloud Serverless Tier 集群中。  \n\n我们进入下一个生态 Terraform，Terraform 是业界默认的跨云 IaC 工具，使用 Terraform 可以使用代码来管理云基础设施，将它集成到我们的 CICD 流程当中，我们在前不久开发了 TiDB Cloud Terraform Provider，使得用户可以通过 Terraform 来管理 TiDB Cloud 的资源。像图上展示的，我们可以通过这样的一个 Terraform 文件来创建一个 TiDB Cloud Serverless Tier 集群。Terraform Core 会解析这个文件，将 TiDB Cloud 资源的相关定义都发给我们开发的 TiDB Cloud Terraform Provider，TiDB Cloud Provider 会调用 TiDB Cloud Go SDK 来操作 TiDB Cloud 的资源。PingCAP 已经和 HashiCorp 成为了技术合作伙伴，TiDB Cloud Terraform Provider 也已经是 HashiCorp 认证的 Partner Provider，欢迎大家使用 Terraform 来操作 TiDB Cloud 的资源。\n\n![TiDB Cloud 与Terraform集成.png](https://img1.www.pingcap.com/prod/Ti_DB_Cloud_Terraform_25f74ea286.png)\n\n## 展望未来\n\n最后，我们一起展望一下未来，TiDB Cloud Serverless Tier 才刚刚发布，我们仍然有很长的路要走。\n\n目前因为刚刚推出，Serverless Tier 还没有向用户开放诸如像备份、恢复、监控、报警这样的能力，我们很快就会添加这些能力并对用户进行开放。我们还会开发 PiTR 和 Branching 这些功能，方便用户进行数据共享，将数据库纳入CICD。我们还会进一步地去降低创建时间和成本，期望 Serverless Tier 集群的创建时间能从现在的 20 秒降低到 5 秒，唤醒时间从数百毫秒降低到数十毫秒。后续会推出 Data API，Data API 是通过 RESTful API 的形式提供数据库的 CRUD 能力，未来除了 RESTful 之外还可能推出 GraphQL API。通过 Data API 希望 Serverless Tier 可以更好地与 Serverless 生态结合，服务边缘请求。现在很多的 Serverless 的部署平台加速从中心化的托管能力向边缘进行扩张。当我们使用边缘的一些托管 runtime 是根本无法发出像传统的 TCP 请求的，所以 Data API 的推出可以让 Serverless Tier 更好地与这些平台进行结合。\n\n![Serverless Tier 未来展望.png](https://img1.www.pingcap.com/prod/Serverless_Tier_88d42f9216.png)\n\n在生态方面，我们会进一步提升 MySQL 兼容性，对接更多平台，给用户提供更多选择。PingCAP 始终坚持开源开放的路线，TiDB 社区从诞生开始就开放并包，我们期望大家加入，共建 TiDB 的繁荣生态。","author":"张翔","category":1,"customUrl":"tidb-serverless-and-technology-ecology-overview","fillInMethod":"writeDirectly","id":466,"summary":"本次分享在介绍 Serverless Tier 的技术细节之余，全面解析了 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。","tags":["TiDB","Serverless"],"title":"TiDB Serverless 和技术生态全景"}},{"relatedBlog":{"body":"## 导读\n\n在 PingCAP 用户峰会 2023 上，PingCAP 联合创始人兼 CTO 黄东旭分享了“The Future of Database”为主题的演讲，介绍了 TiDB Serverless 作为未来一代数据库的核心设计理念。黄东旭通过分享个人经历和示例，强调了数据库的服务化而非服务化数据库的重要性，并展示了 TiDB Serverless 架构的创新之处，同时探讨了 TiDB Serverless 对于中国用户的价值。以下为分享实录。\n\n作为今天上午的最后一个话题，相信大家已经感受到今天我们分享的最核心逻辑，跟刚才刘奇分享的我们部署一代、研发一代相承接，到我这部分就是未来的一代：预研一代。  \n\n因为今天会场有很多熟悉的老朋友，看到我这个标题肯定会心一笑，我每次在大会上的演讲都是这个题目：The Future of Database。选择这个主题一是我发现每次讲未来的东西都有东西可以讲；另外一点，很多老朋友发现我去年总是不时消失一段时间，怀疑我去闭关修炼了，我也跟大家汇报一下东旭去哪儿了。  \n\n**Demo：我花了多长时间构建我自己的 OSSInsight Lite**\n\n![Demo.png](https://img1.www.pingcap.com/prod/Demo_079bcb3718.png)\n\n分享之前给大家看看，刘奇的分享里面的这一页，把我 GitHub 个人数据分析的服务截图放上去了，这个小 demo 是我个人的挑战，我能不能完全做到不写代码，不去买服务器，完全用现代化的在线的云上的应用做一个我自己的数据服务。\n\n![Demo.mp4](https://img1.www.pingcap.com/prod/Demo_16079ecd5d.mp4)\n\n在这个小的视频里边，我几乎全程只用了鼠标来操作，我想分享的点并不是让大家去学习这些技术，而是想让大家稍微体验一下现代的开发者构建应用的方式已经完全不同——门槛越来越低。  \n\n我经常会有一些天马行空的想法，比如我会想如果要给全世界的开发者都提供免费的数据库，这个成本得有多大？以现在的技术肯定支撑不了。那如果要做这么个东西的话，我们可能需要重新去思考数据库本身的一些最基础的东西。  \n\n## 一个人人可用的数据库服务有怎样的技术架构？\n\n![人人可用的数据库特征.png](https://img1.www.pingcap.com/prod/_a5ba0e9b97.png)\n\n这是一些数据库厂商会说的老生常谈：扩展性、稳定性、用户线性的扩缩容、节省成本、多租户、云原生。  \n\n但是刚才我说的那些新的需求或者面向未来的数据库，可能对每一项都会有更高的要求。比如你的系统已经具备了一定的扩展性和稳定性，但更重要的是你能不能给用户一个稳定的性能的预期，我经常说一句话，稳定的慢比不稳定的快其实更好，可预测性对系统和底层的架构提出了更高的要求；第二就是现在几乎每个分布式数据库都支持弹性扩容，而更高的要求可能是，在做这些扩缩容的复杂操作的时候，开发者、DBA 都不需要去费心，数据库的扩缩容对业务来讲是完全无感的，体验非常顺滑；成本层面，我们再把成本压缩到极限——我能不能，不用的时候就不花钱？开源软件的分发上、下载不要钱，但是运行软件的服务器要花钱，现在我们再往前想一步，——数据库、服务器零成本的起步能不能支持；多租户上，我们过去要去强调互相的隔离，但是如果为了实现大规模的海量的免费的用户、中小型的敏捷的业务，不仅要强调隔离，还得强调资源的高效利用和共享；云原生是老生常谈，做到云中立就是进一步的目标。  \n\n![新一代多租户.png](https://img1.www.pingcap.com/prod/_c206e0918c.png)\n\n我这边挑一个简单的例子，就从最近发布的多租户能力说起。如果把租户的规模从私有化部署的几十几百个，扩大到十万个、一百万个、一千万个甚至一亿个，平台如何去支撑这么大的租户数量，它需要哪些基础的能力，我们是怎么思考的？第一老生常谈，多租户一定要隔离；第二是刚才唐刘稍微讲了一下我们现在在研发的东西：资源管控，我们必须得实现一套很好的机制能够让海量用户更高效地利用和共享底层系统的资源，才能达到很低的成本；第三就是能区分，每一个用户在使用的体验上都必须能够感受到自己是在拥有整个数据库的。  \n\n![TiDB 迈向新一代多租户.png](https://img1.www.pingcap.com/prod/Ti_DB_0235c9089e.png)\n\n之前有人问我 TiDB 支持多租户、多应用这种模式吗，我当时一直都是比较保守，通过几个大版本的迭代，我现在可以负责任的说，TiDB 要去实现现代的多租户，基础的能力都已经满足了。  \n\n## TiDB Serverless：未来数据库理念的“概念车” \n\n我们回到最开始的话题：如果我们要给全世界的开发者提供数据库该咋做？今天我就给大家说一下背后的概念车，把 TiDB Serverless 引擎盖掀起来大家看一看。  \n\n![TiDB 经典架构.png](https://img1.www.pingcap.com/prod/Ti_DB_e95cce4b77.png)\n\n今天无数次讲到了 TiDB 的经典架构，然而如果把 TiDB 这个经典架构搬到云上，想实现“人人可用”这个目标，仅从成本上考虑，PingCAP 就得赔死了。  \n\n![TiDB 云原生哲学.png](https://img1.www.pingcap.com/prod/Ti_DB_f552bb4a5b.png)\n\n所以重新设计 TiDB Serverless 的时候，我当时定下了几个规范或者开发的哲学，其中最重要的一条就是我们应该做的是数据库的服务化，而不是服务化的数据库。  \n\n传统意义上来说我们要做云数据库，大家第一直观感觉，底下做个云管平台，每个租户部署一套 TiDB，把自动化的管控做完，这不就可以了吗？但是 TiDB Serverless 在这个方面，我们选择重新去思考一些非常基础的东西，刚才做云上运维 TiDB 的思路是行不通的，如果要做这么大规模这么新的东西的话，而且应该当做一个完整的服务去设计，而不是把它当做一个数据库去设计。  \n\n八年前一开始设计 TiDB 的时候，我看到的东西就是一台台具体的服务器，我看到的是 CPU、内存、磁盘，基于这些东西我们构造了 TiDB。但是如果我们现在在云上构建 Serverless 这个系统，拿到的是一张白纸，我今天重新再开始去设计这个系统的时候，我看到的已经不是 CPU、磁盘机器这样的东西了，我看到的东西是云上给我的服务，EC2、虚拟机，我看到的是对象存储，我甚至可以看到云厂商的 RDS，我能不能拿 RDS 作为系统的一部分，所以在新的云原生的工程哲学里边必须有一条能够充分利用云的基础设施，这也是我们能把成本推到如此极限的一个核心的思想。  \n\n![Serverless 解决之道.png](https://img1.www.pingcap.com/prod/Serverless_eefc36d590.png)\n\n掀开 TiDB Serverless 的引擎盖，大概有三个新的东西，第一个换了新的云原生的引擎 CSE（Cloud-native Storage Engine），非常朴素的名字。第二是终于在 TiDB 引入了逻辑上的 Key Space，第三就是 Resource Control 以及 RU 的概念，从上到下做全局流控。  \n\n![CSE 架构.png](https://img1.www.pingcap.com/prod/CSE_ac2a17d227.png)\n\n这是 CSE 整体的架构，核心就一点，它是一个极致的成本考虑下，极致的多租户背景下的新一代云上 OLTP 存储引擎。本质来说即使在之前的存储层，TiKV 这一层也开始做了存算分离，这就带来一个好处，比如有一些用户的数据是冷数据，因为我们在云上发现大多数的用户的业务和数据满足 82 法则，20%的热数据，80%可能是冷数据，但这些冷数据你在它不用的时候就可以按照流量的需求，直接 compact 到 AWS S3 这样云上更便宜的存储上面。AWS S3 存储的价格每 TB 每个月大概 20 美金，喝两杯咖啡就有一个月一个 TB 的存储空间了，这还是没有任何优惠的情况，实际上还可以更便宜。  \n\n![TiDB Serverless 架构.png](https://img1.www.pingcap.com/prod/Ti_DB_Serverless_5c7a108c6c.png)\n\n所以基于新的存储引擎，我们可以发现本身 TiDB 之上所有的组件一下子就变成了无状态的。当一个组件变成无状态了以后，怎么去降低成本？池化。  \n\n图中 TiDB 右边现在已经把所有的包括计算节点存储节点全都变成了池化的设计，最上面加入了一层 Gateway，用户直接连接到 Gateway，Gateway 负责对现在用户的请求从资源池中捞出一个活跃的节点，它不用的时候连接断开再放回去。  \n\n大家看这个图尤其是做系统架构多年的朋友会有个感觉，这个东西感觉不像一个数据库，反而像大型互联网公司后台的服务——有这个感觉就对了，因为我们在设计这个系统的时候就不是把它当做一个数据库在设计，而是把它当做一个真正的云服务在设计，所以才能达到极致的性能和成本的压缩。  \n\n![Key space 详解.png](https://img1.www.pingcap.com/prod/Key_space_fe6d7088be.png)\n\nTiKV 是 TiDB 的存储引擎，所有的数据都是通过 key-value 来编码的，Key Space 本质上，就是在编码前面加上一个用户 ID 的前缀，将 tenant ID 作为 group keys 的前缀。  \n\n![流控设计.png](https://img1.www.pingcap.com/prod/_ceb3e49390.png)\n\n这张图解释了零成本起步，业务没有流量的时候就不收钱，本质上还是依靠池化来实现的。刚才我提到用户的连接都是连接到一层可以水平扩展的 Cluster Gateway 上，Gateway 来控制计算节点是否启用。如果这个客户的数据特别冷，十天半个月都不访问一下，这个数据完全存储在对象存储上，在对象存储上的成本是极其低的，在用户请求的时候再快速加载回来。这样一个架构保证了 TiDB Serverless 基础设施的成本会被均摊到所有用户身上，用户越多，数据量越大的时候，成本也就会越来越低。  \n\n![OSSInsight 的故事.png](https://img1.www.pingcap.com/prod/OSS_Insight_e28b1c5ec4.png)\n\n我最后分享一个小小的例子。我们公司内部也有自己用自己产品的习惯，这是我们自己的一些服务 demo，全部用 TiDB 自己构建。我们做了一个很有趣的工具叫 OSS Insight，把 GitHub 上的数据抓下来做分析的一个在线应用，这个在以前传统的 TiDB Cloud，也就是经典 TiDB 云上部署架构下，一个月的成本在一万美金左右，上图就是我们付给自己的账单。  \n\n![成本降低.png](https://img1.www.pingcap.com/prod/_c65cdc99fc.png)\n\n同样这个业务今天已经接近 12 个 TB 了，这样一个巨型的数据库前一段把它迁移到 Serverless 以后，总体成本下降了 70%，而业务在使用层面上也完全没有任何的感知。  \n\n![自动应对.png](https://img1.www.pingcap.com/prod/_a72bd89b45.png)\n\n这里有一个很有趣的真实例子，刚才我们看到整体的 TiDB Serverless 的设计是面向弹性去做设计的，但是这种东西总是希望能有一个实际的例子去验证一下这东西是不是真的在现实生活中比较好用，我们也真的有了这样的机会。今年 4 月初 OSS Insight 成功登上了 HackerNews 的首页，流量一下暴增到原来的 7 倍，这个事情还发生在中国时间的深夜，我们的工程师都还在睡梦中，TiDB Serverless 自动发现了流量的突变把集群扩容，承担起 7 倍流量的业务负载以后，又自动缩回来，前端业务的各项指标都还是非常稳定的，也没有额外的收费。这是一个特别好的例子，我们也特别欣慰。  \n\n![Serverless 反哺.png](https://img1.www.pingcap.com/prod/Serverless_31a425ba2b.png)\n\n我今天分享了一些我们未来对数据库的看法，关于 TiDB Serverless，我还有三个点想强调。第一，虽然看到现在它是一个在纯云端的服务，但是我们有计划将更先进的架构服务于中国的客户，甚至你可以未来在私有化环境里面部署 TiDB 的 Serverless。因为我们设计这个系统内核的时候非常仔细的考虑了这个系统本身的可移植性，刚才这些东西未来大家会在自己的数据中心或者自己的云上去使用；第二，我个人认为这也是代表着数据库最前沿的发展的方向，就是云原生加上极致的弹性，我们在思考数据库本身的一些架构或者最底层的想法的变革都会遵循这个方向；第三点我个人觉得Serverless 是我们很好的练兵场，包括中国企业级客户我们预研出来的版本我们新的一些特性，最早会在 Serverless 上应用，比如刚才我说的 Key Space 这个功能，目前已经在 Serverless Tier 上实现了上万个用户的部署，经过上万个集群的打磨，很快也会在企业版和云上托管版本里边落地。  \n\n最后我想小小的总结一下今天我的分享以及我的一些感受。我也代表着 PingCAP，纵使大的经济环境充满各种不确定性，我们永远相信技术创新能够真正给业务带来价值，我也相信技术真正能够改变世界，所以我们相信未来永远是一个更好的世界。","author":"黄东旭","category":5,"customUrl":"the-future-of-database-2023","fillInMethod":"writeDirectly","id":500,"summary":"PingCAP 联合创始人兼 CTO 黄东旭分介绍了 TiDB Serverless 作为未来一代数据库的核心设计理念，同时探讨了 TiDB Serverless 对于中国用户的价值。","tags":["PingCAP  用户峰会","Serverless"],"title":"黄东旭：The Future of Database，掀开 TiDB Serverless 的引擎盖"}}]},{"id":"Blogs_492","title":"TiDB 7.1 LTS 发版：为关键业务提供业务稳定性和多租户场景支持","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 7.1 是 2023 年度发布的首个 LTS 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本。","body":"![活动 banner.jpeg](https://img1.www.pingcap.com/prod/banner_8a580af0b8.jpeg)\n\nTiDB 7.1 是 2023 年度发布的首个 LTS（Long Term Support） 版本，汇集了来自 20+ 个真实场景带来的功能增强，累计优化和修复 140+ 功能，旨在提升关键业务的稳定性和性能，帮助开发人员和数据库管理员提高生产力并进一步降低总体拥有成本（TCO）。用户可在生产环境中使用 TiDB 7.1。\n\n## 半年版本回顾\n\nTiDB 7.1 LTS 距离上一个 LTS 版本 6.5 已经过去了整半年，在这期间，我们对产品的关键能力做了大量的增强和优化，其中最重要的特性有：\n\n- TiDB 7.0 提供了基于资源组的资源管控（Resource Control）：这使得 TiDB 在针对多租户场景有了很好的应对。事实上，经常有用户希望借助 TiDB 的可伸缩特性将多套业务系统归一到一个集群中，从而使得集群管理、资源利用都能得到有效的改进。资源管控特性提供了对多租户的支持，并解决了不同租户间资源争抢的问题。在新版本中，用户可以很方便地借助这个功能完善数据库整合的使用场景。\n- Multi-RocksDB 特性：借助将单一 TiKV 实例中的 RocksDB 拆成多份，TiKV 的写吞吐提升近三倍；此外，在新架构中数据分片（Region）大小将变得更大，由此减小维护分片所带来的开销，减少单位存储所需的固定 CPU 消耗，更节省成本。这使得大写入吞吐，或者需要大量存放温数据的 Data Serving 场景下，TiDB 的表现得到了本质的提升。\n\n对于这些重要的重量级特性，在新版本中也将持续得到打磨和加强。这半年中，TiDB 在一些关键场景的性能也得到长足提升：\n\n- 数据导入 Lightning 性能提升近 30%；\n- 真实业务测试下，Analyze Table 性能提升 42%+；\n- 标准测试 TPC-H 和真实业务测试下，TiDB 分析能力分别提升 15% 和 25%；\n- TiCDC 针对大型单表复制性能提升可达 90%+。\n\n## TiDB 7.1 介绍\n\nTiDB 7.1 是我们计划在 2023 年发布的两个长期可支持（LTS）版本中的第一个，它为您提供了一个面向未来的数据库，可以为各种关键业务应用程序提供动力。TiDB 7.1 为您带来：\n\n- 更稳定地支持关键业务负载，为 DBA 提供多工作负载稳定性控制，并显著改善尾部延迟；\n- 以更少的资源提供更佳的性能，通过架构增强实现更高的吞吐以及更快的在线 DDL。\n\n此外，TiDB 7.1 企业版增强了数据库审计功能，通过更细粒度的事件过滤控制、更友好的过滤条件设置方式、新增的 JSON 文件输出格式以及审计日志的生命周期管理，大幅提升系统的审计能力。\n\n### 更稳定地支持关键业务负载\n\n本节中的功能增强都属于集群稳定性的主题。更具体地说，即使在工作负载较大的情况下，TiDB 也可以保障稳定运行，并稳定处理具有特殊情况的工作负载的延迟。\n\n#### 通过资源组改进资源管控的用户体验，提供更好的隔离性\n\n我们在[文章（TiDB 7.0）](/blog/tidb-7.0-release)中介绍了通过资源组进行资源管控的功能，为 TiDB database consolidation （数据库整合）方案奠定了基础，具有里程碑的意义。多个业务可共享同一个 TiDB 集群，DBA 可为不同的工作负载设置资源配额和优先级，例如为关键业务分配更高的优先级，确保其能够优先获得资源，避免受到其他工作负载的干扰。\n\n在 TiDB 7.1 中，资源管控特性正式 GA 了，并加入了两个特性增强：\n\n- 降低了在重写入密集型工作负载中出现的尾延迟：资源组通过资源配额和优先级控制工作负载。优先级由存储级别控制。当工作负载写入繁重时，基于优先级重新调度机制有时会造成更高的尾延迟（Tail Latency）。在 7.1 版本中，尾延迟被修正到预期水准。\n- 增加原生负载校准工具，帮助用户设置更准确的资源资源分配：资源分配的基础是用户对负载的资源使用量有所了解。新增的校准工具将很好的帮助您评估相关信息，以合理配置资源组。最快的方法是从 SQL 接口运行校准命令来估计基准测试（如 TPC-C 和 sysbench）的资源使用情况。\n\n#### 多个热点场景下性能和稳定性提升\n\n对 TiDB 的底层行存储 TiKV 有三个关键增强，以降低延迟提升稳定性（通过 p99 延迟衡量）。新版本引入了三项优化，分别针对三个级别热点进行处理：Key 级别、分片（Region）级别和节点级别：\n\n- Key 级热点：锁冲突优化\n- Region 级热点：TiKV 子任务的批处理化\n- 节点级热点：引入了基于负载的副本读取\n\n**锁冲突优化（GA）**\n\nTiDB 引入了处理 Key 级热点的优化。在遇到许多单点悲观锁冲突的负载中，唤醒等待请求的算法在新版本中将表现得更稳定，最大限度地减少了重试的资源浪费，从而节省了整个集群的资源并降低了尾延迟。测试表明，当启用锁冲突优化时，如果吞吐量相对较小，即使在冲突最严重的工作负载中，新版本的尾延迟也将降低 40-60%。\n\n![QPS.png](https://img1.www.pingcap.com/prod/QPS_08931bca5b.png)\n\n![99 Latency.png](https://img1.www.pingcap.com/prod/99_Latency_b8134dcf7c.png)\n\n**批处理 TiKV 子任务（GA）**\n\n选择性较差的查询可能会导致需要读取许多数据。在 TiDB 的分布式存算分离架构中，这样的查询可能会带来数万或数十万个 RPC 请求用于获取数据，如果使用索引读取则将更进一步加重这一负担。\n\nTiDB 服务器作为 TiKV 客户端，现在可以识别针对同一分片的批处理任务，并将这些批量发送到对应的存储节点。这大大减少了网络的 RPC 开销，使得这些查询更稳定。这个增强可以将相应场景中的延迟减少多达 50%。\n\n**基于负载的副本读取（GA）**\n\n这个特性用于优化节点级读热点。当大批量查询以不均匀的方式发起读取，可能会出现节点热点。注入 Index Lookup JOIN 这类常见的事情都可能会导致这种情况。一旦发生，读取请求会排队，当队列塞满时，一些请求可能会等待相当长时间。我们希望通过更均匀地分配工作来减少延迟。\n\n新版本中，TiDB 引入了基于负载的副本读取来实现这一点。它为队列提供了一个可配置的持续时间阈值，当超过该阈值时，它会告诉 TiDB 开始优先考虑副本读取。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。\n\n有关此优化的更多信息，请[参阅文档](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#scatter-read-hotspots)。\n\n### 更少的资源，更佳的性能\n\n本节中的功能和改进，提升了 TiDB 读、写以及管理操作的性能，以提供更好的用户体验。新版本中，TiDB 增加了多值索引以提供对 JSON 的查询效率。此外，在写入吞吐、分析查询速度和后台任务效率方面也进行了大量的改进和优化。\n\n#### 多值索引（GA）以增加速度和灵活性\n\n多值索引也称为“JSON 索引”，这种新型辅助索引在 TiDB 6.6 中引入并在 7.1 中 GA。多值索引支持索引记录到数据记录的 N:1 映射，使得查询可以快速检查存储在 JSON 数组中的特定值。\n\n例如，假设您将这样的数据存储在列中：\n\n```\n{\n\n    \"user\":\"Bob\",\n\n    \"user_id\":31,\n\n    \"zipcode\":[94477,94536]\n\n}\n```\n\n无论该数据存储为 blob，还是邮政编码直接存储为 zip 数组，用户都可以创建多值索引来定位特定邮政编码存在于哪一行。\n\n索引是使用表达式创建的，该表达式将 JSON 数据逻辑解析为生成列（Generated Column）和该列上的二级索引。如果您将 JSON 存储为 blob，并且需要支持遍历多层嵌套的查询，您只需创建一个索引以检索。\n\n有关用法和注意事项的更多详细信息，请参阅[多值索引文档](https://docs.pingcap.com/tidb/dev/sql-statement-create-index/#multi-valued-index)。\n\n#### 更快的 TTL（GA）\n\nTTL (Time to live) 在我们的 [TiDB 6.5 发布的文章](/blog/tidb-6.5-release)中作为一个实验特性进行了介绍，而在 7.1 中这个特性 GA 了。此外在新版本中，TiDB 节点可以共享 TTL 相关任务并并发执行，从而拥有了更好的性能和资源利用率。\n\n#### 延迟物化加速分析查询（GA）\n\nTiFlash 是 TiDB 的列式存储引擎，在 7.1 版本中延迟物化特性 GA。当表扫描拥有高过滤性的时候，TiDB 优化器可选择让 TiFlash 启用延迟物化。开启该特性后，TiFlash 支持下推部分过滤条件到 TableScan 算子，即先扫描过滤条件相关的列数据，过滤得到符合条件的行后，再扫描这些行的其他列数据，继续后续计算，从而减少 IO 扫描和数据处理的计算量。\n\n此功能的影响取决于实际负载和数据分布。在某些情况下，它可以显著减少延迟（在我们的测试中延迟最高可降低 70%）。TiDB 的查询优化器可以决定是否使用它，默认情况下打开是安全的。\n\n#### Multi-RocksDB 存储引擎带来巨大性能提升\n\n在 TiDB 6.6 中，我们引入了对 TiKV 存储架构的重大更改。虽然这个架构仍然是实验性的（默认关闭，并且只能在新集群中启用），但在这个 LTS 版本中，该特性获得重大加强，并在预生产环境中收到了很好的测试反馈。\n\n在 TiDB 6.6 之前，单一 TiKV 节点所有 Region 共享一个 RockDB 存储引擎。新架构则将不同 Region 分别存放在不同 RocksDB。新架构的好处是显著的：\n\n- 减少 RocksDB 对应的 LSM 负担，增加了吞吐量，测试结果显示写入吞吐量增加了 200%。\n- 使用不同 RocksDB 也会减少 Compaction 带来的写放大，降低资源消耗。\n- 更好的写入吞吐使集群的扩展速度提高 500%。\n- 在测试一些真实的客户工作负载时，我们观察到尾部延迟减少了近 50%。\n- 更小的单位存储消耗，使得集群可扩展性进一步增强。\n\n在 TiDB 7.1 中，我们进一步提高了该特性的性能和稳定性，并添加了网络带宽优化。当前仍然缺失的是 TiCDC、BR 等生态工具的支持，当这些完成后我们将宣布这个特性 GA。\n\n有关更多详细信息，请[参阅产品文档](https://docs.pingcap.com/tidb/dev/partitioned-raft-kv)。\n\n#### Online DDL 的大幅提升（实验特性）\n\n在《[天下武功唯快不破：TiDB 在线 DDL 性能提升 10 倍](/blog/10-times-online-ddl-performance-improvement)》中，我们介绍了 TiDB 索引构建操作性能的提高方式，并在 7.0 版本 GA。在 TiDB 7.1 中，类似于前述 TTL 改进，我们引入了跨 TiDB 节点分配 DDL 作业的框架，以进一步提高性能。\n\n## 立即体验 TiDB 7.1\n\n浏览 [TiDB 7.1 Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-7.1.0)，下载 TiDB [社区版](/product-community/)，了解更多新增和优化特性。\n\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n</div>\n","date":"2023-06-06","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.1-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"![TiDB 7.0发版.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_7_0_dd0bec1e31.jpeg)\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。  \n\n资源管控适用于以下场景：  \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况：  \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示：  \n\n![TPC-H 基准测试工具测试结果.png](https://img1.www.pingcap.com/prod/TPC_H_54be3f1f7f.png)\n\n## 自动计划缓存减少查询延迟  \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。  \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。  \n\n![TiFlash 存算分离架构.png](https://img1.www.pingcap.com/prod/Ti_Flash_4db2295760.png)\n<center>图：TiFlash 存算分离架构</center>\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。  \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。  \n\n## 使用 Key 分区提高可扩展性  \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求  \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。  \n\n## 使用 LOAD DATA 从远程存储导入数据  \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。  \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n","author":"PingCAP","category":2,"customUrl":"tidb-7.0-release","fillInMethod":"writeDirectly","id":473,"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","tags":["TiDB","Release"],"title":"TiDB 7.0 发版"}},{"relatedBlog":{"body":"## 导读\n\n资源管控技术（Resource Control）是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。  \n\n本文从将技术优势、配置方式、场景实践等角度详细解析 TiDB 7.0 版本中的资源管控技术。  \n\n作为可透明扩展的分布式数据库，TiDB 一直致力于满足企业对大型数据库集群的管理需要，集群内资源管控和资源隔离是企业客户长久以来的诉求之一。资源管控的主要目的在于解决数据库管理中常见的一些问题：  \n\n- 当多个业务共享同一数据库集群时，某个业务的非预期负载变化会影响其他业务的正常运行\n- 当集群中存在混合负载时，对资源需求较高的数据分析或批量作业会影响在线交易类业务的响应时间\n- 在需要 7x24 高可用性的业务系统中，数据备份、统计信息收集等后台任务可能会影响服务质量\n- 应用灰度上线时，小流量引发的性能问题仍可能“击穿”整个生产数据库\n\n为了解决上述场景中的问题，TiDB 开发了资源管控技术，于 TiDB 6.6 首次引入，并在 TiDB 7.0 进行了优化和增强。该技术利用资源组 (Resource Group) 将一个庞大的数据库集群划分为多个逻辑单元，每个资源组都能限制其所需的计算和 I/O 资源。通过特定设置，当集群有空闲资源时，允许一部分资源组超越其限制，以实现资源的充分利用。\n\n## 核心优势\n\n- TiDB 采用了业界领先的双层资源管控机制来实现更精确的管控。“流量控制”模块控制资源限额，确保仅在限额内的操作才能得以执行；“调度控制”模块则对队列中的任务设置不同的优先级，以确保在负载剧烈变化或超负荷运行时，高优先级的任务能够得到快速反馈。与同类产品通常只提供其中一层管控能力不同，TiDB 同时具备流控和调度控制能力，能够精确定义出更符合用户场景的配置。\n- 基于存储计算分离的架构，TiDB 的资源管控对最重要的 I/O 资源进行了限制。I/O 吞吐通常是数据库系统最常见的资源瓶颈，也是资源管控的难点，多数数据库产品并不支持对 I/O 进行控制。只有控制住主要瓶颈，才能保证在资源阻塞时有疏通调控的手段。\n- 把所有资源抽象成统一的单位来进行分配和限制。太过细粒度的设置通常难以衡量，也容易失去灵活性。TiDB 希望通过尽量少的指标来识别用户的意图，自适应地完成最佳的调度方案，提升易用性。\n- 除了隔离性，提升资源利用率也是 TiDB 资源管控的重要目标。在整体资源尚有空闲的情况下，允许部分业务超过资源组定义的限制。 \n- 提供用量统计的精确反馈， 通过监控面板获取实际用量的使用情况，协助用户合理改进配置。同时，配合企业管理目标，TiDB 能够协助企业精确统计各部门数据库资源的使用情况，进而完成合理的成本分摊。\n- 提供灵活的资源绑定手段。支持在用户级，会话级，和语句级指定资源的绑定方式，满足不同场景的资源控制需要。\n\n## 管理方式\n\n资源管控引入了“资源组(Resource Group)”的概念，通过设置“用户”和“资源组” 的对应关系，把会话与用户组进行绑定，利用“用量 (RU)”对资源限额进行定义。结构如下：\n\n![资源组结构.png](https://img1.www.pingcap.com/prod/_d377c2529e.png)\n\n### 资源组 (Resource Group)  \n\n资源组是资源管理的逻辑单元。任意一个会话属于唯一的资源组，而同一资源组的所有会话共享同一组资源限额。TiDB 支持数据库用户与资源组的映射关系，通过设置数据库用户的默认资源组，用户会话可以分属于不同的资源组。未指定默认资源组的用户，与系统内置的 default 资源组相关联。\n\n### 资源限额\n\nTiDB 首先支持为资源组配置用量 (RU)。RU (Request Unit) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位，目前会考虑 CPU、IOPS 和 IO 带宽三个指标，按照一定的比例统一到 [RU 单位上](https://docs.pingcap.com/zh/tidb/v6.6/tidb-resource-control#什么是-request-unit-ru)。TiDB 支持设置资源组为 BURSTABLE 模式，BURSTABLE 模式允许资源组超额使用到集群的空闲资源。\n用户可以查看面板数据的反馈，以获取真实的用量请求和分配情况。通过对数据进行分析，来优化资源组的限额配置。配合真实负载的压力测试，用户还可以通过数据反馈得出整个系统的用量上限。\n\n### 调度优先级\n\n默认情况下，所有资源组的优先级 (PRIORITY)均为“中等(medium)”。当资源组在同一优先级下，调度优先级按照资源配额的比例分配，这已经能够满足绝大多数场景的需要。用户仍旧可以显式地指定资源组优先级为“高(high)”或者“低(low)”，从而完成更复杂的设定。比如，为一个算力需求不大，但优先级很高的应用配置资源组。\n\n### 资源组设定\n\n在 TiDB v7.0，用户能够通过以下方式指定资源组：\n- 用户级别。通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组。绑定后，对应的用户新创建的会话会自动绑定对应的资源组。\n- 会话级别。通过 `SET RESOURCE GROUP` 设置当前会话的资源组。\n- 语句级别。通过优化器 hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n### 配置步骤\n\n- 启用资源管控\n\n手工开启资源管控分两步进行（资源管控在 TiDB 7.0 中默认开启）：  \n\n1)设置 TiDB 全局变量启用“流量控制”：  \n```\nSET GLOBAL tidb_enable_resource_control = 'ON';\n```  \n\n2)在 TiKV 配置中将 `resource-control.enabled` 设为 `true` 启用“调度控制”  \n\n- 估算集群容量\n\n在资源规划之前，TiDB 提供了集群总用量(RU)的估算。需要注意的是，这个值是基于当前硬件配置结合平均负载经验得出的参考值，在运行用户实际应用时可能会有偏差。用户可以以此作为资源组起始规划的参考，后续再根据实际运行数据进行微调。  \n\n```\nCALIBRATE RESOURCE;\n```\n\n- 有了总容量的估算，此时我们可以根据实际业务目标规划和创建资源组。例如创建一个名为 rg1 的资源组，分配每秒 500 RU 的流量，并允许资源组在有空闲资源的情况下超限额分配。  \n\n```\nCREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;\n```\n\n- 将用户 `usr1` 的资源组设置为 `rg1`\n\n```\nALTER USER usr1 RESOURCE GROUP rg1;\n```\n\n完成上述配置后，当系统繁忙时，用户 `usr1` 的所有会话使用的资源上限为 500 RU/秒；非繁忙时间段， `usr1` 则能够使用空闲集群资源。\n\n## 场景演示\n\n我们来看一个配置的示例。假定我们有三个租户分别运行三种不同的业务形态，每类业务有不同的管控目标：\n\n![三租户配置示例.png](https://img1.www.pingcap.com/prod/_963a4a6f64.png)\n\n对于以上这个需求，如果选择严格的多租户物理隔离，就不得不为每一个租户分配足够的资源，同时会造成 oltp 谷值负载时的资源浪费比较严重；而放入一套集群又无法消除租户 batch 对租户 oltp 的影响。利用 TiDB 既“隔离”又“融合”的资源管控技术，我们可以为这几类用户分别创建资源组：\n\n- 为租户 oltp 分配一个较高的用量，租户 batch 和 租户 hr 则相对低，这样在系统资源紧张的情况下，保证租户 oltp 的服务质量。\n- 租户 oltp 和 batch 的资源组设置为 burstable， 这样租户 oltp 发生超预期的负载，仍旧可能会保证质量；而当整个集群负载有空余时， 租户 batch 可以利用空闲资源加速其工作。\n\n![三租户配置示例-2.png](https://img1.www.pingcap.com/prod/2_79a66c4018.png)\n\n- 创建资源组\n\n```\nCREATE RESOURCE GROUP oltp  RU_PER_SEC=4000 BURSTABLE;\nCREATE RESOURCE GROUP batch RU_PER_SEC=400 BURSTABLE;\nCREATE RESOURCE GROUP hr    RU_PER_SEC=400;\n```\n\n- 创建租户对应租户，并设置其所属的资源组\n\n```\nCREATE USER 'oltp' RESOURCE GROUP oltp;\nGRANT ALL PRIVILEGES ON oltp.* TO 'oltp'@'%';\n\nCREATE USER 'batch' RESOURCE GROUP batch;\nGRANT ALL PRIVILEGES ON batch.* TO 'batch'@'%';\n\nCREATE USER 'hr' RESOURCE GROUP hr;\nGRANT ALL PRIVILEGES ON hr.* TO 'hr'@'%';\n```\n\n在完成以上简单的设置之后，我们来模拟几个租户不同的负载，观测吞吐量 (QPS) 和服务质量 (P99 响应时间）。整个场景模拟分为三个阶段：  \n\n1. 首先三类负载同时运行， 租户 oltp 设置为峰值负载。\n2. 切换租户 oltp 的负载到谷值，其他不变。\n3. 再次切换租户 oltp 的负载回到峰值。\n\n![三租户配置示例-3.png](https://img1.www.pingcap.com/prod/3_ec8c33d535.png)\n\n从实际数据来看，TiDB 资源管控技术在负载变化时的反馈非常及时。租户 oltp 的响应时间始终维持在较低的水平，租户 hr 的吞吐被限制在较低的范围内：\n\n1. 当租户 oltp 维持在峰值负载时， 它保持高吞吐和较低的响应时间；租户 batch 和 租户 hr 维持在低吞吐，由于租户 batch 可以使用空闲资源，因此吞吐要略高于租户 hr。\n2. 当租户 oltp 进入谷值负载，吞吐下降，其响应时间仍旧很低。这时由于租户 batch 的资源需求很大，因此它的吞吐迅速提升，响应时间下降， 租户 hr 仍旧被限制在其限额内。\n3. 当租户 oltp 重新回到峰值负载，租户 batch 则立即让出资源，使得租户 oltp 的吞吐再次回到之前的水平，响应时间维持不变。\n\n由此得出， 利用 TiDB 提供的资源管控和调度能力，多个不同诉求的租户能够共存在一套系统中，在保证各自服务目标的基础上，提升资源使用效率。\n\n## 资源管控技术协助企业兼顾质量与成本\n\n从上面的例子我们看到， 资源管控技术能够有效地解决在负载剧烈变化时，服务质量无法保证的问题。我们也可以利用这项技术防止未经验证的应用出现资源过载，比如新业务上线前的灰度测试，为资源组为灰度流量定义上限，避免局部性能问题引发大范围影响。  \n\n资源管控技术同时提供了数据库的多租户隔离能力，支持企业将中小型的系统进行合并，降低数据库运行成本。成本的节约主要来自几个方面：  \n\n- **节省预留资源**：一般来说，我们在规划单系统容量的时候，平均负载一般占到规划容量的 50% 甚至更低，留下足够的空间应对突发的性能抖动，以及未来可能的业务增长。而多个不相关的业务系统很少在同一时间出现负载波动，结合 TiDB 可透明扩展的特性，将这些系统合并到同一集群中，就不必预留相同比例的空间了。\n![节省预留资源.png](https://img1.www.pingcap.com/prod/_01adb7ab23.png)\n\n\n- **缓解峰值谷值波动**：如果将负载峰值与谷值不同的系统整合在一起，整合后的系统可以减少负载波动的幅度。在“削峰填谷”的作用下，资源利用率得到提升，低负载时段的硬件浪费也得到了减少。\n\n![缓解峰值谷值波动.png](https://img1.www.pingcap.com/prod/_9712ec1ec2.png)\n\n\n- **快速扩展与收缩**：企业经常需要为定期的业务活动增加临时的计算资源，以确保系统的稳定性。在多个业务系统合并的情况下，可以借助合理的业务规划，共享预留资源，轮流进行促销活动，而不必反复部署，节约重复的人力投入。\n\n- **提升运维效率**：将多个业务系统整合成一个系统，可以显著降低运维人员的投入。因为管理实体变少了，系统数量也减少到以前的几十分之一，运维难度和需要的人工成本都随之大大降低。\n\n这要求产品需要有很强的负载隔离能力，同时又能够将资源融合，正是 TiDB 资源管控技术想要达成的目标。\n\n## 未来展望\n\nTiDB 发布的资源管控能力是一个很好的开始，我们将沿着这个方向从多角度持续深耕这项技术，通过细粒度资源管控技术为客户创造更多的价值：  \n\n- **更多样的管控方式**： 根据场景的不同，为客户提供百分比，权重，用量等多种资源限额定义方式，并把 TiDB Cloud 中 Serverless 模式的计量方式和经验注入产品，协助客户运行自己的私有云服务，轻松完成成本分摊。扩展资源组的映射方式，支持除用户以外其他会话属性向资源组的映射。\n\n- **更多维的管控范围**： 除了最重要的 CPU 与 I/O 资源，持续延伸管控的范围和粒度，如分析型负载，内存使用，并行度等等。另外， 还将支持把运维操作和系统内部任务编入资源组， 协助客户做更精细的场景定义。\n\n- **更智能的管控手段**：通过分析历史运行数据，提供资源管理的建议，协助客户发现资源配置的潜在问题和风险，结合 TiDB Cloud 的部署运行经验，为客户提供更经济更合理的资源配置建议，协助企业的成本控制。\n\nTiDB 的弹性扩展特性和资源管控能力可以有效提高 IT 系统的效率，并协助企业降低 IT 运营的成本，同时确保系统的稳定性和安全性。随着资源管控技术的不断增强， TiDB 一定能够协助企业在数字化的道路上更加扎实地前进。","author":"宋日杰","category":1,"customUrl":"tidb-resource-control","fillInMethod":"writeDirectly","id":486,"summary":"资源管控技术是 TiDB 7.0 版本中优化提升的重要能力之一，不仅可以在负载剧烈变化时，保证服务质量，同时提供了数据库的多租户隔离能力，能够有效地降低数据库运行成本，帮助企业节省信息化管理开支，提升企业的竞争力。","tags":["Resource Control"],"title":"新特性解析丨TiDB 资源管控的设计思路与场景解析"}}]},{"id":"Blogs_473","title":"TiDB 7.0 发版","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。","body":"![TiDB 7.0发版.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_7_0_dd0bec1e31.jpeg)\n\n我们很高兴地宣布，TiDB 7.0 正式发布。TiDB 7.0 聚焦于帮助用户通过可靠性能和简化数据库操作来快速响应业务需求，从而满足客户的高期望值，并提升开发人员和 IT 运维人员的生产力。新版本中，TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性几个领域获得持续提升，累计引入新特性 20 余项，优化功能 50 余项。TiDB 7.0 是 TiDB 7 系列首个 DMR 版本，适用于开发、测试和 PoC 等场景。\n\n在 7 系列版本以及之后 2-3 年的时间里，我们希望 TiDB 在不断迭代中拥有：\n\n- 更强的基础能力（核心性能，扩展性，性价比，云原生等）；\n- 更加多元化的场景支持（多租户，更多数据模型支持，更好的生态适配）；\n- 更顺滑的运维体验（更强的 DDL 能力，以 SQL 为统一界面的运维体验等，智能运维）；\n- 更可靠更安全（更高的可用性，更好的安全体系整合，更多合规认证）。这些主题都将逐步在 7 系列以及后续版本中落实，给予用户更优的使用体验，让 TiDB 变成一个好用且泛用，可靠且经济的选择。具体到 7.0 版本，TiDB 初步提供了更好的资源管控能力，让 TiDB 针对 SaaS 和多平台统一共存等场景有了根本性的解决方案；其次，TiFlash 发布了面向云的存算分离新架构，这使其可以真正做到存算资源解耦，计算资源可以按需启停，且基于 S3 的存储设计也将大幅降低存储成本；而诸如分析引擎支持落盘，自动执行计划缓存等，则是针对企业级场景做出的必要强化；最后，TiDB 7.0 提供了对 MySQL 8.0 的兼容，这将使得相关用户能更方便地迁移到 TiDB。\n\n接下来让我们具体看看新版本的情况。\n\n## 资源管控增强多租户形态下工作负载稳定性\n\n资源管控特性（Resource Control）在 TiDB 6.6 中引入（实验特性），在 TiDB 7.0 中得到增强和优化，极大地提升 TiDB 集群的资源利用效率和性能表现，为稳定的多租户奠定了基础。资源管控特性对 TiDB 具有里程碑的意义，用户可以将一个分布式数据库集群划分成多个逻辑单元，将不同的数据库用户映射到对应的资源组中，并根据需要设置每个资源组的配额。该功能允许为一个或多个会话组设置资源上限，如果来自某个工作负载或应用程序的消耗异常重，则其资源消耗将被限制在配额内，以防止对其他更关键的工作负载造成干扰。  \n\n资源管控适用于以下场景：  \n\n- 用户可以将多个应用程序合并到单个 TiDB 集群中，降低 TCO 并保证重要工作负载所需的资源。\n- 用户可以在业务运营时间内安全运行批处理任务。\n- 模拟环境（Staging Environments）可共享具有受资源管控限制的单个 TiDB 集群。\n\n会话可通过三种方式绑定到资源组：通过 `CREATE USER` 或 `ALTER USER` 语句将用户绑定到特定的资源组，使得用户会话始终受到设定边界约束；通过 `SET RESOURCE GROUP` 设置当前会话的资源组；也可通过优化器 Hint `RESOURCE_GROUP()` 设置当前语句的资源组。\n\n## TiFlash 支持数据落盘来稳定分析工作负载\n\nTiFlash 是 TiDB 的列存储和计算引擎，是数据库分析工作负载能力的支柱。在 TiDB 7.0 之前，TiFlash 在内存中处理所有数据。从这个版本开始，TiFlash 支持数据落盘功能（Spill to disk），通过调整算子内存使用阈值，控制对应算子的最大内存使用量。对于大查询而言，当算子使用内存超过一定阈值时会自动将数据落盘，牺牲一定的性能换取整体分析查询的稳定性。数据落盘操作根据用户配置参数进行，并适用于单个推送下去的操作。由于该优化发生在单个运算符级别上，因此必须在多个位置执行数据落盘操作。在 TiDB 7.0 中，它首先被应用于以下情况：  \n\n- 相等条件下的哈希连接；\n- GROUP BYs 上的哈希聚合；\n- 窗口函数中 TopN 和排序运算符。\n\n在执行这些操作期间，如果运算符使用的内存量超过了配置限制，会自动将数据落盘并继续进行后续处理。为了说明目标工作负载受影响程度，我们模拟了决策支持系统，使用 TPC-H 基准测试工具进行测试，结果如下表所示：  \n\n![TPC-H 基准测试工具测试结果.png](https://img1.www.pingcap.com/prod/TPC_H_54be3f1f7f.png)\n\n## 自动计划缓存减少查询延迟  \n\n在此之前，TiDB 已经支持使用 PREPARE 准备语句来进行计划缓存。TiDB 7.0 中，非 Prepare 语句的执行计划也能够被缓存，使执行计划缓存能够应用于更广泛的场景。该功能支持在会话级别上对查询进行缓存，全局级别的支持将在未来发布中推出。会话级别的缓存将减少由于查找正确计划而导致的延迟，但可能也会增加全局缓存中可能存在重复数据时所需内存。目前可以通过此功能进行单表过滤和范围查询类型的查询进行缓存，但不能够处理单表复杂查询和 JOIN 查询等其他类型。  \n\n## TiFlash 支持存算分离架构，降低数据分析成本\n\n在 TiDB 7.0 版本，TiFlash 支持存算分离和 S3 对象存储（实验特性）。之前版本的 TiFlash 是存算一体架构，TiFlash 节点既是存储节点，也是计算节点，其计算和存储能力扩展受到一定限制。同时，TiFlash 节点只能使用本地存储。在 7.0 版本中，TiFlash 支持存算分离架构，分为 Write Node 和 Compute Node 两种节点，可以分别部署，单独按需扩展，并支持将数据存储在 Amazon S3 或兼容 S3 API 的对象存储中。  \n\n![TiFlash 存算分离架构.png](https://img1.www.pingcap.com/prod/Ti_Flash_4db2295760.png)\n<center>图：TiFlash 存算分离架构</center>\n\nTiFlash 存算分离架构适用于高性价比的数据分析场景。在数据量很大，但是只有少量数据被频繁查询，大部分冷数据很少被查询的场景下，将经常被查询的数据缓存在 Compute Node 的本地 SSD 上，可以提供较快查询性能，将大量冷数据存储在成本较低的 S3 或者其他对象存储上，从而节省存储成本。在计算资源需求有明显的波峰和波谷场景下，例如晚上执行的重型对账查询，对计算资源要求较高，可以临时扩展 Compute Node，其他时间可以用较少的 Compute Node 完成查询任务。TiFlash 的存算分离架构大幅降低了使用 TiFlash 支持分析工作负载的成本，并且提供了一定程度的工作负载隔离。目前，TiUP 和 TiDB Operator 已经支持部署和缩放 TiFlash 独立组件的能力。  \n\n## TTL 定期删除过期数据为系统减负\n\nTiDB 6.5 引入了 Time to live（TTL）实验特性，提供了行级别的生命周期控制策略，该项特性在 TiDB 7.0 中正式 GA。TTL 是一种通过 SQL 配置设置表中行到期时间的方式，帮助用户周期性且及时地清理不需要的数据，并尽量减少对用户负载的影响。TTL 以表为单位，并发地分发不同的任务到不同的 TiDB Server 节点上，进行并行删除处理。在某些情况下，较大的表格意味着查询时间更长；较大的表格意味着更多的存储成本；在 TiDB 中，一个表越大，Region 就越多，限制表格大小可以减轻系统负担；各种合规性要求可能需要设置数据过期。基于成本、性能或安全等因素考虑，数据库管理员可以配置自动检查并删除过期的表格行数据，例如定期删除验证码、短网址记录、不需要的历史订单、计算的中间结果等。  \n\n## 使用 Key 分区提高可扩展性  \n\n在 7.0 之前，TiDB 支持 Hash、Range 和 List 分区。新版本引入了 key 分区，与 Hash 分区类似，Key 分区可以保证将数据均匀地分散到一定数量的分区里面。Hash 分区只能根据一个指定的整数表达式或字段进行分区，而 Key 分区可以根据字段列表进行分区，且 Key 分区的分区字段不局限于整数类型。Key 分区提供了一种更灵活的方式来对数据集进行划分以改善集群的可扩展性。\n\n## 使用 REORGANIZE PARTITION 适应不断变化的需求  \n\nTiDB 长期以来一直支持分区，修改分区表的唯一方法是添加或删除分区和截断 LIST/RANGE 分区。TiDB 7.0 TiDB 支持 ALTER TABLE... REORGANIZE PARTITION 语法，用户可以对表的部分或所有分区进行重新组织，包括合并、拆分、或者其他修改，并且不丢失数据，增加了可用性和灵活性以满足不断变化的需求。  \n\n## 使用 LOAD DATA 从远程存储导入数据  \n\nTiDB 7.0 中，`LOAD DATA` 语句集成 TiDB Lightning，用户可以使用 `LOAD DATA` 语句完成原先需要使用 TiDB Lightning 才能完成的数据导入任务（实验特性），不仅可以省去 TiDB Lightning 的部署和管理成本，还可以借助 TiDB Lightning 的功能极大扩展 `LOAD DATA` 语句的能力，包括：支持从 Amazon S3 和 Google Cloud Storage 导入数据到 TiDB，且支持使用通配符一次性匹配多个源文件导入到 TiDB；支持查询任务状态，添加操作便利性等。  \n\n浏览 TiDB 7.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v7.0/release-7.0.0)，了解更多新增和优化特性。立即下载试用，开启崭新的 TiDB 探索之旅。企业级用户期待的 TiDB 7.1 LTS 版本将很快与大家见面，敬请期待！\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-7.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n","date":"2023-04-04","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-7.0-release","file":null,"relatedBlogs":[]},{"id":"Blogs_461","title":"TiDB 6.6 版本发布","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"我们很高兴地宣布，TiDB 6.6 版本已经发布了。在这个版本中，TiDB 一如既往地沿着更省心、更便捷、更快的方向前进。","body":"我们很高兴地宣布，TiDB 6.6 版本已经发布了。在这个版本中，TiDB 一如既往地沿着更省心、更便捷、更快的方向前进。\n\n## 更省心  \n\n### 资源组  \n\n在省心运维的主题下，新版本包含了重要的实验特性资源组功能。通过 TiDB 中的资源控制，一个应用的会话使用资源受设定的上限所限制。如果其工作负载变大，它的资源分配就会受到限制，以防止拖慢其他应用。这使得 TiDB 将更合适用于多租户的场景：  \n\n- 用户可以将多个小型或中型应用程序合并到一个TiDB集群中，从而降低整体TCO，同时仍然保证用于不同目的的资源。\n- 用户能够在工作时间安全地运行批处理作业。批处理任务消耗的资源可以包含在特定的资源组中。\n- 所有 Staging 环境都可以共享一个具有托管资源限制的TiDB集群，甚至可以与生产环境一起共享。\n\n用户可以为不同租户定义资源组，每个资源组包含了虚拟资源量，并且用户可以设定资源组是否可以在资源闲置时超额使用资源。  \n\n例如一个典型的资源组设定可以是这样的：\n\n| Resource Group  | RU limit<br>（资源上限）  | Burstable<br>（是否可超额使用）  | 特征  |\n|:----------|:----------|:----------|:----------|\n| Payment    | 4000    | YES    | 支付业务，需要确保资源供给，且在高峰时刻可以占用其他组的资源。    |\n| User Configuration    | 2000    | NO    | 用户信息管理，资源需求少于支付，且响应延迟需求低于支付，也无明显高峰低谷。    |\n| Nightly Batch    | 1000    | NO    | 夜间跑批业务，需要确保其不会过多占用资源。    |  \n\n\n```\nCREATE RESOURCE GROUP payment  RU_PER_SEC=4000 BURSTABLE;\nCREATE RESOURCE GROUP user_conf  RU_PER_SEC=2000;\nCREATE RESOURCE GROUP nightly_batch  RU_PER_SEC=1000;\n```\n\n随着资源组功能的加入，用户不再需要为诸多大大小小的业务和用户划分独立的 TiDB 集群（这样做在 SaaS 场景下甚至是不可能的），这不但节省了开销，也大大简化了运维管理。更进一步，将不同相关业务归于统一集群，也使得跨业务数据互通变得异常简单，无论是打造数据中台，还是架构微服务，都更方便省心。  \n\n### 从历史创建执行计划绑定  \n\nSQL 绑定是保持执行计划正确和稳定的重要方法。在关键业务中，用户往往希望执行计划保持稳定，不会因为数据变更等诱因而变化，因为突变的执行计划可能意味着查询效率大幅下降，资源使用飙升，以及严重的事故。在以往版本中，应对计划突变比较麻烦，哪怕已经明确最优计划是什么，用户也必须自己组装带有提示的计划，并在其之上创建绑定：\n\n```\nCREATE BINDING for\n    SELECT id, name, score FROM table1 WHERE id = 1 AND name = 'tidb';\nUSING\n    SELECT /*+ use_index(@sel_1 table1, idx_id) */ * FROM table1 WHERE id = 1 AND name = 'tidb';\n```\n\n在新版中，用户可以在 TiDB Dashboard 中找到最优的执行计划并绑定（也可使用命令行完成类似工作）：\n\n![在 TiDB Dashboard 中找到最优的执行计划并绑定.mp4](https://img1.www.pingcap.com/prod/Ti_DB_Dashboard_60f71ebbd4.mp4)\n\n\n## 更简单易用\n\n### 外键支持  \n\n在新版本中，TiDB 支持了外键。外键是 TiDB 一直缺失的 MySQL 兼容功能，在以往版本中 TiDB 可以理解外键约束的语法，但无法施加约束，这使得部分用户需要依赖应用代码去实现相应逻辑，这为使用增添了诸多麻烦，也引入了丢失数据完整性的风险。在新版本中，TiDB 终于支持了外键约束。用户可以通过为一张表定义外键的方式引用其他表的主键，从而达到强制约束两张表之间的数据完整性和一致性。例如，你可以为订单数据中的客户信息定义指向客户表的外键，这样在进行数据变更的同时，数据库会保证每个订单都确有对应的用户存在。\n\n### 多值索引\n\n新版中，TiDB 加入了实验特性多值索引（Multi-Valued Index）。多值索引有些类似搜索引擎的倒排索引，它允许用户针对数据中的 JSON 数组进行索引。例如单一客户信息的可能包含多个送货邮编，于是应用程序使用 JSON 数组字段进行保存。在以往版本中，TiDB 的索引仅仅能对单一值进行索引，因此在这个场景下，如果需要以邮编进行索引查找，你必须将邮编数组展开复制成多行（每行确保只有一个邮编），否则只能进行全表扫描，这无疑费心又难于管理。在新版本中，你可以为 JSON 中的数组字段创建多值索引：\n\n`ALTER TABLE customers ADD INDEX zips( (CAST(cust_profile->'$.zipcode' AS VARCHAR(10) ARRAY)) );`\n\n并在查询条件中搜索所有送货地址在某个邮编的用户，这样就能使用多值索引快速检索返回结果：\n\n`SELECT  * FROM customers WHERE ('200040' MEMBER OF (cust_profile->'$.zipcode'));`\n\n## 更快  \n\n### TiKV 和 TiFlash 引擎加速\n\n在新版中，TiKV 迎来了巨大的优化变更。  \n\n首先是实验特性 Partitioned-Raft-KV 存储引擎，以往同一个 TiKV 节点使用一个 RocksDB 存储数据，无论数据量多大，有多少 Region 和表；在 TiDB 6.6 中，TiKV 可以让单一 Region 更大（默认 10 GB），并使用独立的 RocksDB 实例，这将大大减少 LSM Tree 的深度，降低写入的压力，并提升性能。根据测试，写入吞吐提升可达 273%，集群扩缩容可提速 5 倍。\n\n|   | 写吞吐  | 扩容  | 缩容  |\n|:----------|:----------|:----------|:----------|\n| 单 RocksDB    | ~60MB/s    | 0.73GB/min    | 2.86GB/min    |\n| Partitioned-Raft-KV    | ~224MB/s (+273%)    | 3.6GB/min (+500%)  | 13.7GB/min (+480%)   |\n\n其次，TiKV 在新版中可以通过协处理器攒批的方式减少诸如读取索引等操作带来的大量 RPC 调用，在通过索引读取百万以上规模行的场景下，可提速一倍以上。  \n\n再来说说 TiDB 的分析引擎 TiFlash。  \n\nTiFlash 的最基础能力是，支持计算时让数据在不同节点之间交换。为了完成计算，有时分析引擎节点之间需要交换大量数据，例如执行大表的关联时，需要将两张表分别按照关联键进行哈希并相互分发。这种情况下，网卡有时候会成为性能瓶颈。在新版中，分析引擎支持了将数据进行压缩后再分发的能力，这使得 TiDB 针对标准 TPC-H 测试下的性能有 12%-32% 的提升，以及超过 50% 的网络带宽节省。  \n\n与此同时，TiDB 分析引擎在新版中支持了 Stale Read。当用户不追求严格读取实时数据的前提下，使用该功能读取历史数据可带来 30% 左右的性能提升。  \n\n### DM 支持物理导入模式  \n\n新版本中，DM 的全数据（存量数据）迁移能力集成了TiDB Lightning 的物理导入模式。相较于以往的逻辑模式导入数据，新版本中 DM 的迁移性能提升高达 10 倍，大大缩短了数据量大的场景下的迁移时间；现在，要迁移超过 1 TB 的数据，你只需要在 DM 任务中设置参数即可实现高达 500 GB/小时的存量数据迁移性能。用户再也无需额外配置 TiDB Lightning 迁移存量数据以加快导入速度，大大简化了使用：\n\n`import-mode：\"physical\"`\n\n## 总结  \n\n以上是 TiDB 6.6 所带来的重要功能概览，除此之外，新版本共发布了 32 个新特性，37 个增强以及 80 个问题修复，希望了解详情可参考 TiDB 6.6 [Release Notes](https://docs.pingcap.com/zh/tidb/v6.6/release-6.6.0)。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.6-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>","date":"2023-02-20","author":"马晓宇","fillInMethod":"writeDirectly","customUrl":"tidb-6.6-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版（上一个是 [TiDB 6.1](/blog/tidb-6.1-release)），除了携带了诸多备受期待的新特性，同时也将得到 TiDB 开发社区的长期维护，是推荐企业级用户采用的最新版本。\n\n![TiDB 6.5 LTS.png](https://img1.www.pingcap.com/prod/Ti_DB_6_5_LTS_83af544cd2.png)\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.5-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n在这个版本中，TiDB 专注于如下几个主题：\n\n- **产品易用性进一步提升**\n- **内核不断打磨，更加成熟**\n- **多样化的灾备能力**\n- **应用开发者生态构建**\n\n相信长期关注我们的朋友已经发现，这些主题似曾相识。的确如此，TiDB 近年的发展几乎都围绕着它们开展。我们期望 TiDB 成为**更易用，对开发者更友好，且更成熟的企业级数据库**，而这个追求也并没有尽头。\n\n## 产品易用性进一步提升\n\n大家也许不止一次听说过，易用性之于 TiDB 是非常关键的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯穿始终。在新版本中，我们提供了更多的让用户解放心智的能力。\n\n### AND 运算下的索引归并读取\n\n对于数据服务和洞察场景，用户往往会基于诸多查询条件的组合进行数据筛选。例如在物流场景中，用户可能会根据下单日，仓库 ID，转运人，送达日，目标地址等等不同维度进行筛选再分析。而这些条件单独来看，并不一定具备很好的选择性，只有组合起来才能将数据限定在一个小范围。如果条件的组合不多，我们尚可使用特定的组合索引覆盖，但很可能在这类场景中，组合以数十记，完全无法为每个组合都创建特定索引。在新版本中，TiDB 支持根据 AND 条件组合同时选中多组索引，并计算它们的交集再读取实际表数据。这种能力，使得用户可以仅仅为单列创建少量索引，以达到更好的选择性以及更优的性能。\n\n![Screen Shot 2023-01-03 at 00.50.14.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_00_50_14_365a0cbe7e.png)\n\n### 集群闪回\n\n有时候，用户会希望整个集群快速恢复到之前的某个时间点。例如，由于游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版发布后一小时内人手一把。若仅仅如此也就算了，开发者可以很容易回收或这个道具，但这种事故还有次生灾害，例如稀有 Boss 被滥杀，稀有掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会希望时间能回到犯错之前的那一刻，让你修正那个令人追悔莫及的错误。在新版本中，TiDB 就提供了这个能力，它支持用简单一条命令向 GC 时间内的任意时间点进行全集群闪回，就像下面这样。\n\n```sql\nFLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; \n```\n\n我们当然希望这不会是一个常见的状况，但这并不表示需要闪回的时机千年难遇：闪回能力也可用于日常操作，例如将测试环境恢复到测试开始前的状态，以供反复使用。\n\n### 完整的大事务自动拆分支持\n\n在前序版本中，我们支持了针对删除的大事务自动拆分支持。而在新版本中，TiDB 完整支持了针对插入和修改的大事务拆分。在以往版本中，TiDB 用户经常要面对的一个问题就是，一些大规模的数据变更维护操作，例如过期数据删除，大范围数据修订，或者根据查询结果回写数据等操作，会遇到超过 TiDB 单条事务上限的问题，这是由于 TiDB 单一事务需要由单一 TiDB Server 作为提交方而带来的限制，这时候用户往往不得不手动想办法拆小事务以绕过该限制。但在实际使用中，上述类型的数据变更未必真的需要作为单一事务确保原子性，例如数据淘汰和数据修订，只要最终执行完成，哪怕事务被拆开多次执行也并不会影响使用。在 TiDB 6.5 中，我们提供了将大事务自动拆分的能力，例如按照 t1.id 以 10000 条为大小分批数据更新，可以简单使用如下语句完成：\n\n```sql\nBATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;\n```\n\n更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml)。\n\n### TiFlash 结果物化（实验特性）\n\nTiFlash 在过往版本中有一个很大的缺憾是无法在读写事务中使用：经常用户希望将 TiFlash 的计算结果进行回写以供高并发读取（类似物化效果）。从 v6.5.0 起，TiFlash 支持通过 INSERT SELECT 语句回写结果进行物化，节省系统资源并提高响应速度。\n\n```sql\nINSERT INTO top_payments SELECT MAX(amount) FROM payments;\n```\n\n在执行上述 INSERT INTO SELECT 语句时，TiDB 可以将 SELECT 子查询下推到 TiFlash 以提供高速分析计算，并将返回结果通过 INSERT INTO 可以保存到指定的 TiDB 表中。值得一提的是，该功能结合前述大事务拆分可以实现大量结果集物化。\n\n### 高性能全局单调递增 AUTO_INCREMENT 列\n\nTiDB 作为一款分布式数据库，以往在使用 AUTO INCREMENT 列创建主键时，仅保证在每个 TiDB 实例中序列递增，而跨 TiDB 实例则无法保证。但实际使用中，用户仍然经常会遇到需要严格单调递增主键的时候，例如以主键隐式代表时间维度，确定事件发生顺序。在 6.4 版本中，我们加入了高性能的全局单调递增主键的支持，以兼容 MySQL 的行为。该模式下，TiDB 将采取中心化的主键分配以确保单调递增，即使跨 TiDB 实例访问，ID 也不会出现回退，且针对其的写入也可轻松达到数万的 TPS。\n\n### 使用 TTL (Time to Live) 来周期性地删除过期数据（实验特性）\n\n维护数据的生命周期在 TB 以上规模下并不是很容易的事情：由于数据规模大，寻找并清理过期的数据往往需要消耗相当的算力，有时用户为了更快清理数据甚至被迫使用分区表，以删除分区的方式来进行快速清理。更麻烦的是，用户需要维护特定的任务以不断定期淘汰数据。在新版本中，TiDB 提供了 Time to Live (TTL) 能力，使得用户可以设定行级别的生命周期控制策略。通过为表设置 TTL 属性，TiDB 可以周期性地自动检查并清理表中的过期数据。当开启时，TTL 会以表为单位，并发地分发不同的任务到不同的 TiDB 实例节点上，进行并行删除处理，且不影响集群性能。更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/time-to-live)。\n\n## 内核关键特性打磨和增强\n\nTiDB 包含繁多的特性集合，但其中有些仍需不断打磨，例如 JSON 虽然已获支持许久，但实际能力却尚需完善。在新版本中，我们针对重要特性集合用力打磨，以期提供给用户更「丝滑」的体验，让 TiDB 的重大特性以更完善的方式呈现在用户面前，也让 TiDB 演进方式更稳重更有质量。\n\n**首先是 DDL 加强**。支持在线 DDL 是 TiDB 的核心优势之一，在过往一年中，我们加入了对并行 DDL 的支持，使得以往在 SaaS 等多租户场景因 DDL 串行执行互相阻塞导致的 DDL 语句间执行效率低的问题得以解决，通过引入 Metadata Lock 基本消除了 DDL 干扰 DML 的情况。在新的 6.5 版本中，TiDB 支持了类似 Lightning 注入 SST 的设计，针对需要追溯的历史数据直接使用 SST 构建的方式进行生成，大幅提高了 DDL 的构建速度，最快可达 **10 倍提升**。\n\n如下图所示，以 TiDB 6.1 版本为基准值，新版除了取得了数量级的提速，且对比 CockroachDB v22.2 和当前版的 AWS Aurora 也快 2-3 倍。\n\n![Screen Shot 2023-01-03 at 10.15.34.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_10_15_34_49df47db5a.png)\n\n**其次是 JSON 的支持打磨**。JSON 对于需要灵活数据结构的场景非常重要，因此在移动端，游戏开发等场景中广泛使用。从 6.2 版本以来，TiDB 陆续引入了完整的 MySQL 5.7 兼容函数，针对 JSON 的表达式索引支持，更多的生态工具兼容。新版本支持将 JSON 函数 \"->\"、\"->>\"、\"JSON_EXTRACT()\" 下推至 TiFlash，可以提高 JSON 类型数据的分析效率，拓展 TiDB 实时分析的应用场景。\n\n**再者是 TiDB 全局内存控制**。自 v6.5.0 起，TiDB 全局内存控制已能够跟踪到 TiDB 中主要的内存消耗。当单个会话的内存消耗达到系统变量 `tidb_mem_quota_query` 所定义的阈值时，将会触发系统变量 `tidb_mem_oom_action` 所定义的行为 (默认为 `CANCEL`，即取消操作)。当全局内存消耗达到 `tidb_server_memory_limit` 所定义的预设值时，TiDB 会尝试 GC 或取消 SQL 操作等方法限制内存使用，保证 TiDB 的稳定性，对内存的使用效率也更加高效。 \n\n**最后是降低累积的悲观锁对性能的影响**。 在一部分交易系统，尤其是银行业务中，客户应用会在悲观事务中利用 select for update 先锁定一条记录，从而达到对数据一致性的保护，减少事务中后续操作失败的可能，比如\n\n```sql\nBEGIN;\nSELECT c FROM sbtest1 WHERE id = 100 FOR UPDATE; \nUPDATE sbtest1 SET k = k + 1 WHERE k = ?; \nCOMMIT;\n```\n\n而在 TiDB 中，对一行记录反复的 select for update，会造成这条记录的查询性能下降。 在 v6.5.0 中，我们对这部分机制进行了优化， 通过记录连续的锁标记，降低了累积的悲观锁对查询性能的影响，QPS 可大幅提升 10 倍以上。\n\n## 多样化的灾备能力\n\n在过往版本中，TiDB 主要依赖 BR 进行静态的备份恢复，而在 6.2 之后的新版中，TiDB 提供了 PITR 能力，使得数据库可以更灵活地恢复到任意时间点。\n\nTiDB PITR（Point-in-Time Recovery）是结合了 BR 和变更捕获（Change Data Capture）两种能力的灾备特性。以往 BR 的静态灾备只能将数据恢复到备份的时间点，如果要更提供针对更新和更多时间点的恢复，则相应需要提高备份频率。这不但会加重备份对在线业务的负担，也需要更多存储成本。使用 PITR 则可以摆脱这个烦恼，用户无需不断进行全量备份，而是可经由一个全量备份结合增量共同完成针对任意时间点的数据恢复。\n\n![Screen Shot 2023-01-03 at 01.48.32.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_01_48_32_f41d588441.png)\n\n经过半年左右的持续改进，在新版本中，我们减少了 PITR 备份文件大小和数量，加强了稳定性，提升了性能。 例如：确保在绝大多数异常场景下 RPO < 5mins, 单个 TiKV 的备份速度达到100MB/s等。\n\n与此同时，在 6.5 版本中，TiCDC 的吞吐获得了得了至数倍的提升。通过对 TiCDC 内部的设计和实现的不断优化，针对数据复制场景，当下游为 Kafka 集群时，针对大单表场景的吞吐量得到了极大的提升，单个 TiCDC 节点可以支持35k row/s QPS，吞吐量可以达到 50MB/s，并将延迟控制在 2 秒左右，而内存使用量只有之前版本的50%左右。 针对跨区域主备集群容灾场景，TiCDC 单个节点的吞吐量可以达到 30MB/s，并且其延迟也可以稳定在 2 秒左右，稳定性大幅度提高。\n\n其次，在6.5 版本中，DM 正式发布了在数据迁移过程中的增量数据持续校验功能，该特性只对新增或变更的数据进行校验，而不是对整个数据集进行校验，在确保数据迁移过程的准确性和可靠性的同时，大大减少数据校验的时间和资源消耗。尤其是在迁移一些重要系统时，该特性可以让数据迁移过程更加安全。\n\n除此以外，新版本支持了在下游集群使用水位线进行一致性读取的能力：在新版本中，TiCDC 可以在向下游写入时提供特殊的时间戳，而下游集群则可以自动使用该时间戳进行一致性读取而无需担心读到的事务不完整。这使得下游集群在需要严苛事务保证的场景下，也可以良好承担读流量分流的职责。\n\n![Screen Shot 2023-01-03 at 02.04.38.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_02_04_38_3012a4bd0d.png)\n\n## 应用开发者生态构建\n\n在以往版本中，TiDB 更强调 DBA 的使用体验。但在近期的更新中，你也许已经发现我们逐渐开始聚焦 DBA 以外的应用开发者体验。在新版中，我们强化了应用开发所需的生态环境构建，例如这半年来 TiDB 通过增加对 Savepoint，User Level Lock，Multiple Schema Change 等功能的支持，完善了针对常见应用框架 django，prisma 等的支持。与此同时，我们也引入了更多上下游生态厂商的战略合作：Vercel，Hashicorp，Retool 等。在 6.5 版本中，TiCDC 增加了针对向 Object Storage 写入的支持。对象存储是一种面向云的存储服务，具有高可扩展性、高可用性、低成本等优势。使用 TiCDC 将数据同步到对象存储，可以帮助用户实现数据的长期存储、数据的跨区域复制等目的。另外，这使得 TiDB 在云环境下能直接打通向数仓和数据湖环境的通路。更好的生态支持，将使得开发者在使用 TiDB 构建应用时，拥有更多选择，也更简便。\n\n## 总结\n\n作为 TiDB 版本 6 的第二个长期支持版，TiDB 6.5 已经发布。我们希望借助这个版本为更多用户提供更易用且更成熟的企业级数据库。更详细的变更情况请参阅 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.5.0)。欢迎各位和我们一起开启新的[奇妙旅程](https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb)。","author":"马晓宇","category":2,"customUrl":"tidb-6.5-release","fillInMethod":"writeDirectly","id":451,"summary":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。","tags":["TiDB","Release"],"title":"TiDB 6.5 LTS 版本发布"}},{"relatedBlog":{"body":"TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版，携带了诸多备受期待的新特性：**产品易用性进一步提升、内核不断打磨，更加成熟、多样化的灾备能力、加强应用开发者生态构建**……\n\nTiDB 6.5 新特性解析系列文章由 PingCAP 产研团队重磅打造，从原理分析、技术实现、和产品体验几个层面展示了 6.5 版本的多项功能优化，**旨在帮助读者更简单、更全面的体验 6.5 版本**。\n\n本文为系列文章的第一篇，介绍了 TiFlash 在高并发场景下的稳定性和资源利用率的优化原理。\n\n## 缘起\n\n最近的某天，我们测试 TiFlash 在高并发查询场景下的稳定性时，发现 TiFlash 终于可以长时间稳定将 CPU 完全打满，这意味着我们能充分的利用 CPU 资源。回想一年多前，我们还在为高并发查询下的 OOM（out-of memory）、OOT（out-of thread）、CPU 使用率不高等各种问题而绞尽脑汁。是时候来回顾一下我们做了哪些事情，让量变引起质变。\n\n![1.png](https://img1.www.pingcap.com/prod/1_7a99a35a4c.png)\n<center>👆 CPU 使用率打满</center>\n\n我们都知道，对于分析型的查询来说，有时候一个请求就能将机器的 CPU 资源打满。所以，大部分 OLAP 系统在设计和实现的时候，很少考虑系统在高查询并发下的表现——早期的 TiFlash 也没在这方面考虑太多。\n\n早期的 TiFlash 的资源管理比较初级——没有高效的线程管理机制、缺少健壮的查询任务调度器、每个查询的内存使用没有任何限制、最新写入的数据存储和管理也有较大优化空间。这些优化措施的缺位，导致早期的 TiFlash 在高并发查询场景下表现不佳，经常无法将 CPU 使用率打满，稍有不慎还可能出现 OOM 或 OOT。\n\n过去一年里，针对 TiFlash 在高并发场景下的稳定性和资源利用率这个问题，我们在存储和计算上都做了不少尝试和努力。如今回头看，有了上面的结果，也算是达到了一个小里程碑。\n\n## DynamicThreadPool\n\nTiFlash 最开始的线程管理非常简单粗暴：请求到来时，按需创建新线程；请求结束之后，自动销毁线程。在这种模式下，我们发现：对于一些逻辑比较复杂，但是数据量不大的查询，无论怎么增加查询的并发，TiFlash 的整机 CPU 使用率都远远不能打满。\n\n![2.png](https://img1.www.pingcap.com/prod/2_1f33daf820.png)\n<center>👆 CPU 使用率始终保持在 75% 以下</center>\n\n经过一系列的研究之后，我们终于定位到问题的根本原因：高并发下，TiFlash 会频繁地创建线程和释放线程。在 Linux 内核中，线程在创建和释放的时候，都会抢同一把全局互斥锁，从而在高并发线程创建和释放时, 这些线程会发生排队、阻塞的现象，进而导致应用的计算工作也被阻塞，而且并发越多，这个问题越严重，所以 CPU 使用率不会随着并发增加而增加。具体分析可以参考文章：[深入解析 TiFlash丨多并发下线程创建、释放的阻塞问题](https://cn.pingcap.com/blog/deep-interpreting-of-tiflash?utm_source=wechat&utm_medium=social)。\n\n解决这个问题的直接思路是使用线程池，减少线程创建和释放的频率。但是，我们目前的查询任务使用线程的模式是非抢占的，对于固定大小的线程池，由于系统中没有全局的调度器，会有死锁的风险。为此，我们引入了 DynamicThreadPool 这一特性。\n\n在 DynamicThreadPool 中，线程分为两类：\n\n1. 固定线程：固定数量的线程，生命期与整个线程池相同。\n2. 动态线程：运行过程中随着负载升高而创建，会自行在冷却后销毁。\n\n每当有新任务需要执行时，DynamicThreadPool 会按以下顺序查找可用线程：\n\n1. 空闲的固定线程。\n2. 空闲的动态线程。\n3. 当没有可用线程时，创建新的动态线程服务当前任务。\n\n所有空闲的动态线程会组成一个 LIFO 的链表，每个动态线程在处理完一个任务后都会将自身插入到链表头部，这样下次调度时会被优先使用，从而达到尽可能复用最近使用过的动态线程的目的。链表尾部的动态线程会在超过一个时间阈值没有收到新任务之后判断自身已冷却，自行退出。\n\n## MinTSOScheduler\n\n由于 DynamicThreadPool 没有限制线程的数量，在遇到高并发查询时，TiFlash 仍然有可能会遇到无法分配出线程（OOT）的问题。为了解决此问题，我们必须控制 TiFlash 中同时使用的线程数量。\n\n为了控制同时使用的计算线程数量，同时避免死锁，我们为 TiFlash 引入了名为 MinTSOScheduler 的查询任务调度器——一个完全分布式的调度器，它仅依赖 TiFlash 节点自身的信息。\n\n![3.png](https://img1.www.pingcap.com/prod/3_d04c476b42.png)\n<center>👆 MinTSOScheduler 的基本原理</center>\n\nMinTSOScheduler 的基本原理是：保证 TiFlash 节点上最小的 start_ts 对应的所有 MPPTask 能正常运行。因为全局最小的 start_ts 在各个节点上必然也是最小的 start_ts，所以 MinTSOScheduer 能够保证全局至少有一个查询能顺利运行从而保证整个系统不会有死锁。而对于非最小 start_ts 的 MPPTask，则根据当前系统的线程使用情况来决定是否可以运行，所以也能达到控制系统线程使用量的目的。\n\n## MemoryTracker\n\nDynamicThreadPool 和 MinTSOScheduler 基本上解决了线程频繁创建和销毁、线程使用数量不受控制两大问题。对于一个运行高并发查询的环境，还有一个重要的问题要解决——减少查询之间的相互干扰。\n\n实践中，我们发现最重要的一点就是要避免其中某一个查询忽然消耗掉大量内存，导致整个节点 OOM。为了避免某个大查询导致的 OOM，我们显著增强了 MemoryTracker 跟踪和记录每个 MPPTask 使用的内存的精确度。当内存使用超过限制时，可以强行中止请求，避免 OOM 影响其它请求。\n\n## PageStorage\n\nPageStorage 是 TiFlash 中的一个存储的抽象层，类似对象存储。它主要是为了存储一些较小的数据块，如最新数据和 TiFlash 存储引擎的元数据。所以，PageStorage 主要面向新写入数据的高频读写设计。v6.1 及之前 TiFlash 使用的是 PageStorage 的 v2 版本（简称 PSv2）。\n\n经过一系列的迭代和业务打磨，我们发现 PSv2 存在一些问题亟需改进：\n\n1. 在一些写入负载，特别是 append-only 负载下，容易触发激进的 GC 策略对硬盘数据进行重写。重写数据时引起较大的写放大，以及内存的周期性快速上涨，造成系统不稳定。同时也会挤占前台写入和查询线程 CPU。\n2. 在 snapshot 释放时进行内存中的垃圾回收，其中涉及较多内存小对象的拷贝。在高并发写入和查询的场景下，snapshot 释放的过程与读写任务挤占 CPU。\n\n这些问题在大部分写入和查询并发较低的 OLAP 场景下，对系统的影响有限。但是，TiFlash 作为 TiDB 的 HTAP 架构中重要的一环，经常需要面对高并发的写入和查询。为此，我们重新设计并实现了全新的 PageStorage （简称 PSv3）以应对更严苛的 HTAP 负载需求。\n\n![4.png](https://img1.www.pingcap.com/prod/4_2f02641873.png)\n<center>👆 PSv3 架构图</center>\n\n上图是 PSv3 的整体架构。其中，橙色块代表接口，绿色块代表在硬盘上存储的组件，蓝色块代表在内存中的组件。\n\n- WALStore 中维护数据（page）在 BlobFile 中位置，内存中的 PageDirectory 实现了 MVCC 支持。\n- 数据保存在 BlobFile 中，如果其中的数据反复重写，会造成 CPU 以及 IO 资源的浪费。我们通过 SpaceMap 记录了 BlobFile 上的数据块使用情况（空闲或占用）。删除数据时，只需要更新一下标记。写入数据时，可以直接从 SpaceMap 查找符合要求的空闲块直接写入。大部分情况下，BlobFile 可以直接复用被删除的空闲数据块，避免数据重写的发生，最大程度地减少了垃圾回收的需求，从而显著减少 CPU 和内存空间使用。\n- 由于有 SpaceMap 的存在，写线程在 SpaceMap 中分配好数据块位置之后，多个写线程的 IO 操作可以并发执行。在复用空间时 BlobFile 文件大小不变，可以减少了文件元数据的 sync 操作。TiFlash 整体的写延迟降低，进而减少等待数据一致性的 wait index 阻塞时间，提升查询线程的 CPU 利用率。\n- 让读写线程 snapshot 创建和释放时的操作更高效，内存对象的整理的时间从释放 snapshot 时改为在后台线程进行回收，减少了对前台读写任务的影响，从而提升了查询线程的 CPU 利用率。\n\n## 总结\n\n| DynamicThreadPool | MinTSOScheduler | PageStorageV3 | CPU 最大使用率 |\n| --- | --- | --- | --- |\n| enable | enable | enable | 100% |\n| disable | disable | enbale | 75% |\n| enable | disable | enable | 90% |\n| enable | enable | disable | 75% |\n| disable | enable | enable | 85% |\n\n上面这个表格总结了本文介绍的这几个提升 TiFlash 稳定性和 CPU 使用率的关键特性的组合情况，可以看出：\n\n- DynamicThreadPool 解决了频繁创建和销毁线程带来的开销；PageStorage v3 大大降低了 GC 和 snapshot 的开销，提升了高并发写入和查询的稳定性。这两者对提升 CPU 利用率有明显的效果。\n- MinTSOScheduler 调度器限制了查询使用线程的数量，避免了出现分配不出线程的情况，可以有效防止高并发请求导致的 OOM、OOT。\n- 而 MemoryTracker（内存限制）通过主动 cancel 掉部分请求来防止整个进程 OOM，可以有效避免一个大查询导致整个节点不可用（OOM）的情况发生。\n\n除此之外，过去一年，TiFlash 在性能和功能方面也做了不少优化，感兴趣的朋友可以关注我们的 github 代码和官方文档。以上全部改动可以在 TiDB v6.5 LTS 版本中体验到，欢迎尝试。","author":"林金河，颜秋阳","category":1,"customUrl":"new-features-of-tidb-6.5-1","fillInMethod":"writeDirectly","id":455,"summary":"TiDB 6.5 新特性解析系列文章由 PingCAP 产研团队重磅打造，从原理分析、技术实现、和产品体验几个层面展示了 6.5 版本的多项功能优化，旨在帮助读者更简单、更全面的体验 6.5 版本。本文介绍了 TiFlash 在高并发场景下的稳定性和资源利用率的优化原理。","tags":["TiDB","TiFlash"],"title":"TiDB 6.5 新特性解析丨过去一年，我们是如何让 TiFlash 高效又稳定地榨干 CPU？"}}]},{"id":"Blogs_453","title":"TiDB 中标杭州银行核心系统数据库项目","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"近日，平凯星辰 TiDB 分布式数据库成功中标杭州银行核心系统数据库项目。平凯星辰凭借前瞻的产品技术方案、金融领域的经验积累、专业快速的服务保障及高度活跃的开源社区，在竞争中脱颖而出。此次中标再次印证了 TiDB 新一代分布式数据库在银行核心系统建设、确保业务连续性以及支持业务敏捷高效创新等方面具备关键的服务能力。","body":"**近日，平凯星辰 TiDB 分布式数据库成功中标杭州银行核心系统数据库项目**。平凯星辰凭借前瞻的产品技术方案、金融领域的经验积累、专业快速的服务保障及高度活跃的开源社区，在竞争中脱颖而出。此次中标再次印证了 TiDB 新一代分布式数据库在银行核心系统建设、确保业务连续性以及支持业务敏捷高效创新等方面具备关键的服务能力。\n\n![1.png](https://img1.www.pingcap.com/prod/1_1ce4ab0524.png)\n\n核心系统是银行交易和账户处理的中心，是银行信息系统的基础和核心，被誉为银行的“心脏”。在数字经济的发展和新技术崛起的背景下，杭州银行**坚持自主研发、自主创新的系统建设思路，利用云原生、微服务等技术重构杭州银行技术架构和能力体系**，打造满足未来业务发展的新一代全栈式自主可控的分布式技术平台，构建稳定高效和灵活敏捷兼备的核心系统。\n\n分布式数据库是核心系统技术平台的关键组成部分，杭州银行 2019 年启动国产分布式数据库领域的前沿技术研究，有计划、分步骤地推进分布式数据库在业务场景的落地。围绕银行核心业务系统：数**据量大、交易数据变更频繁，交易热点集中；多渠道接入、交易并发量大；数据重要性高、安全等级要求高；系统可用性、可靠性高等特点**；在本次新一代分布式核心系统数据库的选型上，秉持“SAPE”原则（即 Safe 高安全、Availability 高可用、Performance 高性能和 Ecology 多生态）；坚持参照金融行业分布式数据库应用相关规范，结合杭州银行业务发展和新一代分布式核心系统整体架构的思路，开展适配新一代分布式核心系统的金融级分布式数据库选型工作。\n\n在本次核心系统数据库选型过程中，杭州银行组织多方，共建“风洞实验室”从软件开发、建设部署、数据迁移、业务交易、运维监控和容灾切换等多个维度，共同设计产品测试场景和用例，对 TiDB 进行了全面详尽的测试验证。测试结果表明，**TiDB 在开发易用性、混沌故障注入稳定性测试、多中心多活、性能横向扩展、HTAP 特性上具有显著的先进性**。从开放性上看，TiDB 在技术社区的活跃度、开发平台适配方面具备较明显的优势，拥有高度开放的数据技术生态。\n\n**基于前期选型成果和互联网核心的成功实践，杭州银行在新一代分布式核心系统中选择 TiDB 用于数据底座。**\n\nTiDB 历经全球 3000 多家行业用户海量数据的严苛场景打磨，稳定可靠，具备金融关键核心业务的支撑能力。TiDB 分布式数据库成功应用于中国银行、建信金科、浦发银行、北京银行、浙商银行、中国人寿、平安科技、微众银行等多家金融企业的联机交易、在线支付、信贷管理、实时风控等场景，帮助金融机构将核心的业务及数据能力下沉和拓展到更多场景，加速数字化转型与升级。","date":"2023-01-10","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-won-the-bid-of-hangzhou-bank-core-system-database","file":null,"relatedBlogs":[{"relatedBlog":{"body":">作者简介：余军，PingCAP 解决方案事业部总经理。\n\n对于金融企业来说，尤其是银行、证券、保险这些行业，在一个 IT 系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的 IT 发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。\n\n在金融行业来说，数据库作为最核心的基础组件之一，要求它能够安全运行和保障数据安全，这是一个刚需。另外，数据库服务本身的高可用，是我们实现整个对外数据服务连续性的最重要的基石。在这些基础上，光有高可用还是不够的，我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术，以及对应事件的方案，应运而生。在过去的二、三十年里面，关于容灾和技术的技术手段、软件工具，包括各种各样的方案、管理方法，在不断的展现。\n\n## 传统数据库支撑关键计算的高可用/容灾方案短板\n\n回到传统的数据库领域，在过去至少三四十年的时间里，我们都是在使用集中式的数据库，比如大家非常熟悉的 Oracle、DB2 包括曾经很辉煌的 Sybase、Informix 等等。这些数据库都是以大家所熟知的“ IOE”的架构来实现数据服务的。\n\n在这些技术体系下，在长期的技术发展过程当中，也有产生对应的高可用和容灾的方案，比如说大家非常熟悉的 Oracle RAC，比如说我们在 DB2 上，经常会用到的 HACMP，还有曾经大名鼎鼎的 Veritas VCS，MC/SG，以及红帽的 RHCS , Pacemaker/Corosync 等实现单机数据库高可用的。\n\n这些技术都是通过数据库，建主从的实例，然后共享数据库的数据文件，放在高端的数据的存储上。这种集中架构的话，它总体是比较稳定的，但是随着 IT 应用场景的不断发展，到今天为止，我们在考虑数据库的时候，除了要考虑它的可靠性之外，还需要考虑它如何应对海量的数据处理，海量的并发请求。**那么我们需要必须寻求扩展，而集中式的结构，它没有办法做横向扩散。此外的话，这种传统的数据库的高可用方式，非常依赖于外部的组件，就是前面说的这些独立的厂商提供的相关的高可用和容灾组件。**\n\n进入到开源数据库的阶段，大家所熟知的 MySQL 和  PostgreSQL，它们也会有对应的高可用的解决方案，比如 MySQL 它最常见的就是通过它的 Binlog 复制建立起来主从队，然后在数据库之外，我们采取类似像 MHA 这样的一个 SwitchManager 的工具，包括 PG 的话，它有 PAF、RepMgr、Ptroni 这样的技术。\n\n**在这样的技术场景中，其实在可用性和容灾方面，还是有很多的问题**，比如说复制的时候的采用的异步复制，增强的半同步复制以及国内好多互联网公司定制的 MySQL，PG 的同步方案，在多节点，跨地域容灾灾备场景中的一致性的问题，始终是一个很大的挑战。特别是在容灾的场景当中，超过 1000 公里以上的站点距离间隔，用上述复制的方式，用独立的 SwitchManager 的故障切换机制，是不是能够保证在千公里以上的容灾的可靠性是很大一个疑问。\n\n**此外，主从复制的模式资源利用率比较低**。到现在为止，我们还有在主从复制基础上，再往前走一步，提高高可用性的一些保障机制，比如说大家都熟知的组同步，像 Codership 之前做的 Galera，像包括 MariaDB Galera Cluster 和 Percona XtraDB Cluster，都把 Galera 组件放在产品当中。包括现在 MySQL 新版本中的复制技术实现了组同步 MGR。但是这些方向又有它的问题，比如说它的性能损耗非常显著，然后在多写场景的冲突的处理复杂性，以及整个集群的扩展规模，受到这样的限制。\n\n## 分布式数据库备份容灾的挑战\n\n所以，从单机数据库进入到分布式数据库的领域，问题的挑战就更加大了。集中来看的话，就是比如说我们最常见的两个传统的分布式的数据库的架构：MySQL、PG 加上主从复制核心组件，再加一个高可用的外部组件实现 Failover/Switchover，然后再加分库分表中间件。那么这样的方案，在传统的分布式架构当中，它的核心的可用性的技术限制和天花板没有变化。它还是如前文所说的：主从复制加上一个数据库外部组件实现 Failover/Switchover 。\n\n**然后，在分布式数据库架构里，我们需要非常认真的去考虑，分布式数据库的伸缩能力和它怎么样去跟高可用及容灾的要求达到平衡。甚至还要想怎么样再去做进一步的优化，这是比较困难和有挑战的。**\n\n另外，在互联网应用场景中， 访问量和数据量非常的大，业务逻辑相对简单。**但是在银行、保险、证券等这样的传统关键金融场景当中，业务的逻辑是非常复杂的。针对于这样的传统高可用及灾备容灾方案，它与应用进行适配，往往要做一些面向应用的反向适配，应用还需要为此进行调整与妥协**。比如说两地三中心的场景当中，应用适配的难度更加大，所以改造过程当中的适配过程和反向适配的风险，也是一个经常让金融行业的 IT 从业人员非常头痛的一件事情。\n\n最严峻的一个事情，当在这样的传统灾备容灾方案为基底的一套系统在运行的过程当中，真的发生了非预期的重大故障和灾难突发的时候，怎么样保证数据的严格安全，以及如何保证在故障发生以后，对于部分组件，对于机房级的灾难，对于中心级的灾难，在灾难发生的时候，要保证对业务的最小影响，也就是我们经常听到的，RPO 和 RTO 这样的要求。那么在这个过程当中，怎么样最大程度减少人工的干预？因为，**在灾难发生的时候，人的干预是必须的，但是人的反应也是比较迟钝的。所以，怎么样通过一个技术手段，在整个方案的能力上，能够去高效执行灾难恢复的处理工作？**\n\n## TiDB 的金融级备份及容灾之道\n\nTiDB 经常这么多年的积累和逐渐完善，在整个分布式数据库的容灾和灾备的领域，我们达到了金融生产级的要求。那么在整个 TiDB 的备份与灾备、容灾的体系里，我们主要是由以下几个方面来组成的。\n\n![1-TiDB-金融级备份及容灾之道](https://img1.www.pingcap.com/prod/1_Ti_DB_6ddab9cf1a.png)\n\n**第一个是我们默认的，也是我们推荐的，多中心的容灾方案，同城的两中心，异地的一中心，或者扩展到三地五中心模式**。这个方案也是 TiDB 最早原生的核心方案。通过多级标签的感知，能够实现服务器级、机架级、机房级、站点级的故障转移。能达到 RPO 等于 0，以及我们的故障影响时间小于 30 秒，也就是 RTO 小于 30 秒的一个刚性指标。\n\n这一套方案，目前我们在国内和国外，已经有了不少用户，尤其是金融行业的用户，在关键场景投产使用了。这其中也是经受过了很多的考验，比如说，同城光纤的抖动，同城到异地之间的通讯线路出现问题，以及机房里面多个节点同时出现了故障，随着在生产环境上持续运行时间的变长，这些问题都暴露出来了。通过 TiDB 的多中心的容灾方案，非常可靠地避免了这些故障对业务的影响，保障了业务连续性及数据安全。\n\n除此之外，在国内的话，从北到南，我们的运营商的线路也是非常的复杂。对于有些用户来说，从投资成本、业务的重要性、客户网络的物理条件来说，没有办法去构成同城多中心加异地的的容灾架构，他可能只能选择两中心的方案，那么在这个过程当中的话，TiDB 经过这几年对这个方面的积累，我们现在已经有了**两中心的容灾方案**，并且，在这个方案里面，我们有多种配置来适应不同的网络条件。即便是在两中心方案当中，我们也能达到 RPO 等于 0 的保护模式。当然也有一些用户的场景，他的网络线路可能延迟非常高，且用户要求有一个托底的容灾方案，同时对于数据的一致性可以有略微的放松和让步，在这个过程当中，**我们也会通过配置来为其提供异步同步的模式，来帮助其实现托底的容灾方案，最大程度保障服务的连续性和数据安全。**\n\n以上是我们交付给用户的多种金融生产级的灾备容灾的方案，它背后的支撑是由核心的 **TiDB 的 Multi Raft 的高可用机制**，以及一系列针对跨中心的调度、数据的调度管理、故障的自动转移判断等这一整套后台的保障技术机制来实现的。\n\n另外，对于数据业务来说，除了在线的热的故障转移、切换等。我们对于数据库的数据本身，也提供了完善的数据备份方案，除了全量的备份、增量、恢复时间点 (PITR ) 之外，**我们在数据的备份模式上面，也提供了包括基于日志的传统逻辑备份。并且，在去年我们也推出了 TiDB BR 工具和备份方案，直接从数据库的 TiDB 存储引擎 TiKV 层上，直接实现备份和恢复，备份与恢复非常高的效率。**\n\n但光有上述方案是不不够的，PingCAP 对于自身产品的要求是非常严格的，既然是要达到金融生产级的要求，除了要有对应的技术方案、对应的技术实现之外，必须为产品本身提供专业的分布式测试的体系和手段。每一个 TiDB 的版本，在我们的内部，都会通过极其严格及复杂的分布式数据库测试。为此，我们也专门根据混沌工程，设计开发了自己的一套测试平台，并且在最近把它开源了，这套工具叫做 [Chaos Mesh](https://pingcap.com/blog-cn/chaos-mesh/)，可以帮助用户更好的检测分布式系统的可用性和鲁棒性。\n\n在 TiDB 内部测试的整条链路上，我们有非常完善的对于可靠性和一致性和安全方面的测试保障。包括自动化故障注入，包括我们引入的 Jepsen 的一致性验证，包括我们对于一些最核心的算法，引入了 TLA+ 的验证。还有我们每天在数据中心，在我们测试环境，不停跑的自动化模拟的业务负载以及各种各样的集成测试。我们相信只要是人写出来的软件，一定是会有问题的，一定会有 Bug，不可能做到完全没有问题。**所以，在这个过程当中，需要的保障手段，除了高可用和软件架构本身设计的机制之外，先进的、完善的、强大的产品测试体系和可靠性 验证能力，也是最重要的保障手段之一。**\n\n## TiDB 灾备与容灾的核心机制\n\nTiDB 容灾的核心机制是我们的 Raft ，相信各位关注 TiDB 的朋友也通过我们的公众号、官网，包括社区里面，听到过小伙伴们提供的分享。Raft 是基于日志与状态机的一种一致性的算法。我们基于它，在 TiDB 里实现了 Multi Raft 的机制。它能够非常可靠的管理我们的数据与数据的副本，在 TiDB 里面，整个数据对我们的业务来说是自动的透明打散的，然后它会以一个一个 Region 的数据组织方式，在不同的存储节点上面进行自动存储和建立 Raft 副本。\n\n通过 Multi Raft 这样的一个机制，我们可以在不同的主机，不同的机房，不同的园区，一套数据库不同的节点上，产生它的第二、第三副本，甚至更多的副本。这个副本是动态可调的，并且我们可以保证，TiDB 上执行的所有的联机交易事务，在数据变更发生时都可以达到多数的一致，**也就是说在一个实施规划和部署正确的 TiDB 集群里面，在一个多中心的灾备容灾 TiDB 集群中，任何的主机，所在的机架、机房，乃至数据中心的失效，包括数据中心间的网络故障，通过 Multi Raft 机制以及 TiDB 的高可用调度机制，都可以完善的去保障，对我们的业务影响最小，同时，非常严格的保证了数据的绝对安全。**\n\n在 Raft 这个机制上，TiDB 的研发团队也做了大量的优化工作。比如说跨数据中心，包括跨区域的运维方式。另外，我们在 Raft 机制上面，也提供了很多的比如说新的一些增强化，像 Lazy Peer、像 Learner、像 Joint consensus 等机制的研发。\n\n## TiDB 高性能分布式备份机制\n\n刚刚我还提到一个叫 [TiDB BR](https://pingcap.com/blog-cn/cluster-data-security-backup/) 的工具，它是一个在存储层实现高性能分布式数据备份恢复的工具。所以，大家由下图可以看到，我们的测试中的备份速度、恢复速度，都是非常惊人的。而且随着节点数量的增加，在数据量一定的前提下，备份/恢复的性能都会有接近线性的增长：\n\n![2-TiDB高性能分布式备份机制](https://img1.www.pingcap.com/prod/2_Ti_DB_875ad97021.png)\n\n\n## 最强的多中心：TiDB 多中心多活容灾方案\n\n在多中心里面，前面提到，我们通过 Multi Raft 的机制，以及相关的工程优化，实现了跨中心的容灾方案。比如说，对于长距离的异地中心，我们在同城设了两个中心，通过光纤连接，异地的话，通常租用比如运营商的 MSTP 类型的线路，构成一个三中心的结构，通过 TiDB 内置的容灾和灾备的相关的一系列的机制与手段，可以构建出非常强健的容灾的架构。**任何中心级失效，都会由另外两个中心来立刻进行故障的转移，以及对外继续提供正常的数据库服务。**\n\n\n![3-TiDB多中心多活容灾方案](https://img1.www.pingcap.com/prod/3_Ti_DB_36dac4fe16.png)\n\n\n## 安全的两中心：TiDB 两中心容灾方案\n\n前面也提到，有些用户的网络，比如说一个中心在上海，一个在北京，延迟是非常大。因为高等级、低延迟线路的租用使用成本非常高。综合考虑成本及所需要保护的业务的关键性等级，不少用户会做一个权衡。部分用户最终希望核心数据库，只需要完成一个主从站点的容灾和灾备就可以了。\n\n通过 TiDB Binlog 模式能够去适配和满足对多中心网络通信成本敏感且对服务/数据防护能力略低的容灾需求的用户，我们会用两中心的 **TiDB Binlog based 方案**，它是异步同步模式，能够适配两个中心长距离间隔其网络延迟较大，比如延迟大于 30~40 毫秒的。采纳这样方案的用户对于 RPO 的要求就比较宽松了，该模式是一个异步同步，当灾难发生的时候，我们已经在 TiDB 的工程优化上尽可能通过多种机制来减少数据丢失的可能，但是从根本上来说，还是会存在一定数据丢失的情况。**该方案提供给用户低成本的保障能力，同时还提供了比较灵活的可选拓扑，比如双向的环形复制等。**\n\n也有用户希望在两中心的方案里，需要有一个强一致保障的方案。所以我们研发了两中心的 **Raft based 容灾方案**，它可以在同城或者接近同城距离的两中心环境中，且中心间网络条件比较好的情况下，实现严格的强一致同步。**这个方案可以达到 RPO 等于 0 的保障要求，也就是数据不丢失前提下的一个高等级的容灾要求。**\n\n\n![4-TiDB两中心容灾方案](https://img1.www.pingcap.com/prod/4_Ti_DB_fdf9238a38.png)\n\n## 结语\n\n最后，我们一直持续在花非常多的精力和投入，研究如何让 TiDB 变得更强，更安全，更可靠。能够达到更好的金融级的数据服务的支撑能力水平，依托于我们整个工程研发团队、 QA 测试团队，以及我们所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。\n\n\n>本文整理自余军在 [TiDB DevCon 2020](https://pingcap.com/community-cn/devcon2020/) 上的演讲，大会相关视频回顾可以关注官方 Bilibli 账号 [TiDB_Robot](https://space.bilibili.com/86485707) 。","author":"余军","category":1,"customUrl":"tidb-financial-grade-backup-and-multi-center-disaster-recovery","fillInMethod":"writeDirectly","id":5,"summary":"依托于整个工程研发团队、QA 测试团队，以及所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。","tags":["TiDB DevCon 2020","备份恢复","容灾机制"],"title":"TiDB 金融级备份及多中心容灾"}},{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel）  \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n  \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。  \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。  \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。  \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。  \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n![001.png](https://img1.www.pingcap.com/prod/001_ce42a10ada.png)\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n![002.png](https://img1.www.pingcap.com/prod/002_1f9a938e7e.png)\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括：  \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n![003.jpg](https://img1.www.pingcap.com/prod/003_a89e399f30.jpg)\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n![004.png](https://img1.www.pingcap.com/prod/004_be9d5cac08.png)\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。  \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}}]},{"id":"Blogs_451","title":"TiDB 6.5 LTS 版本发布","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。","body":"在 2023 伊始，我们很高兴向大家宣布，TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版（上一个是 [TiDB 6.1](/blog/tidb-6.1-release)），除了携带了诸多备受期待的新特性，同时也将得到 TiDB 开发社区的长期维护，是推荐企业级用户采用的最新版本。\n\n![TiDB 6.5 LTS.png](https://img1.www.pingcap.com/prod/Ti_DB_6_5_LTS_83af544cd2.png)\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.5-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n在这个版本中，TiDB 专注于如下几个主题：\n\n- **产品易用性进一步提升**\n- **内核不断打磨，更加成熟**\n- **多样化的灾备能力**\n- **应用开发者生态构建**\n\n相信长期关注我们的朋友已经发现，这些主题似曾相识。的确如此，TiDB 近年的发展几乎都围绕着它们开展。我们期望 TiDB 成为**更易用，对开发者更友好，且更成熟的企业级数据库**，而这个追求也并没有尽头。\n\n## 产品易用性进一步提升\n\n大家也许不止一次听说过，易用性之于 TiDB 是非常关键的理念。毕竟，TiDB 伊始是为了解决分库分表带来的麻烦，这也使得易用性在 TiDB 研发过程中贯穿始终。在新版本中，我们提供了更多的让用户解放心智的能力。\n\n### AND 运算下的索引归并读取\n\n对于数据服务和洞察场景，用户往往会基于诸多查询条件的组合进行数据筛选。例如在物流场景中，用户可能会根据下单日，仓库 ID，转运人，送达日，目标地址等等不同维度进行筛选再分析。而这些条件单独来看，并不一定具备很好的选择性，只有组合起来才能将数据限定在一个小范围。如果条件的组合不多，我们尚可使用特定的组合索引覆盖，但很可能在这类场景中，组合以数十记，完全无法为每个组合都创建特定索引。在新版本中，TiDB 支持根据 AND 条件组合同时选中多组索引，并计算它们的交集再读取实际表数据。这种能力，使得用户可以仅仅为单列创建少量索引，以达到更好的选择性以及更优的性能。\n\n![Screen Shot 2023-01-03 at 00.50.14.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_00_50_14_365a0cbe7e.png)\n\n### 集群闪回\n\n有时候，用户会希望整个集群快速恢复到之前的某个时间点。例如，由于游戏服务器新版本数据设定问题，将一把绝世好剑设定为 1 元，造成新版发布后一小时内人手一把。若仅仅如此也就算了，开发者可以很容易回收或这个道具，但这种事故还有次生灾害，例如稀有 Boss 被滥杀，稀有掉落随之泛滥，整个游戏内容崩坏。这时候作为游戏设计师，你可能会希望时间能回到犯错之前的那一刻，让你修正那个令人追悔莫及的错误。在新版本中，TiDB 就提供了这个能力，它支持用简单一条命令向 GC 时间内的任意时间点进行全集群闪回，就像下面这样。\n\n```sql\nFLASHBACK CLUSTER TO TIMESTAMP '2022-09-28 17:24:16'; \n```\n\n我们当然希望这不会是一个常见的状况，但这并不表示需要闪回的时机千年难遇：闪回能力也可用于日常操作，例如将测试环境恢复到测试开始前的状态，以供反复使用。\n\n### 完整的大事务自动拆分支持\n\n在前序版本中，我们支持了针对删除的大事务自动拆分支持。而在新版本中，TiDB 完整支持了针对插入和修改的大事务拆分。在以往版本中，TiDB 用户经常要面对的一个问题就是，一些大规模的数据变更维护操作，例如过期数据删除，大范围数据修订，或者根据查询结果回写数据等操作，会遇到超过 TiDB 单条事务上限的问题，这是由于 TiDB 单一事务需要由单一 TiDB Server 作为提交方而带来的限制，这时候用户往往不得不手动想办法拆小事务以绕过该限制。但在实际使用中，上述类型的数据变更未必真的需要作为单一事务确保原子性，例如数据淘汰和数据修订，只要最终执行完成，哪怕事务被拆开多次执行也并不会影响使用。在 TiDB 6.5 中，我们提供了将大事务自动拆分的能力，例如按照 t1.id 以 10000 条为大小分批数据更新，可以简单使用如下语句完成：\n\n```sql\nBATCH ON t1.id LIMIT 10000 update t1 join t2 on t1.a=t2.a set t1.a=t1.a*1000;\n```\n\n更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml)。\n\n### TiFlash 结果物化（实验特性）\n\nTiFlash 在过往版本中有一个很大的缺憾是无法在读写事务中使用：经常用户希望将 TiFlash 的计算结果进行回写以供高并发读取（类似物化效果）。从 v6.5.0 起，TiFlash 支持通过 INSERT SELECT 语句回写结果进行物化，节省系统资源并提高响应速度。\n\n```sql\nINSERT INTO top_payments SELECT MAX(amount) FROM payments;\n```\n\n在执行上述 INSERT INTO SELECT 语句时，TiDB 可以将 SELECT 子查询下推到 TiFlash 以提供高速分析计算，并将返回结果通过 INSERT INTO 可以保存到指定的 TiDB 表中。值得一提的是，该功能结合前述大事务拆分可以实现大量结果集物化。\n\n### 高性能全局单调递增 AUTO_INCREMENT 列\n\nTiDB 作为一款分布式数据库，以往在使用 AUTO INCREMENT 列创建主键时，仅保证在每个 TiDB 实例中序列递增，而跨 TiDB 实例则无法保证。但实际使用中，用户仍然经常会遇到需要严格单调递增主键的时候，例如以主键隐式代表时间维度，确定事件发生顺序。在 6.4 版本中，我们加入了高性能的全局单调递增主键的支持，以兼容 MySQL 的行为。该模式下，TiDB 将采取中心化的主键分配以确保单调递增，即使跨 TiDB 实例访问，ID 也不会出现回退，且针对其的写入也可轻松达到数万的 TPS。\n\n### 使用 TTL (Time to Live) 来周期性地删除过期数据（实验特性）\n\n维护数据的生命周期在 TB 以上规模下并不是很容易的事情：由于数据规模大，寻找并清理过期的数据往往需要消耗相当的算力，有时用户为了更快清理数据甚至被迫使用分区表，以删除分区的方式来进行快速清理。更麻烦的是，用户需要维护特定的任务以不断定期淘汰数据。在新版本中，TiDB 提供了 Time to Live (TTL) 能力，使得用户可以设定行级别的生命周期控制策略。通过为表设置 TTL 属性，TiDB 可以周期性地自动检查并清理表中的过期数据。当开启时，TTL 会以表为单位，并发地分发不同的任务到不同的 TiDB 实例节点上，进行并行删除处理，且不影响集群性能。更详细的说明请[参考文档](https://docs.pingcap.com/zh/tidb/stable/time-to-live)。\n\n## 内核关键特性打磨和增强\n\nTiDB 包含繁多的特性集合，但其中有些仍需不断打磨，例如 JSON 虽然已获支持许久，但实际能力却尚需完善。在新版本中，我们针对重要特性集合用力打磨，以期提供给用户更「丝滑」的体验，让 TiDB 的重大特性以更完善的方式呈现在用户面前，也让 TiDB 演进方式更稳重更有质量。\n\n**首先是 DDL 加强**。支持在线 DDL 是 TiDB 的核心优势之一，在过往一年中，我们加入了对并行 DDL 的支持，使得以往在 SaaS 等多租户场景因 DDL 串行执行互相阻塞导致的 DDL 语句间执行效率低的问题得以解决，通过引入 Metadata Lock 基本消除了 DDL 干扰 DML 的情况。在新的 6.5 版本中，TiDB 支持了类似 Lightning 注入 SST 的设计，针对需要追溯的历史数据直接使用 SST 构建的方式进行生成，大幅提高了 DDL 的构建速度，最快可达 **10 倍提升**。\n\n如下图所示，以 TiDB 6.1 版本为基准值，新版除了取得了数量级的提速，且对比 CockroachDB v22.2 和当前版的 AWS Aurora 也快 2-3 倍。\n\n![Screen Shot 2023-01-03 at 10.15.34.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_10_15_34_49df47db5a.png)\n\n**其次是 JSON 的支持打磨**。JSON 对于需要灵活数据结构的场景非常重要，因此在移动端，游戏开发等场景中广泛使用。从 6.2 版本以来，TiDB 陆续引入了完整的 MySQL 5.7 兼容函数，针对 JSON 的表达式索引支持，更多的生态工具兼容。新版本支持将 JSON 函数 \"->\"、\"->>\"、\"JSON_EXTRACT()\" 下推至 TiFlash，可以提高 JSON 类型数据的分析效率，拓展 TiDB 实时分析的应用场景。\n\n**再者是 TiDB 全局内存控制**。自 v6.5.0 起，TiDB 全局内存控制已能够跟踪到 TiDB 中主要的内存消耗。当单个会话的内存消耗达到系统变量 `tidb_mem_quota_query` 所定义的阈值时，将会触发系统变量 `tidb_mem_oom_action` 所定义的行为 (默认为 `CANCEL`，即取消操作)。当全局内存消耗达到 `tidb_server_memory_limit` 所定义的预设值时，TiDB 会尝试 GC 或取消 SQL 操作等方法限制内存使用，保证 TiDB 的稳定性，对内存的使用效率也更加高效。 \n\n**最后是降低累积的悲观锁对性能的影响**。 在一部分交易系统，尤其是银行业务中，客户应用会在悲观事务中利用 select for update 先锁定一条记录，从而达到对数据一致性的保护，减少事务中后续操作失败的可能，比如\n\n```sql\nBEGIN;\nSELECT c FROM sbtest1 WHERE id = 100 FOR UPDATE; \nUPDATE sbtest1 SET k = k + 1 WHERE k = ?; \nCOMMIT;\n```\n\n而在 TiDB 中，对一行记录反复的 select for update，会造成这条记录的查询性能下降。 在 v6.5.0 中，我们对这部分机制进行了优化， 通过记录连续的锁标记，降低了累积的悲观锁对查询性能的影响，QPS 可大幅提升 10 倍以上。\n\n## 多样化的灾备能力\n\n在过往版本中，TiDB 主要依赖 BR 进行静态的备份恢复，而在 6.2 之后的新版中，TiDB 提供了 PITR 能力，使得数据库可以更灵活地恢复到任意时间点。\n\nTiDB PITR（Point-in-Time Recovery）是结合了 BR 和变更捕获（Change Data Capture）两种能力的灾备特性。以往 BR 的静态灾备只能将数据恢复到备份的时间点，如果要更提供针对更新和更多时间点的恢复，则相应需要提高备份频率。这不但会加重备份对在线业务的负担，也需要更多存储成本。使用 PITR 则可以摆脱这个烦恼，用户无需不断进行全量备份，而是可经由一个全量备份结合增量共同完成针对任意时间点的数据恢复。\n\n![Screen Shot 2023-01-03 at 01.48.32.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_01_48_32_f41d588441.png)\n\n经过半年左右的持续改进，在新版本中，我们减少了 PITR 备份文件大小和数量，加强了稳定性，提升了性能。 例如：确保在绝大多数异常场景下 RPO < 5mins, 单个 TiKV 的备份速度达到100MB/s等。\n\n与此同时，在 6.5 版本中，TiCDC 的吞吐获得了得了至数倍的提升。通过对 TiCDC 内部的设计和实现的不断优化，针对数据复制场景，当下游为 Kafka 集群时，针对大单表场景的吞吐量得到了极大的提升，单个 TiCDC 节点可以支持35k row/s QPS，吞吐量可以达到 50MB/s，并将延迟控制在 2 秒左右，而内存使用量只有之前版本的50%左右。 针对跨区域主备集群容灾场景，TiCDC 单个节点的吞吐量可以达到 30MB/s，并且其延迟也可以稳定在 2 秒左右，稳定性大幅度提高。\n\n其次，在6.5 版本中，DM 正式发布了在数据迁移过程中的增量数据持续校验功能，该特性只对新增或变更的数据进行校验，而不是对整个数据集进行校验，在确保数据迁移过程的准确性和可靠性的同时，大大减少数据校验的时间和资源消耗。尤其是在迁移一些重要系统时，该特性可以让数据迁移过程更加安全。\n\n除此以外，新版本支持了在下游集群使用水位线进行一致性读取的能力：在新版本中，TiCDC 可以在向下游写入时提供特殊的时间戳，而下游集群则可以自动使用该时间戳进行一致性读取而无需担心读到的事务不完整。这使得下游集群在需要严苛事务保证的场景下，也可以良好承担读流量分流的职责。\n\n![Screen Shot 2023-01-03 at 02.04.38.png](https://img1.www.pingcap.com/prod/Screen_Shot_2023_01_03_at_02_04_38_3012a4bd0d.png)\n\n## 应用开发者生态构建\n\n在以往版本中，TiDB 更强调 DBA 的使用体验。但在近期的更新中，你也许已经发现我们逐渐开始聚焦 DBA 以外的应用开发者体验。在新版中，我们强化了应用开发所需的生态环境构建，例如这半年来 TiDB 通过增加对 Savepoint，User Level Lock，Multiple Schema Change 等功能的支持，完善了针对常见应用框架 django，prisma 等的支持。与此同时，我们也引入了更多上下游生态厂商的战略合作：Vercel，Hashicorp，Retool 等。在 6.5 版本中，TiCDC 增加了针对向 Object Storage 写入的支持。对象存储是一种面向云的存储服务，具有高可扩展性、高可用性、低成本等优势。使用 TiCDC 将数据同步到对象存储，可以帮助用户实现数据的长期存储、数据的跨区域复制等目的。另外，这使得 TiDB 在云环境下能直接打通向数仓和数据湖环境的通路。更好的生态支持，将使得开发者在使用 TiDB 构建应用时，拥有更多选择，也更简便。\n\n## 总结\n\n作为 TiDB 版本 6 的第二个长期支持版，TiDB 6.5 已经发布。我们希望借助这个版本为更多用户提供更易用且更成熟的企业级数据库。更详细的变更情况请参阅 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.5.0)。欢迎各位和我们一起开启新的[奇妙旅程](https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb)。","date":"2023-01-04","author":"马晓宇","fillInMethod":"writeDirectly","customUrl":"tidb-6.5-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"![TiDB 6.1.png](https://img1.www.pingcap.com/prod/Ti_DB_6_1_6eecaae325.png)\n\n我们很高兴向大家宣布，TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com/zh/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.1-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n## 长期支持版\n\n在两个月前发布 TiDB 6.0 版本时，我们提过在新发版流程中，我们引入了面向企业级用户的 LTS 版本的概念，与之相对的是开发里程碑版本（Development Milestone Release，简称 DMR）。引入这两种概念是为了让 TiDB 的发版节奏能兼顾快速变化的市场需求以及企业级用户对稳定性的要求。\n\n我们重新思考了发版模型，最后选择了长期支持版结合开发里程碑版的方式：我们保持 2 个月左右一次发版的节奏，以期快速应对市场节奏，但不再对所有发布进行长期维护，而是以半年左右为节奏拣选其中一个版本作为 LTS 长期支持版本。针对 LTS 版本我们提供针对问题的修复补丁而不再合并新功能。与此相对的，DMR 版本则保持快速发版的节奏，不断发布新特性，让用户所需的新需求不必等待很久（但并不提供基于 DMR 的问题修复）。对于用户而言，在没有特定需求开发的情况下，可以选择最新的 LTS 版本投产；如果需求某个 DMR 发布的新功能，则可以选择该版本进行 PoC 以及试运行，待到对应的 LTS 版本发布后升级 TiDB 到稳定生产状态。这样快慢结合的方式，可以最大限度兼顾快速迭代和稳定投产两方面的需求。\n\n对应 LTS 稳定版的主旨，6.1 版本中携带了重要的稳定性更新：\n\n1. 提升 TiKV 高压场景下的内存稳定性。\n2. 解决了由于 Raft Log 复制流量过大导致的 OOM 问题。\n3. 解决了在高压场景下宕机后重启过程中长时间持续反复 OOM 的问题。\n4. 完善了 TiDB Server 内存使用跟踪统计，加强查询内存使用配额限制。\n5. 优化了部分统计信息内存使用。\n\n另外，新版本也包含了 42 个问题修复和 20 个改进提升。\n\n## 是 LTS，也有新惊喜\n\nTiDB 6.1 除了作为第一个推荐企业级用户投产的 6 系版本，本身也携带了诸多强大的特性。\n\n### HTAP 基础能力提升\n\n在新版本中，部分分区表的实验特性 GA，且分析引擎加入了分区表和窗口函数支持。\n\n让我们先来看看分区表：我们在版本 5 中引入了 List 分区和动态裁剪特性，但一直保持实验特性状态。更重要的是，由于旧有的分区静态裁剪在 MPP 下表现欠佳，因此 TiFlash 引擎一直以来并未完整支持分区表特性。这次新发布中，我们宣布 List 分区 / 分区动态裁剪以及 MPP 模式下的分区表支持 GA。对于分区表本身在此无需过多赘述，各位可以参考官方文档，我们单独说下分析引擎下的分区表支持。\n\n对于列存引擎而言，由于并不支持类似行存的细粒度索引，仅仅依靠粗粒度索引并不能满足数据过滤需求。而分区表作为列存下最高效的数据过滤手段，是分析场景下需求优先级非常高的特性。例如在订单管理场景下，用户的数据天然可以将订单创建日期作为分区依据按天将一个月的数据分成 30 个分区，而用户的分析查询往往更高频查询最近一周甚至三五天的订单数据。在以往分析引擎不支持分区的情况下，TiDB MPP 只能进行全表扫描，这不但浪费了无谓的存储带宽，也会消耗 CPU 针对日期字段进行过滤。而在 6.1 版本中，对于上述例子，只要查询条件带有订单创建日，则可以数倍甚至数十倍提高查询效率。\n\n在 6.1 中另一个分析场景下常用的新功能是 MPP 下的窗口函数支持。在新版本中，MPP 执行器加入了对窗口函数的框架性支持，并随之推出了三个最常用窗口函数 rank，dense_rank 以及 row_number。这使得在 MPP 执行模式下，窗口函数除了内存消耗可以被分布式分担，性能也得到大幅提升。以 100G 规模数据集测试为例 ，新版本中查询使用单节点 MPP 模式进行窗口函数计算将提速 282%，使用更多节点将有更大幅度提速。与以往 MPP 模式下对内建函数的支持一样，我们将逐步增加对各类窗口函数的支持。\n\n新版本中，TiDB 引入了非事务性 DML 语句以应对大批量数据变更。新加入的非事务性 DML 将一个普通 DML 拆成多个 SQL 执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。典型的，在新版本中可以使用如下语句淘汰过期数据，而无需担心事务大小限制问题：\n\n`BATCH ON id LIMIT 2 DELETE FROM orders where create_date < '2022-05-01';`\n\n上述 SQL 将会以 2 批次的方式执行 DELETE 操作，以控制单次操作的内存占用。过往版本中，TiDB 仅支持非事务性删除。\n\n### 更完整的生态对接\n\n数据库从来都不是单独被使用的，而 TiDB 也在持续改进和生态环境的对接。在新版本中，TiDB 引入了用户级别锁和 TiCDC 下的 Avro 格式向 Kafka 同步数据的支持。\n\n先说用户级别锁。用户级别锁是 MySQL 通过内置函数提供的用户命名锁管理系统。它们可以用在 SQL 语句的 SQL 函数中，比如 select，where 子句，group by 子句等位置使用。这些语句可以在不同的代码处阻塞，等待，实现用户级别锁管理。用户级别锁在 ORM 框架中也有较为广泛的应用，例如 RoR, Elixir 和 Ecto 等。TiDB 从 6.1 版本开始支持兼容 MySQL 的用户级别锁管理，支持 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等锁管理函数，这使得 TiDB 得以更好支持现有 ORM 框架的生态。\n\n对 TiDB 而言，TiCDC 是集群数据实时变更信息的出口，而支持常用的数据格式以方便消费者解析则是降低开发复杂度的必修课。Avro 作为一种数据序列化系统，采用了压缩二进制格式，传输效率高，数据格式丰富，已经被大量的数据分析、数据集成产品所支持。TiCDC 支持将 TiDB 数据库的增量数据转换为 Avro 格式，并发送到 Kafka 的方式，这将使得 TiDB 数据库和众多的生态系统，例如：Kafka、Snowflake、SQL Server 链接起来。在新版本中，向其他系统实时同步 TiDB 的数据变化，无论是用于实时数据集成还是变更订阅触发操作，都可以借助 Avro 格式变得更简单。更进一步，一些仰赖 Avro 格式的其他生态功能，现在也得以发挥热量，例如用户可以借助 Avro 格式通过 Kafka kSQL 对变更日志进行实时计算。\n\n## 行动起来\n\n除了上述所有新功能外，其实 TiDB 6.1 作为 6 系版本的第一个推荐企业级用户投产的 LTS 版本，是所有需求 6.0 版本特性的用户的理想选择。无论你已经在使用 6.0 版本，还是正在调研中，都推荐大家部署 6.1 版本或升级。相信新版本将为广大用户提供强大的功能和稳定的体验。\n\n查看 TiDB 6.1.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.1.0)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.1.0 企业级云数据库之旅。\n\n\n\n\n","author":"PingCAP","category":2,"customUrl":"tidb-6.1-release","fillInMethod":"writeDirectly","id":395,"summary":"TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。","tags":["TiDB","Release"],"title":"TiDB 6.1 发版：LTS 版本来了"}}]},{"id":"Blogs_448","title":"TiDB 首批通过信通院 HTAP 数据库基础能力评测","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"2022 年 12 月 15 - 16 日，在中国信通院组织的第十五批数据库产品能力评测中，平凯星辰（北京）科技有限公司的分布式数据库 TiDB 成为国内首个完成并顺利通过 HTAP 数据库基础能力测评的产品。","body":"随着数字经济的快速发展，数据已成为重要生产要素，挖掘数据价值成为了用户的普遍需求。**HTAP（混合事务和分析处理）是近年来提出的一种新型的数据库架构**，旨在打破事务处理和分析之间界限， **在一份数据上保证事务处理的同时支持实时分析**，并且可以灵活配置两种负载的资源占比，使得在线交易和分析互不影响，并可以分别实现线性扩展，一站式地解决企业级应用的各种需求，从而大幅度降低成本，同时提高了企业决策的效率。当前，HTAP 已成为数据库发展的前沿领域。\n\n2022 年 12 月 15 - 16 日，**在中国信通院组织的第十五批数据库产品能力评测中，平凯星辰（北京）科技有限公司（以下简称平凯星辰）的分布式数据库 TiDB 成为国内首个完成并顺利通过 HTAP 数据库基础能力测评的产品**。该测评依据《大数据 混合事务和分析型数据库技术要求》进行，该标准共涉及 6 个能力域 41 个能力项，包括 35 个必选项和 6 个可选项，全方位覆盖 HTAP 数据库的基本功能、可靠性、运维管理能力、扩展性、安全性和易用性。\n\n本次参与测评的分布式数据库 TiDB 是平凯星辰研发的一款同时支持在线事务处理与在线分析处理的融合型分布式数据库产品，**具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性**。目标是为用户提供一站式 OLTP、OLAP、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。TiDB 数据库已成为全球最活跃的开源数据库项目之一，在“墨天轮中国数据库流行度排行榜”上长期排名第一。截至目前，TiDB 在全球拥有超过 3000 家企业用户，涉及金融、运营商、制造、零售、互联网、政府等多个行业。\n\n![640.png](https://img1.www.pingcap.com/prod/640_9630b7cd2a.png)\n\n<center>TiDB 数据库 HTAP 架构图</center>","date":"2022-12-20","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-passed-the-capability-evaluation-of-htap-database-by-ict","file":null,"relatedBlogs":[{"relatedBlog":{"body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n![1.png](https://img1.www.pingcap.com/prod/1_93f0db213c.png)\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n![2.png](https://img1.www.pingcap.com/prod/2_81894f8cfc.png)\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n![3.png](https://img1.www.pingcap.com/prod/3_7b2415a552.png)\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n![4.png](https://img1.www.pingcap.com/prod/4_4c3a3da5dc.png)\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n![5.png](https://img1.www.pingcap.com/prod/5_f5295269ca.png)\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n![6.png](https://img1.www.pingcap.com/prod/6_0bed9de7a1.png)\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n![7.png](https://img1.www.pingcap.com/prod/7_c761db6eb7.png)\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n![8.jpg](https://img1.www.pingcap.com/prod/8_923cb0c9a2.jpg)\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n![9.png](https://img1.www.pingcap.com/prod/9_f8a1a72329.png)\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n![10.png](https://img1.www.pingcap.com/prod/10_8a00437db7.png)\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到  Serverless HTAP ，这到底是什么东西？意味着什么？\n\n![11.png](https://img1.www.pingcap.com/prod/11_cc3ffe56c2.png)\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n![12.jpg](https://img1.www.pingcap.com/prod/12_28a125c2bd.jpg)\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n![13.png](https://img1.www.pingcap.com/prod/13_d375c3dd69.png)\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n![14.png](https://img1.www.pingcap.com/prod/14_9c843d72cd.png)\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n![15.png](https://img1.www.pingcap.com/prod/15_c8ed753a77.png)\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n![16.png](https://img1.www.pingcap.com/prod/16_a008ec4dc8.png)\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n![17.png](https://img1.www.pingcap.com/prod/17_63cfa346cc.png)\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n![18.png](https://img1.www.pingcap.com/prod/18_dbfc30531d.png)\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","author":"黄东旭","category":2,"customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","fillInMethod":"writeDirectly","id":440,"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","tags":["HTAP","Serverless"],"title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022"}},{"relatedBlog":{"body":"> CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。\n\nIDC 发布的《IDC 中国企业级应用管理 SaaS 市场，2021H2 》报告显示：2021 年中国企业级应用管理  SaaS 市场规模达 67.8 亿美金，其中 CRM 市场份额为 32%，未来五年将以 23.1% 的 CAGR 快速增长。  \n\n虽然受到疫情影响，但随着企业数字化转型的不断深化，更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看，平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用，提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。\n\n## CRM 的数据架构面临重重挑战\n\n某中国企业级 CRM 头部服务商，其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景，帮助企业转型为真正“以客户为中心”的数字化运营组织，实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长，该服务商实现了从中小企业到大中型企业的覆盖，为了应对不同行业用户的个性化需求推出了 PaaS 平台，基于平台的定制能力服务垂直行业的特定需求；同时，该服务商发力 C 端市场，陆续推出 SCRM 等产品连接海量 C 端用户，打造客户旅程的一体化闭环。  \n\n同时服务几万家不同规模的企业，打通每家企业各个业务系统的数据，为 360 度客户旅程提供数字化支撑，这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库，考虑到大表性能、租户数据量，采用了元数据、租户分库、租户分表的整体方案，共享库按照租户和实体做水平扩展的分库分表设计。  \n\n![多租户共享数据库的分库分表设计.png](https://img1.www.pingcap.com/prod/_f7c203daeb.png)\n<center>多租户共享数据库的分库分表设计</center>\n\n与此同时，为了满足多租户定制化需求，实体主数据表需要预留大量的扩展列，呈现出数据库表多，列多，索引多等特点，也给 CRM 的数据架构带来了重重挑战：\n\n### 大数据量下的分库分表无以为继\n\n随着业务高速增长，CRM 用户数接近 20 万，租户的增长一方面带来海量数据高并发访问的挑战，另一方面使得单租户单实体库数据量快速增长，单表已经超过千万级别。单体 MySQL 数据库无法水平弹性扩展，配置也已经到极限，出现性能下降的问题。此外，MySQL 的分库分表方案，业务拆分难度大，需要进行代码侧的改动进行适配，维护工作也变得非常繁琐。\n\n### 2B 和 2C 客户的体验大打折扣\n\nCRM 业务具有灵活、多变的的特征，经常遇上索引缺失/索引选取错误或者复杂模糊查询等情况，MySQL 性能完全不可接受，慢查询增多导致客户体验差。在批量操作场景，单个任务可能将系统卡死，大量慢查询堆积，严重的时候甚至会造成 OOM，查询被拉黑名单。\n\n### 业务创新的灵活度受到制约\n\n中国的企业级客户由于行业特点和业务环境的变化，通常对 CRM 有定制化和多样化需求，导致数据库需要预留很多的扩展列，经常需要在数据表中增加字段或者增加索引。MySQL 行宽只有 64K，也不支持 Online DDL，使得业务创新的灵活度受到极大制约。\n\n## CRM 真实场景下 MySQL 和 TiDB 的比拼\n\n通过与 CRM 服务商技术部门的探讨，由于 SaaS 业务的稳定性、性能都对最终客户至关重要，组织了一次全面的 PoC 验证工作，覆盖了产品的性能，兼顾数据迁移、稳定性、安全性、运维监控等能力。  \n\n从业务场景的实测结果可以看到：TiDB 并发处理和查询性能提升明显，千万级以上性能提升 70% 左右，单条、跑批都得到了大幅的性能提升（80% 在毫秒级），原先过长时间查询无返回结果的任务，在 TiDB 中得到好转；各类痛点查询，如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等；TiDB 在添加字段，修改字段，增加索引等 DDL 上优势明显。此外，TiDB 提供高效的同步工具 DM，从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。\n\n## 两套数据架构的对比\n\n某 CRM 服务商原有的数据架构中，OLTP 业务通过 Mycat 连接多套 MySQL 数据库处理和存储应用的数据，所有 MySQL 通过 DataPipline 同步到 Greenplum 数仓，由 Greenplum 提供 OLAP 查询服务。引入 TiDB 分布式数据库替换原有架构之后，所有的 OLTP 业务和 OLAP 查询访问一套 TiDB 集群即可，根据业务的实际需求，灵活增加 TiKV 和 TiFlash 节点即可。  \n\n![某 CRM 服务商数据平台架构.png](https://img1.www.pingcap.com/prod/CRM_e1779da679.png)\n<center>某 CRM 服务商数据平台架构</center>\n\n基于 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度体现出优势：\n![TiDB 优势体现.png](https://img1.www.pingcap.com/prod/Ti_DB_9095466037.png)\n\n## “两升一降”助力 SaaS 服务商构建核心竞争力\n\n### 提升海量数据的处理能力和时效性\n\nTiDB 分布式数据库按需弹性扩展能力使得 CRM 服务商可以轻松应对租户、2B 与 2C 业务海量数据的增长。对于 CRM 类 SaaS 服务商来说，TiDB 分布式架构对库、表无数量限制，一键实现节点扩缩容，使得使得数据架构可以动态、平滑地适配业务的增长。TiDB 原生分布式特点在高并发查询、缺失索引、模糊查询等方面性能表现优异，无需担心租户增加带来高并发问题以及租户单实体数据量大等问题；TiDB HTAP 能力使得海量数据场景下的各类查询秒级得到反馈，极大提升了 CRM 的用户使用体验。\n\n### 提升 SaaS 服务商的业务灵活性\n\n在 SaaS 的基础上集成 PaaS 能力已经成为中国企业级 CRM 市场发展的重要趋势，为了满足企业用户的高度定制化和多样化需求，PaaS 平台要求数据平台具备高度灵活的可定制能力，例如增加字段完成功能迭代等。TiDB 支持 Online DDL，可实现在线添加字段，修改字段对业务无影响，加快了业务创新的速度，进一步增强了 CRM 等 SaaS 服务商在同行业中的竞争力。\n\n### 多管齐下，降低成本\n\nTiDB 一个数据栈支持混合负载，并提供实时的数据洞察，精简了 CRM 服务商数据平台的架构。从单体数据库集群、ETL 工具、数据仓库的多套系统组合到一个 TiDB 集群，大幅节省了数据在各个技术栈之间同步的时间成本以及多个数据副本的存储成本。TiDB 无需分库分表，提高了产品研发的敏捷度，减轻了各类应用的适配难度，研发人员可以把更多精力放在功能迭代和业务创新上。此外，TiDB 还提供了整套的数据同步及数据库管理、监控工具，进一步降低了后期的运维管理成本。  \n\n采用一个简单、强大、一栈式的数据服务平台成为越来越多 SaaS 企业的选择，这个平台既可以支撑海量在线交易，又可以提供实时分析能力，以极少的 DBA 和资源投入，就可以从容应对不确定的环境、多变的业务挑战。  \n\n![TiDB应对挑战.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_a8a3f2964f.jpeg)\n","author":"PingCAP","category":4,"customUrl":"htap-database-practice-in-a-chinese-saas-provider","fillInMethod":"writeDirectly","id":435,"summary":"CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。","tags":["HTAP"],"title":"MySQL or TiDB？HTAP 数据库在中国 SaaS 行业头部服务商的应用实践"}},{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel）  \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n  \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。  \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。  \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。  \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。  \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n![001.png](https://img1.www.pingcap.com/prod/001_ce42a10ada.png)\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n![002.png](https://img1.www.pingcap.com/prod/002_1f9a938e7e.png)\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括：  \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n![003.jpg](https://img1.www.pingcap.com/prod/003_a89e399f30.jpg)\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n![004.png](https://img1.www.pingcap.com/prod/004_be9d5cac08.png)\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。  \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}}]},{"id":"Blogs_446","title":"PingCAP 与 Wisconsin-Madison 大学建立科研合作，探索 Key-Value 存储系统的智能管理与自动调整","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"近日，企业级开源分布式数据库厂商 PingCAP 宣布与美国著名公立大学 Wisconsin-Madison 建立科研合作。","body":"近日，企业级开源分布式数据库厂商 PingCAP 宣布与美国著名公立大学 Wisconsin-Madison 建立科研合作，**PingCAP 将与威斯康辛-麦迪孙大学计算机、数据与信息科学学院院长 Remzi Aparci-Dusseau 教授就 Key-Value 存储系统中智能多级缓存管理，和运行中系统自动健康调整展开合作研究**，探索如何确保复杂系统长时间保持最佳状态。\n\nKey-Value 存储系统在不同的应用场景中对缓存的管理和使用有不同的方式，此次探索的智能管理 + 自动调整将尝试为 Key-Value 存储系统带来更鲁棒的适应性和更好的性能。\n\nPingCAP 联合创始人兼 CTO 黄东旭表示：TiDB 久经实战检验和行业认证，在技术领域不断深耕的同时，PingCAP 也一直通过多种形式和全球的开发者们共同探讨分布式存储技术。**PingCAP 在基础研究领域高校合作布局已久，目前已经同国内外 10 余所高校建立了合作，并已成立多个联合实验室，以期培养优秀科技人才、做好长期的专业人才储备。**\n\n威斯康辛-麦迪逊大学是美国最著名的公立大学之一、也是世界著名研究性大学。**其计算机科学系数据库系统组从 1976 年开始进行数据库相关的研究，被认为是美国最好的数据库研究团队之一**。从事的研究课题包括：构建下一代数据库系统、数据集成、数据科学、机器学习和数据库理论。\n\nRemzi Aparci-Dusseau 教授是威斯康辛-麦迪孙大学计算机、数据与信息科学学院院长，美国 Grace Wahba 教授称号获得者。Remzi 教授所著的操作系统原理（OSTEP）一书在互联网上每年被下载上百万次，被全球几百所高校使用。**Remzi 教授是系统、数据库方面的专家，在系统研究领域他的论文有 15000 多次的超高引用。**\n\n日前，PingCAP 联合创始人兼 CTO 黄东旭在威斯康辛麦迪逊作为客座讲师，向学生介绍了 TiDB 在云计算时代如何处理 OLTP/OLAP/HTAP 负载，并同学生进行了圆桌交流。**12 月 16 日，PingCAP 将与威斯康辛麦迪逊大学联合举办在线 meetup**，Remzi 教授将和 Yifan Dai 博士、PingCAP 研发工程师 Qi Xu 共同探讨共栖缓存技术如何优化分布式 KV 存储的性能。\n\n<center>扫描下方二维码了解更多</center>\n\n![640.jpg](https://img1.www.pingcap.com/prod/640_1a5fb5f6fd.jpg)","date":"2022-12-14","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"pingcap-established-a-research-partnership-with-the-university-of-wisconsin-madison","file":null,"relatedBlogs":[]},{"id":"Blogs_443","title":"PingCAP 成为中国唯一入选 Forrester Wave 数据库厂商，被评为卓越表现者","tags":["TiDB","HTAP"],"category":{"name":"公司动态"},"summary":"2022 年 12 月 6 日，国际权威研究机构 Forrester 发布了「Forrester Wave™: Translytical Data Platforms, Q4 2022 」报告，企业级开源分布式数据库厂商 PingCAP 作为中国唯一入围的数据库厂商，首次参评该报告即获评“卓越表现者（Strong Performers）”。","body":"![1.jpg](https://img1.www.pingcap.com/prod/1_022dd2c02f.jpg)\n\n2022 年 12 月 6 日，国际权威研究机构 Forrester 发布了「Forrester Wave™: Translytical Data Platforms, Q4 2022 」报告，**企业级开源分布式数据库厂商 PingCAP 作为中国唯一入围的数据库厂商，首次参评该报告即获评“卓越表现者（Strong Performers）”**。Forrester 认为， TiDB 采用云原生架构，兼容 MySQL 从而减少了迁移工作量，并同时具备交易处理与数据分析能力，在多模态可扩展性和性能方面与其他供应商不相上下。\n\n![2.jpg](https://img1.www.pingcap.com/prod/2_2a2d519d5d.jpg)\n\n<center>Forrester Wave™: Translytical Data Platforms, Q4 2022</center>\n\n**Forrester Wave 主题报告是 Forrester 在全球范围内影响力最大、市场认可度最高的报告系列之一**。Forrester 关注到，事务分析型数据平台（Translytical Data Platform）构建在单个数据库引擎上，支持多种数据类型和数据模型，成为下一代数据平台。它们能够同时支持事务、运营和分析工作负载，而不会牺牲数据完整性、性能和分析规模，成为现代化数据管理平台中热门的新兴市场。\n\n**「Forrester Wave™: Translytical Data Platforms, Q4 2022 」报告通过 26 项指标对全球 15 家主要的 Translytical 平台展开评估，包含 IBM、微软、Oracle、SAP 等成熟供应商，以及 Singlestore 、PingCAP 等新兴厂商**。PingCAP 作为一家成立仅 7 年的数据库厂商首次入围就跻身“Strong Performers”行列，也表示其领先的技术能力得到业界权威认可。**报告指出，“对于需要 MySQL 兼容性的 Translytical 平台的客户来说，PingCAP TiDB 非常适合，该平台可以为密集的事务与分析应用负载提供良好的性能。”**\n\n由 PingCAP 创立的分布式关系型数据库 TiDB，为企业关键业务打造，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等企业级核心特性，帮助企业最大化发挥数据价值，充分释放企业增长空间。\n\nPingCAP 创始人兼 CEO 刘奇表示，“我们相信，Forrester 在其新报告中纳入 PingCAP，**反映了 PingCAP TiDB 的强大性能和成熟度，以及我们作为一家公司的快速成长性**。我们将继续增强我们的产品能力，以满足客户当前和未来的需求。上个月，我们推出了 Serverless Tier on TiDB Cloud，这是一项完全托管的全自动 HTAP 数据库服务，使开发者能够以最具成本效益的方式大规模部署基础设施，而无需管理基础设施。”\n\n目前，PingCAP 已经向包括中国、美国、欧洲、日本、东南亚等国家和地区，超过 3000 家企业提供服务，涉及金融、运营商、制造、零售、互联网、政府等多个行业。\n\n想了解报告更多内容， [点击](https://live.pingcap.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=40450&source=1&pf_type=3&channel_id=30309&channel_name=pingcap-%E5%AE%98%E7%BD%91&tag_id=dafc115c773f5254)获取「Forrester Wave™: Translytical Data Platforms, Q4 2022 」报告全文。","date":"2022-12-07","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"pingcap-named-a-strong-performer-in-the-forrester-wave-translytical-data-platforms-q4-2022","file":null,"relatedBlogs":[{"relatedBlog":{"body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n![1.png](https://img1.www.pingcap.com/prod/1_93f0db213c.png)\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n![2.png](https://img1.www.pingcap.com/prod/2_81894f8cfc.png)\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n![3.png](https://img1.www.pingcap.com/prod/3_7b2415a552.png)\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n![4.png](https://img1.www.pingcap.com/prod/4_4c3a3da5dc.png)\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n![5.png](https://img1.www.pingcap.com/prod/5_f5295269ca.png)\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n![6.png](https://img1.www.pingcap.com/prod/6_0bed9de7a1.png)\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n![7.png](https://img1.www.pingcap.com/prod/7_c761db6eb7.png)\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n![8.jpg](https://img1.www.pingcap.com/prod/8_923cb0c9a2.jpg)\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n![9.png](https://img1.www.pingcap.com/prod/9_f8a1a72329.png)\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n![10.png](https://img1.www.pingcap.com/prod/10_8a00437db7.png)\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到  Serverless HTAP ，这到底是什么东西？意味着什么？\n\n![11.png](https://img1.www.pingcap.com/prod/11_cc3ffe56c2.png)\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n![12.jpg](https://img1.www.pingcap.com/prod/12_28a125c2bd.jpg)\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n![13.png](https://img1.www.pingcap.com/prod/13_d375c3dd69.png)\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n![14.png](https://img1.www.pingcap.com/prod/14_9c843d72cd.png)\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n![15.png](https://img1.www.pingcap.com/prod/15_c8ed753a77.png)\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n![16.png](https://img1.www.pingcap.com/prod/16_a008ec4dc8.png)\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n![17.png](https://img1.www.pingcap.com/prod/17_63cfa346cc.png)\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n![18.png](https://img1.www.pingcap.com/prod/18_dbfc30531d.png)\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","author":"黄东旭","category":2,"customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","fillInMethod":"writeDirectly","id":440,"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","tags":["HTAP","Serverless"],"title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022"}}]},{"id":"Blogs_440","title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022","tags":["HTAP","Serverless"],"category":{"name":"公司动态"},"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n![1.png](https://img1.www.pingcap.com/prod/1_93f0db213c.png)\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n![2.png](https://img1.www.pingcap.com/prod/2_81894f8cfc.png)\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n![3.png](https://img1.www.pingcap.com/prod/3_7b2415a552.png)\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n![4.png](https://img1.www.pingcap.com/prod/4_4c3a3da5dc.png)\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n![5.png](https://img1.www.pingcap.com/prod/5_f5295269ca.png)\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n![6.png](https://img1.www.pingcap.com/prod/6_0bed9de7a1.png)\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n![7.png](https://img1.www.pingcap.com/prod/7_c761db6eb7.png)\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n![8.jpg](https://img1.www.pingcap.com/prod/8_923cb0c9a2.jpg)\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n![9.png](https://img1.www.pingcap.com/prod/9_f8a1a72329.png)\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n![10.png](https://img1.www.pingcap.com/prod/10_8a00437db7.png)\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到  Serverless HTAP ，这到底是什么东西？意味着什么？\n\n![11.png](https://img1.www.pingcap.com/prod/11_cc3ffe56c2.png)\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n![12.jpg](https://img1.www.pingcap.com/prod/12_28a125c2bd.jpg)\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n![13.png](https://img1.www.pingcap.com/prod/13_d375c3dd69.png)\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n![14.png](https://img1.www.pingcap.com/prod/14_9c843d72cd.png)\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n![15.png](https://img1.www.pingcap.com/prod/15_c8ed753a77.png)\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n![16.png](https://img1.www.pingcap.com/prod/16_a008ec4dc8.png)\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n![17.png](https://img1.www.pingcap.com/prod/17_63cfa346cc.png)\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n![18.png](https://img1.www.pingcap.com/prod/18_dbfc30531d.png)\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","date":"2022-12-02","author":"黄东旭","fillInMethod":"writeDirectly","customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","file":null,"relatedBlogs":[]},{"id":"Blogs_423","title":"打造友邻式多元生态，支撑工商银行、平安科技、中国人寿财险、杭州银行的创新实践","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"9 月 22 日的用户峰会上，PingCAP 副总裁陈煜琦发表了以“深耕行业场景，构建多元生态”为主题的演讲，工商银行、杭州银行、中国人寿财险、平安科技分享了在他们的关键业务中如何借助 TiDB 深挖行业场景，来自神州数码、中电金信、天翼云、东软集团、云徙科技、嘉和美康的生态伙伴分享了他们与 TiDB 的共建经验。本文为分享回顾。","body":"作为数据库服务商， PingCAP 肩负着一项重要使命：找到一条深耕行业场景，构建多元生态的路径。9 月 22 日的用户峰会上，PingCAP 副总裁陈煜琦发表了以“深耕行业场景，构建多元生态”为主题的演讲，工商银行、杭州银行、中国人寿财险、平安科技分享了在他们的关键业务中如何借助 TiDB 深挖行业场景，来自神州数码、中电金信、天翼云、东软集团、云徙科技、嘉和美康的生态伙伴分享了他们与 TiDB 的共建经验。以下为分享回顾。\n\n在传统的体系下， 原厂商和渠道商往往处于供应链上下游的位置， 彼此之间是通过商业利益进行连接的。在这种体系下，原厂商往往处于主导地位， 如果用太阳系来比喻这套合作体系， 那么处于太阳系中心的就是原厂商， 各个渠道商就像一颗颗行星， 被吸引着围绕原厂商转动、 产生连接、创造商业价值。但是这样的引力是不可持续的，并且黏性是不够的。\n\n![陈煜琦.jpeg](https://img1.www.pingcap.com/prod/_0cf67761cd.jpeg)\n<center>PingCAP 副总裁陈煜琦</center>\n\nPingCAP 副总裁陈煜琦介绍，我们有非常好的社区文化、开源基因，以及散布在各行各业中的开发者、使用者、源代码贡献者。**通过开源模式，PingCAP 打造出一套“友邻式”的生态体系，任何个人、公司、数据平台、云基础设施都可以通过 TiDB 开源社区连接在一起，持续挖掘和创造商业价值**。\n\n在过去这些年中，基于这样的“友邻式”生态，PingCAP 从研发、产品到服务，积累了非常多体系化的能力，在金融、保险、物流、互联网等行业的深度客户中积累了非常多的场景和经验，与众多生态伙伴共同挖掘 TiDB 的行业场景能力。\n\n## 与深度用户共同挖掘行业场景\n\n> 金融机构尤其是银行，信息化开始都比较早，信息技术已经成为银行经营的主要支柱。银行业务的特殊性是和钱打交道，因此对系统可靠性要求比较高。TiDB 的分布式架构、金融级数据强一致性都为金融用户提供了坚实的数据底座能力。\n\n### 杭州银行：关键业务类系统数据库的选择\n\n杭州银行作为金融企业，为保证系统运行的可靠性、安全性和稳定性，以往比较偏爱国外厂商的高端成熟系统。\n\n随着数字经济发展和新一代技术崛起，以互联网厂商为代表，通过分布式、微服务、云计算等技术也构建出了可以满足业务发展的技术架构，并且在人才体系、业务模式和用户习惯上能够实现多个维度不断破圈。银行也从自身的金融科技发展角度看到了新技术在性能、弹性和成本管理上的优势。**在架构转变过程中，金融科技的自主发展已经成为银行业的发展共识，越来越多的银行同业开始应用分布式技术，在业务发展变革中通过场景实践来带动发展**。\n\n杭州银行坚持自主研发、自主建设、自主可控的系统建设思路。在基础软件领域，杭州银行从 2015 年开始使用 MySQL 等开源软件；2018 年引入私有云建设，在云上所有的业务系统数据库都使用了 RDS ；2020 年，采购单独的分布式数据库产品也投入了生产环节；2021 年随着云原生技术的发展，杭州银行进一步在生产环境引入了容器云平台，在客户关系管理、办公自动化系统等金融分析系统中引入了 TiDB，并在多种业务场景对 HTAP 架构进行验证，了解掌握它的技术特点。\n\n![刘峥.jpeg](https://img1.www.pingcap.com/prod/_e749a0b808.jpeg)\n<center>刘峥 杭州银行 信息技术部副总经理</center>\n\n银行业务交易类系统尤其是关键业务系统，是金融行业中要求最为苛刻的系统。“钱不能错，服务不能停”，这是监管基本要求。作为交易系统的数据承载、服务底座，这种系统的数据库必须满足四个基本要求，**杭州银行信息技术部副总经理刘峥**把它总结为“SAPE”：一是 Safe （安全），数据安全是要绝对保证的，在任何情况下数据不能丢，数据不能错；二是 Availability （高可用），保证业务连续性不仅要符合监管要求底线，也要完善整个体系的可用性；三是 Performance （性能），使用分布式数据库替代传统数据库后，除了自然而然带来的横向扩展能力外，系统性能不能因此而产生降级；四是 Ecology （生态），这是当前背景下的一个特定要求，当前数据库产品众多，产品技术生态一定要有多方支持，由多方共建，对开发者和开发商要有强大吸引力，产品才能持续发展。\n\n杭州银行组织多方参照监管单位发布的关于分布式数据库的技术架构、灾难恢复、安全技术的行业标准，共同设计了产品的测试场景，结合 TiDB 的产品特性在关键业务系统的仿真场景下进行更为详细的测试验证。TiDB 在开发应用、双中心多活、HTAP 等场景下体现出了较大优势，对测试过程中新增的一些产品需求也能及时改进和反馈。从开放性上来讲，TiDB 在人才培养、开发平台的适配、开源生态都有比较明显的优势，**下一步杭州银行将在更多重要业务系统应用 TiDB，进行持续探索和磨合**。\n\n### 工商银行：国产分布式数据库的探索实践\n\n工商银行从 2017 年就开始关注、研究和使用 TiDB。工商银行技术专家王君轶依稀还记得做第一个 TiDB 变更时的情景，那时还是 TiDB 2.0 版本，做一个服务器的置换一做就到第二天天亮。上个月工商银行把所有机型升到 TiDB 5.4 版本，所有升级动作仅在一个小时内就能全部搞定。**近几年 TiDB 的更新迭代非常快，用户体验已经不可同日而语了**。\n\n![王君轶.jpeg](https://img1.www.pingcap.com/prod/_e6bd45b92f.jpeg)\n\n<center>王君轶 工商银行 基础技术实验室 技术专家</center>\n\n王君轶介绍使用 TiDB 的契机是自主可控，当时人行和工信部都提出银行核心系统的国产化替代，工行也积极响应，直到现在也是重点工作之一。同时工行也提出了在分布式数据库技术领域要提前进行技术储备和布局。虽然 TiDB 是当时一款比较火的产品，但是当时业界也不乏其他一些优秀产品，为什么最终工行还是选用了 TiDB？最主要的一个原因就是开源，开源为工行深入研究一款产品提供了可能。同时，跨行业的丰富使用案例，也给工行提供了很多借鉴。社区化的开发模式、版本的快速迭代，可以更快地完善所需功能。后续多家国产数据库陆续开源，也从侧面印证了 TiDB 坚持的开源战略受到了行业的认可。最后一点原因是工行对分布式数据库技术的研究需要。工行在分布式数据库技术领域也是多驾马车并行的，TiDB 可以作为这个技术领域的有益补充。\n\n工行从 2017 年开始对 TiDB 进行研究论证，2018 年开始落地。刚开始上线的时候 TiDB 性能并不是太好，在进行了一系列优化，包括物理机置换，搬迁到万兆网络机房以后，性能肉眼可见地获得了很大提升。在高可用方面，工行进行了负载均衡以及同城双活的改造。整个过程并不是一蹴而就，其实是一个慢慢摸索的发展状态。直到 2020 年后 TiDB 开始慢慢走向成熟，4.0 版本也具备了 HTAP 的能力，工行随之开始寻找合适的试验场景。同时工行也在不断完善集群的一些配套功能，包括报警监控、安全审计等。再之后，工行开始研究 TiDB 上容器，这也顺应了基础设施云化的发展趋势。今年，工行会继续通过 TiDB 国产开源的特性，助力运维数据库的自主可控建设。\n\n**TiDB 在工行前后共投入了四五套集群，主要分为两类：一种是传统的部署架构，另一种是云上多租户，也就是容器集群架构**。传统的部署架构可以支持更大负载的应用，而且具备稳定性和性能两方面的优势，比较适合应用等级比较高，数据规模比较大的应用；容器集群可以通过容器来提高租户间的安全隔离，借助开发的调度编排，实现资源投入和人力成本的降低，比较适合应用等级稍低，数据规模没那么大的应用。两种架构正好形成互补。\n\n![TiDB 在工行的部署.png](https://img1.www.pingcap.com/prod/Ti_DB_92721544ca.png)\n\n上图是一个同城两中心部署架构，具备同城双活高可用能力，通过 F5 实现园区间的流量转发。同时根据服务器的资源配置，将 DB 节点和 KV 节点进行多实例部署，兼具性能、稳定性以及资源利用率两方面的均衡。\n\n工行去年开始试点容器集群，现在还处于摸索阶段。容器集群最大的优势除了能够降低资源投入外，还能节约人力成本。出现故障灾难恢复时，不需要人工干预，能够实现自愈，通过 TiDB  Operator 能够实现集群的全生命周期管理。\n\nTiDB 在工行最初是以运维领域作为研究的切入点。运维应用所使用的数据库也在面临很多挑战，像业务应用基本每个应用都会单独设一套数据库，资源投入多不说还比较难管理。但绝大部分运维应用都不会太大，属于中小型的应用，不过也有极个别的比较复杂，加上人工智能、模型训练等，如果随便找一个业务数据库来跑的话，在分析计算方面还不一定能够搞得定，同时随着业务应用的不断扩张，与之相对应的运维数据呈几何增长，扩容也是一个问题。此外，在多数据中心的情况下如何高可用部署？其实行内的业务系统高可用已经比较成熟，但运维应用的高可用相对比较薄弱，近几年行内对运维应用容灾能力越来越重视。\n\n因此，**工行基于分布式数据库 TiDB 构建了一个多租户 DBaaS 云，能够为多个运维应用提供数据库服务，根据业务的需求进行弹性伸缩**。同时工行进行了同城高可用的部署，在应用上进行试点验证。以工行的智能算法门户应用为例，这个应用是面向运维的，能够提供数据的加工处理，以及运维集成的端到端的运维服务。它一方面会对数据库捞取大量的数据做模型训练，而且实时性要求还不低。另外一方面，它会将运维数据异常检测的一些结果数据对数据库进行高频的读写更新，这比较贴合 HTAP 场景，因此工行以 Spark 作为分布式计算引擎，以 TiDB 作为底层数据存储引擎，来构建高效的流批一体处理框架。\n\n> 数据库也是保险公司信息系统中关键的基础设施，因此，产品优秀，服务到位是保险信息系统稳定运行的前提， PingCAP 与中国人寿财险建立了良好合作，一起打造出分布式数据库在财险行业核心应用的典范。\n\n### 中国人寿财险：“核心系统分布式数据库”改造实践\n\n中国人寿财险是中国人寿集团重要成员单位，成立 16 年以来成果颇丰，目前在中国财险行业排名第四，累计服务了 1.1 亿个人用户，470 万个组织客户。该公司高度重视科技投入，科技应用在公司发展历程上起到了至关重要作用，从最初的技术支撑到逐步引领业务的方向，科技创新成为中国人寿财险最重要的核心竞争力之一。\n\n![陈彬.jpeg](https://img1.www.pingcap.com/prod/_f6006e6148.jpeg)\n\n陈彬 中国人寿财险 金融科技中心系统运行部负责人\n\n**中国人寿财险充分利用两条科技途径推进科技创新，一是利用大数据、云计算、人工智能等新一代技术来改造传统保险业务，二是直接面向互联网、移动化构建新的服务架构和运营模式**。在数字化转型道路上，数据库是最重要的核心基础设施，支持大规模数据、高并发、敏捷响应成为其关键能力，也是保险业务高质量发展的技术保障。\n\n近几年来，中国人寿财险主动应对车险综合改革，业务规模持续上升，盈利能力水平稳步提高，2021 年实现保费收入约 915 亿元。历时三年，中国人寿财险在 2020 年完成了新一代核心业务系统的建设，为深入推进数字化转型打下坚实基础。但是，随着业务规模的不断扩大及保单件数的激增，仍面临一些在应用层面解决不了的痛点，例如，投保业务激增导致高并发，实时数据写入、时效性、可靠性得不到保障。**担心业务高峰期出现单点故障，基础软件做不到完全掌控，而这些痛点正好是分布式数据库善于解决的问题**。\n\n分布式数据库支持横向扩展，满足金融应用系统海量数据存储和百万级 TPS 高并发要求，提高了吞吐能力，降低了响应时间，实现小机向 X86 迁移，摆脱对专有硬件依赖，分布式数据库是解决以上问题的最佳方案。\n\n鉴于分布式数据库金融行业的应用案例相对较少，**中国人寿财险采用四步走策略，包括公开招标、PoC 测试、上线试用、外部评审，尽最大可能选择最适合业务发展的数据库产品**。2020 年，中国人寿财险通过对市场上主流分布式数据库进行深入考察和评估，最后选择 TiDB 4.0 作为核心业务系统分布式数据库的试点。\n\n2020 年 11 月，经过详细的技术验证，应用优化和投产保障规划，中国人寿财险数据库及中间件团队成功上线了单证系统。2021 年，陆续实现了承保辅助决策系统、天财车险、特殊车险承保系统的上线。今年，中国人寿财险已经完成了报价中心的切换上线，后续还会完成非车险承保系统的切换上线。TiDB 大幅提升海量数据和高并发下的性能问题，提供灵活的弹性扩容能力，并符合未来云架构的趋势。目前，TiDB 集群稳定支撑非车险及电子投保系统的客户身份认证、投保、对接银行保单处理、电子发票开具等业务，提供了异构数据库的灾备能力，实现了 RPO=0，RTO<30 秒的金融生产级高等级运行保障要求。\n\n**在整个实践过程中，中国人寿财险和 PingCAP 密切合作，初步形成了分布式数据库自主创新的能力，验证了分布式数据库在核心业务系统的可行性**。中国人寿财险基于 TiDB 实现了核心业务系统的分布式改造，第一次在保险行业联机交易和批量业务场景引入 NewSQL 分布式数据库架构，推动中国人寿财险核心业务系统实现了进一步技术演进迭代和整体降本增效的目标。\n\nTiDB 分布式数据库在中国人寿财险核心业务的成功应用，首先节省了成本，通过 X86 通用服务器代替 IBM 小型机，硬件投入成本降低了 75%；其次，用先进的分布式数据库替换集中式数据库，改造完成之后，OLTP 和 OLAP 性能较原来的 Oracle 数据库均有了明显上升，其中全量状态统计报表的处理时效提升 80 多倍，并具备了更强的数据汇聚和查询能力；最后，通过开放架构实现了安全可控，初步打造了中国人寿财险的自主创新体系，并不断演进，为后续异地双活改造奠定了坚实的技术基础。\n\n## 与行业科技公司共创新型合作模式\n\n> PingCAP 在拓展场景时常常会碰到多种多样的各类需求，而这些需求来自于各个企业所属的竞争环境，这些挑战无论是业务还是技术上，都不是一家企业能够独自完成的，要想深耕行业，就需要各种行业的垂直解决方案、服务能力， PingCAP 在与平安科技的合作中尝试出一种新的生态合作模式，为行业领域用户提供更深入的行业解决方案。\n\n### 平安科技 - 携手共建的发行版战略\n\n平安科技总工程师汪洋分享了 TiDB 发行版 UbiSQL 的前世今生。UbiSQL 是平安基于 TiDB 基础的数据库引擎自研的数据库发行版，定位是金融级分布式数据库，能够覆盖金融全场景，并满足国家信息自主可控和一行两会对于数据库技术的要求。\n\n![汪洋.png](https://img1.www.pingcap.com/prod/_7ba23426e1.png)\n\n<center>汪洋 平安科技 总工程师</center>\n\nUbiSQL 前三个字母 Ubi 是英语 ubiquitous （无处不在）的缩写。在发音上，汪洋称 UbiSQL 为“无比 SQL”，希望这个数据库具有良好的扩展性，非常强的高可用性，能够做到无与伦比，无处不在。\n\n![UbiSQL 的前世今生.png](https://img1.www.pingcap.com/prod/Ubi_SQL_3a1b112b9b.png)\n\n**过去一年来，平安科技与 PingCAP 进一步加强了合作关系，探索出了从产研到交付到服务的全新合作模式**。在该模式转变前，双方各自有一个内循环，围绕着平安、PingCAP 自己的核心场景转动。平安作为一个综合性金融集团，涵盖了全牌照的金融服务，包括银行、基金、保险、投资，甚至包括一些互联网金融，非常丰富。围绕这些核心场景，平安有自己的 UbiSQL 产研团队、解决方案团队、运维团队，这些之间形成了一个内循环。当产品发布之后，平安可以通过自己的数据库架构师或者产品解决方案师，给应用系统做出一些建议，提出一些架构选型方面的建议，还有一些系统的使用性建议。在系统上线后，还可以根据线上问题提供一些售后的运维支持，包括整体系统的优化，定期 review ，健康检查，在这个过程中平安能够发现产品所需要提升的地方，形成了一个闭环。\n\nPingCAP 同样有三种角色，但是唯一不同的是缺少这样的金融场景。所以之前这两个环是相对独立的。\n\n在这种模式运行一段时间后，双方发现在很多方面还没有打通，没有产生 1+1>2 的效果，而是 1+1=2，甚至于可能是小于等于 2 。**现在，通过双方合作的进一步加强，平安和 PingCAP 形成了内循环 + 外循环模式，内循环与外循环是打通的：双方的产研团队打通**，形成产研方面的联合团队；在交付方面打通，形成了解决方案师的联合团队；在售后方面打通，形成了技术服务的联合团队。通过将这些团队角色打通后，双方发现在问题的解决效率、产品新特性的发布、产品问题的修复等方面，都得到了非常大的提升。\n\n这种新模式就是开放合作和共赢。当线上 UbiSQL 的一个应用系统发现问题后，双方组建的运维团队可以迅速介入分析问题，诊断问题。一方面能够快速解决问题，恢复生产，恢复服务；另一方面可以继续去寻找产品产生问题的根本原因，并制定对应的解决方案，让问题不再发生。在查找问题原因、制定解决方案的同时，也会看到一些对产品方面的提升建议，平安会提交给产研联合团队，进一步了解产品的实现机制。\n\n![平安科技与 PingCAP的合作.png](https://img1.www.pingcap.com/prod/Ping_CAP_b180f967a3.png)\n\nPingCAP 的产研团队则更聚焦在 TiDB 最新的版本或者未来的版本上，能够进行产品特性方面的增强或者 bug 修复，而平安的团队也能够把这些方案在产品方面的一些实现，快速应用到现网运行上的一些系统中，快速进行现网产品的提升，这是双方合作的意义所在。**通过组建这些联合团队，可以看到覆盖的应用系统从设计到开发到上线到售后到销售整个生命周期**，覆盖了驻场运维服务、问题咨询、功能申请、技术支持、系统优化、故障上报等端到端服务能力。通过这种全新的合作模式，平安与 PingCAP 形成了共赢的基础。\n\n共赢还使得双方无论在研发能力、运维能力，还是解决方案能力方面，都得以提升。可能连 PingCAP 的研发也没有意识到，在某些特定场景和负载下产品会出现的问题，通过双方合作可以发现和修正。这种模式不仅可以极大程度上帮助 TiDB 打磨金融场景的基础能力，同时还能帮助平安 UbiSQL 的研发团队加深对代码的理解，能够更迅速地从代码级定位问题，修复问题。当产品发生问题后，双方团队可以对问题诊断分析，能够发现一些以前包括研发、运维团队所不知道的特性与机制。**从这些方面来看，合作不光使平安科技的交付团队、运维团队能力得以提升，就连 PingCAP 的售后工程师技能也得以提升**。\n\nPingCAP 与平安就是通过这样更加开放的态度进行更加深入的合作，从而达到双方共赢，实现能力、产品的提升，进一步适配金融场景需要，实现 1+1>2 的效果。**相信通过这种全新的合作模式，PingCAP 和平安，包括 UbiSQL，都可以走得更远，越做越好**。\n\n### 加乘创新 智简未来，构建友邻多元生态\n\n![多元生态.png](https://img1.www.pingcap.com/prod/_e1c1965f70.png)\n\n除平安科技外，PingCAP 的整个生态体系也会涉及到各行各业非常核心的场景，除了前面讲到的社区、技术、人才、共赢生态，还需要有更多传统企业级解决方案加进生态中，融合开源、多源和行业解决方案，将 PingCAP 的整个生态体系进化为“友邻式”的多元生态。\n\n**用户峰会上，陈煜琦与神州数码、中电金信、天翼云、东软集团、云徙科技、嘉和美康等生态合作伙伴共同启动了“加乘创新 智简未来”的共创仪式**，将合力为银行、保险、证券、电信、政企、零售餐饮、制造、医疗等数字转型企业，以及 SaaS、金融科技、游戏、电商等数字原生企业，提供更加丰富的企业级解决方案及服务。\n\n![共创仪式.png](https://img1.www.pingcap.com/prod/_a902132bd9.png)\n\n**赵琳 神州数码企业业务集团软件本部总经理**\n\n“神州数码与 PingCAP 在面向数据库企业服务市场、面向技术人才及开源运营生态、面向双方战略合作共赢上一直有着深入合作，神州数码的数云融合技术战略致力于为企业形成数据洞见及敏捷应对变化和创新的能力，拥抱云和开源，与TiDB 等开源厂商就云原生的分布式架构、Dataops、定制化通用聚合平台等进行解决方案整合，为企业提供一站式企业数字化转型解决方案。”\n\n**邵建军 中电金信副总裁**\n\n“中电金信和 PingCAP 在杭州银行等越来越多的金融机构领域成功合作，我们认为未来与 TiDB 的合作层级会越来越广阔，不断加强合作的深度和广度。”\n\n**侯圣文 天翼云大数据 AI 首席专家**\n\n“天翼云在 2018 年开始参与了 TiDB 开源项目，我们有很多开发者一起探索在云原生当中的 HTAP 场景，在多个行业领域落地，都取得了非常良好的效果。天翼云团队一直在践行着中国人真正的担当，走向了一个自主可控的路径，未来和 TiDB 一起，希望我们能把自研数据库做得越来越好。”\n\n**郭晓龙 东软集团股份有限公司医疗保障事业部开发中心主任**\n\n“东软集团成立于 1991 年，在汽车互联，软件国际化服务都属于领先领域。我们和 PingCAP 是在医疗保障行业里深度合作，通过产品选型和技术认证，我们选择了 PingCAP 的 TiDB，并打造了山东临沂千万级别人口城市标杆的医保项目，这个项目解决了传统的分布式数据库的适配成本高，管理成本大，性能优化难的问题，受到了医保，山东医保的高度肯定。接下来我们想和 PingCAP 公司携手共进，开展更加全面深入多元化的合作。”\n\n**江威 云徙科技副总裁**\n\n“云徙科技主要在企业服务里做基于中台的营销数字化服务，帮企业构建一体化的数字增长服务。我们和 TiDB 面向大数据的营销场景、业务中台应用落地，未来希望在越来越多企业应用中与 TiDB 一起共同提供更好的服务。”\n\n**潘状 嘉和美康平台数据中心产品总监**\n\n“嘉和美康是国内比较早从事医疗软件研发和产业化的公司，公司主营业务是医疗软件，在这个行业内深耕了 11 年，目前已经形成具有自主知识产权，包括临床医疗，医患互动，医养一体，医疗大数据相关产业链。我们与 TiDB 合作的主要方向是在医疗大数据方向，看重 TiDB 优秀的在线数据分析能力，数据处理能力，未来我们希望与 PingCAP 一起在医疗行业内秉承合作共赢、开放的理念，加速我国医疗信息化数字化转型。”\n\n未来，相信将有更多的企业用户和合作伙伴加入 PingCAP 这个“友邻式的多元生态”，共同助力数字转型企业和数字原生企业的业务敏捷创新。","date":"2022-09-29","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"create-a-friendly-and-diversified-ecosystem","file":null,"relatedBlogs":[{"relatedBlog":{"body":"本文回顾了 PingCAP 创始人兼 CEO 刘奇在 9 月 22 日的用户峰会上以《现在决定未来》为主题的演讲，**分享了 PingCAP 在技术演进、用户价值、数据库技术趋势、国际化、社会价值等方面的思考**，同时也记录了建信金科、百胜中国、传音控股、老虎国际等用户在刘奇的演讲中分享的最佳实践。全文字数约 8,800，预计阅读时间 20 分钟。\n\n![刘奇.png](https://img1.www.pingcap.com/prod/_6c926b4679.png)\n\nPingCAP 到今天已经成立 7 年了，在全球拥有 3,000 多家大中型用户，其中很多还参与到 TiDB 开源社区的建设中，这些情况如果放到创业之初很难想象。\n\n**今天，我们认识到做一个真正广泛应用的数据库，是一个需要以十年为时间单位进行投入的基础工程**。这一路走来离不开关心和支持 PingCAP、喜欢 TiDB 的每个人。\n\n## 与客户对话，客户眼中的 TiDB\n\n过去一段时间，在和包括日本、美国、印度、欧洲等全球客户交流时，我们试图从更多不同客户的视角去了解他们到底是怎么看待 TiDB 的。\n\n在 TiDB 的设计里，有很多设计是从第一天就开始的，我们甚至完全不觉得这个设计有什么特别之处。直到我问一些专家型用户“你到底为什么选择 TiDB ？”时，他们告诉我：**因为 TiDB 的开放式架构可以管理复杂性**。我当时挺诧异，因为这个东西第一天就是这样设计的，已经融入 PingCAP 的血液当中，所以我们自身已经无感。但对这些专家来说，他们当中很多人在各个大公司本身就做过数据库，甚至是大型分布式系统，做过这些系统的人都会产生一个心态，那就是对“复杂性”会无比敬畏。\n\n![与专家型客户对话.png](https://img1.www.pingcap.com/prod/_b7cdaa3e30.png)\n\n一个数据库，哪怕它是一个小型数据库，通常代码规模都会有几十万行，上百万行，如果是一个传统的成熟型商业数据库，那更是一个以千万行代码为单位的系统。**面对如此复杂的系统，用户在考虑未来的迭代时，通常要做 3-5 年的规划**。如果用户需要花 3-5 年来替换一个 PB 级数据库，很大程度上意味着接下来 5-10 年的时间他就不想再动了，这也是本次峰会的主题为什么是“现在决定未来”。\n\n**今天我们做一个数据库替换的决定，它的影响周期很可能是接下来的 10-20 年**。在这个较长的周期中，大家看系统价值的时候就会看到完全不一样的价值。比如最近我意外地发现 TiDB 在 CFO 眼里其实很受欢迎，他们表示，在现有实践中，TiDB 至少可以降低一半的成本，所以 CFO 很快就会批下来对 TiDB 的部署和应用。大家可以试想一下，如果用户有 PB 级的数据，用 TiDB 替换能够省一半的成本，是不是非常有吸引力？\n\n今天的世界充满了不确定性，在此前提下如何能更好地生存下去？省钱自然会变成一个全世界都关注的话题。\n\n但所有这些价值的前提是接下来 5-10 年，甚至 10-20 年这个系统不能死，能持续支撑业务。这时候问题就来了，**凭什么一个系统在接下来 10-20 年间还能够支撑用户的业务？用户做架构选择最重要的标准是什么？**\n\n是整个设计团队是不是具备掌控复杂性的能力，是不是能够看到未来 10-20 年企业中的系统复杂性会朝什么方向迭代，今天在系统里做好设计，可以应对未来的高速演进和迭代，而不只是一个过渡方案，过两年还要再换。**虽然我们在设计 TiDB 的过程中，已经做了高度分离式架构，开放式 API ，但有些东西融入血液时就会无感，而在用户看来这恰恰是他们最看重的，这给了我们很大启发**。\n\n一个专家型用户跟我说：“**人类几千年来应对复杂性只学会了一个道理，就是分而治之**”。这听起来好像是一个很简单的道理，回想一下会觉得他说得太对了，这也是人类几千年来应对复杂性的唯一办法。分而治之落在软件或者数据库的复杂性上面，应该是什么样的？这就是 TiDB 未来的演进方向，也是整个行业未来的演进方向。\n\n![与应用型客户对话.png](https://img1.www.pingcap.com/prod/_0e4e2d2a4a.png)\n\n与专家型用户不同，应用型客户又是完全不一样的观点。有些用户是做创业公司，能不能活过两三年自己也不知道。**如果选择一个东西需要花 2-3 年才能看到足够大的价值，肯定等不起，他需要更快地兑现价值**。事实上，这些应用型客户不仅仅是那些创业公司，还有很多是大公司里面的新项目。大家知道在一个大公司里经常出现一种情况，当做一个新业务时，每个人心里都清楚时间很有限，公司可能等不了用 5 年时间来做一个创新，所以怎么才能更快地释放数据价值才是他们关心的话题。\n\n今天的数据库是一个百花齐放的状态，甚至在国内的一些场景出现了数据库“四世同堂”的局面，同时跑着大型机、小型机、x86，接下来甚至还要引入分布式数据库、云数据库，对用户而言选择一个数据库其实非常困难。\n\n**世界变化太快，很多时候用户可能是在项目进行的过程中突然有了一个新的想法**。怎么用最快的速度把这个东西做出来，并且做出来之后不用操心它是不是能扛更高的并发？如果快速把第一个原型推到线上，用户是不是可以不用操心后面的并发问题？当推到市场时立刻就能获得新的反馈，新反馈作为新需求加进来后，能不能在当天就直接提供服务？这个时候非常依赖数据库的能力，特别是当我们和越来越多的年轻人聊时，会发现他们今天已经不再关心数据库任何底层的东西。**他们只关心你有没有能力让他用最快的速度将产品或服务推向市场，在推向市场后有没有能力支持业务高速发展**，有些用户甚至连 SQL 都不想写了。\n\n## 重新思考：如何以敏捷性应对未来\n\n所有这些对数据库的能力要求非常高，本质上我们要用数据库的能力支撑业务的敏捷性：如果要支持一个敏捷业务，那数据库本身的迭代能力是不是足够敏捷？**这让我们对敏捷产生了全新的思考**。\n\n有两个用户让我觉得特别震撼，其中一个是区块链领域的用户，通过使用区块链技术追踪区块链里的每一笔交易，如果是相同的人还可以追踪跨链的交易。这个用户在不到一年的时间里，单个集群数据量从几 TB 上涨到一百多 TB。因为 TiDB 太好用了，他会把更多的数据往 TiDB 里放，把 TiDB 作为在线服务。当你有这个想法时就会发现，你根本找不到一个其他数据库能满足这个需求；它需要在线服务、低延迟，需要从不同角度查询数据，你可以用索引、HTAP 能力，还必须要有非常强大的 SQL 能力，因为用户会不停往里面塞数据。\n\n![客户感受.png](https://img1.www.pingcap.com/prod/_c02e4a56a0.png)\n\n前两天在 Hacker News 上有一个热帖，微软云的 CTO 发了一个推特，引起了轩然大波，他说现在 C 和 C++ 这类语言被标识为过时的语言，如果大家用 Java 或者其他软件，经常会把过时的不再支持的 API 标记成过时数据。他的建议是我们应该把 C++ 标记成过时，任何项目不再用 C++ 写，应该全面使用 Rust。可能有人有印象，TiDB 在 2015 年就开始用 Rust 写存储层。但对于新用户来说，当知道我们用 Rust 和 GO 作为编程语言时，他们就会说你们好时尚，实际上这是我们 7 年前的决策。当初，Rust 还没有发布 1.0 版本，拿这个东西来写数据库简直是开玩笑。\n\n**很多时候，我们的一点创新，一点激进的动作，很可能在当初饱受非议，但在未来却可能成为主流**。PingCAP 在技术、架构上面一直会选择非常积极的创新，非常具有前瞻性的创新，这些创新甚至要在 5-7 年后才能感受到当初的选择是非常正确的。\n\n![客户成功范式.png](https://img1.www.pingcap.com/prod/_0b64827dd5.png)\n\n总结来说，如果用几个词来形容 PingCAP 的成功范式，那就是自主开源+持续引领+面向未来的创新，都服务于客户成功，不管是专家型的客户还是应用型的客户，TiDB 都能够很好地去支持他们的业务更好、更敏捷地迭代发展。TiDB 也因此成为众多行业头部用户的共同选择，助力用户业务敏捷增长。\n\n### 用户分享：建信金科为什么选择与 TiDB 同行？\n\n![建信金科.png](https://img1.www.pingcap.com/prod/_8915b47379.png)\n\n**建信金科基础技术中心副总裁邢磊分享了建信金科如何借助 TiDB 实现业务增长敏捷性**。建信金科自关注分布式数据库以来，PingCAP 一直未离开过其视线。与大多数用户不同，建信金科与 PingCAP 的接触不是从 TiDB 开始，而是 TiKV，为什么是这样的选择？\n\n建信金科的微服务、分布式，要求对数据做拆分，需要在现有业务不做大调整的情况下，去开启业务应对未来不确定性的能力。在这个过程中有一个绕不过去的问题，这么多传统渠道、传统业务和交易，如何在不影响现有交易模式的前提下改造后端的服务能力？TiKV 在这样的场景下进入视野，以前建信金科用的是国外开源软件，整个历程中遇到的问题和挑战非常大，也给自己的安全稳定运行带来很大挑战。\n\n建信金科一直在思考怎么去找一个自己能掌控的技术，去解决后续将在这个领域上面对的问题。从 2020 年开始接触 TiKV，做业务场景适配，包括早期的技术、产品验证，以及双方在 TiKV 上投入研发的资源和精力，一起努力了差不多一年时间。这是建信金科做过的所有案例里耗时最长、投入最大的项目。2021 年 10 月，建信金科第一次把 TiKV 5.0.4 版接入到全行分布式体系当中，顺利扛住 4 万多 TPS 压力稳定运行，开启 TiKV 在建信金科分布式体系中的重要作用。**随着核心业务的改造，建信金科去年底将整个核心业务在分布式平台上进行切换，TiKV 起到了非常关键的作用。自 2022 年开始，建信金科更进一步借助 TiKV 的高可用体系构建了跨地域、跨中心的灾备能力**。\n\n**HTAP 在金融场景的验证**\n\n传统金融企业在交易业务线、数据分析业务线的处理其实都会分开，多维查询和管理类分析业务倾向于用大数据业务处理，但随着自己的数字化转型逐步深入以及各种平台生态建设，所有的关键业务、核心业务都面临着新的挑战，这恰恰就是 HTAP 要解决的问题。这个场景用传统的大数据技术很难在数据实时更新场景下同时提供多维的分析和查询能力。在这个场景下，当时建信金科遇到非常大的挑战，留给 PingCAP 的时间非常短，从 4 月底提出到 5 月底验证，只有一个月的时间。去年 10 月正式投产进入稳定的迭代。现在，建信金科每个新的场景都会有 TiDB 的身影。\n\n**当前，建信金科正在尝试将系统升级到最新的 TiDB 6.1 版本。同时，也在将更多的统一视图、全量资产、反洗钱业务在 HTAP 上做验证和迁移**。未来，建信金科与 PingCAP 将进行联合技术创新攻关，在金融场景下更大规模业务模式的创新以及未来数据库如何更好的适应云计算趋势等方面进行更多探索。\n\n回顾来看，为什么 PingCAP 能够在众多分布式数据库厂商中受到建信金科的持续关注？主要有三点：  \n\n**第一，服务于客户成功**。数据库是一个服务于应用的产品，只有关注客户的成功，关注客户遇到的实际问题，才能够赢得更好的发展；  \n\n**第二，PingCAP 的开放性**。PingCAP 从出生开始就一直以开源开放的特征存在于数据库行业，正是这一点使得建信金科更倾向于选择它，相信开源和开放的力量会成为未来企业技术重要的组成部分；  \n\n**第三，成长性**。所有的技术不能光看它在当前已经取得的成就，以及当前表现出来的状态，更重要的是关注它的成长性。技术从当前的里程碑到下一个里程碑，加速度是不是足够快，如果有更快的加速度，现在所有存在的困难和差距都会在短时间内得到突破。与 PingCAP 一起，与优秀的开发者和专家一起，将取得更大的成长。\n\n### 百胜中国：拥抱开源，加速创新\n\n百胜中国首席技术官张雷分享到，百胜中国是中国最大的餐饮企业，致力于成为全球最创新的餐饮先锋。百胜中国获受肯德基、必胜客和塔可贝尔在中国内地的独家运营和授权经营权，并完全拥有小肥羊、黄记煌和 COFFii & JOY 餐饮品牌，也和意大利咖啡企业 Lavazza 合作，在中国探索和发展 Lavazza 咖啡店品牌概念。截止 2022 年 6 月底，百胜中国在中国的足迹遍布除港、澳、台之外的所有省市自治区，在 1,700 多座城镇，有 40 多万员工经营着 12,000 多家餐厅，全年客流量超 20 亿次。  \n\n2021 年，百胜中国正式启用了位于上海、南京、西安三地的数字化研发中心，这是公司打造一个充满活力的数字化生态系统的重要里程碑。由数字化研发中心、合资公司以及第三方合作伙伴组成的多层次研发体系，为公司品牌和业务进一步创新发展，加速扩张，抓住市场机遇奠定了坚实的基础。**在数字化不断发展的今天，打造敏捷高效的数字化能力，成为了餐饮企业的立身之本**。  \n\n百胜中国在业内率先推出了手机点餐业务，在全国范围门店推出了数字支付，疫情期间也落地了大规模的无接触配送，百胜中国不仅持续地完善从线上点餐、外卖到会员计划、礼品卡等消费者场景，同时在餐厅内也构建了百胜自主研发的点餐和收银系统，持续打造餐饮业领先的端到端的数字化生态。  \n\n截止 2022 年 6 月底，百胜中国的线上会员数量超过了 3.85 亿，2022 年第二季度，数字化订单占比达到了 89%，会员营销额也约占到了系统销售额的 62%。百胜中国也不断利用数字化能力赋能门店运营，例如基于数据和 AI 能力，构建了餐饮行业特有的营运大脑以及口袋经理，为门店运营效能的提升提供了数据以及系统支撑。同时也聚焦自动化、IoT 及智能餐厅等领域，基于当前不断蓬勃发展的大数据、云计算等基础能力，借助于百胜中国自己的研发中心、合资公司以及第三方合作伙伴，共同为百胜中国两万家餐厅的目标夯实牢固的数字化基础。  \n\n**百胜的生态环境中拥有丰富的应用场景，让各种技术能力有生根落地的机会**。同时随着企业数字化转型进入了深水区，对于数字化基础设施的自主可控性和灵活性的要求也进一步在提升。开源软件起到了越来越重要的作用，成为企业创新实践的催化剂。  \n\n![百胜中国.png](https://img1.www.pingcap.com/prod/_4cdb5f9900.png)\n\n基于开源基础软件体系，可以提升企业 IT 技术的标准化；活跃的开源社区，也可以有效帮助企业降低试错成本。当企业投入一定的资源协助开源社区建设时，能够同步提升自主的技术品牌和技术人才的能力以及影响力。TiDB 是业内开源分布式数据库的翘楚，百胜中国在 2019 年就开始了前期研究，以尝试替代传统的商业数据库产品。**百胜中国非常看重核心数据的处理主权，开源数据库恰恰能够帮助掌握这一主权，同时借助活跃的开源社区，进行企业内部创新性的架构研究以及落地**。  \n\n**经过大概一年的探索，TiDB 最终在百胜的业务中台，例如消息中台、用户中台以及支付中台中得以落地实施，用于支撑百胜中国的线上交易**。TiDB 对于百胜中国的海量数据提供了稳定可靠的系统支持。众所周知，由于餐饮行业存在着明显的高低峰场景，目前像肯德基“疯狂星期四”，它的交易量是远超平常的，TiDB 的灵活水平扩展能力，使得百胜中国可以根据业务的需求进行计算资源实时调整，助力降本增效。  \n\n同时，在社群营销、ERP 报表等典型分析场景中 TiDB 的 HTAP 特性，也使得百胜中国可以以较小的代价进行海量数据的在线融合分析，以实现敏捷的业务支撑，百胜中国将 ERP 中的交易数据同步到 TiDB 中，再与 BI 工具进行集成，大幅缩短了企业内部的财务报表生成时间，极大提升了内部的工作效率。随着云原生和开源技术的持续发展，百胜中国不断加强各种新型开源技术的深度探索、应用以及融合，从而更有力地推动餐饮垂直行业云能力以及自我创新的发展。  \n\n![分布式数据库联合实验室.png](https://img1.www.pingcap.com/prod/_55e5ecc5a8.png)\n\n本次峰会中，**PingCAP 与百胜中国强强联合，成立“百胜中国 ✖️ PingCAP 分布式数据库联合实验室”**。联合实验室立足于双方的技术和生态优势，共同探索前瞻技术的创新和落地实践，提升餐饮行业的数字化服务水平和能力。  \n\n![数字生活 24 小时.png](https://img1.www.pingcap.com/prod/24_8ab85a9704.png)\n\n其实不只是建信金科与百胜中国，今天 TiDB 已经支撑了很多人一天 24 小时各种各样的生活需求，融入了人们的日常生活中。  \n\n![业务敏捷.png](https://img1.www.pingcap.com/prod/_ec97814792.png)\n\n在软件领域有一句经典的话，“Make it work, make it right, make it fast”，TiDB 今天就在 make it fast 的阶段。随着 TiDB 架构本身的分离做得越来越好，TiDB 架构的正确性会让性能提升和改进非常惊人。一个正确的内核才有成长的可能和更高的成长性。在过去一年的时间里，PingCAP 在核心场景 OLTP 领域获得了显著的性能提升。\n\n## 新物种：聊聊 HTAP\n\n![新物种 HTAP.png](https://img1.www.pingcap.com/prod/HTAP_9d37dafa2a.png)\n\n我在和客户聊的时候发现，HTAP 是一个很难讲明白的技术，它和 Hadoop 有什么区别？原来的大数据非常重，像是一只大象，相较之下 OLTP 数据库就像一条蛇，很灵活很快速，它不是加法，而是融合，是一个全新的物种。  \n\n但关于 HTAP 的挑战并没有解决，到底什么叫 HTAP？有没有一个例子能让用户一下子明白？TiDB 能干什么别人干不了的事吗？我们做了一个 DEMO，试图在 5 分钟内讲明白到底什么是 HTAP，到底 HTAP 能带来什么样的价值。\n\n![OSS Insight demo 简介.mp4](https://img1.www.pingcap.com/prod/OSS_Insight_demo_11f2a32fab.mp4)\n  \n\n一个好的 DEMO 应该具备什么特点？第一得好看，第二得好用，我们的 DEMO 除了好看、好用，还得好玩。这个 DEMO 所有数据都是真实的，并且一秒就能体验。我们也希望将这个 DEMO 开源出来分享给其他伙伴，这也非常符合 PingCAP 开源的理念。\n\n![OSS Insight 价值启发.png](https://img1.www.pingcap.com/prod/OSS_Insight_45d7bdad71.png)\n\n有一位用户曾经问我们 “用 HTAP 前后有什么差别？”，有一个非常直观的体验：OSS Insight 第一版只用了两个人，一个周末就做出来了。如果是传统方案，通常要用 4-6 个人，花半年时间。  \n\n![Insight.jpeg](https://img1.www.pingcap.com/prod/Insight_ddd6ff75b5.jpeg)\n\n这个事情给了我们另外一个启发，**每个人都有好奇心，每个人都有自己洞察的视角，每个好奇的灵魂都值得用 Insight 去激发**。这之前，我们只能看非常冰冷的 TPCC、TPCH 等和业务看起来一点关系都没有的东西，对新一代程序员来说这简直是上古语言。产品的价值能不能和用户的挑战结合起来？业务创新的敏捷性又依赖于数据敏捷。  \n\n最近一段时间脱口秀比较火，人人都能说 5 分钟的脱口秀。通过 OSS Insight ，我们可以让人人都能在 5 秒钟内获得 Insight 。我们设想每一个组织、每一个企业、每一个人都可以获得这个能力，都有这个好奇心去获取 Insight，像我们 700 人的企业就有 700 个脑袋。OSS Insight 中都是开源数据，任何一个人去看都能提出自己的 idea。  \n\n通常情况下，用户接下来的问题会是：到底有什么场景不是你的舒适区？我们根据所有线上用户真实的情况，画了下面这张图，大致描述了 TiDB 的舒适区到底在哪里。  \n\n![TiDB的数据敏捷区间.png](https://img1.www.pingcap.com/prod/Ti_DB_25b538382e.png)\n\n\n### HTAP 已死？\n\n在我们和用户聊的时候，经常有用户说 HTAP 这个概念已经听了 8-9 年，为什么一直没有火？甚至以为 HTAP 已经死了。**如果按照它原来的定义，HTAP 确实已经死了**。  \n\nHTAP 原来的形态基于两个基础假设：一个是内存即硬盘。十年前，“内存是新一代的磁盘”这一说法被炒得火热，如果真是这样，每台机器上现在都可以拥有 1 PB 以上的内存。但现在大家看到内存依然很贵，这意味着当时 HTAP 的第一个假设，内存足够大足够便宜，被证明是不现实的；另外一个是摩尔定律，过去当 CPU 高速发展的时候，我们对摩尔定律充满期待，而显然过去十年 CPU 发展速度让我们很失望，所以当时的两个基础到今天都不存在了。  \n\n但有一句话说得好， “科学的每一次进步都是在葬礼上取得的”；**上一个 HTAP 已经死了，为什么 PingCAP 还在坚持 HTAP ？最近 HTAP 又很火的样子，这是为什么呢**？  \n\n实际上，关于足够大的内存和硬盘，足够多的 CPU 和算力，如今都可以通过云的方式来得到，在云上你可以拥有近乎无限的内存。今天用户的使用习惯也产生了改变，用户希望在一个系统里面能存储足够多的数据，足够快地处理事务。所以，**一个强大的 OLTP 能力是 HTAP 的基础，但凡不具备这个基础就不能称之为 HTAP**。  \n\n![HTAP 重生.png](https://img1.www.pingcap.com/prod/HTAP_7fe55562d3.png)\n\n**在这个背景下，HTAP 重生了**。过去一年里， MySQL 发布了 HeatWave 作为 MySQL 的 HTAP 解决方案，Google 也在今年发布了 AlloyDB ，不久前 Snowflake 也发布了它的 HTAP 引擎 Unistore。  \n\n![HTAP 特性.png](https://img1.www.pingcap.com/prod/HTAP_14cf0a5239.png)\n\n**我们认为 HTAP 带给用户的体验就是简单 + 实时，同时还要求整个系统具备非常强的隔离性**。共享一份资源会面临较大挑战，因为它会吃掉大量的 OLTP 资源，所以物理隔离是 HTAP 的基础。TiDB 的架构很直接地展示了这个能力，当我们完全是物理隔离的时候，TiDB 的执行计划会很智能地从 OLTP 中选择这部分数据。TiDB 在过去发展过程中，最早是作为一个业务数据库在用，随着里面数据越来越多，一定程度上它就变成了一个实时数据服务层。各种各样的业务系统开始把 TiDB 作为中间层提供彼此交互的能力，比如 CRM 不能和 ERP 直接对话，但通过 TiDB 把数据聚集在一起，它们就可以直接对话了。  \n\n![TiDB 典型应用场景.png](https://img1.www.pingcap.com/prod/Ti_DB_2711011985.png)\n\n\n## 持续引领数据服务的敏捷性\n\n![持续引领.png](https://img1.www.pingcap.com/prod/_a47b16f178.png)\n\nTiDB 在持续引领数据库的演进方向，我们相信在接下来 2-3 年的时间里，会有越来越多的数据库加入这个队伍，朝着共同的方向去迭代和演进。  \n\n![DB 微服务化.png](https://img1.www.pingcap.com/prod/DB_8a0c4a6007.png)\n\n**未来的方向一定是数据库微服务化**。这表面看起来有点奇怪，为什么数据库要微服务化？微服务和数据库有什么关系？我们认为，今天的数据库不仅仅是数据库的一个内核，它已经是一套复杂系统，前面提到的掌控复杂性的方法只有一个，那就是分而治之。  \n\n**微服务化本质上会达到一个效果，让规模化效应开始掌控一切，最后带来的结果和用户的价值，可以大幅压低用户使用成本**。目前，TiDB Cloud 在过去一年中通过持续孵化改造，成本已经降到了原来的 1/10。一个很简单的例子，今天每一个数据库都有一个能力叫 GC，如果每一台服务器都去配这样一个能力，要么压力大的时候不够用，要么完全浪费了，但是这个功能又不得不配上。比较好的办法是让这个 GC 也能够规模化，使它本身变成微服务。数据压缩、持续后台优化都是这样，我们不能用原来的系统资源去做，用户希望花钱买的每一份计算资源都是为他服务，而不是用 1/3 来做后台服务。\n\n## 连接中国与世界\n\n**在全球，TiDB 一直发挥着连接中国和全世界的作用**。为什么那么多的用户、合作伙伴会选择我们？开源、云中立以及全球合规，就是 TiDB 起到的连接作用。\n\n![应用场景连接中国与世界.png](https://img1.www.pingcap.com/prod/_7113459090.png)\n\n同时，PingCAP 有大量的应用场景也是连接全球的，上图可以看到今天 TiDB 已经被用到了全球各行各业。每一个场景里都有中国的用户，也有来自美国、日本、新加坡、欧洲和印度的用户。  \n\n基于中国全球领先的场景，基于开源非常高效透明的传播与协作模式，基于开源汇聚全球的智慧，最终使得 PingCAP 得到全球更多的客户与合作伙伴的信任。  \n\n### 用户分享：传音携手 PingCAP 打造全新数字化非洲土壤\n\n传音控股是一家致力于成为新兴市场消费者最喜爱的智能终端产品和移动互联服务提供商，在与 PingCAP 的合作中，将其移动商店的整体服务架构迁移到了 TiDB 上。传音控股移动互联 CTO 史团委表示，**PingCAP 使得传音控股可以将更多资源投入在业务的推进上，从中后台工作中解放出来，大幅降低成本**。TiDB 的水平扩展、故障自恢复、数据强一致性、高度兼容性等特点，帮助传音控股实现了技术进阶，提升了用户体验，加速了技术架构平台化与垂直化的演进。\n\n![传音移动互联.png](https://img1.www.pingcap.com/prod/_79a61abd29.png)\n\n### 用户分享：老虎国际 - 只有真正的全球化公司 才能服务全球化客户\n\n老虎国际作为全球知名的国际化券商，在新加坡、美国、中国香港、澳大利亚等地持有 59 张牌照或资质，在全球多地开展业务。老虎国际技术副总裁柳锴表示，只有真正的全球化公司才能服务全球化客户。基于全球化的业务，老虎国际的数据架构、数据安全等也面临着全球化的挑战。**TiDB 可以解决系统架构的复杂度，同时通过低延迟、数据强一致性，解决业务挑战与数据安全挑战**。  \n\n![老虎国际.png](https://img1.www.pingcap.com/prod/_47275021c8.png)\n\n## 技术人如何创造社会价值？\n\n作为一个技术人员，我们一直在想一个问题，**作为一家企业怎么创造社会价值，怎么做更多的贡献**？PingCAP 最早从开源起家，把所有一切能开源的东西都开源了，开源始终融在我们的基因里。  \n\n作为数据库从业人员，作为数据库的开发者，我记得上大学时还没有一个非常好的数据库教程。那时数据库依然没有办法做到足够的平民化，并不是每一个人、每一个开发者都能拥有一个永远在线的数据库。所以当时我就有一个想法，以后一定要让数据库变得触手可及，让每个人都可以拥有自己的数据库。为了让 TiDB 触手可及，我们做了很多事情，推出了自己的 Talent Plan，与 VLDB 合作，所有的一切都是希望让数据库变得触手可及。同时这也帮我们带来了非常繁荣、多样化的社区， 目前已有 1,895 位 Contributor，覆盖 45 个国家与地区。  \n\n![TiDB让开发者触手可及.png](https://img1.www.pingcap.com/prod/Ti_DB_44c8aff85e.png)\n\n说到触手可及，最要紧的一件事情就是成本。随着 TiDB 的新一代分布式架构和规模化效应，今天我们终于能够让每一个开发者都可以拥有一个永远在线的免费的数据库，我们可以随时去体验这个数据库，这就是新的架构带来的成本优势。  \n\n![与开源同行.jpeg](https://img1.www.pingcap.com/prod/_3f21f3105e.jpeg)\n\n在过去的 7 年中，PingCAP 一路走来磕磕绊绊，我一直在想能不能把这些经验教训也都开源出来？今天我们非常高兴地宣布，经过半年多的集体创作，我们将过去 7 年的那些经历、经验和教训，也开源出来，首发《与开源同行》这本书，希望大家喜欢，继续与 PingCAP 同行。  \n\n最后，[TiDB Hackathon](https://tidb.net/events/hackathon2022?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-keynote) 是我最期待的一年一度的技术盛会，也期待你的加入。  \n\n![Hackathon 2022.jpeg](https://img1.www.pingcap.com/prod/Hackathon_2022_d7a6299f4a.jpeg)\n","author":"刘奇","category":5,"customUrl":"the-future-is-now-by-max-liu","fillInMethod":"writeDirectly","id":420,"summary":"9 月 22 日 PingCAP 用户峰会上，PingCAP 创始人兼 CEO 刘奇和来自建信金科、百胜中国、传音控股、老虎国际的用户共同分享了 PingCAP 在技术演进、用户价值、数据库技术趋势、国际化、社会价值等方面的思考与实践。","tags":["TiDB"],"title":"刘奇：能否掌控复杂性，决定着分布式数据库的生死存亡"}},{"relatedBlog":{"body":"在刚刚结束的「 PingCAP 用户峰会」中，PingCAP 研发副总裁唐刘、PingCAP 中国区技术服务总经理李超群从 PingCAP 的**自主开源、工程研发体系、产品未来技术演进方向等方面，分享了 PingCAP 如何通过产品研发和服务体系将产品价值“又快又稳”地交付给客户，获得客户的信任，并帮助客户实现成功**。以下为分享实录。\n\n![唐刘.jpeg](https://img1.www.pingcap.com/prod/_21a492c193.jpeg)\n\n服务对于数据库公司来说是一个沉甸甸的词汇。对于产研团队来说，只有做出产品，并把产品交付客户，才会有后面的服务。但 PingCAP 作为一家非常年轻的公司，所做的是一个非常有挑战性的数据库产品，如何让客户选择相信 PingCAP？如何让客户放心地将他们的数据存放到 TiDB 数据库？\n图片\n\n## “透明”建立信任\n\n开源是 PingCAP 的基因，PingCAP 从一开始就将源代码开放出来，让所有人都能看到 TiDB 到底是什么样子。但仅仅只有代码的开源是远远不够的，经过 7 年多的发展，**我们深知开源有着不同的阶段**。当把源代码开放后，客户和用户就能够自行下载 TiDB 源代码进行编译，发布到自己的生产环境中，服务于自己的客户；当他们遇到问题时，可以选择自己修复 bug，或与 PingCAP 一起探索，共同完善 TiDB 功能；有一些用户、企业甚至将 TiDB 作为自己的上游版本，通过 TiDB 构建自己的发行版，服务于客户。我们也希望能有越来越多的用户构建自己的 TiDB 发行版创造更多价值。  \n\n面对不确定的经济环境，我们如何从当前的复杂环境中生存下来？**开源是建立信任的最佳途径，但只有开源也是远远不够的，PingCAP 认为唯有透明才能解决问题，透明一切能透明的事情**。为什么透明对 PingCAP 和用户都如此重要？一方面，PingCAP 到目前为止有 3000 家用户、 1800 多位开发者分布在全球 45 个国家和地区，同时 PingCAP 内部有 300 多位研发工程师。PingCAP 和开发者、用户之间形成了一个非常多元的网状结构。所以我们开源了源代码、设计文档。  \n\n为了更加透明，我们还将 TiDB 未来 1-3 个月的产品路线图开放，让大家了解 TiDB 即将发布的功能。有一些朋友可能会问：你们把所有东西都开源，都透明了，友商看到会有什么动作？其实比起担心这个问题，**我们更希望让客户清楚地了解 PingCAP 到底在做什么以及 TiDB 未来的方向，并因此更加相信 PingCAP，共同走向未来**。\n\n## 让客户“又快又稳”感知到产品的价值\n\n作为一家做数据库产品的公司，仅仅只有开源与透明也是不够的，如果 TiDB 不能给客户带来价值，如果客户不能使用 TiDB，其实就建立不了任何信任，我们需要让客户又快又稳地感受到 TiDB  的价值。PingCAP 是一家非常年轻的公司，一方面产品需要快速地迭代，不断将产品价值快速交付客户；另一方面，面对许多核心场景，我们需要打磨一个更加稳定的产品，让客户非常高效非常放心地使用。所以， **PingCAP 采用了一个“稳态+敏态”双轨并行的研发机制，保证产品更新对用户触手可及，同时在核心场景也能稳定放心的使用**。\n\n![又快又稳感知产品的价值.png](https://img1.www.pingcap.com/prod/_134ef9fa8b.png)\n\n那么，PingCAP 是如何实现“稳态+敏态”双轨并行的研发机制呢？  \n\n- 一是开放式架构，分离一切能分离的，从物理上保证隔离性；\n- 二是 TiDB 有着非常丰富的应用场景，用户在 TiDB 社区持续参与产品共创。\n\n下面通过几个小例子讲讲 PingCAP 如何与客户进行共创：  \n\n第一个例子是中通快递。快递物流行业在双十一或者 618 时面临的挑战是非常巨大的，中通快递实时数据业务需要将全国 3 万多网点产生的实时物流信息写入到数据库中，然后动态分析业务状况。双十一等物流高峰期间，日写入 / 更新流量超 30 亿条，分析库总量在百亿级。中通快递很早就拥抱了 HTAP ，通过实际业务场景的打磨，**TiDB 帮助中通快递抗住了双十一的流量高峰，HTAP 分析引擎配合分区表动态裁剪的高效数据过滤，支持了中通快递双十一 20 多个报表系统秒级查询**。通过业务场景的深入应用，中通快递将 HTAP 读写混合的极限负载能力提升了 100% 以上。\n\n![中通快递案例.png](https://img1.www.pingcap.com/prod/_46d41fcb8e.png)\n\n第二个例子是 [OSS Insight](https://ossinsight.io)。这是一个非常有代表性的业务场景，首先它是一个从 0 到 1 快速打造的产品，适合当前很多公司的敏态业务。这个产品的主要产品经理就是我们的 CEO 刘奇，需求天天变，今天提的需求明天就要交付，对于研发工程师来说是非常大的压力和挑战。但 OSS Insight 有将近 50 亿条数据，很多查询条件非常复杂，面对这样高度复杂的情况，一方面要实现快速迭代，另一方面还要保证查询稳定高效运行。之前我们通过加很多 HINT 的方式来保证查询计划的稳定，但当业务不断变化时会增加很多索引，调整 DDL ，导致之前的 HINT 失效，为了解决这样的问题我们和 OSS Insight 研发工程师一起，不停打磨重构 TiDB 的优化器，现在不光研发工程师不再需要写 HINT ，我们发现 TiDB 的智能优化水平比人工写 HINT 提速了 20-30%。\n\n![OSS Insight 案例.png](https://img1.www.pingcap.com/prod/OSS_Insight_2b438696c0.png)\n\n第三个例子是某头部股份制银行。该行一直坚信 TiDB 能应用到银行核心系统上，与 PingCAP 协力持续打磨 TiDB 的内核能力，在 7×24 小时性能测试过程中，将整个延迟抖动控制在 2% 以内。在互联网交易系统上，更将整个延迟缩短了 4 倍，满足了互联网业务线上交易的核心述求。\n\n![银行案例.png](https://img1.www.pingcap.com/prod/_10de7b9511.png)\n\n## 平滑升级，让客户又快又稳地感知到产品价值\n\n由于 TiDB 不断打磨，快速发布新版本，许多用户会面临一个非常大的选择问题：新产品是非常好，但我的数据库跑得好好的，为什么要升级？数据库在企业数字化系统中是非常核心的组件，版本升级往往面临着着很大的风险，能不能不升级？  \n\n我们的答案是，要升级：**一方面客户通过升级到最新版本，在延迟和性能方面都得到了大幅提升，同时也更有信心将注意力聚焦于自己的业务逻辑开发上**，另一方面，PingCAP 研发工程师与服务团队一起打造了一套完善的数据库升级体系，支持客户的平滑升级。  \n\n在技术、产品之外，PingCAP 还在产研内部专门成立了保障企业级客户成功的组织，比如金融架构师团队。它由 PingCAP 的资深架构师组成，致力于重要金融客户的共创、功能研发和项目支持。\n\n## 未来，与客户持续户共创，携手成长\n\n**很多企业级客户选择 TiDB 的理由，就在于它的可生长性**。未来， TiDB 仍然会在这方面不断地努力。首先，我们会聚焦于 TiDB 的内核，不断打磨。我们相信，无论怎么生长，如果没有坚固的底座是不可能向外更好生长的。在这个基础之上，TiDB 会在 DB 微服务化、云原生、智能化上不断拓展产品的边界和能力，与各种各样的生态结合，为客户提供更多价值。  \n\n这些年来，TiDB 一直持续不断地专注于 OLTP 核心能力提升，以银行交易核心为抓手，在优化系统、细粒度资源控制以及长尾延迟等各方面实现了突破，让 TiDB 变得更快更好用，在大表快速添加索引方面性能提升 10 倍， 在 Real-time HTAP 提速 1-2 倍。  \n\n![Serverless.png](https://img1.www.pingcap.com/prod/Serverless_8b1a211b76.png)\n\n**当前，无论国内还是在海外，云都是技术演化的未来**。而恰恰云能够将整个 PB 级别的数据库服务平台价值无限放大，未来 PingCAP 会提供一种全新的数据处理和访问形式—— Serverless。PingCAP 提供非常方便易用的 Data API，让企业级用户只需关注自己的业务，不用在意数据在哪里，底层长什么样。  \n\n**我们有一个梦想，当 TiDB 具备 Serverless 能力的时候，每个开发者都可以拥有自己的数据服务**。这个数据服务能做到秒级别的创建速度，亚秒级别的唤醒启动，毫秒级别的访问延迟。当一个数据库具备这样能力时，对于用户的价值其实是非常大的。一方面，所有开发者都拥有数据库，关于 TiDB 人才培养再也不需要担心；另一方面，用户只需要关注于自己的业务逻辑开发，以及如何更快将业务推向市场。  \n\n![TiDB 技术方向战略清单.png](https://img1.www.pingcap.com/prod/Ti_DB_d3e1c1bca5.png)\n\n上图是 TiDB 整个产品的技术演进方向，包含 TiDB 内核、DB 微服务化、云原生、智能化以及生态。在智能化方面，TiDB 在不断打磨自动诊断服务 Clinic ，通过自动诊断服务可以让每个用户都拥有一个 TiDB 性能调优专家，让每个用户都可以更好地使用 TiDB 。\n\n## PingCAP 服务体系\n\n客户成功这件事，不仅仅是产品研发团队的事情，也是整个 PingCAP 公司一起努力的结果。PingCAP 中国区技术服务总经理李超群在用户峰会上分享了 PingCAP 服务体系。  \n\n目前为止， PingCAP 技术服务人员的总人数已经占到了公司总人数的 25% ，成为继产研之后的第二大团队。可以说，**PingCAP 既是一家产品型公司，也是一家服务型公司**。  \n\n![李超群.jpeg](https://img1.www.pingcap.com/prod/_7b7bb3b034.jpeg)\n\nPingCAP 服务体系包含三个方面——**订阅服务、专家服务和培训认证**：  \n\n**订阅服务**：过去一年，PingCAP 实现了用工单系统做客户技术服务，可以非常容易地跟踪工单进展；我们开通了产研直通渠道，客户如有紧急问题可以第一时间拉通产研；第三，基于庞大的社区，我们把社区以及工单里的所有问题都整理出来，建立了 TiDB 知识库，在今年 12 月份会向所有企业客户开放。\n\n![订阅服务.png](https://img1.www.pingcap.com/prod/_1245be8752.png)\n\n**专家服务**：PingCAP 按照应用构建的全生命周期构建了一张服务体系大图。TiDB 所面对的场景和遇到的挑战与其他数据库有所不同，有数据库替换场景，有大数据替换场景，如何帮助客户在这些场景里用好 TiDB ，是 PingCAP 首要解决的问题。所以 PingCAP 推出了架构咨询服务，我们希望帮助客户做真正的场景调研，做可行性分析与架构设计。专家服务除了要有体系，还依赖于真正的经验积累。我们通过一套服务标准化的流程，把所有的实践，所有的经验汇聚起来变成一套可以复用的资产和工具体系。\n\n![专家服务.png](https://img1.www.pingcap.com/prod/_4889c13d83.png)\n\n**培训认证**：TiDB 的培训认证体系进行了全新升级。我们把初级课程的门槛降低，让更多人可以接触到 TiDB ，同时把高级课程变得多路并行，除了以前的数据库管理方向，还添加了性能调优、数据迁移、故障排查和运营管理方向。\n\n![DBA 培训.png](https://img1.www.pingcap.com/prod/DBA_98c68686fb.png)\n\n此外，今年 PingCAP 还推出了**专门针对应用开发者的培训认证**，帮助应用开发者用好其实能让 TiDB 跑得更快也更稳定，这门课程已经正式向所有商业客户和合作伙伴开放。\n\n![开发者培训.png](https://img1.www.pingcap.com/prod/_90a1e21c71.png)\n\n最后，回到本文的主题，**PingCAP 为什么能够服务好企业级用户**？答案并不复杂：PingCAP 以开源为基础，与客户建立了牢固的信任体系；与此同时，PingCAP 持续引领技术趋势，打造面向未来的数据库产品；最关键的一点，PingCAP 从开始到现在，始终保持以客户成功为核心的企业文化，从产品研发到技术服务，与用户共同面对不确定性的挑战。","author":"唐刘","category":5,"customUrl":"transparency-is-the-best-way-to-build-trust-with-our-customers","fillInMethod":"writeDirectly","id":428,"summary":"PingCAP 研发副总裁唐刘、PingCAP 中国区技术服务总经理李超群分享了 PingCAP 如何通过产品研发和服务体系将产品价值“又快又稳”地交付给客户，获得客户的信任，并帮助客户实现成功。","tags":["TiDB"],"title":"唐刘：透明一切，是我们在复杂环境下与客户建立信任的最佳途径"}}]},{"id":"Blogs_415","title":"TiDB v6.2 发版","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB v6.2 于 8 月 23 日发布。在全新的版本中，TiDB 提供了诸多方面的提升，主要集中于：可观测性、性能、稳定性、数据生态加强以及 MySQL 兼容几个领域。","body":"![TiDB V6.2.png](https://img1.www.pingcap.com/prod/Ti_DB_V6_2_198a364daf.png)\n\nTiDB v6.2 于 8 月 23 日发布了。在全新的版本中，TiDB 提供了诸多方面的提升，它们主要集中于：**可观测性、性能、稳定性、数据生态加强以及 MySQL 兼容**几个领域。\n\n## 可观测性\n\n在新版本中，TiDB Dashboard 支持了可视化执行计划。以往 TiDB 用只能借助观察文字输出的执行计划排查问题，这对于简单的交易类 SQL 而言问题并不大，但分析型 SQL 很可能会产生庞大的执行计划信息，造成用户难以观察分析。在新版本中，TiDB Dashboard 在 Statements 和 Slow Query 中提供可视化执行计划和基础问题诊断的能力。这是一种全新的查询计划的展示方式，目标是通过图形化的手段展示 Query 查询计划的每个步骤，从而使得用户能够更加直观方便地了解查询执行计划的细节。对于复杂的大型查询语句，可视化的展示方式对于深入理解其执行过程大有裨益。\n\n![1.gif](https://img1.www.pingcap.com/prod/1_889dd1b71c.gif)\n\n在这个版本中，TiDB Dashboard 也新增的 Monitoring 页面，展示了在业务性能调优中所需的核心指标，使得用户大部分的日常运维监控需求可以在这里完成，无需在 Grafana 和 Dashboard 间跳转。\n\n![2.gif](https://img1.www.pingcap.com/prod/2_7f81a629f8.gif)\n\n除此之外，新版本中 TiDB 锁视图支持乐观事务被阻塞的信息。大量锁冲突往往会造成严重的性能问题，而锁冲突定位是这类性能问题排查的必要手段之一。TiDB v6.2.0 之前版本支持通过系统视图 `INFORMATION_SCHEMA.DATA_LOCK_WAITS` 查看锁冲突关系，但是不支持乐观事务被悲观锁阻塞的情况。TiDB v6.2.0 扩展了 `DATA_LOCK_WAITS` 视图，提供乐观事务被悲观锁阻塞情况下的冲突关系，可以帮助用户快速定位锁冲突，同时为业务改进提供依据，从而减少这类锁冲突的发生频率，提升系统整体性能。\n\n## 性能\n\n在新版本中 TiDB HTAP 性能有进一步提升。\n\n首先，TiFlash 在 6.2.0 中引入了新的存储格式 PageStore V3。该格式大幅减轻了在高并发、高负载场景下 GC 造成 CPU 占用高的问题，可以有效减少后台任务 IO 流量，提升高并发、高负载下的稳定性。6.2.0 版本默认以新版本存储格式保存数据。\n\n在计算引擎方面，TiFlash 通过实现细粒度数据交换（shuffle）使窗口函数 （Window function） 可以利用多线程并行计算，成倍降低查询响应时间，使其在典型场景下可提速 4～5 倍。而在去重计算 COUNT(DISCINT) 中，分析引擎通过降低数据倾斜优化了计算效率。\n\n除了分析场景，新版本中引入新的 DDL 并行执行框架，在不同表对象上的 DDL 可以并发执行，解决了之前不同表之间 DDL 相互阻塞的问题。同时在不同表对象的追加索引、列类型变更等场景下支持并行执行，大幅提升执行效率。\n\n除了分析场景，新版本中引入新的 DDL 并行执行框架，在不同表对象上的 DDL 可以并发执行，解决了之前不同表之间 DDL 相互阻塞的问题。同时在不同表对象的追加索引、列类型变更等场景下支持并行执行，大幅提升执行效率。\n\n## 稳定性\n\n除了性能加强，V6.2 也包含了重要的稳定性加固。\n\nTiKV 在新版本中支持自适应调整 CPU 使用率。数据库通常会使用后台进程来执行一些内部操作，通过采集各种统计信息，帮助用户定位性能问题，生成更优的执行计划，从而提升数据库的稳定性和性能。然而如何平衡后台操作和前台操作的资源开销，在不影响用户日常数据库使用的基础上如何更高效地采集信息，一直是数据库领域最为头疼的问题之一。从 v6.2.0 开始，TiDB 支持通过 TiKV 配置文件设置后台请求的 CPU 使用率, 进而限制自动统计信息收集等后台操作在 TiKV 的 CPU 使用比例，避免极端情况下后台操作抢占对用户操作的资源，确保数据库稳定高效运行。同时 TiDB 还支持 CPU 使用率自动调节的功能, 这时 TiKV 会根据实例的 CPU 占用情况, 自适应地对后台请求占用的 CPU 资源进行动态调整。该功能默认关闭。\n\n而 TiFlash 则加固了在处理大量数据的场景。在新版本中，通过减少分布式事务处理的内存放大（memory amplification），TiFlash 大幅降低了内存消耗，相较于 v6.1 之前版本最好的情况下内存使用峰值可降低 50% 以上，从而减少了大规模分析场景下不同任务内存资源冲突问题出现的可能性。\n\n## 数据生态加强\n\n在新版本中，最重要的数据生态功能是支持 Point-in-Time Recovery (PiTR)。PiTR 指的是允许用户在新集群上恢复备份集群的历史任意时刻点的快照。从技术而言，PiTR 是基于变更日志和快照数据共同进行的数据备份和恢复。该功能可以满足以下的用户需求：\n\n- 降低备份恢复在灾备场景下的 RPO，如实现十几分钟的 RPO；\n- 用于处理业务数据写错的案例，如回滚业务数据到出错事件前；\n- 业务历史数据审计，满足行业合规的需求。\n\n针对数据导入场景，TiDB Lightning 优化并减小了导入对集群带来的性能影响。TiDB Lightning 原有的物理导入模式 (backend='local') 对目标集群影响较大，例如导入过程将停止 PD 调度等，因此仅适用于目标集群初次导入数据。新版本中，TiDB Lightning 在现有基础上做了改进，导入时影响范围由集群级别降低到表级别，即非导入的表仍可进行读写操作。\n\n除此之外，BR 现在已支持恢复用户和权限数据，这使得备份恢复体验变得更平滑，用户不再需要在集群恢复之后单独处理用户和权限信息。\n\n最后，TiCDC 加入了 DDL 过滤机制。自 v6.2 起，TiCDC 支持过滤指定类型的 DDL 事件，支持基于 SQL 表达式过滤 DML 事件，从而适应更多的数据同步场景。例如在一些特殊的场景下，用户可能希望对 TiDB 增量数据变更日志进行一定规则的过滤，例如过滤 Drop Table 等高风险 DDL。\n\n## MySQL 兼容\n\n在 MySQL 兼容的道路上，TiDB 在 v6.2 加入了 SAVEPOINT 机制以及单 `ALTER TABLE` 语句增删改多个列或索引。\n\n先说说 SAVEPOINT。事务是数据库保证 ACID 特性的一系列连续操作的逻辑集合。在一些复杂业务场景下，你可能需要管理一个事务的大量操作，有时候需要在事务内实现部分操作的回退能力。SAVEPOINT 就是针对事务内部实现的可命名保存点机制，通过这个机制，你可以灵活地控制事务内的回退节点，从而实现更复杂的事务管理能力，实现更为多样的业务设计。\n\n然后是 `ALTER TABLE` 操作多列和多索引。之前版本中，TiDB 仅支持单一 DDL 变更，导致用户在迁移异构数据库时经常会遇见 DDL 操作不兼容的情况，需要耗费额外的精力将复杂的 DDL 修改成 TiDB 支持的多个简单 DDL。同时还有一些用户依赖 ORM 框架，实现 SQL 组装，最终出现了 SQL 不兼容等问题。TiDB 从 v6.2.0 开始，支持使用 `ALTER TABLE` 语句修改一个表的多个模式对象，方便了用户 SQL 实现，也提升了产品易用性。\n\n查看 TiDB 6.2.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v6.2/release-6.2.0)，立即[下载试用](https://pingcap.com/zh/product-community)，开启 TiDB 6.2.0 企业级数据库之旅。\n\n","date":"2022-08-23","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-6.2-release","file":null,"relatedBlogs":[{"relatedBlog":{"body":"![TiDB 6.1.png](https://img1.www.pingcap.com/prod/Ti_DB_6_1_6eecaae325.png)\n\n我们很高兴向大家宣布，TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com/zh/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.1-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n## 长期支持版\n\n在两个月前发布 TiDB 6.0 版本时，我们提过在新发版流程中，我们引入了面向企业级用户的 LTS 版本的概念，与之相对的是开发里程碑版本（Development Milestone Release，简称 DMR）。引入这两种概念是为了让 TiDB 的发版节奏能兼顾快速变化的市场需求以及企业级用户对稳定性的要求。\n\n我们重新思考了发版模型，最后选择了长期支持版结合开发里程碑版的方式：我们保持 2 个月左右一次发版的节奏，以期快速应对市场节奏，但不再对所有发布进行长期维护，而是以半年左右为节奏拣选其中一个版本作为 LTS 长期支持版本。针对 LTS 版本我们提供针对问题的修复补丁而不再合并新功能。与此相对的，DMR 版本则保持快速发版的节奏，不断发布新特性，让用户所需的新需求不必等待很久（但并不提供基于 DMR 的问题修复）。对于用户而言，在没有特定需求开发的情况下，可以选择最新的 LTS 版本投产；如果需求某个 DMR 发布的新功能，则可以选择该版本进行 PoC 以及试运行，待到对应的 LTS 版本发布后升级 TiDB 到稳定生产状态。这样快慢结合的方式，可以最大限度兼顾快速迭代和稳定投产两方面的需求。\n\n对应 LTS 稳定版的主旨，6.1 版本中携带了重要的稳定性更新：\n\n1. 提升 TiKV 高压场景下的内存稳定性。\n2. 解决了由于 Raft Log 复制流量过大导致的 OOM 问题。\n3. 解决了在高压场景下宕机后重启过程中长时间持续反复 OOM 的问题。\n4. 完善了 TiDB Server 内存使用跟踪统计，加强查询内存使用配额限制。\n5. 优化了部分统计信息内存使用。\n\n另外，新版本也包含了 42 个问题修复和 20 个改进提升。\n\n## 是 LTS，也有新惊喜\n\nTiDB 6.1 除了作为第一个推荐企业级用户投产的 6 系版本，本身也携带了诸多强大的特性。\n\n### HTAP 基础能力提升\n\n在新版本中，部分分区表的实验特性 GA，且分析引擎加入了分区表和窗口函数支持。\n\n让我们先来看看分区表：我们在版本 5 中引入了 List 分区和动态裁剪特性，但一直保持实验特性状态。更重要的是，由于旧有的分区静态裁剪在 MPP 下表现欠佳，因此 TiFlash 引擎一直以来并未完整支持分区表特性。这次新发布中，我们宣布 List 分区 / 分区动态裁剪以及 MPP 模式下的分区表支持 GA。对于分区表本身在此无需过多赘述，各位可以参考官方文档，我们单独说下分析引擎下的分区表支持。\n\n对于列存引擎而言，由于并不支持类似行存的细粒度索引，仅仅依靠粗粒度索引并不能满足数据过滤需求。而分区表作为列存下最高效的数据过滤手段，是分析场景下需求优先级非常高的特性。例如在订单管理场景下，用户的数据天然可以将订单创建日期作为分区依据按天将一个月的数据分成 30 个分区，而用户的分析查询往往更高频查询最近一周甚至三五天的订单数据。在以往分析引擎不支持分区的情况下，TiDB MPP 只能进行全表扫描，这不但浪费了无谓的存储带宽，也会消耗 CPU 针对日期字段进行过滤。而在 6.1 版本中，对于上述例子，只要查询条件带有订单创建日，则可以数倍甚至数十倍提高查询效率。\n\n在 6.1 中另一个分析场景下常用的新功能是 MPP 下的窗口函数支持。在新版本中，MPP 执行器加入了对窗口函数的框架性支持，并随之推出了三个最常用窗口函数 rank，dense_rank 以及 row_number。这使得在 MPP 执行模式下，窗口函数除了内存消耗可以被分布式分担，性能也得到大幅提升。以 100G 规模数据集测试为例 ，新版本中查询使用单节点 MPP 模式进行窗口函数计算将提速 282%，使用更多节点将有更大幅度提速。与以往 MPP 模式下对内建函数的支持一样，我们将逐步增加对各类窗口函数的支持。\n\n新版本中，TiDB 引入了非事务性 DML 语句以应对大批量数据变更。新加入的非事务性 DML 将一个普通 DML 拆成多个 SQL 执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。典型的，在新版本中可以使用如下语句淘汰过期数据，而无需担心事务大小限制问题：\n\n`BATCH ON id LIMIT 2 DELETE FROM orders where create_date < '2022-05-01';`\n\n上述 SQL 将会以 2 批次的方式执行 DELETE 操作，以控制单次操作的内存占用。过往版本中，TiDB 仅支持非事务性删除。\n\n### 更完整的生态对接\n\n数据库从来都不是单独被使用的，而 TiDB 也在持续改进和生态环境的对接。在新版本中，TiDB 引入了用户级别锁和 TiCDC 下的 Avro 格式向 Kafka 同步数据的支持。\n\n先说用户级别锁。用户级别锁是 MySQL 通过内置函数提供的用户命名锁管理系统。它们可以用在 SQL 语句的 SQL 函数中，比如 select，where 子句，group by 子句等位置使用。这些语句可以在不同的代码处阻塞，等待，实现用户级别锁管理。用户级别锁在 ORM 框架中也有较为广泛的应用，例如 RoR, Elixir 和 Ecto 等。TiDB 从 6.1 版本开始支持兼容 MySQL 的用户级别锁管理，支持 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等锁管理函数，这使得 TiDB 得以更好支持现有 ORM 框架的生态。\n\n对 TiDB 而言，TiCDC 是集群数据实时变更信息的出口，而支持常用的数据格式以方便消费者解析则是降低开发复杂度的必修课。Avro 作为一种数据序列化系统，采用了压缩二进制格式，传输效率高，数据格式丰富，已经被大量的数据分析、数据集成产品所支持。TiCDC 支持将 TiDB 数据库的增量数据转换为 Avro 格式，并发送到 Kafka 的方式，这将使得 TiDB 数据库和众多的生态系统，例如：Kafka、Snowflake、SQL Server 链接起来。在新版本中，向其他系统实时同步 TiDB 的数据变化，无论是用于实时数据集成还是变更订阅触发操作，都可以借助 Avro 格式变得更简单。更进一步，一些仰赖 Avro 格式的其他生态功能，现在也得以发挥热量，例如用户可以借助 Avro 格式通过 Kafka kSQL 对变更日志进行实时计算。\n\n## 行动起来\n\n除了上述所有新功能外，其实 TiDB 6.1 作为 6 系版本的第一个推荐企业级用户投产的 LTS 版本，是所有需求 6.0 版本特性的用户的理想选择。无论你已经在使用 6.0 版本，还是正在调研中，都推荐大家部署 6.1 版本或升级。相信新版本将为广大用户提供强大的功能和稳定的体验。\n\n查看 TiDB 6.1.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.1.0)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.1.0 企业级云数据库之旅。\n\n\n\n\n","author":"PingCAP","category":2,"customUrl":"tidb-6.1-release","fillInMethod":"writeDirectly","id":395,"summary":"TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。","tags":["TiDB","Release"],"title":"TiDB 6.1 发版：LTS 版本来了"}},{"relatedBlog":{"body":"![TiDB 6.0.jpeg](https://img1.www.pingcap.com/prod/Ti_DB_6_0_67ed961868.jpeg)\n\n## 概览\n\n我们很高兴为大家带来 TiDB 最新版 6.0 的介绍。虽然是一个开源数据库，但 TiDB 的定位一直都是面向企业级和云的数据库，而 TiDB 6.0 也是围绕这个主题而研发的。在最新版本中，我们大幅度加强了作为企业级产品的可管理性，与此同时也加入了诸多云原生数据库所需的基础设施。\n\n对于企业级和云数据库，除了性能，可用性和功能等常规维度外，一个重要维度就是可管理性。除了提供必备的「硬」能力以完成用户的技术及业务目标，是否「好用」，是用户做选择时的重要考量，可管理性维度也会很深地影响用户实际使用数据库的隐性成本。而这点对于云数据库则更为明显，将数据库作为云服务提供，将使得可管理性的重要程度被放大：一个可运维性更好的数据库，在固定的运维和支持资源下，将为用户提供更好的服务。\n\n针对这个方向，TiDB 6.0 引入数据放置框架（Placement Rules In SQL），增加了企业级集群管理组件 TiDB Enterprise Manager ，开放了智能诊断服务 PingCAP Clinic 的预览，大幅加强了生态工具的可运维性，并针对热点问题为用户提供了更多的手段。这些努力加在一起，将使用户无论使用的是公有云服务，还是私有部署，都获得体验更平滑和近似的使用体验，让 TiDB 在成熟的企业级云数据库维度更向前迈进。\n\n除此之外，在这一年的时间内 TiDB 6.0 相较于前序版本也有了长足的进步，修复了 137 个 Issues，并融入了 77 个严苛的真实环境锤炼带来的增强。而社区一直期望的 [TiFlash 开源](https://github.com/pingcap/tiflash)也实现了，欢迎广大社区开发者一起参与。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com/zh/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.0-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n## 全面加强可管理性\n\n可管理性是数据库的一个重要能力维度：在满足业务需求的前提下，是否灵活易用，将决定了用户技术选择背后的隐性成本。这种成本可大可小，可以是一句抱怨，也可能会结合人因带来灾难性后果。在最新版本研发过程中，我们结合了客户和市场反馈，总结了当前的可管理性的问题仍存在的缺失，这包含了「复杂且不直观的集群的日常管理」、「无法控制数据的存储位置」、「数据生态套件难于使用」、「面对热点缺少解决方案」等多个维度，而 TiDB 6.0 从内核、数据生态套件、增强组件多个方面针对这些问题进行了加强。\n\n### 自主的数据调度框架\n\n让我们先从内核部分开始。\n\nTiDB 6.0 以 SQL 形式对用户暴露数据调度框架（Placement Rule In SQL）。以往，TiDB 的数据调度对于用户一直都是黑盒，TiDB 自行决定某一个数据块应该存在哪个节点，无论数据中心的物理边界和不同规格机器差异。这使得 TiDB 在多中心，冷热数据分离和大量写入所需的缓冲隔离等场景下无法提供灵活的应对。\n\n我们先看两个有趣的场景：\n\n1. 你有一个业务横跨多个城市，北京、上海和广州都设有数据中心。你希望将 TiDB 以跨中心的方式部署在这三个数据中心，分别覆盖华北、华东和华南的用户群，让不同区域的用户可以就近访问数据。在以往的版本中，用户的确可以跨中心的方式部署 TiDB 集群，但却无法如上述期望地将归属不同用户群的数据存放在不同的数据中心，只能任由 TiDB 按照热点和数据量均匀分布的逻辑将数据分散在不同中心。在高频访问的情况下，用户访问很可能会频繁跨越地域进而承受很高的延迟。\n\n2. 你希望用一组导入专用节点专门用于隔离导入数据所带来的性能抖动，而后再将导入完的数据迁回工作节点；或者你希望用一组低配节点存放冷数据，接受低频历史数据访问。暂时，还没有特别的手段支持这样的用况。\n\nTiDB 6.0 开放的数据调度框架提供了针对分区 / 表 / 库级数据在不同标签节点之间的自由放置接口，用户可以针对某张表、某个数据分区的存储位置做出自定义的选择。在新版本中，用户可以将一组节点给与标签，并为这组标签定义放置约束。例如你将所有位于纽约机房的 TiDB 存储节点定义放置策略：\n\n```\nCREATE PLACEMENT POLICY 'newyork' CONSTRAINTS = \"[+region=nyc]\";\n```\n\n然后将这个策略应用于表：\n\n```\nCREATE TABLE nyc_account (ID INT) PLACEMENT POLICY = 'newyork';\n```\n\n通过这种方式，所有 NYC_ACCOUNT 的数据将存放在纽约机房，而用户的数据访问请求也自然会被路由到本地机房。\n\n类似的，用户可以为机械磁盘节点打标签用以冷存和低频访问以节省成本，并将旧数据分区放置在低成本节点。\n\n```\nCREATE PLACEMENT POLICY storeonhdd CONSTRAINTS=\"[+disk=hdd]\";\nALTER TABLE orders PARTITION p0 PLACEMENT POLICY = 'storeonhdd'；\n```\n\n另外，该功能也可被用于多租户隔离场景。例如在同一集群中，用户可以将不同租户的数据经由放置规则分配到不同节点，而不同租户的负载也将自动由对应节点处理。这使得 TiDB 具备了租户隔离的能力，且辅以合理的权限设置，租户之间仍保有数据互访的可能。\n\n虽然是一个大型功能引入，但实际上这个框架的主体部分，已经通过 TiFlash 的行列分离能力于 4.0 版本间接发布给用户使用了，且经过了超过一年的迭代和打磨。因此，虽然是一个重大变更，但该框架却已经拥有了成熟的案例。本次发布将 Placement Rules 能力借以 SQL 的形式向用户全面开放，除了解决上述问题之外，也希望借助社区无限的想象力，发掘更多有价值的用法。\n\n### 热点场景应对\n\n分布式数据架构下，有一个恼人的话题：如何应对热点。在热点数据访问或锁冲突场景下，分布式数据库无法发挥多计算节点的性能优势，造成性能瓶颈，影响业务稳定和应用体验。TiDB 6.0 针对这类问题增加了多种解决方案。\n\n#### 小表缓存\n\n有时用户的业务同时涉及大表（例如订单）和若干小表（例如汇率表），其中大表的负载很容易通过分布式分担，但每次交易亦要访问的小表的数据却容易造成性能瓶颈。TiDB 6.0 新引入的小表缓存功能，支持显式将小的热点表缓存于内存中以大幅提高访问性能，提升吞吐，降低访问延迟，适用于高频访问低频更新的小表场景，例如配置表，汇率表等。\n\n#### 内存悲观锁\n\n通过将悲观锁事务缓存化，大幅降低悲观场景下的资源开销，CPU 和 IO 开销降低 20%左右，同时性能提升 5%-10% 左右。\n\n除了上述新增功能外，TiDB 未来还将提供基于负载的热点 region 自动分裂能力，提升热点数据的访问吞吐，解决非预期突发热点访问造成的性能问题。\n\n### 数据生态套件可管理性提升\n\n作为 TiDB 产品重要的一环，数据生态套件之于可管理性尤为重要。具体到数据迁移场景，当用户在对大规模的MySQL Sharding 系统进行迁移时，需要有很多的迁移任务、迁移规则、源端和目标端表相关的配置和管理工作。 在数据同步环境的日常管理过程中，经常需要对数据同步任务进行监控、诊断、创建、删除等管理操作。 命令行的操作在进行复杂运维操作，或者大量任务操作时，通常会效率很低，而且容易出错。由此，在新版本中，DM 推出了基于 Web 的图形管理工具，帮助用户更加方便的对整个数据迁移环境进行管理。它包含了如下功能：\n\n- Dashboard： 包含了 DM 中同步任务的主要监控信息和运行状态信息，帮助用户快速了解任务的整体运行状况，以及与延迟、性能相关的重要信息。\n- 数据迁移任务管理功能，帮助用户监控、创建、删除、配置复制任务。\n- 数据迁移上游管理功能，帮助用户管理数据迁移环境中的上游配置，包含了，新增、删除上游配置、监控上游配置对应的同步任务状态、修改上游配置等相关的管理功能。\n- 迁移任务详细信息管理功能，根据用户指定的筛选条件查看同步任务的具体配置和状态信息，包括，上下游配置信息，上下游数据库名称、表名称等。\n- 集群成员信息管理功能，帮助用户查看当前 DM 集群的配置信息和各个 worker 的状态信息。\n\n![1.png](https://img1.www.pingcap.com/prod/1_3e5c53fbc3.png)\n\n### 全新的管理平台和智能诊断套件\n\n#### TiEM 管理平台\n\n从最初版本至今，TiDB 的日常运维都是以命令行操控为主。虽然 TiDB 从 4.0 开始推出 TiUP 工具对 TiDB 集群进行安装部署和运维操作，降低了管理复杂度，然而它终究是命令行工具，学习成本较高，对相当多的企业用户而言，并不合意。除此之外，我们也经常遇到用户同时管理多个业务的多套集群，且配置和规格各不相同，任何集群变更和监控都是一个很大的挑战。一个无心的疏忽登录了错误的管理节点，应用了错误的变更，就可能带来无法挽回的损失。我们曾经遇到过仅仅因为切错命令行分页，而将生产集群当做测试集群关闭的惨况。现下诸多企业级数据库都拥有图形化管理界面，而 TiDB 6.0 中，也引入了 TiEM（TiDB Enterprise Manager）。\n\n![2.png](https://img1.www.pingcap.com/prod/2_2a7eeabc8b.png)\n\n在当前版本中，TiEM 集成了资源管理，多集群管理，参数组管理，数据的导入导出，系统监控等诸多功能。用户可以通过 TiEM 在同一界面管理多套集群，扩缩容，数据备份恢复，统一参数变更，版本升级，主备集群切换等。TiEM 还内置了监控和日志管理，让集群巡检变得轻松高效，不再需要在多套工具和监控之间不断切换。通过 TiEM 的管理平台，除了方便的统一界面进行多集群管理外，也将很大程度避免人为疏失带来的灾难，而用户也可以从繁杂易错的工作中解脱。\n\n#### PingCAP Clinic 自动诊断服务（预览版）\n\n和其他数据库系统一样，TiDB 本身存在一定的内在的复杂性，问题诊断和解决并不是非常容易的事情。而对于云环境下，服务提供商更需要面对大量不同用况的用户，对于集群的问题定位，诊断，问题解决都提出了全新的挑战。为了更好更高效地应对问题诊断，定位和修复，TiDB 必须用不同以往的方式面对。究极而言，我们希望数据库是可以智能地自调整自修复，但这却是一个非常宏大的目标。\n\n传统上，我们依赖具备专家知识的工程师 / DBA 进行分析诊断，但这些知识是否可以通过程序来提供，以方便我们的日常运维管理，甚至这些知识是否可以通过不断积累我们由不同真实案例而变得更智能更强大？作为 TiDB 迈向自服务的全新一步，我们希望对于集群运行情况的分析，风险预警和问题定位是可以作为智能服务来提供的：在 TiDB 6.0 发布的同时，新版本也引入了智能诊断服务 PingCAP Clinic 的预览版。PingCAP Clinic 从全生命周期确保集群稳定运行，预测并降低问题出现概率，快速定位并修复问题，加速问题解决效率。它集成了诊断数据采集、智能诊断、智能巡检、云诊断平台等功能，这些功能将逐步向用户开放。\n\nPingCAP Clinic 通过访问（经过用户允许）信息采集组件获取各类故障信息，在对各种问题进行排查的同时也不断增强自身的能力。PingCAP Clinic 将受益于我们面对的数千个场景迥异的用户所提供的各类集群运行数据。我们会不断将从问题中抽象出的规则固化到智能诊断中，并通过在线/离线升级的方式分发给 TiDB 用户，这使得用户在使用 TiDB 的同时也不断获得整个 TiDB 社区的积累。可以预见到的是，当 TiDB 获得更多云端客户时，PingCAP Clinic 也将更容易不断「学习」来提高自己。作为一个宏大目标的起点，我们欢迎大家的关注和讨论。关于更多 PingCAP Clinic 的信息，请阅读官方文档，并关注后续进展发布。\n\n### 面向非专家的可观测性\n\n作为可管理性的一个重要组成部分，可观测性是TiDB 一直以来都在不断加强可观测性。除了其他分布式系统都具备的基本监控和指标，从 4.0 起，TiDB 已陆续发布了诸如 Key Visualizer，SQL 统计和慢查询展示，监控关系图，持续 Profiling 等分布式数据库专有的功能，这些都是对 TiDB 的可观测性很好的补强，能帮助 DBA 和工程师更好地理解自己业务在 TiDB 上的运行情况，以更精准地定位问题和进行系统调优。但这些多多少少是专家向的特性，需要用户对系统有一定的技术理解。\n\n而从 6.0 开始，我们将引入更多的非专家向可观测性特性，让对分布式数据库和 TiDB 并不那么了解的用户也能排查系统问题。Top SQL 的推出是践行理念的第一步。\n\nTop SQL 是一个面向运维人员及应用开发者的一体化、自助的数据库性能观测和诊断功能。与现有 TiDB Dashboard 中各个面向数据库专家的诊断功能不同的是，Top SQL 完全面向非专家：你不需要观察几千张监控图表寻找相关性，也不需要理解诸如 Raft Snapshot、RocksDB、MVCC、TSO 等 TiDB 内部机制，仅需要知道常见数据库概念，如索引、锁冲突、执行计划等，即可开始使用它来快速分析数据库负载情况，并提升应用程序的性能。Top SQL 以用户自助使用、判断分析的方式，与 PingCAP Clinic 自动化规则一起，共同为用户提供从常见到复杂罕见的不同性能场景的覆盖方案。\n\nTop SQL 无需额外配置，在 TiDB 6.0 版本中开箱即用，集成于 TiDB Dashboard 图形化界面，且不影响数据库现有应用程序性能。当前版本 Top SQL 率先提供各个节点 30 天的 CPU 负载情况，你可以直观了解各节点的高 CPU 负载是来自于哪些 SQL 语句，从而快速分析诸如数据库热点、突发的负载升高等场景。在未来版本中我们还将持续迭代改进 Top SQL，重组整合流量可视化、慢查询、锁视图等现有的专家功能到 Top SQL 中，以一体化的、面向非专家的功能形式，帮助运维人员及应用开发者更简单、更全面地分析数据库性能问题。\n\n![3.png](https://img1.www.pingcap.com/prod/3_173646c19e.png)\n\n## 更成熟的 HTAP 能力\n\nTiDB 5.0 是其分析引擎架构初步成型的版本，这个版本中我们引入了 MPP 执行模式，从而得以服务于更广的用户场景。这一年来 TiDB HTAP 也经受了严苛的考验，无论是双十一场景下数十万 TPS 写入合并数十张实时报表中高频刷新，交易分析混合下优化器自动路由完成的高并发数据服务，这些用例都成为 TiDB HTAP 不断成熟的依托。相较 TiDB 5.0，最新版本中分析引擎 TiFlash 拥有了：\n\n- 更多算子和函数支持：相较 5.0，TiDB 分析引擎新增加了 110 多个常用内建函数以及若干表关联算子。这将使得更多计算能享受 TiDB 分析引擎的加速带来的数量级性能提升。\n- 更优的线程模型：在 MPP 模式下，以往 TiDB 对于线程资源是相对无节制的。这样实现的后果是，当系统需要处理较高并发的短查询时，由于过多的线程创建和销毁带来的开销，系统无法将 CPU 资源用满，从而带来大量资源浪费。另外，当进行复杂计算的时候，MPP 引擎也会占用过多线程，带来性能和稳定性的双重问题。针对这个问题，最新版中引入了全新的弹性线程池，并对算子持有线程的方式进行了较大重构，这使得 TiDB MPP 模式下的资源占用更为合理，在短查询下达到同等计算资源倍增的计算性能，且在高压力查询时稳定性更佳。\n- 更高效的列存引擎：通过调整存储引擎底层文件结构和 IO 模型，优化了访问不同节点上副本和文件区块的计划，优化了写放大以及普遍的代码效率。经客户实景验证，在极高读写混合负载下提升超过 50%～100% 以上并发能力，同等负载下大幅度降低 CPU / 内存资源使用率。\n\n## 强化的容灾能力\n\n除了可管理性之外，作为数据容灾的关键组件，TiCDC 也迎来了核心能力增强：通过对整个处理增量数据处理过程的优化、控制拉取事务日志速度等方式，TiCDC 在大规模集群数据容灾方面的能力有了长足的进步。\n\nTiCDC 对于增量数据的提取、排序、加载、投递等多个处理流程都进行了优化，降低在处理每一张表的增量数据时所需要使用的 CPU、内存量、减少进程间的通信次数。 这极大地提升了 TiCDC 在大规模集群下同步数据的稳定性、并降低了资源消耗和数据延迟。 真实用户场景测试显示， 6.0 版本的 TiCDC 可以在上游集群的规模达到 100K 张表、集群每秒钟数据改变行数低于 20 K/s、数据改变量低于 20 MB/s 的情况下，确保 99.9% 的数据延迟时间低于 10 秒钟， RTO < 5 分钟，RPO < 10 分钟。就整体而言，在上游集群 TiDB 集群节点进行计划内升级或者停机的场景中，可以将延迟控制在 1 分钟之内。\n\n另外，为了降低数据复制过程中对上游集群的性能影响，保证数据复制过程中业务无感知， TiCDC 增加了对于主集群事务日志扫描的限流功能。在绝大多数情况下，确保TiCDC 对于上游集群的 QPS、 SQL 语句平均响应时间的影响不超过 5%。\n\n## 面向企业级版本的锚定\n\n随着对版本发布的节奏把控不断成熟，随着 TiDB 6.0 发布，针对企业级用户的稳定性要求，我们也再次进行发版模型调整。从 6.0 版本开始，在 2 个月为周期内的版本迭代基础上，TiDB 发版策略将引入半年为发布周期的 LTS（Long Term Support）版本，同时为用户提供只包含修复的长期稳定版和快速迭代版以兼顾不同倾向的版本需求。其中 LTS 版本面向不需求最新功能，但希望不断收到问题修复的用户，生命周期为 2 年；而非 LTS 版本则拥有更高的迭代速度，只维护 2 个月，面向对最新功能有需求且稳定性需求不高的非生产场合。规划中的 TiDB 6.1 将作为第一个 LTS 版本发布。\n\n## 展望\n\n由于云数据库并不强调版本，因此在前文中我们没有对 [TiDB Cloud](https://tidbcloud.com/free-trial) 进行过多赘述。但是可以看到，6.0 版本不但是 TiDB 迈向企业级 HTAP 数据库的又一个全新版本，也是 TiDB 向云数据库进发的新起点。诸如可管理性主题，数据放置框架，Clinic 自动诊断兼顾了私有部署的使用，但实际上它们都将在云端形态下拥有更大的潜力。  \n\n云原生数据库是一个很有趣的话题。我们对云数据库的认识随着持续的摸索在不断提升中，从在云上可运行的数据库，到借助云基础设施实现的数据库，再到在云上可自运维数据库，6.0 版本是我们践行这个理念的重要一步。试想，结合良好的可管理性，当云数据库服务为成千上万用户提供支持的同时，也可以采集到远超于现在的非敏感的集群运行数据，这些数据将作为数据库自运维自服务的基础信息，不断学习不断进化，在用户体验提升的前提下也解放服务后端团队更多的资源，集中精力更好地提供用户所需的产品，这将带来私有部署形态无法替代的优势。  \n\n而在后续的版本规划中，我们将尝试通过借助云存储服务和资源按需启停等技术，为用户提供超越以往形态的使用体验。借助开源的力量，让用户觉得云服务相比免费使用私有部署更值得，转化为我们新的推力，是我们和整个整个社区双赢的共同目标。\n\n查看 TiDB 6.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v6.0/release-6.0.0-dmr)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.0.0 企业级云数据库之旅。\n\n\n","author":"PingCAP","category":3,"customUrl":"tidb-6.0-release","fillInMethod":"writeDirectly","id":371,"summary":"2022 年 4 月 7 日，TiDB 6.0 发版。在该版本中，我们大幅度加强了作为企业级产品的可管理性，与此同时也加入了诸多云原生数据库所需的基础设施，让 TiDB 在成熟的企业级云数据库维度更向前迈进。","tags":["TiDB","Release"],"title":"TiDB 6.0 发版：向企业级云数据库迈进"}},{"relatedBlog":{"body":"> TiDB 有一些功能和其它功能不一样，这类功能可以作为构建其它功能的基础，组合出新的特性，这类功能称之为：Meta Feature。\n> <p align=\"right\">《关于基础软件产品价值的思考方式》 - 黄东旭</p>\n\n\n\n对一款分布式数据库而言，数据如何分散存储在不同节点永远是个有趣的话题。你是否有时会期望能具体控制数据具体存储在哪些节点？\n\n- 当你在同一个 TiDB 集群上支持多套业务以降低成本，但又担心混合存储后业务压力互相干扰\n\n- 当你希望增加重要数据的副本数，提升关键业务的可用性和数据可靠性\n\n- 当你希望把热点数据的 leader 放到高性能的 TiKV 实例上，提升 OLTP 性能\n\n- 当你希望实现热冷数据分离（热数据存放在高性能介质，冷数据反之），降低存储成本\n\n- 当你希望在多中心部署下，将数据按照实际地域归属和数据中心位置来存放，以减少远距离访问和传输\n\n你也许已经知道，TiDB 使用 Placement Driver 组件来控制副本的调度，它拥有基于热点，存储容量等多种调度策略。但这些逻辑以往对于用户都是近似不可控的存在，你无法控制数据具体如何放置。而这种控制能力就是 TiDB 6.0 的 Placement Rules in SQL 数据放置框架希望赋予用户的。\n\nTiDB 6.0 版本正式提供了基于 SQL 接口的数据放置框架（Placement Rules in SQL）。它支持针对任意数据提供副本数、角色类型、放置位置等维度的灵活调度管理能力，这使得在多业务共享集群、跨 AZ 部署等场景下，TiDB 得以提供更灵活的数据管理能力，满足多样的业务诉求。\n\n让我们来看几个具体的例子。\n\n## 跨地域部署降低延迟\n\n想象下你是一个服务供应商，业务遍布全球，早期架构为中心化设计，随着业务跨地域开展后，业务拆分全球化部署，中心数据访问延迟高，跨地域流量成本高。随着业务演进，你着手推动数据跨地域部署，以贴近本地业务。你的数据架构有两种形式，本地管理的区域数据和全局访问的全局配置数据。本地数据更新频次高，数据量大，但是几乎没有跨地域访问的情况。全局配置数据，数据量少，更新频率低，但是全局唯一，需要支持任意地区的访问，传统的单机数据库或单地区部署数据库无法满足以上业务诉求。\n\n以下图为例，用户将 TiDB 以跨中心的方式部署在三个数据中心，分别覆盖华北，华东和华南的用户群，让不同区域的用户可以就近访问本地数据。在以往的版本中，用户的确可以将以跨中心的方式部署 TiDB 集群，但无法将归属不同用户群的数据存放在不同的数据中心，只能按照热点和数据量均匀分布的逻辑将数据分散在不同中心。在高频访问的情况下，用户访问很可能会频繁跨越地域承受较高的延迟。\n\n![1.jpg](https://img1.www.pingcap.com/prod/1_9faf413613.jpg)\n\n\n通过 Placement Rules In SQL 能力，你设置放置策略将区域数据的所有副本指定到特定区域的特定机房内，所有的数据存储，管理在本地区内完成，减少了数据跨地区复制延迟，降低流量成本。你需要做的仅仅是，为不同数据中心的节点打上标签，并创建对应的放置规则：\n\n```SQL\nCREATE PLACEMENT POLICY 'east_cn' CONSTRAINTS = \"[+region=east_cn]\";\nCREATE PLACEMENT POLICY 'north_cn' CONSTRAINTS = \"[+region=north_cn]\";\n```\n\n并通过 SQL 语句控制数据的放置，这里以不同城市分区为例：\n\n```SQL\nALTER TABLE orders PARTITION p_hangzhou PLACEMENT POLICY = 'east_cn'；\nALTER TABLE orders PARTITION p_beijing PLACEMENT POLICY = 'north_cn'；\n```\n\n这样，归属不同城市的订单数据副本将会被「固定」在对应的数据中心。\n\n## 业务隔离\n\n假设你负责大型互联网企业的数据平台，内部业务有 2000 多种，相关业务采用一套或多套 MySQL 来管理，但是因为业务数量太多，MySQL 实例数接近 1000 个，日常的监控、诊断、版本升级、安全防护等工作对运维团队造成了巨大的压力，且随着业务规模越来越大，运维成本逐年上升。你希望通过减少数据库实例数量来减少运维管理成本，但是业务间的数据隔离、访问安全、数据调度的灵活性和管理成本成为你面临的严峻挑战。\n\n借助 TiDB 6.0，通过数据放置规则的配置，你可以很容易灵活的集群共享规则，例如业务 A，B 共享资源，降低存储和管理成本，而业务 C 和 D 独占资源，提供最高的隔离性。由于多个业务共享一套 TiDB 集群，升级、打补丁、备份计划、扩缩容等日常运维管理频率可以大幅缩减，降低管理负担提升效率。\n\n![2.jpg](https://img1.www.pingcap.com/prod/2_4424b9bfd4.jpg)\n\n\n\n```SQL\nCREATE PLACEMENT POLICY 'shared_nodes' CONSTRAINTS = \"[+region=shared_nodes]\";\nCREATE PLACEMENT POLICY 'business_c' CONSTRAINTS = \"[+region=business_c]\";\nCREATE PLACEMENT POLICY 'business_d' CONSTRAINTS = \"[+region=business_d]\";\n\nALTER DATABASE a POLICY=shared_nodes;\nALTER DATABASE b POLICY=shared_nodes;\nALTER DATABASE c POLICY=business_c;\nALTER DATABASE d POLICY=business_d;\n```\n\n基于 SQL 接口的数据放置规则，你仅仅使用少数 TiDB 集群管理大量的 MySQL 实例，不同业务的数据放置到不同的 DB，并通过放置规则管理将不同 DB 下的数据调度到不同的硬件节点上，实现业务间数据的物理资源隔离，避免因资源争抢，硬件故障等问题造成的相互干扰。通过账号权限管理避免跨业务数据访问，提升数据质量和数据安全。在这种部署方式下，集群数量大大减小，原本的升级，监控告警设置等日常运维工作将大幅缩减，在资源隔离和性价比上达到平衡，大幅减少日常的 DBA 运维管理成本。\n\n## 主从多机房 + 低延迟读取\n\n现在你是一个互联网架构师，希望通过 TiDB 构建本地多数据中心架构。通过数据放置规则管理，你得以将 Follower 副本调度到备中心，实现同城高可用。\n\n```SQL\nCREATE PLACEMENT POLICY eastnwest PRIMARY_REGION=\"us-east-1\" REGIONS=\"us-east-1,us-east-2,us-west-1\" SCHEDULE=\"MAJORITY_IN_PRIMARY\" FOLLOWERS=4;\nCREATE TABLE orders (order_id BIGINT PRIMARY KEY, cust_id BIGINT, prod_id BIGINT) PLACEMENT POLICY=eastnwest;\n```\n\n与此同时，你让对于一致性和新鲜度不高的历史查询通过基于时间戳的方式读取（[Stale Read](https://docs.pingcap.com/tidb/stable/as-of-timestamp)），这样避免了跨中心数据同步造成的访问延迟，同时也提高对从机房的硬件利用率。\n\n```SQL\nSELECT * FROM orders WHERE order_id = 14325 AS OF TIMESTAMP '2022-03-01 16:45:26';\n```\n\n## 总结\n\nTiDB 6.0 的 Placement Rules In SQL 是一个很有趣的功能：它暴露了以往用户无法控制的内部调度能力，并提供了方便的 SQL 接口。你可以通过它对分区 / 表 / 库不同级别的数据进行基于标签的自由放置，这开启了诸多以往不可能实现的场景。除了上述可能性，我们也期望和你一起探索更多有趣的应用。\n\n> 查看 TiDB 6.0.0 [Release Notes](https://docs.pingcap.com/zh/tidb/v6.0/release-6.0.0-dmr) ，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.0.0 企业级云数据库之旅。\n\n","author":"PingCAP","category":1,"customUrl":"what-are-placement-rules-in-sql","fillInMethod":"writeDirectly","id":376,"summary":"TiDB 有一些功能和其它功能不一样，这类功能可以作为构建其它功能的基础，组合出新的特性，这类功能称之为：Meta Feature。","tags":["TiDB"],"title":"TiDB 6.0 的元功能：Placement Rules in SQL 是什么？"}}]},{"id":"Blogs_395","title":"TiDB 6.1 发版：LTS 版本来了","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。","body":"![TiDB 6.1.png](https://img1.www.pingcap.com/prod/Ti_DB_6_1_6eecaae325.png)\n\n我们很高兴向大家宣布，TiDB 6.1 于 6 月 13 日发布，这是 TiDB 6 系版本的第一个长期支持版（Long Term Support，简称 LTS）。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com/zh/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.1-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n## 长期支持版\n\n在两个月前发布 TiDB 6.0 版本时，我们提过在新发版流程中，我们引入了面向企业级用户的 LTS 版本的概念，与之相对的是开发里程碑版本（Development Milestone Release，简称 DMR）。引入这两种概念是为了让 TiDB 的发版节奏能兼顾快速变化的市场需求以及企业级用户对稳定性的要求。\n\n我们重新思考了发版模型，最后选择了长期支持版结合开发里程碑版的方式：我们保持 2 个月左右一次发版的节奏，以期快速应对市场节奏，但不再对所有发布进行长期维护，而是以半年左右为节奏拣选其中一个版本作为 LTS 长期支持版本。针对 LTS 版本我们提供针对问题的修复补丁而不再合并新功能。与此相对的，DMR 版本则保持快速发版的节奏，不断发布新特性，让用户所需的新需求不必等待很久（但并不提供基于 DMR 的问题修复）。对于用户而言，在没有特定需求开发的情况下，可以选择最新的 LTS 版本投产；如果需求某个 DMR 发布的新功能，则可以选择该版本进行 PoC 以及试运行，待到对应的 LTS 版本发布后升级 TiDB 到稳定生产状态。这样快慢结合的方式，可以最大限度兼顾快速迭代和稳定投产两方面的需求。\n\n对应 LTS 稳定版的主旨，6.1 版本中携带了重要的稳定性更新：\n\n1. 提升 TiKV 高压场景下的内存稳定性。\n2. 解决了由于 Raft Log 复制流量过大导致的 OOM 问题。\n3. 解决了在高压场景下宕机后重启过程中长时间持续反复 OOM 的问题。\n4. 完善了 TiDB Server 内存使用跟踪统计，加强查询内存使用配额限制。\n5. 优化了部分统计信息内存使用。\n\n另外，新版本也包含了 42 个问题修复和 20 个改进提升。\n\n## 是 LTS，也有新惊喜\n\nTiDB 6.1 除了作为第一个推荐企业级用户投产的 6 系版本，本身也携带了诸多强大的特性。\n\n### HTAP 基础能力提升\n\n在新版本中，部分分区表的实验特性 GA，且分析引擎加入了分区表和窗口函数支持。\n\n让我们先来看看分区表：我们在版本 5 中引入了 List 分区和动态裁剪特性，但一直保持实验特性状态。更重要的是，由于旧有的分区静态裁剪在 MPP 下表现欠佳，因此 TiFlash 引擎一直以来并未完整支持分区表特性。这次新发布中，我们宣布 List 分区 / 分区动态裁剪以及 MPP 模式下的分区表支持 GA。对于分区表本身在此无需过多赘述，各位可以参考官方文档，我们单独说下分析引擎下的分区表支持。\n\n对于列存引擎而言，由于并不支持类似行存的细粒度索引，仅仅依靠粗粒度索引并不能满足数据过滤需求。而分区表作为列存下最高效的数据过滤手段，是分析场景下需求优先级非常高的特性。例如在订单管理场景下，用户的数据天然可以将订单创建日期作为分区依据按天将一个月的数据分成 30 个分区，而用户的分析查询往往更高频查询最近一周甚至三五天的订单数据。在以往分析引擎不支持分区的情况下，TiDB MPP 只能进行全表扫描，这不但浪费了无谓的存储带宽，也会消耗 CPU 针对日期字段进行过滤。而在 6.1 版本中，对于上述例子，只要查询条件带有订单创建日，则可以数倍甚至数十倍提高查询效率。\n\n在 6.1 中另一个分析场景下常用的新功能是 MPP 下的窗口函数支持。在新版本中，MPP 执行器加入了对窗口函数的框架性支持，并随之推出了三个最常用窗口函数 rank，dense_rank 以及 row_number。这使得在 MPP 执行模式下，窗口函数除了内存消耗可以被分布式分担，性能也得到大幅提升。以 100G 规模数据集测试为例 ，新版本中查询使用单节点 MPP 模式进行窗口函数计算将提速 282%，使用更多节点将有更大幅度提速。与以往 MPP 模式下对内建函数的支持一样，我们将逐步增加对各类窗口函数的支持。\n\n新版本中，TiDB 引入了非事务性 DML 语句以应对大批量数据变更。新加入的非事务性 DML 将一个普通 DML 拆成多个 SQL 执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。典型的，在新版本中可以使用如下语句淘汰过期数据，而无需担心事务大小限制问题：\n\n`BATCH ON id LIMIT 2 DELETE FROM orders where create_date < '2022-05-01';`\n\n上述 SQL 将会以 2 批次的方式执行 DELETE 操作，以控制单次操作的内存占用。过往版本中，TiDB 仅支持非事务性删除。\n\n### 更完整的生态对接\n\n数据库从来都不是单独被使用的，而 TiDB 也在持续改进和生态环境的对接。在新版本中，TiDB 引入了用户级别锁和 TiCDC 下的 Avro 格式向 Kafka 同步数据的支持。\n\n先说用户级别锁。用户级别锁是 MySQL 通过内置函数提供的用户命名锁管理系统。它们可以用在 SQL 语句的 SQL 函数中，比如 select，where 子句，group by 子句等位置使用。这些语句可以在不同的代码处阻塞，等待，实现用户级别锁管理。用户级别锁在 ORM 框架中也有较为广泛的应用，例如 RoR, Elixir 和 Ecto 等。TiDB 从 6.1 版本开始支持兼容 MySQL 的用户级别锁管理，支持 GET_LOCK，RELEASE_LOCK, RELEASE_ALL_LOCKS 等锁管理函数，这使得 TiDB 得以更好支持现有 ORM 框架的生态。\n\n对 TiDB 而言，TiCDC 是集群数据实时变更信息的出口，而支持常用的数据格式以方便消费者解析则是降低开发复杂度的必修课。Avro 作为一种数据序列化系统，采用了压缩二进制格式，传输效率高，数据格式丰富，已经被大量的数据分析、数据集成产品所支持。TiCDC 支持将 TiDB 数据库的增量数据转换为 Avro 格式，并发送到 Kafka 的方式，这将使得 TiDB 数据库和众多的生态系统，例如：Kafka、Snowflake、SQL Server 链接起来。在新版本中，向其他系统实时同步 TiDB 的数据变化，无论是用于实时数据集成还是变更订阅触发操作，都可以借助 Avro 格式变得更简单。更进一步，一些仰赖 Avro 格式的其他生态功能，现在也得以发挥热量，例如用户可以借助 Avro 格式通过 Kafka kSQL 对变更日志进行实时计算。\n\n## 行动起来\n\n除了上述所有新功能外，其实 TiDB 6.1 作为 6 系版本的第一个推荐企业级用户投产的 LTS 版本，是所有需求 6.0 版本特性的用户的理想选择。无论你已经在使用 6.0 版本，还是正在调研中，都推荐大家部署 6.1 版本或升级。相信新版本将为广大用户提供强大的功能和稳定的体验。\n\n查看 TiDB 6.1.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-6.1.0)，立即[下载试用](https://pingcap.com/zh/product/#SelectProduct)，开启 TiDB 6.1.0 企业级云数据库之旅。\n\n\n\n\n","date":"2022-06-13","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-6.1-release","file":null,"relatedBlogs":[]},{"id":"Blogs_385","title":"TiDB Cloud GA，助力全球企业在云上构建新一代云原生应用","tags":["TiDB Cloud","Release"],"category":{"name":"公司动态"},"summary":"PingCAP 宣布 TiDB Cloud 正式商用，助力全球企业在云上构建新一代云原生应用。","body":"PingCAP 宣布 TiDB Cloud 正式商用，助力全球企业在云上构建新一代云原生应用。\n\n企业用户可以借助 TiDB Cloud 全托管数据库服务轻松支撑各类创新业务场景，将企业从后台的基础设施运维和数据备份等复杂工作中解放出来。\n\n2022 年 5 月 11 日，企业级开源分布式数据库厂商 PingCAP 宣布 TiDB Cloud 在全球范围正式商用。\n\n经过一年多全球用户和合作伙伴的广泛测试，TiDB Cloud 今天开始正式面向全球用户提供全托管的 DBaaS （Database-as-a-Service）服务，支持用户在全托管的数据库上运行关键业务交易和实时分析任务，并充分享受云上的性能优势和业务连续性保障。\n随着数据驱动的数字化转型进程不断加速，企业的业务增长面临着大规模数据存取和数据孤岛的挑战。TiDB Cloud 提供下一代云原生数据库解决方案，帮助用户在多云环境下快速构建云原生的关键应用，无论这些应用是运行在 Amazon Web Services 还是 Google Cloud 上面。\n\n> 传统数据库已经无法支持今天每秒百万级别的交易量，PingCAP 一直致力于解决海量、实时、在线的数据处理与分析问题，为全球企业提供新一代数据库，让企业用户在管理海量数据处理的同时激活实时数据分析的能力，TiDB Cloud 进一步降低了企业用户使用 HTAP 实时分析能力的门槛。\n> <p align=\"right\">——PingCAP 联合创始人兼 CTO 黄东旭</p>\n\n\nTiDB Cloud 具备 TiDB 分布式数据库的所有能力，并针对云端的托管模式提供了很多新的企业级特性，企业用户可以用更低的基础设施成本，更简化的方式来处理复杂的业务。\n\nTiDB Cloud 面向企业用户的新特性主要包括以下几个方面：\n- 通过审计日志提高安全性：使企业有能力监督所有用户的操作，以确保其数据的安全性； \n- 内置监控和报警中心：帮助企业在新问题影响业务之前解决这些问题；\n- 对 Prometheus 和 Datadog 的支持和整合：为企业提供高效工具来监控和管理 TiDB 集群；\n- 持续增加新的区域节点：在  Amazon Web Services  上增加了对印度孟买节点的支持；\n- 进一步增加计算能力选择：为 TiDB 和 TiKV 节点增加了新的 4vCPU 和 16vCPU 选项；\n\n通过 TiDB Cloud，PingCAP 正在帮助用户整合和简化技术栈，让企业用户不再维护昂贵而独立的数据库实例。TiDB Cloud 屏蔽了 TiDB 数据库部署、运维和性能调优的复杂性，设置只需要几分钟，从而大大简化了开发人员和 DBA 的工作任务，同时降低了企业的整体成本。\n\n在标准服务之外，TiDB Cloud 新增两项服务支持-- Enterprise 和 Premium，这两项高级服务支持提供更快的响应和问题解决方式，让用户获得更多的紧急救援服务。\n\n过去一年已经有很多中国出海用户在使用 TiDB Cloud 公测版本，TiDB Cloud 正式商用将为这些用户提供更好的服务保障，也为寻求跨云的 MySQL 数据库用户提供了安全易用的新选择。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-cloud-ga\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n  </div>\n</div>","date":"2022-05-11","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tide-cloud-ga","file":null,"relatedBlogs":[]},{"id":"Blogs_377","title":"Talent Plan 学习营初体验：交流+坚持 开源协作课程学习的不二路径","tags":["Talent Plan"],"category":{"name":"公司动态"},"summary":"Talent Plan 是 PingCAP 联合华东师范大学、华中科技大学、中国科学技术大学、武汉大学和神州数码面向高校和工程师的未来数据库内核人才培养计划。本文是对 Talent Plan KV 2021 学习营一等奖获奖战队的专访，分享了他们在学习营中的收获以及获奖经验。 ","body":"[Talent Plan](https://tidb.net/talent-plan) 是 PingCAP 联合华东师范大学、华中科技大学、中国科学技术大学、武汉大学和神州数码面向高校和工程师的未来数据库内核人才培养计划。通过结业考核的学员将获得官方认证的证书，并具备进入 TiDB 生态企业交流、实习和工作的机会。\n\n为了让更多学员不会对体系庞大、内容艰深的 Talent Plan 课程望而却步，或是半途而废，Talent Plan 学习社区推出了 Talent Plan 学习营活动。学习营以线上自学为主，参加学习分享讲座为辅，邀请往届毕业的学员做导师，将自己学习过程中遇到的坑和必要的知识点分享给其他学员，帮助学员们将时间用在真正关键的学习上。\n\nTalent Plan KV 2021 学习营学员来自福州大学、华东师范、清华大学、武汉大学、卡内基梅隆大学 、早稻田大学、纽约大学等高校，参与人数达到 400 人，可见大家对数据库知识学习的渴望。Talent Plan 课程有如下 5 个学习路径：Rust 编译原理和实现、实现一个 mini 版本分布式关系型数据库、实现一个 mini 版本分布式KV数据库、参与工业级开源分布式数据库 TiDB 开发、参与工业级开源分布式 KV 数据库 TiKV 开发。\n\n**从课程内容上讲，有如下3个系列：**\n\n系列 1: 开源协作\n- TP101: 开源软件简介\n- TP102: 如何使用 Git 和 Github\n- TP103: 建立一个社区\n\n系列 2: Rust编程\n- TP201: Rust 网络编程\n- TP202: Rust 分布式系统\n\n系列 3: 分布式数据库\n- TP301: 用 Go 语言实现 TinySQL 分布式数据库\n- TP302: 用 Go 语言实现 TinyKV 分布式 KV 数据库\n\n学习内容涵盖了SQL 语句基础知识、编译原理前端、DDL 异步变更算法、SQL 优化原理与优化器实现、统计信息与代价估算、Join reorder、执行引擎、物理算子的实现、KV 单机存储引擎（LSM-Tree）、Raft 一致性协议、Percolator 分布式事务模型、 Go语言、 Rust 语言及开源协同工具等方面。\n\n来自福州大学的「奥特曼都是假的」战队以优异的成绩获得了一等奖，我们在学习营结业后对「奥特曼都是假的」战队的黄章衡同学进行了专访，请他分享在学习营中的收获以及获奖经验。 \n\n![0419zhangheng.mp4](https://img1.www.pingcap.com/prod/0419zhangheng_224327d147.mp4)\n\n\n> “我之前也参加过一些软件设计类的竞赛，比如中国大学生服务外包创新创业大赛等。但这些比赛可能更关注项目的包装，在 Talent Plan 学习营中，更关注的是学生的动手能力，以及是否坚持到底将项目完成。”\n> \n> <div align = right>——黄章衡</div> \n\n## 开源为学习数据库打开一扇新大门\n\n黄章衡来自福州大学 2019 级计算机系，平常在校的生活中，经常会和实验室的小伙伴参与一些软件设计类的竞赛，拿过不少奖项。从大二下学期开始，逐渐开始接触分布式系统和数据库相关领域，并参与到一些开源项目中，之后就一发不可收拾，开始不断地学习分布式数据库相关知识。\n\n之所以能够在本次学习营中取得一等奖的好成绩，黄章衡坦言这段时间的学习起到了非常关键的作用：“我的基础比较扎实，在参加学习营之前，我有学习到很多分布式数据库相关的理论知识。还有就是要不懈坚持，在做项目的过程中会遇到很多 bug ，只有不断地坚持，修改那些 bug ，慢慢就会成功了。”\n\n与开源的接触也为章衡学习分布式数据库打开一扇新的大门。他介绍，首次接触开源是一个叫 sofajraft 的开源项目。参与开源带给他最大的改变，是从前学习一些软件项目，源码基本都看不懂。但是当领取一些开源项目的新手计划或者一些高难度的项目后，在做的过程中慢慢就发现之前一些看不懂的代码突然可以看懂了。然后，通过慢慢地消化这些代码，继而学习整个系统架构，就可以把所学的知识与实践相结合，这对于个人发展是非常有帮助的。\n\n## 遇到困难多交流\n\n在学习营之前，黄章衡其实已经对 TiKV 的整体架构有了一定了解，但他自我调侃了解程度还只是浮于表面，并且由于之前没有系统学习过 Rust 语言，并没有深入研究它的代码。后来，章衡在一些前辈的朋友圈里看到了 Talent Plan 学习营的通知，就报名参加了。 \n\n在本次 Talent Plan 学习营中，主要学习的课程是 TinyKV 项目。该课程中包含了四个 Project ：\n- Project1 是构建一个单机 kv server；\n- Project2 是基于 raft 算法实现分布式键值数据库服务端；\n- Project3 是在 project2 的基础上支持多个 raft 集群；\n- Project4 是在 project3 的基础上支持分布式事务。\n\n其中 Project 3 是众多学员公认难度最大的一个。黄章衡也表示  Project 3 里的每一个测试都会让人怀疑人生。事实上，每一个战队都会在 Project 3 卡很久。Project 3 中有一些 bug 不太好找，很多人可能在调试的过程中，调试了好几天都没有什么结果，就放弃了。\n\n章衡认为这时候有一个比较好的解决方案：去找一些别的战队或者导师交流经验，看看他们是否有发生过类似的问题，并且他们是如何解决的。因为很多 bug 大家都会遇到，可能有些人会有思路，去请教他们的思路，就可以解决自己的 bug。学习营中的导师通常都会非常热心地帮助学员解决问题。\n\n在交流的过程中，由于章衡的队名「奥特曼都是假的」比较奇特，很多小伙伴都会直接叫他“奥特曼”，这也给短短两个月的学习过程中留下了有趣的回忆。章衡就靠着这个方法不断地改进着自己的项目，并最终获得成功。\n\n## 学习建议\n\n作为过来人，章衡也为其他想学习 Talent Plan 学习营的小伙伴，分享了一些自己的学习经验：第一点，要把项目文档阅读好。实际上文档里已经把要做的事情都已经说清楚了。第二点，要坚持不懈，不要轻言放弃。在做项目的过程中你可能会遇到各种各样奇怪的 bug ，多去和别人交流，多去看一些前辈的经验，了解他们是如何解决遇到的 bug ，不要遇到 bug 就随便放弃了，这其实对个人发展也不好。\n\n## 个人收获\n\n在采访中，章衡透露自己也报名了下一届学习营的导师，希望将自己的学习经验分享给更多参与学习营的小伙伴们。不出意外的话，你就会在下一届学习营导师名单中看到“黄章衡”。\n\n目前，章衡已经在 PingCAP 实习中，个人对未来发展的方向也希望偏向基础架构、分布式数据库等方向。“我会继续往数据库这一领域去发展，在学习数据库的过程中，包括底层的存储和上层的计算，个人都是非常感兴趣的。从事分布式数据库相关的研发是我最感兴趣的事情。未来，我想我也会找这一块相关的工作。”\n\n最近，Talent Plan 新活动——Talent Plan 2022 分布式事务短训营开营！专为 VLDB Summer School 2021 开发的课程——《分布式事务实现》经过后期升级上线，在本次学习营中正式亮相。本次学习营是 Talent Plan 学习社区针对有一定数据库基础的学员开展的线上学习活动，意在帮助大家利用两周的时间快速、透彻地学习分布式事务编程基础，在 TinyKV 中实现 Percolator、实现隔离与并发控制以及实现分布式时钟等实用主题。感兴趣的小伙伴可以点击[阅读原文](https://github.com/tiny-talent/distributed-txn)了解学习。 \n","date":"2022-04-21","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"first-experience-of-talent-plan-learning-camp","file":null,"relatedBlogs":[]},{"id":"Blogs_370","title":"TiFlash 开源了","tags":["TiFlash"],"category":{"name":"公司动态"},"summary":"TiFlash 终于开源了，我们选了这个特别的节日开源并做出承诺，希望能显得更加真诚。","body":"![0.jpeg](https://img1.www.pingcap.com/prod/0_0d85512f2d.jpeg)\n\nTiFlash 终于[开源](https://github.com/pingcap/tiflash)了，而且不再闭源：**我们选了这个特别的节日开源并做出承诺，希望能显得更加真诚 :)**\n\nPingCAP 一直以来对开源这件事情，是有**信仰**的。这种信仰植根于创始人的情怀，也深深影响了这个旗帜下汇聚的所有人。开源本身并不是一种市场策略：远在我们看清开源到底能带来什么的时候，我们就有了开源的坚持，这也使得我们的开源精神相对**纯粹**。作为 TiDB 社区的一个重要力量，我们和其他社区贡献者一起贡献代码，通过社区用户的使用、打磨，大家共同分享 TiDB 不断进步的红利，没有任何人为障碍和边界。自由和共赢的理念，也是我们对技术对开源的**倔强**。\n\n![01.png](https://img1.www.pingcap.com/prod/01_39623260e8.png)\n\n**TiDB 是一款 HTAP 分布式数据库，其中提供 HTAP 能力的重要组成部分是 TiFlash**。从原型开发起，由于是一个探索型的项目，一开始我们并没有想好最终形态和架构（TiFlash 在 2018 年也的确经历了一次彻底翻新重做），为了不引起外界太多讨论，我们选择了让 TiFlash 暂时闭源，等大体成型了再开源。虽然从一开始我们就计划开源，但待到真正着手做的时候，我们发现它已经欠下了不少「开源债」，显得和 TiDB 主干格格不入：发布流程没有完全融合，开源所需的文档缺失，编译体验相当糟糕，甚至部分代码风格有些丑陋。要还上这些债务，需要投入相当多的时间和人力。与此同时，产品迭代的压力和有限的资源就成为约束 TiFlash 开源的最大障碍。\n\n作为将开源当成信仰的团队而言，TiFlash 闭源对我们来说其实是如鲠在喉。因此，虽然仍有诸多缺失，我们选择投入时间逐步还债。毕竟，单独就这个引擎而言，我们也从社区有所取，**无论是 ClickHouse 绝佳的 Runtime 基础，还是诸多社区用户提供的真实场景和改进建议，这些都让 TiFlash 获益无算，可以说没有这些助力，就不会有 TiFlash**。\n\nTiFlash 首先受益于开源社区的其他项目，除开我们所使用的各类基础库，最重要的部分是：TiFlash 的框架代码是基于 ClickHouse 的。**我们使用 ClickHouse 的方式是将它当做一个单机的 Compute Runtime 和 Server 框架，并复用了 Storage Interface**。针对在线事务数据分析的大目标，我们加入了事务相关逻辑、MPP 能力和可实时更新的列存引擎，引入 Raft 协议和 MySQL 兼容以融入整个 TiDB 体系。很感谢 ClickHouse 为社区提供了一套高性能的计算引擎，对我们而言，一个好的基础大大加速了 TiFlash 的研发进度。**值得一提的是，TiFlash 和 ClickHouse 拥有完全不同的擅长场景：TiFlash 完全偏重于事务性数据的分析，我们也并不希望用户以为 TiFlash 是更好的 ClickHouse**。\n\n作为一个年轻的引擎，在两年多的时间里，受到天使用户们包容和帮助的同时，我们也通过近距离倾听用户的声音高速迭代改进产品。这一切也反过来帮助用户简化了分析链路的架构，享受实时数据的红利。彼时 TiFlash 虽未开源，却已得到了 TiDB 社区的加持。\n\n我们清楚地记得，在早期版本时，税务系统的朋友和我们一起测试，尝试优化缴税流程的实时性，虽未成功落地，但让我们对系统设计在真实场景上的得失有了第一手体感，进而直接导致了一次重大重构：我们完全重新设计了存储层，引入了 Raft Learner 作为复制协议，且决定使用 TiDB-Server 作为统一入口而非 TiSpark，这也是大家今日所见的架构；而随着 TiDB 4.0 一起发布的正式版本，则可以说是完全仰赖小红书在发布前数月就提供场景和我们一起探索，而这个尝试最终成功落地电商实时看板场景，让交易数据得以实时展现；待到 5.0，从中通有惊无险却时有毛刺的 618，到流量倍增却平平稳稳的双十一，TiFlash 在高压实时场景的表现得到了提升和验证。而这代表的不仅是全球领先快递公司的核心业务落地，也不仅是数万 TPS 和数十亿订单的实时监控，更是用户的包容，信任和互助。\n\n![02.jpeg](https://img1.www.pingcap.com/prod/02_8af891c036.jpeg)\n<center>TiFlash 在中通快递</center>\n\n至今我们都经常会收到客户的私信，说自己某个场景由于 TiFlash 的能力而得到实在的业务收益。每次看到这些可爱的消息，我们都会在团队内分享喜悦。能帮助大家，提供独特的价值，是我们所追求的；与此同时，社区的支持，也是产品发展不可或缺的给养，推动它在更严苛更有价值的场景落地。可以说，没有社区的力量，我们也无法向更多人提供更好的产品。而时至今日，开源则是一个全新的渠道，让 TiFlash 能以更深入的方式和社区互助共赢。\n\n最后容我们说一句抱歉。虽然开源，但 TiFlash 仍然缺失必要的面向社区的代码解读。关于 TiFlash 和 TiDB HTAP 的架构解析，可以参考我们在 VLDB 2020 发布的论文《[TiDB: A Raft-based HTAP Database](http://www.vldb.org/pvldb/vol13/p3072-huang.pdf)》，或者《[TiDB HTAP 深度解读](https://zhuanlan.zhihu.com/p/205663113)》、《[TiDB 的列式存储引擎是如何实现的？](https://pingcap.com/zh/blog/how-tidb-implements-columnar-storage-engine)》文章。社区同学也整理了一份 TiFlash 相关文章的[合辑列表](https://asktug.com/t/topic/632816)。可惜的是，这些都是基于 TiDB 4.0 版本，当时 TiFlash 仍不具备重要的 MPP 能力。除此之外，源码解析和阅读指南，也仍在缺失状态。这些都将在后续的几个月内陆续补上，以帮助大家阅读和理解 TiFlash。希望关注 TiFlash 的大家在使用以外，借助开源能有更多手段帮助它变得更好，无论是更多的函数，算子支持，更直观的 Tracing 能力，还是更快更稳定的 Delta Tree 列存引擎。\n\n是的，我们期待你的贡献，因为这份力量将会借助社区的翅膀飞跃令人惊叹的奇景。\n\n祝大家节日快乐。\n\n访问 [GitHub TiFlash](https://github.com/pingcap/tiflash) 仓库，开启你的数据实时分析之旅！","date":"2022-04-01","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tiflash-is-open-sourced","file":null,"relatedBlogs":[]},{"id":"Blogs_346","title":"TiDB 5.4 发版丨新功能解读","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 5.4 作为 2022 年开山之作，于 2 月 15 日正式发版，5.4 版本包含了许多有用有益的新功能和持续性的性能/稳定性提升。本文着重介绍重要新增功能和特性所带给用户的新体验和价值。","body":"TiDB 5.4 作为 2022 年开山之作，包含了许多有用有益的新功能和持续性的性能/稳定性提升。**本文着重介绍重要新增功能和特性所带给用户的新体验和价值**，按照以下章节来组织：\n\n- 基础性能优化和提升\n\n- 面向云环境的功能拓展\n\n- 产品易用性和运维支持\n\n- 新增实用性功能涉及到的系统配置开关选项\n\n- 主要的 bug 修复和稳定性提升\n\n更多详细内容还可以参照 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-5.4.0/) 和[用户手册](https://docs.pingcap.com/zh/tidb/stable)。\n\n## 基础性能优化和提升\n\nTiDB 5.4 在性能提升方面实现了以下的重要改进：查询计划可利用多个列上的索引进行高效条件过滤相关的优化工作，即通过正式支持**索引合并**查询优化功能，使此类查询的性能获得数量级的提升，并且具有响应时间稳定不占系统资源的突出特点；对于数据量大、读写更新频繁的分析场景， TiFlash 存储引擎的性能优化将**使 CPU 占用率在现有基础上显著降低**并间接帮助提升并发查询下的总体性能；最后，TiDB 5.4 在大规模数据同步场景下显著提升了同步工具 Lightning 的性能使得**大规模的数据同步任务更轻松快捷**。\n\n### TiFlash 存储层大幅优化行存到列存转码效率\n\n#### 用户场景与挑战\n\nHTAP 平台和应用中，数据更新和大量扫表行为交织在一起，存储系统的效能是影响性能和稳定性的关键因素，重度用户总是期待系统能有更好的性能并承载更多的业务。特别是 TiDB HTAP 采用了事务处理与分析查询物理分离的架构，同一份数据根据业务的需要，在后台进行自动的行式存储到列式存储的转换以分别响应 OLTP 和 OLAP 两种类型的负载。存储层大幅优化了从 TiKV “行”存储到 TiFlash “列”存储格式的转换效率，在“行 - 列”转换环节的 CPU 效率大幅提升，进而使得高负载情况下可以节约出更多的 CPU 资源用于其他环节的计算任务。\n\n#### 解决方案与效果\n\nTiDB 5.4 重新梳理了 TiFlash 中行存到列存转码模块的代码架构，大量简化了冗余的数据结构和判断逻辑，采用 CPU 缓存和向量化友好的数据结构和算法，从而大幅提高运行效率。另外，新版本还相应地优化了 TiFlash 的存储引擎 DeltaTree 的默认配置，综合效果的确认参见下文。\n\n列式存储引擎写入性能验证：**在不同并发情况下吞吐性能提高 60%～90%**\n\n验证环境：\n\n6 TiKV（ 1 副本）、1 TiFlash（ 1 副本），每个节点 40 个 CPU 逻辑 core，CH-benCHmark (1500 warehouse)。\n\n![2.png](https://img1.www.pingcap.com/prod/2_2e061539a1.png)\n\nCH-benCHmark 测试结果： **10 并发下部分查询（Q1、Q6）性能提高约 20%**\n\n测试环境：\n\n3 TiKV（ 3 副本）、2 TiFlash（ 2 副本），每个节点 40 个 CPU 逻辑 core，CH-benCHmark (1500 warehouse)。\n\n![3.png](https://img1.www.pingcap.com/prod/3_bbf6c0e3f1.png)\n\n#### 小结\n\nTiDB 行存与列存之间的数据转换同步通常被外界认为是一种较大的 overhead， 但是经过努力，今后 TiDB 的行列转换在架构保持大体不变的情况下，实际运行时已经不构成明显的性能瓶颈。\n\n### TiDB 正式支持索引合并查询优化\n\n#### 用户场景与挑战\n\n以往有些查询在逻辑上需要同时扫描多个列，而之前版本的 TiDB 处理区域扫描的查询中只能选择单独某一列（或多列）上的索引（或一个复合列索引），即便各列上都已经有索引但整体的性能受此影响不能达到理想状态。在 TiDB 5.4 版本中，正式提供了索引合并功能，得以允许优化器在查询处理中同时选择使用多列的索引以减少回表，达到超过一两个数量级的过滤效果。对于此类以往容易形成性能瓶颈的问题在查询时间和性能稳定性上都有较大帮助，例如（参见下文）查询的响应时间可以由 600 毫秒缩短 30 倍至 20 毫秒，并提升一个数量级的查询并发度。\n\n#### 解决方案\n\nTiDB 在原有三种读数据算子基础上增加了第四种类型的算子 **IndexMergeReader**：\n\n1. TableReader\n\n2. IndexReader\n\n3. IndexLookUpReader\n\n4. **IndexMergeReader**\n\n前两种比较好理解，直接读取主表数据或者索引表数据。IndexLookUpReader（回表算子）会先读取索引表，得到 row_id，再根据 row_id 从主表中读取数据。\n\nIndexMergeReader 执行流程类似于 IndexLookUpReader，区别在于可以利用多个索引进行回表，在如下例的场景可以极大提升查询的性能：\n\n```sql\nSELECT * FROM t1 WHERE c1 < 10 OR c2 < 100;\n```\n\n上述查询中如果 c1/c2 上都有索引，但是由于过滤条件是 OR，无法单独使用 c1 或 c2 索引，导致只能进行全表扫。使用索引合并可以解决无法使用索引的问题：索引合并会单独利用 c1/c2 索引得到 row_idx ，然后将两个索引拿到的 row_id 进行 UNION 操作，以 UNION 操作的结果从主表中获取实际行。\n\n##### 索引合并优势场景\n\n数据来源为以 TPC-H SF 1 （lineitem 表行数为 600W），使用如下的查询来获取 lineitem 表中价格为 930，或者 orderkey 为 10000 且 comment 为特定字符串的行：\n\n ```sql\nSELECT l_partkey, l_orderkey\nFROM  lineitem\nWHERE ( l_extendedprice = 930\nOR l_orderkey = 10000 AND Substring(Lpad(l_comment, 'b', 100), 50, 1) = 'b' )\nAND EXISTS(SELECT 1\nFROM  part\nWHERE l_partkey = p_partkey);\n ```\n\n不使用索引合并时，执行时间为 **3.38s+**\n\n![4.jpeg](https://img1.www.pingcap.com/prod/4_46389ca6d4.jpeg)\n\n使用索引合并时，执行时间为 8.3ms：\n\n![5.jpeg](https://img1.www.pingcap.com/prod/5_452f57a098.jpeg)\n\n##### 索引合并非舒适场景\n\n如果使用过滤性很差的条件，则直接使用全表扫的性能会比使用索引合并更好\n\n```sql\nSELECT l_partkey, l_orderkey\nFROM  lineitem\nWHERE ( l_extendedprice >= 930     \nOR l_orderkey >= 10000 )    \nAND EXISTS(SELECT 1\nFROM  part\nWHERE l_partkey = p_partkey);\n```\n\n下面的查询没有使用索引合并，执行时间只有 2.34s\n![9.png](https://img1.www.pingcap.com/prod/9_95c5b18d23.png)\n\n使用 hint 强制优化器选择索引合并，由于需要额外的回表时间，执行时间需要 19.79s\n\n![10.png](https://img1.www.pingcap.com/prod/10_740b53fad9.png)\n\n##### 无明显收益场景\n\n在以下场景中，使用索引合并不会带来明显的收益\n在数据量不大的情况下，由于数据很快能扫描并过滤完成，使用索引合并不会有很大收益\n在过滤条件计算比较快的情况下（例如只是整型的比较），即使数据量相对较大（例如百万行级别），相对于全表扫，索引合并也不会有很大提升。\n\n如下查询，虽然条件的过滤性很高，但是由于计算比较轻量级（只是整型的比较），计算都在 TiKV 完成，所以使用索引合并(26ms) 和不使用索引合并(30ms) 性能差异不大。\n\n```sql\nSELECT l_partkey, l_orderkey\nFROM  lineitem\nWHERE ( l_extendedprice <= 930     \nOR l_orderkey = 10000 ) \nAND EXISTS(SELECT 1\nFROM  part\nWHERE l_partkey = p_partkey);\n```\n##### 资源消耗\n\n在索引合并优势场景的查询中，由于大部分行已经在 TiKV 过滤掉，所以 CPU/内存资源消耗基本可以忽略。\n\n未使用索引合并的查询，由于过滤条件无法下推，导致需要将所有行都传给 TiDB 进行 Selection 操作，内存消耗较大，在 10 个并发查询情况下，TiDB 需要 2G 内存来过滤 600W 行数据。\n\n![6.jpeg](https://img1.www.pingcap.com/prod/6_b8b7d64a7e.jpeg)\n\n#### 小结\n\n- 在过滤条件选择率较高时，可以考虑使用索引合并。数据流量较大且过滤条件较好的场景，查询响应时间可缩短 2 个数量级（本文给出的例子是 400 倍），将秒级响应的查询变为毫秒级。\n- 索引合并可大幅减少并发查询时的系统资源消耗，特别是过滤条件无法下推的查询（消耗资源较大）可以达到颠覆性的效果（例如原本消耗 2GB 的查询，使用索引合并之后资源消耗甚至可以忽略不计）。\n\n### TiDB Lightning 新增高效的重复数据检测特性\n\n#### 用户场景与挑战\n\n在生产环境中，由于历史原因，用户的各个分片 MySQL 实例的数据可能存在重复，当主键/唯一索引重复时则形成冲突数据。因此在将多个分片 MySQL 合并导入下游 TiDB 时必须进行检测和处理，且可能高达几十 TB 的单表数据量对检测效率也是一项极大的挑战。\n\n#### 解决方案\n\nTiDB Lightning 是用于从 CSV/SQL 文件高速导入大规模数据到新 TiDB 集群的工具。Lightning 的 local backend 模式可将源数据编码为有序键值对，直接插入 TiKV 存储，其导入效率极高，并且支持使用多台主机并行导入一张表，是目前初始化 TiDB 集群数据的常用方式。\n\n在 local backend 模式下，数据导入并不会经过事务写入的接口，因此无法在插入时检测冲突数据。在之前的版本， Lightning 仅能通过对比 KV 级别的校验码来实现，但局限性较大，仅能知晓发生了错误，却无法定位冲突数据的位置。\n\n新增的重复数据检测特性使得 Lightning 精准检测冲突数据，并且内置了一种冲突数据删除算法以自动聚合。检测到冲突数据后， Lightning 可以将其保存以供使用者筛选后再次插入。\n\n重复数据检测特性默认关闭，可以在使用时根据不同的场景需求设置 record/remove 等不同的处理方式。\n\n详细性能验证数据可参考下表：\n\n![7.png](https://img1.www.pingcap.com/prod/7_5f578c716a.png)\n\n#### 小结\n\n使用 Lightning 并行导入特性，开启重复数据检测，可以精准定位数据源中的冲突数据，执行效率在多次优化后耗时占比约为总时长的 20%。\n\n## 面向云环境的功能拓展\n\nTiDB 5.4 重视与云环境的生态结合，特别推出了一项可以大幅节约存储成本的 Raft Engine日志存储引擎,可为用户节约 30% 以上的数据传输费用同时还在某些场合下有额外的性能收益；强化了数据备份效率，在支持 Amazon S3、Google Cloud Storage 的基础上，新增了对 Azure 环境的支持，完成了与世界主流云厂商存储服务的对接。\n\n### 支持使用 Raft Engine 作为 TiKV 的日志存储引擎\n\n#### 用户场景与挑战\n\n云环境上用户最为关心的问题之一是成本，数据存储量和 IO 请求所产生的开销不可小觑。通常来说，分布式数据库在处理用户写入时需要复制并持久化记录大量的日志，这无疑会增加用户部署服务的成本。另一方面看，由于云环境下的硬件资源有较为明确的限制，当用户负载发生波动，而预设的硬件配置无法满足时，服务质量也会受到显著影响。\n\n#### 解决方案\n\nTiDB 5.4 推出一项**实验性功能**：Raft Engine，一款自研的[开源](https://github.com/tikv/raft-engine)日志存储引擎，相较于使用默认的 RocksDB 引擎，它最大的优势在于节省了磁盘带宽的使用量。首先，Raft Engine 将 TiDB 集群的“写入日志”压缩后直接存放在文件队列中，而不进行额外的全量转储。另外，Raft Engine 拥有更为高效的垃圾回收机制，利用过期数据的空间局部性进行批量清理，在大部分场景下不额外占用后台资源。\n\n这些优化能够大幅降低同等负载下 TiDB 集群中存储节点的磁盘带宽使用量。这意味着，同等水平的集群将能服务更高峰值的业务输入，而同等强度的业务可以缩减部分存储节点数量来获得近似的服务水平。\n\n另外，作为自研引擎，Raft Engine 具有更轻量的执行路径，在一些场景下显著减少了写入请求的尾延迟。\n\n在实验环境中，TPC-C 5000 Warehouse 负载下，使用 Raft Engine 能够减少集群约 30% 的总写入带宽，并对前台吞吐有一定提升。\n\n![8.png](https://img1.www.pingcap.com/prod/8_8402bc3c6e.png)\n\n详情参见[用户手册](https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file/#raft-engine)。\n\n#### 小结\n\n使用 Raft Engine 存储集群日志，能够有效减少写入带宽用量，节省云上部署成本的同时提升服务稳定性。\n\n### 支持 Azure Blob Storage 作为备份目标存储\n\nBackup & Restore (BR) 支持 Azure Blob Storage 作为备份的远端目标存储。在 Azure Cloud 环境部署 TiDB 的用户，可以支持使用该功能方便地将集群数据备份到 Azure Blob Storage 服务中，支持 **AD 备份** 和 **密钥访问** 两种恢复方式。囿于篇幅，具体信息请移步用户手册中的 [Azure Blob Storage 备份支持](https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-azblob/)与[外部存储](https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-storages/)章节。\n\n## 产品易用性和运维支持\n\nTiDB 5.4 持续提升产品易用性和运维效率，做出了以下的努力：为提升优化器生成执行计划的质量，增强了统计信息的收集和管理功能，可以针对不同的表、分区、索引设置不同的采集配置项并且默认保存设置，方便后续收集统计信息时沿用已有配置项；数据备份过程有时会影响正常业务，这是长久以来困扰一些用户的问题。5.4 BR 新增了备份线程自动调节功能，可显著减轻备份带来的负面影响；TiDB 运行过程中产生的大量日志数据处理不当会造成对性能和稳定性的影响，5.4 版本提供了新的实验特性可 使用 Raft Engine 保存日志，可以显著减少写流量和 CPU 使用率，提升前台吞吐减少尾延迟；此外，TiDB 自 5.4 开始[支持 GBK 字符集](https://docs.pingcap.com/zh/tidb/stable/character-set-gbk/)。\n\n### 统计信息采集配置持久化\n\n详情参见[用户手册](https://docs.pingcap.com/zh/tidb/stable/statistics/#analyze-%E9%85%8D%E7%BD%AE%E6%8C%81%E4%B9%85%E5%8C%96)。\n\n### 优化备份对集群的影响\n\n详情参见[用户手册](https://docs.pingcap.com/zh/tidb/stable/br-auto-tune/)。\n\n## 新增实用性功能涉及到的系统配置开关选项\n\nTiDB 5.4 对系统配置参数的优化做出了许多努力，完整信息可参见 [Release notes](https://docs.pingcap.com/zh/tidb/stable/release-5.4.0/) 和相关用户手册，本文仅举其中一项代表性的改善点。 \n\n### 支持 session 变量设置有界限过期读\n\nTiDB 是基于 Raft 协议的多副本分布式数据库。面对高并发，高吞吐业务场景，可以通过 follower 节点实现读性能扩展，构建读写分离架构。针对不同的业务场景，follower 可以提供以下两种读模式：\n\n- 强一致读：通过强一致读，可以确保所有节点读取的数据实时一致，适用于一致性要求严格的业务场景，但是因为 leader 和 follower 的数据同步延迟导致强一致读的吞吐较低、延迟较高，特别是在跨机房架构下延迟问题被进一步放大。\n\n- 过期读：过期读是指可以通过快照读取过去时间的过期数据，不保证实时一致性，解决了 leader 节点和 follower 节点的延迟问题，提升吞吐。该读模式适用于数据实时一致性要求较低或者数据更新不频繁的业务场景。\n\nTiDB 目前支持通过显示只读事务或 SQL 语句的方式开启 follower 过期读。两种方式均支持“指定时间”的精确过期读和“指定时间边界”的非精确过期读两种模式，详细用法请参考[过期读官方文档](https://docs.pingcap.com/zh/tidb/stable/tidb-read-staleness/)。\n\n从 TiDB 5.4.0 版本开始，TiDB 支持通过 session 变量设置有界限过期读，进一步提升易用性，具体设置示例如下：\n```bash\nset @@tidb_replica_read=leader_and_follower\nset @@tidb_read_staleness=\"-5\"\n```\n\n通过该设置，TiDB 可以通过 session 变量快速开启过期读，避免了频繁的显示开启只读事务或者在每个 SQL 内指定过期读语法，提升易用性，方便批量地实现就近选取 leader 或 follower 节点，并读取 5 秒钟内的最新过期数据，满足准实时场景下低延迟、高吞吐数据访问的业务诉求。 \n\n## 主要的 bug 修复和稳定性提升\n\n自 TiDB 5.1 版本发布以来，提高稳定性不断“捉虫”，是研发和 QA 团队最优先的任务。5.4 版本总计进行了 200 余项的体验优化，其中主要部分在 [Release notes](https://docs.pingcap.com/zh/tidb/stable/release-5.4.0/) 中记录，其他细节可以参考 [GitHub](https://github.com/pingcap/tidb) 上的 PR 记录。TiDB 研发和 QA 团队始终秉持对用户负责的姿态，使产品日臻完善，期待赢得广大用户的信任。\n\n## PM 寄语\n\n2022 年是广大 TiDB 用户事业虎虎生风蒸蒸日上的一年，希望 TiDB 5.4 能给用户带来更多的舒心，更多的便利，助力各种应用和业务的健康高效发展。敬请关注 [TiDB 官网](https://docs.pingcap.com/zh/tidb/stable/)，[GitHub](https://github.com/pingcap/tidb) 以及各种社交媒体账号，谨代表 TiDB 产品经理（PM） 团队、研发工程与质量团队一道，期待与广大用户一起开创更美好的一年。如果您对 TiDB 的产品有任何建议，欢迎来到 [internals.tidb.io](https://internals.tidb.io) 与我们交流。\n\n查看 TiDB 5.4.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-5.4.0)，立即[下载试用](https://pingcap.com/zh/product/)，开启 TiDB 5.4.0 之旅。\n","date":"2022-02-15","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-5.4-release","file":null,"relatedBlogs":[]},{"id":"Blogs_320","title":"TiDB 5.3 发版 —— 跨越可观测性鸿沟，实现 HTAP 性能和稳定性的新飞跃","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"2021 年 11 月 30 日，TiDB 5.3.0 版本正式上线，该版本推出持续性能分析 （Continuous Profiling) 功能（目前为实验特性），跨越可观测性的鸿沟，为用户带来数据库源码水平的性能洞察，彻底解答每一个数据库问题。","body":"“当用户使用软件时，会需要面对的两个鸿沟：一个是执行的鸿沟，在这里，用户要弄清楚如何操作，与软件「对话」；另一个是评估的鸿沟，用户要弄清楚操作的结果。” PingCAP 联合创始人兼 CTO 黄东旭在《做出让人爱不释手的基础软件》中提到，“ 我们作为设计师的使命就是帮助用户消除可观测性和可交互性这两个鸿沟。” \n\n2021 年 11 月 30 日，**TiDB 5.3.0 版本正式上线**，该版本推出持续性能分析 （Continuous Profiling) 功能（目前为实验特性），跨越可观测性的鸿沟，为用户带来数据库源码水平的性能洞察，彻底解答每一个数据库问题。\n\n在提升数据可观测性的同时，**TiDB 5.3.0 实现了 HTAP 性能和稳定性的大幅提升，数据迁移效率、高可用性和易用性也实现了大幅提升，为所有用户带来重磅福利**。\n\n## 5.3.0 功能亮点与用户价值\n* 支持持续性能分析 (Continuous Profiling) ，引领数据库的可观测性潮流\n* 深度优化分布式时间戳获取技术，提升系统的整体性能\n* 持续优化存储和计算引擎，提供更敏捷更可靠的 HTAP 服务\n* 进一步降低上游系统同步数据至 TiDB 的延迟，助力高峰期业务增长\n* 新增并行导入功能，提升全量数据迁移效率\n* 引入临时表，一条 SQL 语句简化业务逻辑并提升性能\n\n## 支持持续性能分析，引领数据库的可观测性潮流\n\n在企业遭遇的 IT 故障中，约有 30% 与数据库相关。当这些故障涉及到应用系统、网络环境、硬件设备时，恢复时间可能达到数小时，对业务连续性造成破坏，影响用户体验甚至营收。在复杂分布式系统场景下，如何提高数据库的可观测性，帮助运维人员快速诊断问题，优化故障处理流程一直是困扰着企业的一大难题。在 TiDB 5.3.0 版本中，PingCAP 率先在数据库领域推出了持续性能分析 (Continuous Profiling) 特性（目前为实验特性），为企业提供了数据库源码水平的性能洞察。\n\n持续性能分析以低于 0.5% 的性能损耗实现了对数据库内部运行状态持续打快照（类似 CT 扫描），以火焰图的形式从系统调用层面解读资源开销。 让原本**黑盒**的数据库变成**白盒**。在 TiDB Dashboard 上一键开启持续性能分析后，运维人员可以方便快速定位性能问题的根因，无论过去现在皆可回溯。\n\n![1.png](https://img1.www.pingcap.com/prod/1_3ef5025427.png)\n\n* **当数据库意外宕机时，可降低至少 50% 诊断时间**\n\n在互联网行业的一个案例中，当客户集群出现报警业务受影响时，因缺少数据库连续性能分析结果，运维人员难以发现故障根因，耗费 3 小时才定位问题恢复集群。如果使用 TiDB 的持续性能分析功能，运维人员可比对日常和故障的分析结果，仅需 20 分钟就可恢复业务，极大减少损失。\n\n* **在日常运行中，可提供集群巡检和性能分析服务，保障集群持续稳定运行**\n\n持续性能分析是 TiDB 集群巡检服务的关键，为商业客户提供了集群巡检和巡检结果数据上报。客户可以自行发现和定位潜在风险，执行优化建议，保证每个集群持续稳定运行。\n\n* **在数据库选型时，提供更高效的业务匹配**\n\n在进行数据库选型时，企业往往需要在短时间内完成功能验证、性能验证的流程。持续性能分析功能能够协助企业更直观地发现性能瓶颈，快速进行多轮优化，确保数据库与企业的业务特征适配，提高数据库的选型效率。\n\n**注**：性能分析结果存储在监控节点上，不会对处理业务流量的节点产生影响。\n## 深度优化分布式时间戳获取技术，为海量业务数据处理提供坚强后盾\n当互联网行业的核心业务系统具有庞大的用户数量和业务数据时，在高并发访问的场景下，可能会出现数据库时间戳获取延迟增大而导致业务响应变慢、超时频发、用户体验急剧下降的情况。海量的业务数据要求数据库拥有良好的扩展性。TiDB 本身拥有能够水平扩展的优势，但是不断增长的业务数据量使时间戳获取能力逐渐成为阻碍集群扩展的瓶颈，最终限制集群整体的扩展。\n\n为进一步提升时间戳获取能力，在 TiDB 5.3.0 版本中，TiDB 在保持原有的全局时间戳管理方式的基础上，新增两个时间戳处理调优参数，在 PD 负载达到瓶颈的情况下，可以有效减轻负载，降低了时间戳获取延迟，大大提升了系统的整体性能：\n\n* 支持参数设置 PD follower proxy 开关，开启后允许 follower 批量转发时间戳处理请求。\n* 支持设置 PD client 批量处理时间戳的最大等待时间参数，提高时间戳请求的处理带宽。\n\n通过本次优化，TiDB 能够更好地支撑百 TB 或百万 QPS 大规模集群的扩展。经过 Sysbench 512 线程的测试验证，时间戳处理流程优化后，TiDB 集群整体 QPS 吞吐提升了 100% 以上。具体测试环境如下：\n\n| 角色 | 数量 | 规格     |\n| ---- | ---- | -------- |\n| TiDB | 26   | 8 cores  |\n| PD   | 3    | 4 cores  |\n| TiKV | 5    | 12 cores |\n\n\n本次优化适用于以下场景：\n\n* 拥有百 TB 或 百万 QPS 以上超大规模集群，需要实现大规模集群的扩展。\n* 拥有中等规模集群，但随着业务的急速增长，数据的成倍增加，需要实现集群的无限扩展。\n\n## 持续优化存储和计算引擎，提供更敏捷更可靠的 HTAP 服务\n在大型物流和金融服务类企业中，在线交易和实时业务监控等应用场景对数据有较高的一致性和时效性要求，尤其是当读写混合负载大时，会对数据库管理系统的性能和稳定性形成较大挑战。在年度流量峰值时段，数据平台的写入/更新和分析任务往往会激增数倍。例如，某合作伙伴（物流龙头）在双十一期间，每天处理超 2500 亿条更新和插入记录，同时还要兼顾海量历史数据（50 亿～100 亿）的分析任务。\n\nTiDB HTAP 致力于为企业的规模化在线交易和实时分析应用提供一栈式数据服务平台，提升关键业务的时效性，降低数据技术栈的复杂性。在已有产品基础上，TiDB 5.3.0 进一步优化了 HTAP 的性能和稳定性，大幅改善了高混合负载场景下并发查询能力和查询任务的执行速度。主要的改进包括：\n\n* **性能大幅提升（50%～100%），CPU /内存资源使用率进一步优化，查询失败减少**：TiDB 5.3.0 优化了列式存储引擎，调整了存储引擎底层文件结构和 IO 模型，优化了访问节点副本和文件区块的计划，缓和了写放大问题以及改进了普遍的代码效率。总体上高负载时因资源不足造成的失败状况大大缓解。\n* **远程数据读取提速，任务成功率提高，告警可读性增强**：优化了 MPP 计算引擎，支持更多的字符串/时间和其他函数/算子下推至 MPP 引擎，并改善了存储层写入/更新事务量较大时数据等待造成内部进程超时的问题，同时还优化了查询请求的告警信息，便于追踪和定位问题。\n* **轻松扩展节点**：在 TiDB 5.3.0 中，TiDB HTAP 架构可随业务增长轻松扩展到 200 节点甚至更大的集群规模，并且确保 OLTP 与 OLAP 之间原则上不产生资源冲突和相互性能影响。\n* **增强运维能力**：完善了数据校验，解决了节点重启时内部处理可能出现的问题；同时进一步提升了 SQL 告警信息和增强了日志收集、检索功能。\n\n## 低延迟同步至 TiDB，助力企业业务持续增长\n伴随着业务持续增长，企业订单系统的数据库压力也不断增加。核心交易库写流量巨大，造成订单提交时间变长，影响网站用户体验。面对这一典型的业务场景，为了帮助提升企业缩短订单提交时间，TiDB 支持作为下游只读从库提供业务查询服务，为核心交易系统减压。\n\n**TiDB Data Migration (DM) 作为一款实时的数据同步工具，支持将数据从与 MySQL 协议兼容的数据库同步到 TiDB，实现业务分流，减轻高峰期前端订单写入时的压力**。而交易场景高度的即时性，要求业务查询延迟极低、数据实时性极高，这给 DM 的同步性能带来了极大挑战。\n\n为了保证低延迟，数据迁移工具 DM 在 v5.3.0 实现了两项优化：\n\n* 合并单行数据的多次变更，减少同步到下游的 SQL 数量，提高迁移效率，降低数据延迟，为网站用户更快地提供业务查询服务；\n* 批量的点查更新合并为单一的语句操作，减少远程过程调用请求的数量，同样数量的 binlog 可以更快地同步完成，进而降低延迟，为网站用户更准确地提供业务查询服务。\n\n极低的同步延迟保障了下游 TiDB 数据查询实时性，企业在保持现有架构的情况下，无需进行大规模改造，就能快速引入 TiDB 以增强实时查询分析能力，更好更快萃取数据价值。\n\n经场景实测，在 300K QPS 数据同步流量下，99.9% 时间内 DM 同步延迟降低至 1 秒以内，尤其适用于高负载业务压力下 TiDB 作为只读从库的场景。\n\n## 新增并行导入功能，提升全量数据迁移效率\n目前 MySQL 分库分表架构日益普遍，很多企业的数据量已经达到百 TB 级别。随着企业数据量的增长，从集中式数据库迁移到以 TiDB 为代表的分布式数据库已经成为必然，然而存量系统里面的 100 TB 数据没有方便高效的工具进行迁移。 \n\n为解决此问题，TiDB 5.3.0 发布了 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-distributed-import#tidb-lightning-%E5%88%86%E5%B8%83%E5%BC%8F%E5%B9%B6%E8%A1%8C%E5%AF%BC%E5%85%A5\n) 并行导入功能，提供了高效的 TiDB 集群初始化能力。用户可以同时启动多个 TiDB Lightning 实例，并行地将单表或者多表数据迁移到 TiDB，**速度可以横向扩展，极大地提高了数据迁移效率**。 \n\n并行导入示意图如下。用户可以使用多个 TiDB Lightning 实例导入 MySQL 的分表到下游的 TiDB 集群。\n\n![2.png](https://img1.www.pingcap.com/prod/2_03c383a08d.png)\n\n并行导入功能支持多种数据源，包括：CSV/SQL 格式的文本数据、MySQL 分表导出数据 。支持的最大单表规模在 20 TB ～ 30 TB 之间，导入单表数据建议使用 1 个 ～ 8 个 TiDB Lightning 实例，每个实例最佳规模保持在 2 TB～ 5 TB 。对于多表总规模和使用 Lightning 的个数没有上限要求。 \n\n经测试，使用 10 台 TiDB Lightning，20 TB 规模的 MySQL 数据可以在 8 小时内导入到 TiDB，单台 TiDB Lightning 可以支持 250 GB/h 的导入速度，整体效率提升了 8 倍。\n\n## 引入临时表，一条 SQL 语句简化业务逻辑并提升性能\n### 业务临时中间数据存储不易\n在数据量大的场景下，用户业务常常需要处理庞大的中间数据。如果业务需要反复使用数据中的一部分子集，用户通常会临时保存这部分数据，用完后释放。因此，DBA 不得不频繁地建表和删表，可能还需要自行设计数据存储结构，把中间数据存储至业务模块中。这不仅增加了业务复杂度，也造成了庞大的内存开销，而且如果管理不善，还存在内存泄漏导致系统崩溃的风险。\n\n### TiDB 临时表帮助用户简化业务逻辑并提升性能\n为帮助用户解决以上痛点，TiDB 在 5.3.0 版本中引入了临时表功能。该功能针对业务中间计算结果的临时存储问题，让用户免于频繁地建表和删表等操作。用户可将业务上的中间计算数据存入临时表，用完后自动清理回收，**避免业务过于复杂，减少表管理开销，并提升性能**。\n\nTiDB 临时表主要应用于以下业务场景：\n\n* 缓存业务的中间临时数据，计算完成后将数据转储至常规表，临时表会自动释放。\n* 短期内对同一数据进行多次 DML 操作。例如在电商购物车应用中，添加、修改、删除商品及完成结算，并移除购物车信息。\n* 快速批量导入中间临时数据，提升导入临时数据的性能。\n批量更新数据。将数据批量导入到数据库的临时表，修改完成后再导出到文件。\n\n### 一条 SQL 语句轻松创建临时表\n可通过 CREATE [GLOBAL] TEMPORARY TABLE 语句创建临时表。临时表中的数据均保存在内存中，用户可通过 tidb_tmp_table_max_size 变量限制临时表的内存大小。\n\nTiDB 提供的临时表分为 Global 和 Local 两类，无论使用哪种临时表，都能**有效帮助用户简化业务逻辑并提升性能**：\n\n* Global 临时表：\n1. 对集群内所有 Session 可见，表结构持久化。\n2. 提供事务级别的数据隔离，数据只在事务内有效，事务结束后自动删除数据。\n* Local 临时表：\n1. 只对当前 Session 可见，表结构不持久化。\n2. 支持重名，用户无需为业务设计复杂的表命名规则。\n\n提供会话级别的数据隔离，降低业务设计复杂度，会话结束后删除临时表。\n\n## 结语\n本次发布的 5.3.0 版本**进一步完善了系统的可观测性、提升了分布式数据库可扩展性、保证了数据的低延迟同步、大幅提升了全量数据迁移效率、提升了实时分析的稳定性**，是 TiDB 迈向成熟企业级 HTAP 平台的一个重要里程碑。\n\nPingCAP 首席架构师唐刘表示：TiDB HTAP 的使命不仅仅局限于对传统数据库的升级或者是交易和分析处理性能的提升，本质上 TiDB HTAP 是一个开放的生态体系，在企业中承担着支持数据服务消费化和构建统一实时数据服务平台的角色，为用户带来业务与架构的创新与提升。\n\nTiDB 的每一次发版和进步都离不开每一位用户的反馈、每一位开发者的 PR 合并、每一位质量保证人员的测试。感谢所有人的贡献，TiDB 在后续版本中会不断加强大规模场景下的稳定性和易用性，**不忘初心，砥砺前行，成为一款让人爱不释手的基础软件，给用户带来更好的使用体验**。\n\n查看 TiDB 5.3.0 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-5.3.0)，立即[下载试用](https://pingcap.com/zh/product/)，开启 TiDB 5.3.0 之旅。\n","date":"2021-11-30","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-5.3-release","file":null,"relatedBlogs":[]},{"id":"Blogs_302","title":"TiDB 5.2 发版 ——“交易+分析”双引擎提速，挑战极限业务场景","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"","body":"作为数字化新时代的企业级数据库， TiDB 基于海量数据规模的在线事务处理和实时分析能力在全球金融、互联网、物流、零售、在线游戏等各个行业得到充分验证，并广受好评。今年 4 月 ，TiDB 发布针对企业级的里程碑 5.0 版本，并在 6 月份发布了 5.1 版本，目前已经应用在数十家大型企业的生产环境。 \n\nTiDB 5.2 聚焦于用户真实场景，挑战更为严苛的超大规模 OLTP 和实时数据分析的性能极限，进一步拓展了“交易+分析”双引擎数据处理能力的边界。测试结果表明，无论是高负载大集群场景还是高吞吐写入的并发实时分析场景，TiDB 5.2 均表现出了更优异的稳定性、更出色的实时性、更佳的易用性，可以更轻松地加速企业实现数字化转型和数据价值变现。\n\n## TiDB 5.2 功能亮点和用户价值\n\n近年来，为满足不同场景的业务需求，企业内部往往存在不同的数据存储方案，造成在线和离线业务数据分离，全量数据实时查询和分析成为难题。\n\n在这种情况下，企业可以将数据实时汇聚到可无限水平扩展并兼容 MySQL 的 TiDB，由 TiDB 直接对接数据应用端。数据汇聚到 TiDB 后，无论是处理面向 C 端或 B 端客户的 OLTP 请求（例如，电商平台的 C 端和 B 端请求分别来自买家和卖家，物流平台的 C 端和 B 端请求分别来自寄件人和快递员），还是处理企业后台实时数据服务（例如，Real-time BI、风控、Ad-Hoc 查询），TiDB 都可以提供一站式的数据解决方案，帮助企业打通数据孤岛，既能保证高负载下大集群的查询稳定性和实时性，又能保证高吞吐写入下的并发实时查询和分析的性能与稳定性，并降低企业运维成本。\n\n![1-update.jpeg](https://img1.www.pingcap.com/prod/1_update_c2966b7825.jpeg)\n\nTiDB 5.2 针对多源实时数据汇聚四大典型场景中的主要挑战和特点做了大量优化，为不同场景量身打造更好用、更省心的数据库。\n\n**在面向 C 端用户的高并发、高频查询场景中，全面提升高负载下大集群的稳定性**\n\n- 提升大表在高负载写入时在线建索引的速度，优化大流量写入时的内存使用，提升高读写负载压力下大集群的稳定性。\n- 实现 Leader 自动转移，降低单节点性能抖动对整个集群的影响。\n- 升级热点调度策略，有效打散小表热点，并且提供列存引擎 TiFlash 的热点调度能力，实现集群资源的充分利用。\n- 在 200K QPS 压力负载下，DM（TiDB Data Migration）仍可以保证 99% 时间的数据同步延迟在 1s 以内，提高汇聚库的数据更新实时性。\n\n**在面向 B 端客户中等并发的实时综合查询场景中，使优化器执行计划更智能**\n\n- 当数据不断更新时，针对统计信息过期或缺失的情况，提升优化器选中正确索引的概率；提升估算模块的准确度，减少人工绑定索引。\n- 当使用 SPM（SQL Plan Management, 执行计划管理）功能自动或人工绑定索引时，用户可以更容易地使用、诊断、调试 SPM 功能。\n\n**在实时 BI 场景中，让企业轻松应对复杂实时 BI 查询，让业务决策更实时**\n\n- 实现更多的算子下推，更充分地利用 MPP 引擎的能力，降低查询的响应时间。\n\n**在高吞吐写入的同时提供并发实时分析的场景中，提升并发实时分析性能和稳定性，助力企业从容应对双十一**\n\n- 平稳支持超平时 200%～300% 的峰值写入流量，提供更强大的数据写入支持。\n- 消除了在特殊条件下内部线程互相等待死锁的状况，带来更智能的 MPP 执行引擎，提高分析处理能力。\n- 提升并发能力，可支持 30 量级的并发查询（全表扫描型）稳定执行。\n\n## 提升高负载下大集群的稳定性，挑战极限业务场景\n\n面向 C 端用户的高并发、高频查询以点查为主，也有部分基于索引的小范围查询，需要底层数据库具有非常好的弹性扩展能力、极低的查询延迟、极高的业务查询的稳定性。例如，在交易所的账户和订单等核心场景，业务对延迟极为敏感（订单写入需要控制在 1ms 以内），同时需要提供对客户端的高并发历史订单查询，在高峰期可能会对主流程造成影响。在此场景下，可以采取主从架构，突破 MySQL 单机瓶颈限制，通过数据迁移工具 DM 将前端多个 MySQL 分片的数据实时汇聚到一个 TiDB 集群，由 TiDB 承载核心链路上的高频查询，避免高峰期对前端订单写入造成压力，从而影响交易业务。\n\n![2-update.png](https://img1.www.pingcap.com/prod/2_update_12c7a6d2ce.png)\n\n针对这些高负载低延迟的场景，TiDB 5.2 进一步提升了大规模 OLTP 性能和稳定性，为用户带来更流畅的业务体验：\n\n**提升高读写负载压力下大集群的稳定性**\n\n- 提升大表在线建索引的速度：在 DDL 过程中合理均衡热点 Region 的 range。\n- 实现 Leader 自动转移：当某个存储节点变慢时，将 Raft 协议中的 leader 角色自动转移到正常的存储节点上以承载业务流量，保证单节点出现性能抖动时集群整体吞吐能力不受影响。\n- 优化 TiKV 的内存使用：严格限制 Raft Log 的 cache 以及 Raft 消息的内存占用，解决了在大流量写入情况下 TiKV 潜在的 OOM 问题。\n\n**热点调度引入 QPS 参考维度，实现集群资源的充分利用**\n\n- 支持按维度调整热点均衡优先级，提高了对热点场景的处理能力，确保在节点数较多的集群中均衡 CPU 的使用率，避免出现单点瓶颈。在热点小表客户仿真场景中，CPU 资源的均衡度大幅提升，QPS 提升了近一倍。另外也支持对 OLAP 引擎 TiFlash 的热点调度能力，解决了 HTAP 场景的热点调度问题。\n\n**提升高负载下 DM 数据同步的性能和稳定性，提高汇聚库的数据更新实时性**\n\n- 减少 DM 资源消耗：DM 2.0.6 以前版本对 CPU 资源消费较多。单 DM 节点的复制流量 1k ~ 3k QPS 下，消耗 35% ～ 50% 的 CPU 资源。为了减少资源的消耗，v2.0.6 版本对多个逻辑点进行了优化，包括 relay log 读写、数据转码优化等。测试结果表明，DM v2.0.6 最多可减少 50% 的 CPU 使用量。\n- 大流量低延迟实时复制：使用 DM 同步 MySQL Shard 上的高负载（聚合后 200K QPS）业务写入数据到 TiDB，DM 可以保持 99% 时间内 1s 实时数据同步延迟。\n\n## 优化器执行计划更智能，助力电商平台大促卖家订单处理\n\n面向 B 端客户中等并发的综合查询通常基于索引查找小范围的数据，查询语句多样化，表关联可能会比较多，会遇到聚合、子查询、Top N 排序以及翻页 Limit。大小商户的数据量差异可能会非常大，通常有数据倾斜。电商平台通常采用读写分离的数据库架构，借助 TiDB 数据迁移工具 DM 将上游分库分表的订单实时汇聚到一个 TiDB 集群，提供实时的数据存取和查询服务。在电商大促销期间，面对比平时高几倍甚至几十倍的查询流量，如何在平台数据不断更新的情况下提高查询性能是对数据库的一大挑战。\n\n**TiDB 5.2 版本提供了一个更智能的查询优化器，使数据库能高效选中包含正确索引的最优的执行计划，更快速稳定地给出查询结果，为企业带来更实时的数据查询体验：**\n\n- 当优化器生成执行计划所需的统计信息过期或缺失时，TiDB 优化器会先使用启发式规则的方法来对索引进行裁剪和优化，提升选中正确索引的概率。\n\n- 对优化器的估算模块进行了优化，使更多的查询可由优化器来自动选择正确索引计划，减少人工绑定索引。\n\n- 当使用 SPM（SQL Plan Management, 执行计划管理）功能自动或人工绑定索引时，用户可以更容易地使用、诊断、调试 SPM 功能：\n\n  - 绑定的查询语句会按照绑定时间戳排序显示，不再是无序显示的结果，方便定位绑定的语句。\n  - 支持通过 `EXPLAIN` 语句执行的附加信息获知该 SQL 语句是否使用了绑定。\n  - 支持通过设置黑名单定义自动捕获绑定的语句，为用户带来更大的使用灵活性。\n\n## 轻松应对复杂实时 BI 查询，让业务决策更实时\n\n实时 BI 提供商业智能系统中的数据实时动态刷新，具有数据量大、查询复杂、高并发性等特点，同时对查询的实时性有较高要求。例如，在金融领域，大量的交易数据需要给业务或风控部门提供自助分析，帮助用户及时调整金融方案。这些数据同时包含历史数据和实时数据，动辄几千万行，较为复杂的查询则会关联多个这样的数据表，且包含复杂度量（例如精确去重）的计算。\n\nTiDB 的 HTAP 功能是这类需求的理想解决方案，**一方面 TiDB 提供了高速的数据写入能力**，实时数据可以高并发地写入至 TiKV 中，并利用 Raft 协议快速准确地将数据同步至 TiFlash 的列存中，实现了数据的实时性；**另一方面，TiFlash 支持 MPP 模式的查询执行**，最大限度地利用了计算资源，实现了数据查询的实时性。TiFlash 支持的函数或算子越多， TiDB 可以下推至 TiFlash 节点进行计算的 SQL 语句就越多，查询性能就越高。值得注意的是，只要某条 SQL 语句中存在一个尚不支持下推到 TiFlash 的算子或函数，该 SQL 语句的整个执行计划都无法下推至 TiFlash 节点，从而无法享受查询性能的提升。因此，多支持一个函数或算子就意味着某些特定查询数量级的性能飞跃。\n\n为了给复杂 BI 场景带来更高的实时性，TiDB 5.2 新增了几十个下推函数和算子（如 MOD, LENGTH, LOG, ROUND, DATE, INET_ATON 等，详情请查看 [TiDB 5.2 TiFlash 新增下推支持](https://docs.pingcap.com/zh/tidb/stable/release-5.2.0#%E6%8F%90%E5%8D%87%E6%94%B9%E8%BF%9B)，进一步完善了 TiFlash 的 SQL 语法支持。实际测试发现，TiFlash 在新支持某个函数后：\n\n- 单并发场景下，简单查询的查询延迟由数十秒降低至不到一秒，复杂查询则是由数分钟降低至一秒左右。\n- 数十并发场景下，简单查询依然可以以不到一秒的延迟响应查询，复杂查询则是从查询超时降低至 10 秒左右。\n\n**我们计划在未来一年内持续支持剩余常用的 MySQL 函数和算子，持续提升 BI 实时分析的查询响应时间。**\n\n## 提升高吞吐写入下的并发实时分析性能和稳定性，助力物流平台备战双十一\n\n随着互联网时代的到来，提供海量数据实时分析服务的场景日益增多。以国内某头部物流公司的双十一场景为例，该公司一个基于宽表的典型 BI 查询应用，数据总量达百亿级别、日均更新达过亿级别、BI 实效性控制在分钟级、且有较高并发要求。TiDB 通过无限水平扩展的存储和实时 HTAP 的特性，较好地满足了该公司的需求。但随着双十一数据更新和分析任务的同时激增，业务对 TiFlash 的稳定性提出了更高的要求：**如何避免节点磁盘内存使用不均衡引发内存 OOM、 如何缓解 IO 等系统资源压力、如何解决在大流量数据写入时产生的热点问题。**\n\n为了更好地满足前端海量数据写入+后端实时报表的需求，TiDB 5.2 提供以下功能助力企业更轻松地应对大数据量与高并发带来的压力。\n\n- 更强大的数据写入支持：同规模的集群可以平稳承受 200%～300% 于以往的峰值写入流量，实现“写平衡”，各节点磁盘空间差异在 10% 以内。\n- 更健壮的 MPP 执行引擎：消除了在特殊条件下内部线程互相等待死锁的状况，进一步改善在高负载情况下查询出错或超时取消的问题。\n- 更高的并发支持：在 20～30 并发量级的全表扫描查询，业务查询不出现内存 OOM。在更高的写入流量和并发查询下，出现 OOM 现象可减少 90%以上。\n- 更简单的运维：即使偶发集群不稳定状态（例如节点重启），系统可以自动恢复，或在人工干预下很快恢复。在扩缩容集群时，对客户端的查询响应不会停止，极大地降低了维护 TiFlash 集群时对业务的影响。\n\n## 结语\n\nTiDB 针对极限 OLTP 和 OLAP 场景的产品能力打造和持续优化提升，具有非常大的挑战。5.2 版本只是一个开端，我们将在后面 1～2 个版本按照用户反馈持续优化、快速迭代，**把复杂交给 TiDB，把简单留给用户**，打造更加适合用户场景的数据库。\n\nTiDB 自 5.1 版本开始采用火车发版模型，加速场景和功能的升级迭代，感谢 TiDB 社区每一位开发者的贡献，特别感谢知乎、理想汽车、小米等公司为 5.2 版本的产品改进提供的宝贵建议。相信在大家的共同努力和开放透明的协作下，TiDB 会越来越好，为用户创造更多价值，助力用户更好地拥抱数字化时代。\n\n查看 [TiDB 5.2 Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-5.2.0)，立即[下载试用](https://pingcap.com/zh/product/)，开启 TiDB 5.2 之旅。","date":"2021-08-30","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-5.2-ga-is-now","file":null,"relatedBlogs":[]},{"id":"Blogs_348","title":"TiDB 5.1 发版，打造更流畅的企业级数据库体验","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"TiDB 5.1 拥有更加稳定的响应延迟表现，更优的 MPP 性能与稳定性，更便捷的可运维性，开发者和 DBA 可以轻松地基于 TiDB 5.1 构建任意规模的关键业务应用。","body":"自 TiDB 5.0 发布以来，陆续在金融、互联网 & 新经济、物流等行业用户的生产环境得到应用，收获不少用户的积极评价：\n\n- TiDB 服务 58 金融、安居客等数仓报表的复杂读取与关联查询，在多表关联查询中，相比 4.0 版本性能最高提升达 90%；\n\n- 经过网易互娱场景实测，与 4.0 相比 TiDB 5.0 整体性能表现更加稳定，没有出现明显的抖动；\n\n- TiDB 5.0 在汽车之家大数据 join 与聚合场景的应用中，MPP 体现出明显的优势，与 MySQL 相比总体效能提升 20 - 50 倍。\n\n“用户的反馈激励我们不断前行，我们的使命是持续提升开发者和 DBA 的体验，让用户用得省心，用得顺手。” PingCAP 联合创始人兼 CTO 黄东旭说，“ TiDB 每一个版本的发布都立足于解决 DBA 的痛点。真实场景就是最好的架构师，从 5.0 版本开始 TiDB 缩短了发版周期，采用了更灵活、更敏捷的火车发版模型，每一个用户真实场景需求的输入，在两个月周期内就有可能成为下一个版本交付的功能。”\n\n得益于大量用户真实应用场景的快速反馈，TiDB 5.1 提速发版，进一步打造更流畅的企业级数据库体验。TiDB 5.1 拥有更加稳定的响应延迟表现，更优的 MPP 性能与稳定性，更便捷的可运维性，开发者和 DBA 可以轻松地基于 TiDB 5.1 构建任意规模的关键业务应用。\n\n## TiDB 5.1 功能亮点和用户价值\n\n- 支持 ANSI SQL 99 标准的 Common Table Expression，用户可以写出更加简洁、更易维护的 SQL 代码，轻松应对复杂的业务逻辑，提高开发效率。\n\n- 进一步提升 MPP 性能和稳定性，帮助用户更快做出实时决策。5.1 通过支持 MPP 模式下的分区表以及新增的多个函数表达式和算子优化，实时分析性能提升一个数量级以上；通过增强的内存管理和负载平衡机制，让分析查询变得更快、更稳。\n\n- 在突发的大流量写入、集群扩缩容以及在线数据导入和备份等场景下，5.1 版本优化了数据库的长尾查询延迟的稳定性，应对不同的工作负载，延迟能够降低 20% - 70% 。尤其对于金融行业延迟敏感类型的关键业务应用，大幅提升了在高压力负载下的查询稳定性。\n\n- 支持列类型变更，与 MySQL 兼容度更高。5.1 新增 Stale Read 模式，在读写分离场景中通过打散读热点大幅提升读吞吐能力；引入新的系统表，实现在高并发事务场景中快速定位锁冲突；改进统计信息分析引擎，提升优化器选择索引的精准度，保障业务查询的效率和稳定性。\n\n- 面向大集群提供更加友好的运维体验，进一步降低 DBA 工作负荷。5.1 版本集群扩缩容和数据迁移速度提升 40%，改善了大规模集群运维的可靠性，降低大规模集群整体备份和恢复的耗时，通过优化 CDC 数据链路临时中断后的自动恢复机制，进一步提升数据同步链路的可靠性。\n\n## Common Table Expression - 让 SQL 化繁为简\n\n在金融交易类场景，由于业务的客观复杂性，有时候会写出长达 2000 行的单条 SQL 语句，其中包含大量的聚合和多层子查询嵌套，维护此类 SQL 堪称开发人员的噩梦。5.1 版本支持 ANSI SQL 99 标准的 [Common Table Expression（CTE）](https://docs.pingcap.com/zh/tidb/v5.1/sql-statement-with)及递归的写法，极大提升开发人员和 DBA 编写复杂业务逻辑 SQL 的效率，增强代码的可维护性。\n![1.jpg](https://img1.www.pingcap.com/prod/1_beb60444a4.jpg)\n\n## HTAP 实时分析能力再升级\n\n### 进一步提升 MPP 的性能和稳定性\n\n5.1 版本进一步增强 TiFlash  MPP 计算引擎的综合能力，帮助用户提升业务决策速度：\n\n- MPP 支持分区表，结合业务逻辑可优化海量数据分析查询所消耗的资源，提升查询速度；\n\n- 新增多个常用 SQL 函数支持，并优化算子使得查询能够更充分利用 MPP 来加速；\n\n- 提供便利的强制 MPP 模式开关，用户可自主决定是否开启 MPP 模式；\n\n- 通过优化集群负荷的分散与平衡机制，消除热点，提升系统“综合”承载能力；\n\n- 修复引擎内存使用问题，提供更加平稳流畅的使用体验。\n\n###  升高压力负载下查询分析的稳定性\n\n在金融类业务场景下，技术人员每天会对数据进行高压力的跑批计算，生成最新的市场和营销分析报告，以辅助商业决策。跑批流程对连续性要求极高，无法容忍中间过程出错。针对该场景，5.1 版本优化了 TiDB 的请求重试机制和 TiKV 的请求处理机制，显著降低了在高负载下由于 TiFlash 同步数据不及时导致的 [Region Unavailable](https://docs.pingcap.com/zh/tidb/stable/troubleshoot-tiflash#%E9%83%A8%E5%88%86%E6%9F%A5%E8%AF%A2%E8%BF%94%E5%9B%9E-region-unavailable-%E7%9A%84%E9%94%99%E8%AF%AF) 出错概率。\n\n### 无缝集成 TiSpark\n\nTiSpark 5.1 版本实现了对含有聚簇索引表的读写支持，不带来任何额外的性能开销，对用户完全透明，用户可以立刻迁移到新版 TiSpark 来体验与 TiDB 5.1 的无缝集成。\n\n## 降低读写延迟抖动\n\n在延迟敏感的应用场景下，当线上产生突发写流量、操作 TiDB 扩缩容、后台执行统计任务，以及在线数据导入和备份时，可能造成数据库的 P99 和 P999 百分位的延迟抖动，对长尾查询产生一定影响.\n\nTiDB 5.1 加强了对磁盘读写链路的管理，限制后台任务对磁盘资源的使用，大幅降低上述场景对线上业务的干扰，改善读写链路的效率和稳定性。在 AWS EC2 r5b.4xlarge 实例挂载 EBS gp3 盘的环境下，通过 TPC-C 基准测试（10k WH）的实测结果：\n\n- 操作集群从 6 台 TiKV 缩到 3 台，P99 响应时间降低 20%，P999 响应时间降低 15%；\n\n- 执行在线导入 200GB 数据，P99 响应时间降低 71%，P999 响应时间降低 70%。\n\n## 增强业务开发灵活性\n\n### 支持列类型变更\n\n在典型的 TiDB 应用场景中，经常借助 binlog 将多个 MySQL 上游数据汇聚到一个 TiDB 集群。原先 TiDB 不支持变更列类型的操作，如果上游 MySQL 修改表的字段类型会导致与 TiDB 数据同步的中断。5.1 版本新增对修改列类型 DDL 语句的支持，彻底解决上述问题并进一步提升 [MySQL 兼容性](https://docs.pingcap.com/zh/tidb/dev/sql-statement-modify-column#mysql-%E5%85%BC%E5%AE%B9%E6%80%A7)。\n\n### Stale Read\n\n[Stale Read](https://docs.pingcap.com/zh/tidb/v5.1/stale-read#stale-read-%E5%8A%9F%E8%83%BD%E7%9A%84%E4%BD%BF%E7%94%A8%E5%9C%BA%E6%99%AF) 适用于读多写少并且能够容忍读到旧数据的场景。例如 Twitter 用户发出一条消息后，系统会产生成千上万甚至上亿次读取，并且新发出的消息在一定时间后被读到是可以容忍的。该场景给数据库带来相当大的读并发压力，可能会产生读热点，导致节点的负载分布不均，整体吞吐成为瓶颈。借助 Stale Read，用户可以指定一个过去的时间点从任意一个数据副本读取数据（不必从 leader 读取），从而显著分散节点的压力负载，使得整体读吞吐能力提升近一倍。\n\n```\n/* 例如：可以通过设置当前事务为查询 5 秒之前的数据状态来开启 Stale Read */\n> SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND;\n> SELECT * FROM T;\n```\n\n### 快速定位锁冲突(实验特性)\n\n业务开发需要很谨慎地处理数据库并发事务，一旦发生锁表会给线上业务带来巨大影响，而 DBA 需要快速定位锁表原因以保证业务能够恢复正常。TiDB 5.1 中新增 [Lock View 系统表视图](https://github.com/pingcap/docs-cn/blob/master/troubleshoot-lock-conflicts.md#%E4%BD%BF%E7%94%A8-lock-view-%E6%8E%92%E6%9F%A5%E6%82%B2%E8%A7%82%E9%94%81%E7%9B%B8%E5%85%B3%E7%9A%84%E9%97%AE%E9%A2%98)，可以快速定位到引起锁表的事务和相关 SQL 语句，从而提高锁冲突问题的处理效率。下面一个小例子展示如何使用 Lock View 快速定位发生锁表的事务和 SQL 语句。\n\n```\n/* 1. 获取当前发生锁等待的事务相关信息: */\nmysql> SELECT B.ID,B.STATE,B.WAITING_START_TIME,B.ALL_SQL_DIGESTS FROM DATA_LOCK_WAITS A,TIDB_TRX B WHERE A.CURRENT_HOLDING_TRX_ID = B.ID OR A.TRX_ID=B.ID \\G;\n*************************** 1. row ***************************\n                                   ID: 426015366622478337\n                            STATE: LockWaiting\nWAITING_START_TIME: 2021-07-01 14:19:15.652134\n      ALL_SQL_DIGESTS: [c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de]\n*************************** 2. row ***************************\n                                   ID: 426015363607822337\n                            STATE: Normal\nWAITING_START_TIME: NULL\n      ALL_SQL_DIGESTS: [3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d]\n2 rows in set (0.00 sec)\n\n/* 2. 根据锁表事务提供的 SQL 指纹，进一步找出事务执行过的历史 SQL */\n\n/* 持有锁事务历史执行 SQL*/\nmysql> SELECT DIGEST_TEXT,DIGEST FROM CLUSTER_STATEMENTS_SUMMARY WHERE DIGEST IN('3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d')\\G;\n*************************** 1. row ***************************\nDIGEST_TEXT: update `a` set `id` = ?\n           DIGEST: 3a0938060e1e3e66148f3e00a7d4a8a21a2482cab5d60a27d52ac6044e17f31d\n1 row in set (0.00 sec)\n\n/* 请求锁事务历史执行 SQL*/\nmysql>  SELECT DIGEST_TEXT,DIGEST FROM CLUSTER_STATEMENTS_SUMMARY WHERE DIGEST IN('c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de')\\G;\n*************************** 1. row ***************************\nDIGEST_TEXT: delete from `a`\n           DIGEST: c5f8471b8590d075d2de681fe5fe7e4f4dd2dd57709058c11d359bb9a64185de\n1 row in set (0.01 sec)\n```\n\n### 更快更准的统计信息分析\n\n随着业务数据持续不断的变更，表的统计信息也会变得陈旧，进而导致优化器执行计划准确度降低，使得查询变慢。DBA 通过执行 ANALYZE 操作，对表的统计信息进行重建。TiDB 5.1 对 ANALYZE 采样算法的性能进行了优化，生成统计信息的平均时间缩减为三分之一，同时新增一项新的统计数据类型，让优化器选择索引更加准确。\n\n## 提升大集群运维和数据传输的可靠性\n\n### 超多数量表的备份优化\n\n优化超多数量表的备份，在 50k 张表的量级下，TiDB 集群全量备份时间降低到之前的 30~40%。此外， 5.1 版本优化了备份模块的元信息文件组织形式（简称v2），启动 BR 时可以通过指定参数 “--backupmeta-version=2” 来启用 v2，从而减少单次写入量来降低内存消耗，有效避免低规格内存（≤8GB）环境下的异常退出。\n\n### 提升大规模集群运维可靠性\n\nTiDB 集群规模越大对生产集群扩缩容、硬件升级以及节点搬迁等日常运维操作的耗时就越久。TiDB 5.1 显著提升了扩缩容时数据迁移的性能，以下是两组测试结果：\n\n- 100 个节点规模下，完成集群所有数据跨数据中心迁移的耗时降低 20%；\n\n- 增加新节点或对某节点的数据进行迁移，耗时缩短约 40%。\n\n### 优化内存使用\n\n内存溢出（Out Of Memory）一直是困扰数据库行业的典型问题，5.1 版本针对 TiDB 的内存使用进行了一系列优化，从而降低 OOM 风险：\n\n- 无论数据量大小，窗口函数 row_number 将只占用固定大小内存；\n\n- 优化分区表的读取，占用更少内存；\n\n- 为存储层加入可配置的内存限制，当限制触发时，系统将释放部分缓存以降低内存占用；\n\n- TiFlash 写入的内存占用比上一版本降低 80%。\n\n### 提升 CDC 同步链路可靠性\n\nTiCDC 5.1 在无需人工干预的情况下提供同步链路的可靠性：当发生环境扰动或硬件故障时，TiCDC 可以保证同步持续进行；即使发生同步中断，TiCDC 也会根据实际情况自动进行重试。\n\n最后，特别感谢小米、奇虎 360、知乎、爱奇艺、理想汽车、新浪、虎牙、小电、跨越速运、亿玛科技等公司和社区开发者们在 TiDB 5.1 版本的设计、开发和测试过程中做出的贡献，是你们一如既往的支持，帮助 TiDB 在实际场景中持续提升开发者和 DBA 的使用体验，让 TiDB 变得更加简单易用。\n\n查看 TiDB 5.1 [Release Notes](https://docs.pingcap.com/zh/tidb/v5.1/release-5.1.0)，立即[下载试用](https://pingcap.com/zh/product-community/)，开启 TiDB 5.1 之旅。","date":"2021-07-01","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-5.1-release","file":null,"relatedBlogs":[]},{"id":"Blogs_256","title":"PingCAP 发布 TiDB 5.0 里程碑版本 构建一栈式数据服务平台","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"PingCAP 联合创始人兼 CTO 黄东旭在 TiDB 5.0 发布会上进行了《What’s Next? 新一代数据库的构想》的精彩演讲，讲述了 TiDB 作为一款企业级数据库的成长史，并分享 PingCAP 对于企业级数据库的思考与内外功修炼。","body":"前不久，PingCAP 刚刚度过六岁生日。对于数据库这样一个古老的行业，六年只是刚刚起步。TiDB 5.0 的发布就像一个庆祝成长的生日礼物，为 TiDB 带来了一个具有里程碑意义的版本。通过引入 MPP （Massively Parallel Processing，大规模并行处理）架构，年轻的 TiDB 已经成为一款具备完整 HTAP 能力的分布式数据库。\n\n**PingCAP 联合创始人兼 CTO 黄东旭在 TiDB 5.0 发布会上进行了《What’s Next? 新一代数据库的构想》的精彩演讲，讲述了 TiDB 作为一款企业级数据库的成长史，并分享 PingCAP 对于企业级数据库的思考与内外功修炼。**\n\n## 一个企业级数据库的辛酸成长史\n\nTiDB 从诞生的第一天起，就被设定了一个很高的目标——成为 **一款面向核心系统的企业级数据库。**也因为这个很高的目标，其发展历程充满着辛酸的故事。\n\n5 年前，当带着 TiDB 第一个版本见客户时，还没有人用过 TiDB ，而客户的问题就是“有谁在用你的产品？” 很显然这段对话的结果就是被拒绝。毕竟作为一款企业级数据库，替换数据库的动作就像动心脏手术一样，客户通常都非常谨慎。\n\n### TiDB 的第一次用户尝试就成为“救命”的产品\n\nTiDB 的第一个用户是一家游戏公司，当时的数据库不能满足其广告投放系统的实时查询，于是就抱着死马当活马医的心态开始试用，结果 TiDB 成为救活这个公司的产品。说来也巧，这个广告系统恰好是一个 HTAP 场景，似乎也预示了 TiDB 的救命能力与实时性数据处理密不可分。\n\n### 一个小目标：开拓金融行业客户\n\n之后的几年中，随着在 Mobike 、今日头条等互联网创业企业中应用，TiDB 逐步成为互联网行业在分布式数据库领域的事实标准，也有了一些知名度。但熟悉的对话再次发生，客户在与 PingCAP 交流中问 “你们现在有没有金融行业的案例？”，当时 TiDB 还正处于 1.0 - 2.0 阶段，并没有金融行业案例，客户认为这还不算真正的企业级数据库。\n\n到了 3.0 、4.0 版本时， TiDB 逐渐有了一些核心的金融行业客户，具备了金融客户使用案例。但客户又问 “你们有大行核心系统的应用案例吗？” “没有” “那不好意思，告辞！”\n\n这段历史很辛酸，**每个人都有第一次，一个新产品也总得有第一个客户。** 但数据库这种东西所有人都说必须得别人用过，自己才敢用。这就是做企业级数据库的现状，因为这个东西实在太过于重要，没有人愿意当小白鼠。\n\n## 从“救命” 到“省心放心” 企业级数据库的成熟之路\n\n### TiDB 跨过最危险的开源鸿沟\n\nTiDB 与很多数据库相比，很特别的一点在于它是一个开源软件。在业界，开源软件有一个跨越鸿沟的理论，它描绘了一个新技术的发展阶段：**一开始大家的预期都很高，逐渐有一些早期的用户，市场也在不断发出声音。持续一段时间后会经历一个高峰期，高峰过后就会进入一个很长时间没有增长的阶段。**很多开源项目死于这个死亡之谷，那是一段非常焦虑非常煎熬的时期。\n\n![1](https://img1.www.pingcap.com/prod/1_e0db76bf37.png)\n\n上图中，蓝线代表 Kubernetes —— 目前全世界最流行的开源软件，从图中能明显看到它也经历过这样一个曲线。另外一条绿线代表了 TiDB ，作为一个历经六年的开源项目，也没有逃出这个客观规律。在中间长达两年的时间里几乎没有增长，这段时间对于一个开源数据库是最难熬的日子。从 4.0 版本发布至今，TiDB 终于跨过了这个最危险的开源鸿沟。根据开源的历史规律，TiDB 与 PingCAP 将会迎来一段高速的增长，现在已经是一个“死不了”的产品。在基础软件行业，一个死不了的开源软件已经很不容易了。\n\n这个规律的背后说明了什么？**一个真正好用的基础软件，一款真正好用的企业级数据库，并不是几个天才工程师写出来的，而是被人“用”出来的。** 中间那段长达两年的，其实并不是没有增长，它只是在不停地进化，不断地在各种各样的场景中打磨产品。\n\n回到 “什么是企业级数据库” 这个问题。有很多用户是通过数据库的用户案例来判断是否企业级，有的认为贵的软件收费就是企业级，也有很多人甚至觉得开源就不是企业级，每个人心中都有着不同的答案。\n\n### 做“省心，放心，不担心”的企业级数据库\n\nPingCAP 认为，**一个真正的企业级数据库厂商应该把自己放在用户的角度去思考，无论是一个企业去购买数据库应对数字化挑战，还是一个工程师去面对数百台的数据库集群维护，他们需要的就是“省心、放心、不担心“。**\n\n**第一，省心。** 省心其实主要是易用性问题，很多时候，人们认为易用性是一个有关用户体验的事情。这里有一个特别简单的标准，如果它带来的问题要小于它解决的问题，这就是易用。如果你发现用一个新东西的时间和精力比它解决问题所花费的时间还多，那就是不省心。\n\n**第二，放心。** 数据不会错、不会丢、性能无抖动是对于一个数据库最基础的要求。其实在使用数据库的过程里，并不在于它有多少功能、多高性能，而是万一出现问题，有没有人提供背后的企业级服务。一个 DBA 工作中可能有 50-60% 的时间在部署、安装、备份、维护数据库，如果这个数据库他不会运维，不知道怎么调优，就无法让人放心。PingCAP 背后有一支专业的服务团队，比起其他没有生态的数据库软件更能让人放心，维护不愁人。\n\n**第三，不担心。** 用户到底在担心什么？是业务的增长吗？是数据量变大吗？是担心这家数据库公司倒闭吗？其实在数据库领域里，从用户的视角来看，真正的敌人是系统的复杂性，这个系统越复杂，在应对业务高速增长、快速变化时，应对的动作就会越迟缓。这个复杂性是各种各样的技术架构、各种各样的软件组合在一起，产生了很多的数据对接，以及维护各种各样的技术栈。\n\n关于不担心，在 TiDB 里有一个真实的故事：\n\n+ [视频](https://v.qq.com/x/page/k3242wd985n.html)\n\n在传统的数据处理与大数据方案中，引入了各种各样的复杂性，用户的在线系统和离线大数据系统是完全割裂的两个系统。使用 TiDB 后，大多数场景用一套系统就可以支撑。对于用户来说，**一个简洁优雅的技术架构就是不用担心的方案。**\n\n## 里程碑！TiDB 5.0 核心能力向企业级演进\n\n### TiDB 5.0 的内功：TiDB，栈稳了！\n\n![2](https://img1.www.pingcap.com/prod/2_2aabfe48db.png)\n\n如果要给 TiDB 5.0 定义一个关键字的话，那就是“练内功”。现在整个行业对于 TiDB 的认知和需求已经进入一个深水区，过去大家认为这是一个创新型产品，会在一些创新型的业务上用。但从 4.0 开始至今，越来越多的金融机构或大型企业，开始把 TiDB 用在一些非常关键、非常核心的交易、支付场景里。很多人表面上看 5.0 似乎并没有发布特别多新功能，其实在 5.0 这个版本能看到的显性功能只是冰山一角，冰山下面更多看不见的是 TiDB 产研团队、用户和贡献者对稳定性以及性能的持续优化，这些“内功”也是一个真正的企业级数据库应该追求的能力。\n\n![3](https://img1.www.pingcap.com/prod/3_e53159095d.png)\n\n**从 4.0 版本到 5.0 版，TiDB 做了大量优化，包括减少性能抖动、提升性能、提升安全性等，上图中能看到这条黄色曲线最终变成了红色曲线，减少抖动将近 100 项。** 对于一个企业级数据库来说，内功其实是非常重要的一个壁垒。\n\n### 真 HTAP 来了！TiDB 5.0 补全 HTAP 能力拼图\n\n回顾整个 TiDB 历史，你可以看到 HTAP 是如何一步步变成今天这个形态的。TiDB 刚诞生的时候，出发点非常朴素，就是想做一个 MySQL 分库分表的替代品，比 MySQL 分库分表用起来更方便，解决 OLTP 规模化的问题。\n\n4.0 版本已经实现初步的 HTAP 能力，第一次引入了 HTAP 的重要插件 —— 列式存储 TiFlash 引擎。列存引擎在底层为 TiDB 打下一个基础，与 OLAP 数据库相比不再有天生的缺陷。\n\n![4](https://img1.www.pingcap.com/prod/4_b38de4d69f.png)\n\nTiDB 5.0 最新版在 TiFlash 的基础上引入了 MPP 架构，在功能上补全了 HTAP 最后一块拼图。**提供与存储匹配的分布式计算引擎，进一步提升海量数据下的并行计算与分析能力。** 这对于 TiDB 来说是一个里程碑，标志着 TiDB 成为一个拥有完整能力的 HTAP 分布式数据库。但里程碑并不代表终点，对于一个企业级数据库来说，TiDB 还有很长的路要走。前路漫漫，希望大家多多包容，多多呵护 TiDB 继续成长壮大。\n\n## 抛掉过去，重新出发——数据库未来趋势\n\n如果从数据库的发展历史角度来看，上世纪六七十年代，IBM、Oracle 发明了关系型数据库。2010 年前后，互联网普及了 Shared Nothing 架构，分布式数据库慢慢走向主流。现在基本一个成规模的互联网公司或者数据量大一点的公司，大多都在用 Shared Nothing 的数据库支撑。但从架构来说，我们也许需要新的思路来解决未来的问题。2021 年我们又站在了一个新十年时间窗口的开始，直觉告诉我们，接下来即将进入一个数据库技术的全新时代。这个时代需要抛弃掉过去所有对于数据库的假设，去面向这个时代的基础设施重新设计。\n\n首先，**规模效应会重新掌握一切。** 早年间有一个预言说未来这个世界上只需要五台计算机，现在来看应该不是五台计算机，而是五朵云。云的基础设施也许会变成新的基础设施，未来的年轻一代工程师或许都不知道什么是 CPU、内存、磁盘，他们看到的基础设施就是云厂商提供的 API 或服务接口。从 Snowflake 的实践来看，新一代的基础软件只有基于云底层能力深度重构才能真正获取弹性的能力。Snowflake 是第一个，但是肯定不会是最后一个。\n\n**未来可期，PingCAP 已经准备好重新出发！**\n\n> 更多 TiDB 5.0 发布会相关内容：  \n[成为一栈式数据服务生态： TiDB 5.0 HTAP 架构设计与场景解析](https://pingcap.com/zh/blog/tidb-5.0-htap-architecture-design-and-become-scenario-analysis)；  \n> [数字化加速，如何做到数据保鲜和数据价值变现？ — TiDB 行业应用场景及案例解读](https://pingcap.com/zh/blog/how-to-keep-data-fresh-and-how-to-realize-value)","date":"2021-04-28","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"what-is-the-next-tidb-5.0","file":null,"relatedBlogs":[]},{"id":"Blogs_271","title":"TiDB 5.0 RC Release Notes","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"本文将介绍 TiDB 5.0.0-rc 版本中的性能提升与新特性。","body":"TiDB 5.0.0-rc 版本是 5.0 版本的前序版本。在 5.0 版本中，我们专注于帮助企业基于 TiDB 数据库快速构建应用程序，使企业在构建过程中无需担心数据库的性能、性能抖动、安全、高可用、容灾、SQL 语句的性能问题排查等问题。\n\n在 TiDB 5.0 版本中，你可以获得以下关键特性：\n\n- 开启聚簇索引功能，提升数据库的性能。例如：TPC-C tpmC 测试下的性能提升了 39%。\n\n- 开启异步提交事务功能，降低写入数据的延迟。例如：Sysbench oltp-insert 测试中延迟降低了 37.3%。\n\n- 通过提升优化器的稳定性及限制系统任务对 I/O、网络、CPU、内存等资源的占用，降低系统的抖动。例如：长期测试 72 小时，衡量 Sysbench TPS 抖动标准差的值从 11.09% 降低到 3.36%。\n\n- 引入 Raft Joint Consensus 算法，确保 Region 成员变更时系统的可用性。\n\n- 优化 `EXPLAIN` 功能、引入不可见索引等功能帮助提升 DBA 调试及 SQL 语句的效率。\n\n- 通过备份文件到 AWS S3、Google Cloud GCS 或者从 AWS S3、Google Cloud GCS 恢复到 TiDB，确保企业数据的可靠性。\n\n- 提升从 AWS S3 或者 TiDB/MySQL导入导出数据的性能，帮忙企业在云上快速构建应用。例如：导入 1TiB TPC-C 数据性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h。\n\n## SQL\n\n### 支持聚簇索引（实验特性）\n\n开启聚簇索引功能后，TiDB 性能在以下条件下会有较大幅度的提升, 例如： TPC-C tpmC 的性能提升了 39%。聚簇索引主要在以下条件时会有性能提升：\n\n- 插入数据时会减少一次从网络写入索引数据。\n\n- 等值条件查询仅涉及主键时会减少一次从网络读取数据。\n\n- 范围条件查询仅涉及主键时会减少多次从网络读取数据。\n\n- 等值或范围条件查询涉及主键的前缀时会减少多次从网络读取数据。\n\n聚簇索引定义了数据在表中的物理存储顺序，表的数据只能按照聚簇索引的定义进行排序，每个表只能有一个聚簇索引。\n\n用户可通过修改 `tidb_enable_clustered_index` 变量的方式开启聚簇索引功能。开启后仅在创建新表时生效，适用于主键是多个列或者单个列的非整数类型。如果主键是单列整数类型或者表没有主键，系统会按照原有的方式进行数据排序，不受聚簇索引的影响。\n\n例如，可通过 `select tidb_pk_type from information_schema.tables where table_name = '{tbl_name}'` 语名可查询 `tbl_name` 是否有聚簇索引。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/system-variables#tidb_enable_clustered_index-%E4%BB%8E-v500-rc-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5)\n\n- 相关 issue：[#4841](https://github.com/pingcap/tidb/issues/4841)\n\n### 支持不可见索引\n\nDBA 调试和选择相对最优的索引时，可以通过 SQL 语句将某个索引设置成 `Visible` 或者 `Invisible`，避免执行消耗资源较多的操作，例如：`DROP INDEX` 或 `ADD INDEX`。\n\nDBA 通过 `ALTER INDEX` 语句来修改某个索引的可见性。修改后优化器会根据索引的可见性决定是否将此索引加入到索引列表中。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/sql-statement-alter-index)\n\n- 相关 issue：[#9246](https://github.com/pingcap/tidb/issues/9246)\n\n### 支持 `EXCEPT/INTERSECT` 操作符\n\n`INTERSECT` 操作符是一个集合操作符，返回两个或者多个查询结果集的交集。一定程度上可以替代 `Inner Join` 操作符。\n\n`EXCEPT` 操作符是一个集合操作符，将两个查询语句的结果合并在一起，并返回在第一个查询语句中有但在第二个查询句中不存在的结果集。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/set-operators)\n\n- 相关 issue：[#18031](https://github.com/pingcap/tidb/issues/18031)\n\n## 事务\n\n### 提升悲观事务执行成功的概率\n\n悲观事务模式下，如果事务所涉及到的表存在并发 DDL 操作和 `SCHEMA VERSION` 变更，系统会自动将该事务的 `SCHEMA VERSION` 更新到最新版本，确保事务会提交成功，避免事务因 DDL 操作而中断。事务中断时客户端会收到 `Information schema is changed` 的错误信息。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/system-variables#tidb_enable_amend_pessimistic_txn-%E4%BB%8E-v407-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5)\n\n- 相关 issue：[#18005](https://github.com/pingcap/tidb/issues/18005)\n\n## 字符集和排序规则\n\n使用 `utf8mb4_unicode_ci` 和 `utf8_unicode_ci` 排序规则和字符集比较排序时不区分大小写。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/character-set-and-collation#%E6%96%B0%E6%A1%86%E6%9E%B6%E4%B8%8B%E7%9A%84%E6%8E%92%E5%BA%8F%E8%A7%84%E5%88%99%E6%94%AF%E6%8C%81)\n\n- 相关 issue：[#17596](https://github.com/pingcap/tidb/issues/17596)\n\n## 安全\n\n### 错误信息和日志信息的脱敏\n\n系统在输出错误信息和日志信息时，支持对敏感信息进行脱敏处理，避免敏感信息泄露。敏感信息可能是身份证信息、信用卡号等。\n\n- 通过 SQL 语句修改 `tidb_redact_log=1` 开启 tidb-server 的错误信息和日志信息脱敏功能\n\n- 通过修改 tikv-server 的 `security.redact-info-log = true` 配置项开启错误信息和日志信息脱敏功能\n\n- 通过修改 pd-server 的 `security.redact-info-log = true` 配置项开启错误信息和日志信息脱敏功能 [#2852](https://github.com/tikv/pd/issues/2852) [#3011](https://github.com/tikv/pd/pull/3011)\n\n- 通过修改 tiflash-server 的 `security.redact_info_log = true` 以及 tiflash-learner 的 `security.redact-info-log = true` 配置项开启错误信息和日志信息脱敏功能\n\n[用户文档](https://docs.pingcap.com/zh/tidb/v5.0/log-redaction)\n\n相关 issue：[#18566](https://github.com/pingcap/tidb/issues/18566)\n\n## 性能提升\n\n### 支持异步提交事务（实验特性）\n\n开启异步提交事务可使延迟有较大幅度的降低，例如：Sysbench oltp-insert 测试中开启异步提交事务的延迟与不开启时相比降低了 37.3%。\n\n数据库的客户端会同步等待数据库通过两阶段 (2PC) 完成事务的提交。开启 Async Commit 特性后事务两阶段提交在第一阶段提交成功后就会返回结果给客户端，第二阶段会在后台异步执行。通过事务两阶段异步提交的方式降低事务提交的延迟。\n\n此特性只能显式地修改 `tidb_guarantee_external_consistency = ON` 变量后才能保证事务的外部一致性。开启后性能有较大幅度的下降。\n\n用户可通过修改 `tidb_enable_async_commit = ON` 全局变量开启此功能。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/system-variables#tidb_enable_async_commit-%E4%BB%8E-v500-rc-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5)\n\n- 相关 issue：[#8316](https://github.com/tikv/tikv/issues/8316)\n\n### 提升优化器选择索引的稳定性（实验特性）\n\n优化器若无法长期稳定地选择相对合适的索引，会在很大程度上决定着查询语句的延迟是否有抖动。为确保相同的 SQL 语句不会因为统计信息缺失、不准确等因素导致优化器每次都从多个候选索引选持不同的索引，我们对统计信息模块进行了完善和重构。主要完善如下：\n\n- 扩展统计信息功能，收集多列 NDV、多列顺序依赖性、多列函数依赖性等信息，帮助优化器选择相对较优的索引。\n\n- 重构统计信息模块，帮助优化器选择相对较优的索引。\n\n    - 从 `SKetch` 中删除 `TopN` 值。\n\n    - 重构 `TopN` 搜索逻辑。\n\n    - 从直方图中删除 `TopN` 信息，建立直方图的索引，方便维护 Bucket NDV。\n\n相关 issue：[#18065](https://github.com/pingcap/tidb/issues/18065)\n\n### 优化因调度功能不完善或者 I/O 限流不完善引起的性能抖动问题\n\nTiDB 调度过程中会占用 I/O、Network、CPU、Memory 等资源，若不对调度的任务进行控制，QPS 和延时会因为资源被抢占而出现性能抖动问题。通过以下几项的优化，长期测试 72 小时，衡量 Sysbench TPS 抖动标准差的值从 11.09% 降低到 3.36%。\n\n- 减少节点的容量总是在水位线附近波动引起的调度及 PD 的 `store-limit` 配置项设置过大引起的调度，引入一套新的调度算分公式并通过 `region-score-formula-version = v2` 配置项启用新的调度算分公式 [#3269](https://github.com/tikv/pd/pull/3269)\n\n- 通过修改 `enable-cross-table-merge = true` 开启跨 Region 合并功能，减少空 Region 的数量 [#3129](https://github.com/tikv/pd/pull/3129)\n\n- TiKV 后台压缩数据会占用大量 I/O 资源，系统通过自动调整压缩的速度来平衡后台任务与前端的数据读写对 I/O 资源的争抢，通过 `rate-limiter-auto-tuned` 配置项开启此功能后，延迟抖动比未开启此功能时的抖动大幅减少 [#18011](https://github.com/pingcap/tidb/issues/18011)\n\n- TiKV 在进行垃圾数据回收和数据压缩时，分区会占用 CPU、I/O 资源，系统执行这两个任务过程中存在数据重叠。GC Compaction Filter 特性将这两个任务合二为一在同一个任务中完成，减 I/O 的占用。此特性为实验性特性，通过 `gc.enable-compaction-filter = ture` 开启 [#18009](https://github.com/pingcap/tidb/issues/18009)\n\n- TiFlash 压缩或者整理数据会占用大量 I/O 资源，系统通过限制压缩或整理数据占用的 I/O 量缓解资源争抢。此特性为实验性特性，通过 `bg_task_io_rate_limit` 配置项开启限制压缩或整理数据 I/O 资源。\n\n相关 issue：[#18005](https://github.com/pingcap/tidb/issues/18005)\n\n### 提升 Real-time BI / Data Warehousing 场景下 TiFlash 的稳定性\n\n- 限制 DeltaIndex 的内存使用量，避免大数据量下内存使用过多导致系统 OOM。\n\n- 限制后台数据整理任务使用的 I/O 写流量，降低对前台任务的影响。\n\n- 新增加线程池，排队处理 coprocessor 任务，避免高并发处理 coprocessor 时内存占用过多导致系统 OOM。\n\n### 其他性能优化\n\n- 提升 `delete * from table where id < ?` 语句执行的性能，p99 性能提升了 4 倍 [#18028](https://github.com/pingcap/tidb/issues/18028)\n\n- TiFlash 支持同时向本地多块磁盘并发读、写数据，充分利用本地多块磁盘并发的读、写数据的能力，提升性能\n\n## 高可用和容灾\n\n### 提升 Region 成员变更时的可用性（实验特性）\n\nRegion 在完成成员变更时，由于“添加”和“删除”成员操作分成两步，如果此时有故障发生会引起 Region 不可用并且会返回前端业务的错误信息。引入的 Raft Joint Consensus 算法，可提升 Region 成员变更时的可用性，将成员变更操作中的“添加”和“删除”合并为一个操作，并发送给所有成员。在变更过程中，Region 处于中间的状态，如果任何被修改的成员失败，系统仍然可以使用。用户可通过 `pd-ctl config set enable-joint-consensus true` 修改成员变量的方式开启此功能。\n\n- [用户文档](https://docs.pingcap.com/zh/tidb/v5.0/pd-configuration-file#enable-joint-consensus-%E4%BB%8E-v500-rc-%E7%89%88%E6%9C%AC%E5%BC%80%E5%A7%8B%E5%BC%95%E5%85%A5)\n\n- 相关 issue：[#18079](https://github.com/pingcap/tidb/issues/18079) [#7587](https://github.com/tikv/tikv/issues/7587) [#2860](https://github.com/tikv/pd/issues/2860)\n\n### 优化内存管理模块，降低系统内存溢出的风险\n\n- 减少缓存统计信息的内存消耗。\n\n- 减少使用 Dumpling 工具导出数据时的内存消耗。\n\n- 通过将数据加密码的中间结果存储到磁盘，减少内存消耗。\n\n## 备份与恢复\n\n- BR 支持将数据备份到 AWS S3、Google Cloud GCS（[用户文档](https://docs.pingcap.com/zh/tidb/v5.0/backup-and-restore-tool#%E5%A4%87%E4%BB%BD%E6%95%B0%E6%8D%AE%E5%88%B0-amazon-s3-%E5%90%8E%E7%AB%AF%E5%AD%98%E5%82%A8)）\n\n- BR 支持从 AWS S3、Google Cloud GCS 恢复数据到 TiDB（[用户文档](https://docs.pingcap.com/zh/tidb/v5.0/backup-and-restore-tool#%E4%BB%8E-amazon-s3-%E5%90%8E%E7%AB%AF%E5%AD%98%E5%82%A8%E6%81%A2%E5%A4%8D%E6%95%B0%E6%8D%AE)）\n\n- 相关 issue：[#89](https://github.com/pingcap/br/issues/89)\n\n## 数据的导入和导出\n\n- TiDB Lightning 支持从 AWS S3 将 Aurora Snapshot 数据导入 TiDB（相关 issue：[#266](https://github.com/pingcap/tidb-lightning/issues/266)）\n\n- 使用 TiDB Lightning 在 DBaaS T1.standard 中导入 1TiB TPCC 数据，性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h\n\n- Dumpling 支持将 TiDB/MySQL 数据导出到 AWS S3（实验特性）（相关 issue：[#8](https://github.com/pingcap/dumpling/issues/8)，[用户文档](https://docs.pingcap.com/zh/tidb/v5.0/dumpling-overview#%E5%AF%BC%E5%87%BA%E5%88%B0-amazon-s3-%E4%BA%91%E7%9B%98)）\n\n## 问题诊断\n\n### 优化 `EXPLAIN` 功能，收集更多的信息，方便 DBA 排查性能问题\n\nDBA 在排查 SQL 语句性能问题时，需要比较详细的信息来判断引起性能问题的原因。之前版本中 `EXPLAIN` 收集的信息不够完善， DBA 只能通过日志信息、监控信息或者盲猜的方式来判断问题的原因，效率比较低。此版本通过以下几项优化事项提升排查问题效率：\n\n- 支持对所有 DML 语句使用 `EXPLAIN ANALYZE` 语句以查看实际的执行计划及各个算子的执行详情 [#18056](https://github.com/pingcap/tidb/issues/18056)\n\n- 支持对正在执行的 SQL 语句使用 `EXPLAIN FOR CONNECTION` 语句以查看实时执行状态，如各个算子的执行时间、已处理的数据行数等 [#18233](https://github.com/pingcap/tidb/issues/18233)\n\n- `EXPLAIN ANALYZE` 语句显示的算子执行详情中新增算子发送的 RPC 请求数、处理锁冲突耗时、网络延迟、RocksDB 已删除数据的扫描量、RocksDB 缓存命中情况等 [#18663](https://github.com/pingcap/tidb/issues/18663)\n\n- 慢查询日志中自动记录 SQL 语句执行时的详细执行状态，输出的信息与 `EXPLAIN ANALYZE` 语句输出信息保持一致，例如各个算子消耗的时间、处理数据行数、发送的 RPC 请求数等 [#15009](https://github.com/pingcap/tidb/issues/15009)\n\n[用户文档](https://docs.pingcap.com/zh/tidb/v5.0/sql-statement-explain)\n\n## 部署及运维\n\n- TiUP 支持将 TiDB Ansible 的配置信息导入到 TiUP。以前导入 Ansible 集群的时候 TiUP 会将用户的配置放在 `ansible-imported-configs` 目录下面。用户后续修改配置执行 `tiup cluster edit` 时，配置编辑界面中不显示导入的配置，会给用户造成困扰。现在导入 TiDB Ansible 配置信息的时候 TiUP 不仅会放一份到 ansible-imported-configs 目录下面，还会导入到 `tiup cluster edit` 的配置编辑界面，这样用户以后编辑集群配置时就能够看到导入的配置了。\n\n- 增强 `TiUP mirror` 命令的功能，支持将多个镜像合并成一个，支持在本地镜像发布组件，支持添加组件所有者到本地镜像 [#814](https://github.com/pingcap/tiup/issues/814)\n\n    - 金融行业或者大型企业生产环境的变更是一项非常严肃的事情，若每个版本都采用光盘安装一次，用户使用起来不是很方便。TiUP 提升 `merge` 命令将多个安装包合并成一个，方便 DBA 安装部署。\n\n    - 在 v4.0 中，用户发布自建的镜像时需要启动 tiup-server，使用起来不是很方便。在 v5.0 中，执行 `tiup mirror set` 将当前镜像设置成本地的镜像就可以方便发布自建镜像。","date":"2021-01-21","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-5.0-rc-release-notes","file":null,"relatedBlogs":[]},{"id":"Blogs_78","title":"2020，Chaos Mesh 开源第一年：扬帆起航的一年","tags":["Chaos Mesh"],"category":{"name":"公司动态"},"summary":"本文将从多个方面和大家一起回顾 Chaos Mesh 在这一年中的变化与成长，畅谈一些 Chaos Mesh 未来的目标与计划。","body":"Chaos Mesh 开源刚刚一周年，这一年来，Chaos Mesh 产品不断迭代成长，从单一的故障注入工具到现在以构建完整混沌工程生态为目标持续前进。Chaos Mesh  社区从无到有，不断为 Chaos Mesh 带来新的力量，并成功帮助 Chaos Mesh 加入 CNCF 成为沙箱托管项目。\n\n在这篇文章中，笔者会从多个方面和大家一起回顾 Chaos Mesh 在这一年中的变化与成长，畅谈一些 Chaos Mesh 未来的目标与计划。\n\n## 产品：明确目标，茁壮成长\n这一年里， Chaos Mesh 在大家共同的努力下在以肉眼可见的速度成长着。从第一个版本，到最近我们刚刚发布的 [1.1](](https://github.com/chaos-mesh/chaos-mesh/releases/tag/v1.1.0)\n) 版本，无论是功能上，还是易用性，安全性等方面，Chaos Mesh 都有了很大的提升。\n\n### 功能方面\n\n刚开源的时候，Chaos Mesh 支持 PodChaos，NetworkChaos 以及 IOChaos，经过这一年的不断丰富，Chaos Mesh 已经能够全方位的对网路、时间、JVM 应用、文件系统、操作系统等进行故障注入。这一年中 Chaos Mesh 共新增 5 类故障类型：  \n\n- StressChaos: 模拟 CPU，Memory 压力场景\n\n- TimeChaos：模拟时钟偏移\n\n- DNSChaos：模拟 DNS 服务故障\n\n- KernelChaos：模拟内核故障  \n\n- JVMChaos：模拟 JVM 应用异常 (Reviewing)\n\n![1](https://img1.www.pingcap.com/prod/1_c9cf128f5e.png)\n\n经过这一年的持续优化，Chaos Mesh 提供了更加灵活的调度机制，可以帮助用户更好的去设计自己的混沌实验，为我们下一步支持混沌编排功能打下基础。\n\n期间，很多用户开始在各大云平台上使用 Chaos Mesh，比如 AWS，GKE，阿里云，腾讯云等。 为了更好的适配各大云平台，我们也不断的进行兼容性测试与适配，以及支持针对特定云平台的故障注入能力。\n\n此外，为了更好的支持 Kubernetes 原生组件以及节点级别故障，Chaos Mesh 单独开发了 [Chaosd](https://github.com/chaos-mesh/chaosd) 组件，Chaosd 主要目的是提供物理节点级别的故障注入能力，Chaosd 组件还在快速开发迭代中，欢迎大家一起参与进来。\n\n### 易用性方面\n\n为了能够让用户快速体验 Chaos Mesh，我们单独提供了一键安装脚本，用户只需要执行一条命令，就可以在本地快速地体验 Chaos Mesh。此外，我们还实现了全新组件 Chaos Dashboard，Chaos Dashboard 极大地简化了管理混沌实验的复杂度，用户可以直接通过可视化界面来管理和监控混沌实验。  \n\n![2](https://img1.www.pingcap.com/prod/2_d047951b08.png)\n\n此外，很多用户在使用 IoChaos  的时候，经常被各种配置问题阻塞住，这个问题一度困扰了我们好久，经过多次调研和讨论，最后我们放弃 Sidecar 的实现方式，使用 chaos-daemon 动态侵入目标 Pod 命令空间的方式，具体实现细节可以阅读之前分享技术解析[文章](https://pingcap.com/blog-cn/chaos-mesh-internals-how-to-inject-io-faults-during-runtime/#chaos-mesh-%E6%8A%80%E6%9C%AF%E5%86%85%E5%B9%95--%E5%A6%82%E4%BD%95%E6%B3%A8%E5%85%A5-io-%E6%95%85%E9%9A%9C)。经过此次优化，Chaos Mesh 真正实现了动态注入 I/O 故障，用户不再需要额外的配置，只需专注于实验本身。\n\n### 安全性方面\n\n这一年中，Chaos Mesh 在提高安全性方面同样作出了诸多努力。Chaos Mesh 提供更加完善的 Selectors 用来控制实验范围，支持设置特定的 Namespaces 来保护重要应用。此外，Chaos Mesh 还支持在 Namespace 权限使用，用户可以把 Chaos Mesh 的权限范围限制在特定某个 Namespace 下，如此一来可以更大程度控制实验的“爆炸半径”，提供更加安全的混沌实验体现。  \n\n此外，Chaos Mesh 直接复用 Kubernetes 的原生权限机制，在 Chaos Dashboard 组件上支持身份验证，以避免其他用户的误操作造成混沌实验的失败或者不可控。\n\n## 生态：不断深入，互帮互助 \n\n在这一年，Chaos Mesh 成功进入 CNCF 沙箱托管项目，这意味 Chaos Mesh 得到整个云原生社区的初步认可，这也意味 Chaos Mesh 后续也将承担推动云原生社区发展的责任，以及推动混沌工程在云原生应用领域上落地。在这一年中 Chaos Mesh 和整个云原生生态相互配合，共同成长。\n\n### Grafana \n\nChaos Mesh 为了进一步提高混沌实验的可观测性，单独开发了 [Grafana 插件](https://github.com/chaos-mesh/chaos-mesh-datasource)，方便用户直接将混沌实验的信息展示在自己的监控面板上。用户在 Grafana 上安装了此插件后，可以直接在应用的监控面板上开启混沌实验信息按钮，混沌实验的相关信息会以 [Annotations](https://grafana.com/docs/grafana/latest/dashboards/annotations/) 的方式在当前的面板上展示出来，这样用户就可以在一个界面上同时观察到应用的运行情况以及当前运行的混沌实验信息。\n\n### Github Action \n\n为了帮助用户在开发阶段就运行混沌实验，我们开发了 [chaos-mesh-action](https://github.com/chaos-mesh/chaos-mesh-action) 这个项目，让 Chaos Mesh 运行在 GitHub Actions 的 workflow 中，让 Chaos Mesh 可以更方便地集成到系统的日常开发、测试中，为 GitHub 上每一次代码的提交保驾护航。\n### TiPocket \n\nTiPocket 是一个同时集成 Chaos Mesh 和 Argo 的自动化测试平台，实现完全自动化的混沌实验。通常我们进行混沌实验的时候，存在很多步骤，比如部署待测试应用，运行 workload，以及注入异常，业务检查等等，为了让这些步骤完全的自动化起来，TiPocket 在 Chaos Mesh 的基础上引入了 Argo 工具，一方面 Chaos Mesh 提供丰富的故障注入能力，另一方面 Argo 提供灵活的编排和调度能力。\n\n![3](https://img1.www.pingcap.com/prod/3_cab43ad87a.png)\n\n## 社区：从无到有，共同进步\n\nChaos Mesh 是社区驱动的项目，项目和生态的迭代和演进离不开一个活跃、友好、开放的社区。开源以来，Chaos Mesh 迅速成为了混沌工程领域最耀眼的开源项目之一，并且在短短的一年中，在 GitHub 上积累了 3k star，吸引了 70+ 贡献者，以及吸引腾讯、小鹏汽车、Dailymotion、网易伏羲实验室、JuiceFS、APISIX、美团等在内的数十家知名用户。回首这一年，Chaos Mesh 社区从无到有，为创建一个透明、开放、友好，自治的开源社区打下了基础。\n\n### 加入 CNCF，借力云原生社区\n\n云原生从 Chaos Mesh 创立之初就写在了项目的 DNA 里。加入 CNCF 也是 Chaos Mesh 社区在这一年里的重要里程碑之一，也是 Chaos Mesh 走向厂商中立、社区自治、开放透明的开源社区的重要一步。除了上文中和云原生的生态的集成，加入 CNCF 对于 Chaos Mesh 社区发展和完善也有很积极的促进作用。\n\n- 更多的社区以及项目曝光。通过生态之间的合作、以及各种云原生社区活动如 Kubernetes Meetup，KubeCon 等，我们也获得了更多与社区分享、交流的机会。社区中不断产生的优质内容也对 Chaos Mesh 的社区品牌传播起到了正面的促进作用。\n\n- 更完善、开放的社区框架。加入 CNCF 的一个重要作用是对开源社区运营的指引和规范。加入 CNCF 时，Chaos Mesh 开源仅半年时间，是一个相对年轻的社区。在 CNCF 的指引下，我们完善了社区的基本框架，如 Code of Conduct, Contributing Guide, 公开的 RoadMap，在 CNCF 的 Slack 下创建了 #project-chaos-mesh 的频道；同时，社区也从初期就提供了逐步完善的用户和开发文档。\n\n### 友好、互助的社区氛围\n\n我们有一个很有潜力的项目，获得 CNCF 的认可，以及一个初步完善的社区框架，这具备了一个有吸引力社区的前提条件。可是，如何让用户、贡献者保持长期、持续参与到社区中，这取决于社区体验和氛围。对于 Chaos Mesh 社区，打造友好、一站式的上手体验，建立快速响应、互助的社区氛围是第一年需要重点关注的目标。具体来说，\n\n- 持续丰富文档内容，优化文档结构，更新文档信息。目前已形成了包含用户文档，开发文档，快速上手、用户案例文档、贡献指南等在内的面向不同人群的文档体系，并随着版本发布保持迭代更新。\n\n- 和社区一起持续发布包含 Chaos Mesh 教程、案例分享、混沌工程实践等主题的博客文章。截止本文发布时间，已累计产生 25 篇 Chaos Mesh 相关文章，以及 1 个发布于 OReilly Katakoda 的[入门互动教程](https://chaos-mesh.org/interactive-tutorial)，为文档提供了有力补充。\n\n- 通过社区阅读会议、以及各种会议、meetup 等形式分享视频教程。\n\n- 作为一个快速迭代的开源项目，Chaos Mesh 社区注重来自社区的反馈、问题的快速响应。\n\n## 未来可期\n\n最近 Google 全球宕机事件再次提醒用户对服务可用性的重视，再次凸显混沌工程的重要性。CNCF 技术委员会主席 Liz Rice 分享 2021 年值得关注的五项技术中，混沌工程赫然在列。大胆预测在未来的一段时间内，混沌工程即将进入一个全新的阶段。\n\n![4](https://img1.www.pingcap.com/prod/4_225199cb09.png)\n\n这一年中我们成功发布了 1.1 版本，经过一段时间的积累以及接受用户各种反馈，Chaos Mesh  有了更加明确的目标，朝着构建完善的混沌工程生态不断前行。目前我们正在快速开发 Chaos Mesh 2.0 版本，在 2.0 中， Chaos Mesh 将引入内嵌的 Workflow 引擎，用来支持定义和管理更加灵活的混沌实验场景，以及引入应用状态检查机制和提供更加完善的混沌实验报告。2.0 版本预计会在几个月后发布，并且项目的后续计划安排，我们会及时在项目的 [roadmap](https://github.com/chaos-mesh/chaos-mesh/blob/master/ROADMAP.md) 上持续更新。 \n\n## 最后\n\n说了这么多，最后也是最重要的，经过这一年努力，Chaos Mesh 不断成长，但依旧年轻，我们朝着我们的目标，扬帆起航，在成长的过程中，需要大家共同参与，一起打造完善的混沌工程体系生态！\n\n欢迎大家加入 Chaos Mesh 社区，加入 Chaos Mesh [Slack(#project-chaos-mesh)](https://slack.cncf.io/) ，一起参与到项目的讨论与开发中来！大家在使用过程发现 bug 或缺失什么功能，也可以直接在 GitHub 上面提 [issue](https://github.com/pingcap/chaos-mesh/issues) 或 PR。\n\n最后附上 Chaos Mesh 社区调查链接，填写有惊喜哦：[https://bit.ly/2LzES5o](https://bit.ly/2LzES5o)","date":"2021-01-18","author":"殷成文, 翁浩","fillInMethod":"writeDirectly","customUrl":"chaos-mesh-the-first-year-of-open-source","file":null,"relatedBlogs":[]},{"id":"Blogs_16","title":"PingCAP 完成 D 轮 2.7 亿美元融资，创造全球数据库历史新的里程碑","tags":["TiDB","PingCAP"],"category":{"name":"公司动态"},"summary":"企业级开源分布式数据库厂商 PingCAP 日前宣布完成 2.7 亿美元的 D 轮融资，创造全球数据库历史新的里程碑。","body":"**企业级开源分布式数据库厂商 PingCAP 日前宣布完成 2.7 亿美元的 D 轮融资，创造全球数据库历史新的里程碑**。本轮融资由纪源资本（GGV Capital）、Access Technology Ventures、晨曦投资 （Anatole Investment）、时代资本（Jeneration Capital）、五源资本（5Y Capital 原晨兴资本）共同领投，贝塔斯曼亚洲投资基金（BAI）、Coatue、天际资本（FutureX Capital）、昆仑资本（Kunlun）、挚信资本（Trustbridge Partners）及老股东经纬中国（Matrix Partners China）、云启资本（Yunqi Partners）跟投，瑞银担任本轮融资的独家财务顾问。\n\n![1-pingcap](https://img1.www.pingcap.com/prod/1_pingcap_2571ba8b07.jpg)\n\n本轮融资将用于分布式数据库关键核心技术的研发，聚焦解决方案和专业服务支持体系的不断完善，持续加大开源社区生态体系建设，进一步推进云数据库服务在全球市场的覆盖，持续领跑全球新一代分布式数据库赛道。\n\nPingCAP 成立于 2015 年，是一家企业级开源分布式数据库厂商，提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务，致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据基础设施，解放企业生产力，加速企业数字化转型升级。\n\n由 PingCAP 创立的分布式关系型数据库 TiDB，为企业关键业务打造，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等企业级核心特性，帮助企业最大化发挥数据价值，充分释放企业增长空间。\n\n## 打造新一代云原生分布式数据库\n\nHTAP （Hybrid transaction/analytical processing） 是近年数据库界重点关注的研究方向。这种架构打破了在线交易业务与分析业务之间的壁垒，在全面支持关键在线交易业务的同时，让业务数据得以被实时分析和处理，极大提升业务决策和平台构建效率，形成业务全链路闭环，从而成为未来企业的核心竞争力之一。\n\n2020 年 5 月， TiDB 推出 4.0 版本，作为 TiDB「新一代云原生分布式数据库」道路上的重要里程碑，TiDB 4.0 在提供良好的交易处理能力前提下，创新性地引入了基于 Raft 算法的 HTAP 架构解决方案。这套架构设计成功地解决了以往困扰 HTAP 架构的隔离性，一致性和性能之间的矛盾，以此为基础的论文《TiDB: A Raft-based HTAP Database》被国际顶级数据库会议 VLDB 2020 收录，标志着该架构得到了全球学术界的认可。\n\n云原生技术的普及加速了企业数字化转型，极大的降低上云的成本。基础设施借助于云的能力，变得更加弹性、无限扩展、可用性更强，按需付费更加节省成本。根据 Gartner 预测，到 2022 年将有 75% 的数据库将被部署或迁移到云上。\n\nTiDB 作为开源分布式数据库，弹性伸缩的架构天然具备云原生的特性，通过与 Kubernetes 无缝对接，TiDB 可以轻松部署在任何公有云、私有云和混合云之上，极大降低用户的总体拥有成本（TCO），提升资源利用率。2020 年 6 月，PingCAP 发布了 TiDB Cloud 产品，依托于公有云提供开箱即用的 TiDB 云数据库托管服务。借助于云，TiDB Cloud 可以通过水平扩展，拥有近乎无限的存储容量和计算能力，使用户可以专注在自身业务的快速增长。\n\n## 助力行业数字化转型\n\n大数据时代，信息数据爆炸性增长，几乎所有的企业数据都呈现指数级暴涨，数据库作为基础软件领域的重要基石，是企业全面数字化转型的关键引擎。PingCAP 成立五年多来，TiDB 作为通用分布式数据库，已被全球超过 1500 家企业用于线上生产环境，包括中国银行、光大银行、浦发银行、浙商银行、北京银行、微众银行、亿联银行、百信银行、中国银联、中国人寿、平安人寿、平安财险、国泰君安、华泰证券、陆金所、马上消费、拉卡拉、中国移动、中国联通、中国电信、新华财经、人民在线、吉林祥云、中体骏彩、国家电网、新奥燃气、北大人民医院、北京友谊医院、格力电器、理想汽车、小鹏汽车、VIVO、OPPO、麦当劳、百胜中国、中国邮政、顺丰速运、中通快递、腾讯、美团、京东、拼多多、小米、新浪微博、58同城、360、知乎、爱奇艺、哔哩哔哩、喜马拉雅、新东方、伴鱼、小红书、汽车之家、网易游戏、盖娅互娱、游族网络、Square（美国）、PayPay（日本）、Dailymotion（法国）、Shopee（新加坡）、ZaloPay（越南）、BookMyShow（印度）等，涉及金融、电信、政府、能源、公共事业、高端制造、高科技、新零售、物流、互联网、游戏等多个行业。\n\n以金融行业为例，TiDB 已成功在多家头部金融机构成功上线并长期稳定运行，支撑了包括核心总账交易、支付结算、在线贷款、零售理财、风控反欺诈、互联网金融、管理驾驶舱等诸多关键业务系统，全面满足金融行业对数据库稳定性、安全性和性能的高标准要求，成为金融机构数字化转型中 “稳态+敏态” 双轮驱动发展的关键赋能平台。\n\n## 开源文化构建国际化生态体系\n\nPingCAP 从成立之初就以开源为长期核心战略，并坚定地认为开源是基础软件在全球范围取得成功的最优道路。截止到 2020 年 10 月，TiDB 项目在 GitHub 上已总计获得超过 25000 颗星，近 1200 位开源代码贡献者，参与企业包括美团、知乎、伴鱼、丰巢、小米、微众银行、UCloud、Zoom、Samsung、Square、PayPay 等行业领军企业，TiDB 已成为全球基础软件领域的知名开源项目。高度活跃的开源社区为 TiDB 产品发展带来了正向反馈闭环，TiDB 的研发能力、工程质量、迭代速度都已处于世界一流水平，成为 PingCAP 最核心的、具有加速度的竞争力和护城河。\n\nPingCAP 一贯坚持开源精神，积极回馈开源社区，力争成为全球技术标准的引领者。2020 年 9 月，由 PingCAP 创立的分布式存储引擎 TiKV 正式从云原生基金会（CNCF）毕业；2020 年 7 月，由 PingCAP 创立的混沌工程测试平台 Chaos Mesh 正式成为 CNCF 托管项目；CNCF 2019 年年度报告提到，PingCAP 在 2019 年 CNCF 全球代码贡献排行榜中名列第六。PingCAP 已成为全球知名的开源软件厂商。\n\nPingCAP 以开源社区为依托，积极打造全球产业生态。PingCAP 已与复星、长亮科技、神州信息、文思海辉、中科软、汉得信息、迪思杰、爱可生、知乎、伴鱼、RedHat、Databricks、Datadog、Confluent 等行业领军企业建立了合作伙伴关系，涵盖产品研发、解决方案、技术服务、上下游生态、云服务等多个领域。广泛而高效的生态协同，使 TiDB 可以与合作伙伴一起持续创新，为用户创造更多的业务价值。\n\nPingCAP 创始人、CEO 刘奇表示：“我相信开放的社区生态与最具挑战的业务场景才能够催生出更好的产品。在过去五年，PingCAP 的产品历经了来自全球多个行业，不同业务场景的打磨，得到了全球用户的认可。未来 PingCAP 将继续夯实产品、完善生态合作，助力企业及开发者简化开发，加速迭代，专注于创新、创造，为全球企业的数字化转型贡献自己的力量。“\n\nGGV 纪源资本管理合伙人符绩勋表示：“开源基础软件是个巨大的市场，也是 GGV 重点投资的领域。PingCAP 的新一代分布式数据库，引领了全球的技术发展，受到了全球顶尖的大型企业客户的认可。我们相信在创始团队的带领下，PingCAP 能发展成为世界一流的技术公司。”\n\n五源资本创始合伙人刘芹表示：“这一轮融资，PingCAP 吸引到了全球最顶尖投资人的支持,  无论从投资规模还是投资人阵容上看，都是数据库及全球开源领域新的标杆和里程碑。公司在疫情期间，加速完成了全球化业务的扩张和国际化团队的落地，从一家技术极客公司进化到了一家全球化科技产品公司。”\n\n瑞银证券董事总经理、投资银行部科技媒体及电信组主管陈洁表示：“作为本次交易的独家财务顾问，瑞银非常荣幸能够协助 PingCAP 完成此次 D 轮融资，创造了全球基础软件领域的新历史。在市场充满挑战的背景下，PingCAP 的商业模式以及其开放的社区共荣理念获得了全球范围内最优质投资机构的认可，预祝 PingCAP 在助力全球企业数字化转型过程中持续承担关键角色，并不断发展壮大。”\n\nPingCAP 此前曾在 2015 年获得经纬中国领投的天使轮融资，2016 年获得云启资本领投 A 轮融资，2017 年获得华创资本领投 B 轮融资，2018 年获得复星、五源资本（原晨兴资本）领投的 C 轮融资。","date":"2020-11-23","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"series-d-financing","file":null,"relatedBlogs":[]},{"id":"Blogs_157","title":"Chaos Mesh 1.0 GA，让混沌工程变得简单！","tags":["Chaos Mesh"],"category":{"name":"公司动态"},"summary":"从开源到现在近一年的时间里，Chaos Mesh 在所有贡献者的共同努力下，在不断完善新功能的同时，在易用性和稳定性上也都取得了阶段性的成果，今天，我们自豪的宣布 Chaos Mesh 1.0 正式发布！","body":"Chaos Mesh 是一个云原生的混沌测试平台，在去年的最后一天，我们开源了这个项目，以帮助大家更好的进行混沌实验。从开源到现在近一年的时间里，Chaos Mesh 在所有贡献者的共同努力下，在不断完善新功能的同时，也在易用性和稳定性上取得了阶段性的成果。今天，我们自豪的宣布 Chaos Mesh 1.0 正式发布！\n\nChaos Mesh 1.0 是一个里程碑，不仅支持更多混沌注入的类型，提高了框架组件的稳定性，并且增加了 Chaos Dashboard 组件用来改善 Chaos Mesh 的易用性。下面请跟随我们的脚步梳理 Chaos Mesh 1.0 有什么样的惊喜。\n\n## 核心亮点\n\n### 1. 丰富易用的混沌实验类型\n\n混沌实验的核心是注入故障，Chaos Mesh 从分布式系统的出发，充分考虑分布式系统可能出现的故障，提供更加全面、细粒度的故障类型，能全方位的帮用户对网络、磁盘、文件系统、操作系统等进行故障注入。同时，使用 Chaos Mesh，不需要应用做任何修改，做到真正的被测试系统无感知。Chaos Mesh 目前支持的故障注入有：\n\n*   pod-kill：模拟 Kubernetes Pod 被 kill。\n\n*   pod-failure：模拟 Kubernetes Pod 持续不可用，可以用来模拟节点宕机不可用场景。\n\n*   container-kill：模拟 Container 被 kill。\n\n*   network-latency：模拟网络延迟。\n\n*   network-loss：模拟网络丢包。\n\n*   network-duplication：模拟网络包重复。\n\n*   network-corrupt：模拟网络包损坏。\n\n*   network-partition：模拟网络分区。\n\n*   cpu-burn：模拟 CPU 压力。\n\n*   memory-burn：模拟 Memory 压力。\n\n*   clock-skew：模拟时钟偏移。\n\n*   io-latency：模拟文件系统 I/O 延迟。\n\n*   io-fault：模拟文件系统 I/O 错误。\n\n*   io-attribution-override：模拟文件异常。\n\n*   kernel-injection: 模拟内核故障。\n\n### 2. 简单易用的可视化界面\n\nChaos Mesh 从用户角度出发，不仅可以提供通过 YAML 文件定义混沌实验的方式，还单独开发了 Chaos Dashbaord 组件，提供可视化支持。Chaos Dashboard 极大简化了混沌实验的复杂度，用户可以直接通过可视化界面来管理和监控混沌实验，仅需鼠标点一点就能够定义混沌实验的范围、指定混沌注入类型、定义调度规则，以及在界面上获取到混沌实验的结果等。\n\n![1-dash](https://img1.www.pingcap.com/prod/1_dash_cfc67d6308.gif)\n\n### 3. 提供 Grafana 插件支持\n\nChaos Mesh 为了进一步提高混沌实验的可观测性，单独开发了 [Grafana 插件](https://github.com/chaos-mesh/chaos-mesh-datasource)，方便用户直接将混沌实验的运行信息展示在自己的监控面板上。用户在 Grafana 上安装了此插件后，可以直接在应用的监控面板上开启混沌实验信息按钮，此时混沌实验的相关信息会以 [Annotations](https://grafana.com/docs/grafana/latest/dashboards/annotations/) 的方式在当前的面板上展示出来，这样用户就可以在一个界面上同时观察到应用的运行情况以及当前运行的混沌实验信息。\n\n![2-Grafana插件](https://img1.www.pingcap.com/prod/2_Grafana_84507b9536.png)\n\n### 4. 安全可控的混沌实验\n\n当在进行混沌实验的时候，我们需要严格的控制实验范围，只影响需要测试的应用程序，避免导致整体应用的雪崩。Chaos Mesh 在 1.0 版本中不仅提供了丰富的 Selectors 用来控制实验范围，还支持设置被保护的 Namespaces 用来保护重要应用。此外，在 1.0 中 Chaos Mesh 还支持在 Namespace 权限使用，也就是说用户可以在单个 Namespace 下安装 Chaos Mesh 或者是把 Chaos Mesh 的权限范围限制在特定某个 Namespace 下，如此一来可以更大程度控制实验的“爆炸半径”，提供更加安全的混沌实验体现。\n\n## 快速体验\n\n大家通过 install.sh 安装脚本或者是使用 Helm 工具就可以在自己的 Kubernetes 环境下快速的部署 Chaos Mesh，具体安装步骤可以参考 [Chaos Mesh 部署文档](https://chaos-mesh.org/docs/user_guides/installation)。此外社区的小伙伴也贡献了在线 Chaos Mesh 简单教程，想要快速尝试的小伙伴也可以直接按照课程，在线试用，课程地址：[https://chaos-mesh.org/interactive-tutorial](https://chaos-mesh.org/interactive-tutorial)。\n\n对于 1.0 GA 之前版本的用户，请参考 [1.0 Release Note](https://github.com/chaos-mesh/chaos-mesh/releases/tag/v1.0.0) 了解 1.0 的变更内容和升级指南。\n\n## 致谢\n\n感谢所有 Chaos Mesh 的贡献者 （[https://github.com/chaos-mesh/chaos-mesh/graphs/contributors](https://github.com/chaos-mesh/chaos-mesh/graphs/contributors))，Chaos mesh 能够走到 1.0 GA 离不开每一位贡献者的努力！\n\n最后欢迎大家为 Chaos Mesh 提交 issue 或者参考文档开始提交代码，Chaos Mesh 期待大家的参与和反馈！","date":"2020-09-25","author":"殷成文","fillInMethod":"writeDirectly","customUrl":"chaos-mesh-1.0-ga","file":null,"relatedBlogs":[]},{"id":"Blogs_23","title":"基于 TiDB 开源社区的友邻合作伙伴体系构建","tags":["合作伙伴生态"],"category":{"name":"公司动态"},"summary":"2020 年 PingCAP 合作伙伴生态体系构建全面启动，基于 TiDB 社区，秉承开放平等的全新社区化合作伙伴生态理念，产业生态合作、解决方案合作、联合技术中心等众多计划百花齐放。","body":">作者简介：余梦杰，PingCAP 合伙人、执行副总裁。\n\n2020 年 PingCAP 合作伙伴生态体系构建全面启动，基于 TiDB 社区，秉承开放平等的全新社区化合作伙伴生态理念，产业生态合作、解决方案合作、联合技术中心等众多计划百花齐放，下面介绍一下我们的合作伙伴生态体系理念、整体框架和一些落地成果。\n\n\n## 传统模式下的合作伙伴游戏规则\n\n在传统的体系下，原厂商和渠道商是处于供应链上下游的位置，彼此之间是通过商业利益进行连接的。在整个过程中，原厂商往往处于主导地位，如果我们用一个星系来比喻这套合作体系的话，那么处于太阳系这个星系的圆心，即绝对中心的就是原厂商，各个渠道商就像一颗颗行星一样围绕着原厂商去转动、发生连接、创造商业价值。\n\n但是在我看来，这样的引力是不可持续的，并且粘性是脆弱的。在 PingCAP 之前我本人也曾服务过数家软件企业，亲眼见证了诸多原厂商和渠道商的合作不顺利、合作破裂、不成功的情况。\n\n从本质上来讲，只要这家原厂商从源头上去切断他和渠道商的引力，那么合作关系在这样一个体系下就很难继续了。因为从生态角度来看，一旦渠道商被切断了引力，就无法继续同这个星系去发生连接了。\n\n\n## PingCAP 与合作伙伴间的游戏规则\n\n\n大家都知道 TiDB 本身是以开源为主导的模式。在这样的模式下，我们与合作伙伴之间的合作方式有没有可能有不一样的地方呢？\n基于 TiDB 的开源社区，我们希望打造一套 “友邻式” 的合作伙伴体系。在 TiDB 的这个星系里面，处于核心位置，处于引力源、太阳系位置的，不再是 PingCAP 这样一家商业公司，而是 TiDB 开源社区。因为 TiDB 本身是基于 Apache-2.0 的协议来开发和运营的，任何个人、公司、云厂商，只要不违反  Apache-2.0 协议的相关规定，都可以自由的去下载、研读、改写、编译 TiDB 的原代码，甚至可以发行自己的发行版，进行相应的商业活动。\n\n\n在这样的体系下，PingCAP 公司与合作伙伴之间是完全平等、独立的行星关系，PingCAP 公司是不可能切断合作伙伴与 TiDB 开源社区，也就是星系中的行星与太阳之间的连接的。即使有一天 PingCAP 这家商业公司不存在了，但是只要 TiDB 的社区还在，整个的生态还在，合作伙伴还是可以在这个大的 TiDB 的星系里面去持续的发掘和创造商业价值的。\n\n可能有一个比较好的例子就是 PostgreSQL（PG），现在有多少人知道 PG 的原厂是谁呢？\n\n刚才提到了整个 TiDB 星系里面的核心、引力源、太阳是 TiDB 的社区。目前为止，TiDB 社区已有超过 500 家的全球用户，超过 1000 位 Contributors，并且这些用户、Contributors 的数量是在不断加速增长的，他们不是 PingCAP 这家商业公司的资产，而且属于整个 TiDB 星系的。\n\n![1-TiDB-星系](https://img1.www.pingcap.com/prod/1_Ti_DB_c222740733.png)\n\n这个星系里面有各种各样的角色，除了总代和分销这样的角色以外，我们认为其他的合作伙伴都是和 PingCAP 完全平等、独立的行星。总代和分销商更像是 PingCAP 这一家商业公司的卫星，除此之外，整个星系中其他角色都是独立、与 PingCAP 平等的行星。大家彼此之间可以建立连接，有通航，有商业的合作；同时也可以不建立连接、不通航、不进行合作。但这并不妨碍整个 TiDB 星系的玩家以 TiDB 的社区作为辐射，在里面去寻找商业价值。\n\n当然我们是非常愿意为这些行星、伙伴提供相应的商业计划的。接下来我将逐一的介绍一下我们这些合作伙伴的类型以及我们为他提供的商业方案。\n\n\n## PingCAP 合作伙伴类型及商业方案\n\n\n\n### 1. 解决方案合作伙伴\n\n第一类行星，是解决方案合作伙伴。大家都知道 TiDB 本身是一个 Infra 的 database，它是不可能独立于应用去提供价值的，所以我们必须要和解决方案合作伙伴一起把产品的价值转化为解决方案的价值，从而转化为业务价值，乃至于战略价值，去成就我们的客户，去共同的帮助客户成功。\n所以针对这样的解决方案的合作伙伴，我们提供了一系列层次分明的合作伙伴计划，从优选、到高级、到白金 进行分层，同时对不同级别的合作伙伴也有对应的要求。\n\n![2-联合解决方案合作伙伴](https://img1.www.pingcap.com/prod/2_2804f4821d.png)\n\n比如我们要进行可靠性的验证，对新版本、新特性，包括功能、性能的一些测试；在行业标杆客户有落地的案例。同时在社区，我们有相应的 TiDB 技术内容的输出；有活跃的社区贡献者；有社区的布道师以及相应的联合市场活动等等。当然，我们也为不同级别的合作伙伴提供了对应的权利，包括但不限于，商机的共享、培训、售前和售后的支持以及分润和返点等。\n\n从 4 月份启动该合作方案的计划以来，我们已经和数家行业领先的解决方案厂商建立了合作伙伴关系。我们一起完成了兼容性的测试，性能和功能的测试，并且对大多数的合作伙伴，我们都在行业客户进行了落地。比如：神州信息的分布式核心系统、分布式网贷系统；长亮科技的银行分布式核心业务系统；文思海辉的金融分布式核心系统；开科唯识的银行互联网代销系统；汉得的清结算系统；北大医信的临床数据中心等。在这部分，我们也期望和更多解决方案合作伙伴一起来打造更蓬勃发展的 TiDB 星系。\n\n\n### 2. 技术服务合作伙伴 \n\n第二类行星，是技术服务的合作伙伴。技术服务的合作伙伴是指，坚定地看好 TiDB 的技术栈，愿意和 TiDB 共同成长，愿意以 TiDB 作为主航道之一的合作伙伴。因为 TiDB 还比较年轻，且头部客户对技术服务的要求比较高，所以，我们推出了联合技术中心的商业计划，来帮助我们的合作伙伴去培养 TiDB 的专业人才，为客户提供有 PingCAP 品质保证、价格有差异的技术服务能力。\n\n\n### 3. 产业生态合作伙伴\n\n第三类行星，是我们的产业生态合作伙伴。数据库的产业生态上下游，会包括如操作系统、芯片、中间件厂商等合作伙伴。对这些合作伙伴，我们提供了产品兼容性的测试以及相应的认证计划。截止到目前我们已经完成了和华为鲲鹏、中国电子飞腾、浪潮 OpenPOWER、统信 UOS、麒麟软件银河麒麟、东方通应用中间件、宝兰德应用中间件的兼容性测试和认证工作，值得一提的是 TiDB 是第一家同华为鲲鹏完成 validated 认证的数据库，后续还有更多的产业生态的合作也在推进过程中。\n\n\n### 4. 产品研发合作伙伴\n\n第四类行星，是我们的产品研发合作伙伴。因为 TiDB 本身是一个开源的数据库产品，研发实力比较强的合作伙伴可以基于自己对数据库、行业、运维和服务的理解，对 TiDB 进行定制化的开发。比如：独立的存储引擎；异构平台的打通；运维相关经验的平台产品等。针对这样的合作伙伴，我们是非常欢迎的，也相应的推出了联合产品的开发以及产品运营的计划。目前已有多家合作伙伴正在推进过程中。\n\n\n### 5. 云服务合作伙伴 \n\n最后一类行星，是我们云服务的合作伙伴。云既是未来，更是现在。TiDB 作为一个 Cloud-Native 的 HTAP 分布式数据库，同云的结合是 “丝滑柔顺” 的。我们在这个行业也有大量的落地以及相应的行业经验，我们非常愿意同云服务的合作伙伴一起，基于公有云、行业云的合作计划，共同为客户提供价值，为合作伙伴创造利润。\n\n在 TiDB 的这样的星系里面，PingCAP 只是一个很小的行星，为了蓬勃发展 TiDB 的星系，今年我们成立了独立的合作伙伴生态部门，来为 TiDB 的星系添砖加瓦。截止到目前，短短半年的时间里，我们已经拥有了众多 解决方案的行星、技术服务和产品研发的行星、产业生态的行星以及云服务的行星。随着 TiDB 星系的玩家越来越多，我们对更美好的未来充满自信。\n\n\n\n## PingCAP 爱可生战略合作\n\n\n\n最后我想借今天这个场合（注：6 月 6～7 日举办的 [TiDB DevCon 2020 技术大会](https://pingcap.com/community-cn/devcon2020/)），正式宣布 PingCAP 公司同爱可生公司的战略合作。\n\n爱可生公司是行业领先的基于 MySQL 的解决方案提供商，在金融、电信等行业有诸多的头部客户和极大的行业影响力。PingCAP 将和爱可生一起打造业界领先的基于 MySQL Family 的联合解决方案，为我们的客户持续创造价值。\n\n双方的合作包括：\n\n+ 爱生可将进入 TiDB 的社区，成为 TiDB 社区的企业级的贡献者；\n+ 爱可生将实现其运维管理平台 DMP 对 TiDB 多集群可视化管理的全面支持；\n+ 构建 DBLE 到 TiDB 的双向实时复制的产品级的解决方案以及相应的数据迁移服务能力；\n+ 双方将建立联合技术中心，共同研究和推广 TiDB 在智能运维管理、私有云建设、多中心容灾等领域的解决方案，并面向我们的商业客户提供整体打通的企业级运维服务。\n\n爱可生的 CEO 李恒先生也给我们发来的致辞：\n\n>作为 NewSQL 分布式数据库的代表产品，爱可生非常看好 TiDB 在 HTAP 领域为各行业应用带来的创新体验。同时，TiDB 开发的生态体系也为像爱可生这样的解决方案厂商带来了全新的市场空间。此次 PingCAP 与爱可生的战略合作源于爱可生在数据库管理平台领域的深厚技术积累以及金融数据库解决方案的丰富落地。在数据库领域除了数据库内核能力，管理平台和体系化管理服务对于数据库的大规模使用也至关重要。\n>\n>TiDB 是优秀的分布式数据库产品，爱可生将致力于把这样优秀的开源数据库内核纳入我们的数据库管理产品能力和服务范畴，未来爱可生将提供面向私有云的更多数据库的管理平台产品和服务，更好地帮助客户解决数据库国产化替代当中的实际问题。\n>\n>最后我相信 PingCAP 的产品能力，加之爱可生的管理解决方案能力的强强联合，会将 TiDB 推动到新的高度，谢谢大家。\n\n感谢李恒先生的致辞。我们也怀着真诚的、开放的态度，诚邀各行各业的合作伙伴加入以 TiDB 社区为核心的 TiDB 星系，打造独立、平等、长期可持续发展的合作关系。\n\n**星辰大海，与你同行，谢谢大家！**\n\n\n>本文整理自余梦杰在 [TiDB DevCon 2020](https://pingcap.com/community-cn/devcon2020/) 上的演讲，大会相关视频回顾可以关注官方 Bilibili 账号 [TiDB_Robot](https://space.bilibili.com/86485707)。","date":"2020-06-22","author":"余梦杰","fillInMethod":"writeDirectly","customUrl":"partner-system-based-on-the-tidb-open-source-community","file":null,"relatedBlogs":[]},{"id":"Blogs_155","title":"云上 TiDB 管理「利器」，TiDB Operator 1.0 GA 发布","tags":["Cloud-TiDB","TiDB Operator","社区","社区动态"],"category":{"name":"公司动态"},"summary":"开源后到现在的近一年内，我们一方面基于用户反馈不断打磨项目的易用性，另一方面通过严苛的稳定性测试持续提升可靠性。今天，我们自豪地宣布 TiDB Operator 1.0 GA 正式发布！","body":"![头图](https://img1.www.pingcap.com/prod/1_6117b14a41.png)\n\n去年八月份，我们 [开源了 TiDB Operator](https://pingcap.com/blog-cn/tidb-operator-introduction/) 项目，以实现 TiDB 在 Kubernetes 上的部署和运维。开源后到现在的近一年内，我们一方面基于用户反馈不断打磨项目的易用性，另一方面通过严苛的稳定性测试持续提升可靠性。今天，我们自豪地宣布 TiDB Operator 1.0 GA 正式发布！\n\n![TiDB Operator architecture](https://img1.www.pingcap.com/prod/2_299af41fbd.png)\n\n<div class=\"caption-center\">TiDB Operator architecture</div>\n\n\n**TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统。提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。**\n\n1.0 是 TiDB Operator 的首个 GA 版本，具备以下核心亮点。\n\n## 核心亮点\n\n### 1. 简化 TiDB 运维管理\n\nTiDB 是一个复杂的分布式系统，它的部署和运维需要比较深入的领域知识，这带来了颇高的学习成本和负担。TiDB Operator 则通过自定义资源对象（Custom Resource）、自定义控制器（Custom controller）和调度器扩展（Scheduler extender）为 Kubernetes 注入 TiDB 的专业运维知识，允许用户以 Kubernetes 的声明式 API 风格来管理 TiDB 集群。具体来说，用户只需要描述集群规格，TiDB Operator 就会不断调整 Kubernetes 中的资源，驱动实际集群满足该描述。**在这种模式下，TiDB 集群会自动完成服务的健康检查、故障转移，而部署、升级、扩缩容等操作则能通过修改集群的规格定义“一键”完成，极大简化了 TiDB 集群的运维管理。**\n\n更重要的是，标准化的集群管理 API 允许用户完成内部工具链或 PaaS 平台与 TiDB 集群管理的深度整合，真正赋能用户玩转 TiDB。\n\n### 2. 稳定可靠\n\n作为数据库，TiDB 往往处于整个系统架构中的最核心位置，对于稳定性有着严苛要求。这同样也是对 TiDB Operator 的要求。为了确保所有自动化运维操作的稳定可靠，我们为 TiDB Operator 专门设计了稳定性测试，在施加较大读写负载的同时，不断进行各类运维操作并模拟主机、容器、磁盘、网络、Kubernetes 组件和 TiDB Operator 组件的各类故障，观察在这些场景下 TiDB Operator 的行为是否符合预期。通过 7 * 24 小时不间断运行稳定性测试，我们发现并修复了诸多极端的边界情况。在 1.0 发布前，TiDB Operator 稳定性测试已经稳定运行数月。\n\n### 3. 多云支持\n\n**1.0 提供了面向 AWS、谷歌云和阿里云的 Terraform 部署脚本。** 这些脚本能帮助大家在十几分钟内创建一个 Kubernetes 集群，并在该集群上部署一个或更多生产可用的 TiDB 集群。在后续的管理过程中，Terraform 脚本会在操作 TiDB 集群的同时对相关的云资源进行操作。比如，当扩容一个 TiDB 集群时，Terraform 脚本就会自动创建更多的云服务器来承载集群扩容后的资源需求。\n\n## 体验 TiDB Operator\n\n大家可以通过 Terraform 在 AWS（[部署文档](https://pingcap.com/docs-cn/v3.0/tidb-in-kubernetes/deploy/aws-eks/)）、谷歌云（[部署文档](https://pingcap.com/docs-cn/v3.0/tidb-in-kubernetes/deploy/gcp-gke/)）、阿里云（[部署文档](https://pingcap.com/docs-cn/v3.0/tidb-in-kubernetes/deploy/alibaba-cloud/)）上快速部署 TiDB Operator 以及下属的 TiDB 集群，也可以参考 [通用 Kubernetes 部署文档](https://pingcap.com/docs-cn/v3.0/tidb-in-kubernetes/deploy/general-kubernetes/) 在任何 Kubernetes 集群上部署并体验 TiDB Operator。\n\n对于 Pre GA 版本的用户，请参考 [1.0 Release Note](https://github.com/pingcap/tidb-operator/blob/master/CHANGELOG.md) 了解 1.0 的变更内容和升级指南。\n\n## 致谢\n\n感谢所有 TiDB Operator 的贡献者（[https://github.com/pingcap/tidb-operator/graphs/contributors](https://github.com/pingcap/tidb-operator/graphs/contributors)），1.0 能够走到 GA 离不开每一位贡献者的努力！\n\n**最后欢迎大家为 TiDB Operator [提交 issue](https://github.com/pingcap/tidb-operator/issues) 或参考[贡献文档](https://github.com/pingcap/tidb-operator/blob/master/docs/CONTRIBUTING.md)开始提交代码，TiDB Operator 期待大家的参与和反馈！**","date":"2019-07-30","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-operator-1.0-ga","file":null,"relatedBlogs":[]},{"id":"Blogs_85","title":"TiDB 3.0 GA，稳定性和性能大幅提升","tags":["TiDB","版本","社区动态"],"category":{"name":"公司动态"},"summary":"2019 年 6 月 28 日，TiDB 3.0 GA 正式发布，请跟随我们的脚步看看 TiDB 3.0 有什么样的惊喜。","body":"TiDB 是 PingCAP 自主研发的开源分布式关系型数据库，具备商业级数据库的数据可靠性，可用性，安全性等特性，支持在线弹性水平扩展，兼容 MySQL 协议及生态，创新性实现 OLTP 及 OLAP 融合。\n\n**TiDB 3.0 版本显著提升了大规模集群的稳定性，集群支持 150+ 存储节点，300+TB 存储容量长期稳定运行。易用性方面引入大量降低用户运维成本的优化，包括引入 Information_Schema 中的多个实用系统视图、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特别是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升约 4.5 倍，Sysbench 性能提升约 1.5 倍，OLAP 方面，TPC-H 50G Q15 因实现 View 可以执行，至此 TPC-H 22 个 Query 均可正常运行。新功能方面增加了窗口函数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）。**\n\n截止本文发稿时 TiDB 已在 500+ 用户的生产环境中长期稳定运行，涵盖金融、保险、制造，互联网，游戏等领域，涉及交易、数据中台、历史库等多个业务场景。不同业务场景对关系型数据库的诉求可用 “百花齐放”来形容，但对关系数据库最根本的诉求未发生任何变化，如数据可靠性，系统稳定性，可扩展性，安全性，易用性等。请跟随我们的脚步梳理 TiDB 3.0 有什么样的惊喜。\n\n## 一、提升大规模集群稳定性\n\n3.0 与 2.1 版本相比，显著提升了大规模集群的稳定性，支持单集群 150+ 存储节点，300+TB 存储容量长期稳定运行，主要的优化点如下：\n\n1\\. 优化 Raft 副本之间的心跳机制，按照 Region 的活跃程度调整心跳频率，减小冷数据对集群的负担。\n\n2\\. 热点调度策略支持更多参数配置，采用更高优先级，并提升热点调度的准确性。\n\n3\\. 优化 PD 调度流程，提供调度限流机制，提升系统稳定性。\n\n4\\. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 时间，提升系统稳定性。\n\n## 二、提升查询计划的稳定性\n\n众所周知，数据库查询计划的稳定性对业务至关重要，TiDB 3.0 版本采用多种优化手段提升查询计划的稳定性，如下：\n\n1. 新增 Fast Analyze 功能，提升收集统计信息的速度，降低集群资源的消耗及对业务的影响。\n\n2. 新增 Incremental Analyze 功能，提升收集单调递增的索引统计信息的速度，降低集群资源的消耗及对业务的影响。\n\n3. 在 CM-Sketch 中新增 TopN 的统计信息，缓解 CM-Sketch 哈希冲突导致估算偏大，提升代价估算的准确性，提升查询计划的稳定性。\n\n4. 引入 Skyline Pruning 框架，利用规则防止查询计划过度依赖统计信息，缓解因统计信息滞后导致选择的查询计划不是最优的情况，提升查询计划的稳定性。\n\n5. 新增 SQL Plan Management 功能，支持在查询计划不准确时手动绑定查询计划，提升查询计划的稳定性。\n\n## 三、提升系统性能，TPC-C 性能提升约 4.5 倍，Sysbench 性能提升约 1.5 倍\n\n### 1. OLTP\n\n\n![OLTP-1](https://img1.www.pingcap.com/prod/1_c231715457.png)\n\n![OLTP-2](https://img1.www.pingcap.com/prod/2_97acf01ed0.png)\n\n![OLTP-3](https://img1.www.pingcap.com/prod/3_741015bb2e.png)\n\n![OLTP-4](https://img1.www.pingcap.com/prod/4_f79a4da72d.png)\n\n3.0 与 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升约 1.5 倍，TPC-C 性能提升约 4.5 倍。主要的优化点如下：\n\n1. TiDB 持续优化 SQL 执行器，包括：优化 `NOT EXISTS` 子查询转化为 Anti Semi Join，优化多表 Join 时 Join 顺序选择等。\n\n2. 优化 Index Join 逻辑，扩大 Index Join 算子的适用场景并提升代价估算的准确性。\n\n3. TiKV 批量接收和发送消息功能，提升写入密集的场景的 TPS 约 7%，读密集的场景提升约 30%。\n\n4. TiKV 优化内存管理，减少 `Iterator Key Bound Option` 的内存分配和拷贝，多个 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。\n\n5. 引入 Titan 存储引擎插件，提升 Value 值超过 1KB 时性能，缓解 RocksDB 写放大问题，减少磁盘 IO 的占用。\n\n6. TiKV 新增多线程 Raftstore 和 Apply 功能，提升单节点内可扩展性，进而提升单节点内并发处理能力和资源利用率，降低延时，大幅提升集群写入能力。\n\n### 2.TiDB Lightning\n\n![TiDB Lightning](https://img1.www.pingcap.com/prod/5_6e03a685d5.png)\n\nTiDB Lightning 性能与 2019 年年初相比提升 3 倍，从 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，优化点，如下：\n\n1. 提升 SQL 转化成 KV Pairs 的性能，减少不必要的开销。\n\n2. 提升单表导入性能，单表支持批量导入。\n\n3. 提升 TiKV-Importer 导入数据性能，支持将数据和索引分别导入。\n\n4. TiKV-Importer 支持上传 SST 文件限速功能。\n\n## 四、提升系统安全性\n\n**RBAC（Role-Based Access Control，基于角色的权限访问控制）** 是商业系统中最常见的权限管理技术之一，通过 RBAC 思想可以构建最简单“用户-角色-权限”的访问权限控制模型。RBAC 中用户与角色关联，权限与角色关联，角色与权限之间一般是多对多的关系，用户通过成为什么样的角色获取该角色所拥有的权限，达到简化权限管理的目的，通过此版本的迭代 RBAC 功能开发完成。\n\n**IP 白名单功能（企业版特性）**：TiDB 提供基于 IP 白名单实现网络安全访问控制，用户可根据实际情况配置相关的访问策略。\n\n**Audit log 功能（企业版特性）**：Audit log 记录用户对数据库所执行的操作，通过记录 Audit log 用户可以对数据库进行故障分析，行为分析，安全审计等，帮助用户获取数据执行情况。\n\n**加密存储（企业版特性）**：TiDB 利用 RocksDB 自身加密功能，实现加密存储的功能，保证所有写入到磁盘的数据都经过加密，降低数据泄露的风险。\n\n**完善权限语句的权限检查**，新增 `ANALYZE`，`USE`，`SET GLOBAL`，`SHOW PROCESSLIST` 语句权限检查。\n\n## 五、提升系统易用性\n\n1. 新增 SQL 方式查询慢查询，丰富 TiDB 慢查询日志内容，如：Coprocessor 任务数，平均/最长/90% 执行/等待时间，执行/等待时间最长的 TiKV 地址，简化慢查询定位工作，提高排查慢查询问题效率，提升产品易用性。\n\n2. 新增系统配置项合法性检查，优化系统监控项等，提升产品易用性。\n\n3. 新增对 `TableReader`、`IndexReader` 和 `IndexLookupReader` 算子内存使用情况统计信息，提高 Query 内存使用统计的准确性，提升处理内存消耗较大语句的效率。\n\n4. 制定日志规范，重构日志系统，统一日志格式，方便用户理解日志内容，有助于通过工具对日志进行定量分析。\n\n5. 新增 `EXPLAIN ANALYZE` 功能，提升SQL 调优的易用性。\n\n6. 新增 SQL 语句 `Trace` 功能，方便排查问题。\n\n7. 新增通过 `unix_socket` 方式连接数据库。\n\n8. 新增快速恢复被删除表功能，当误删除数据时可通过此功能快速恢复数据。\n\n## 六、增强 HTAP 能力\n\n**TiDB 3.0 新增 TiFlash  组件，解决复杂分析及 HTAP 场景。TiFlash 是列式存储系统，与行存储系统实时同步，具备低延时，高性能，事务一致性读等特性。** 通过 Raft 协议从 TiKV 中实时同步行存数据并转化成列存储格式持久化到一组独立的节点，解决行列混合存储以及资源隔离性问题。TiFlash 可用作行存储系统（TiKV）实时镜像，实时镜像可独立于行存储系统，将行存储及列存储从物理隔离开，提供完善的资源隔离方案，HTAP 场景最优推荐方案；亦可用作行存储表的索引，配合行存储对外提供智能的 OLAP 服务，提升约 10 倍复杂的混合查询的性能。\n\nTiFlash 目前处于 Beta 阶段，计划 2019 年 12 月 31 日之前 GA，欢迎大家申请试用。\n\n## 七、未来规划\n\n**未来我们会继续投入到系统稳定性，易用性，性能，弹性扩展方面，向用户提供极致的弹性伸缩能力，极致的性能体验，极致的用户体验。**\n\n稳定性方面 V4.0 版本将继续完善 V3.0 未 GA 的重大特性，例如：悲观事务模型，View，Table Partition，Titan 行存储引擎，TiFlash 列存储引擎；引入近似物理备份恢复解决分布数据库备份恢复难题；优化 PD 调度功能等。\n\n性能方面 V4.0 版本将继续优化事务处理流程，减少事务资源消耗，提升性能，例如：1PC，省去获取 commit ts 操作等。\n\n弹性扩展方面，PD 将提供弹性扩展所需的元信息供外部系统调用，外部系统可根据元信息及负载情况动态伸缩集群规模，达成节省成本的目标。\n\n## 八、社区概况\n\n我们相信战胜“未知”最好的武器就是社区的力量，基础软件需要坚定地走开源路线。截止发稿我们已经完成 41 篇源码阅读文章。TiDB 开源社区总计 265 位 Contributor，6 位 Committer，在这里我们对社区贡献者表示由衷的感谢，希望更多志同道合的人能加入进来，也希望大家在 TiDB 这个开源社区能够有所收获。\n\n>TiDB 3.0 GA Release Notes：[https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/](https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/)","date":"2019-06-28","author":"段兵","fillInMethod":"writeDirectly","customUrl":"tidb-3.0-ga","file":null,"relatedBlogs":[]},{"id":"Blogs_125","title":"TiDB Binlog 组件正式开源","tags":["TiDB Binlog","社区","社区动态"],"category":{"name":"公司动态"},"summary":"为方便用户和开发者更加深入理解和使用 TiDB Binlog 组件，以及基于 TiDB Binlog 组件做二次开发用于更多的业务场景， TiDB 团队决定于 2019 年 5 月 6 日正式开源 TiDB Binlog 组件。","body":"[TiDB Binlog](https://github.com/pingcap/tidb-binlog) 组件用于收集 TiDB 的 binlog，并准实时同步给下游，如：TiDB/MySQL等。该组件在功能上类似于 MySQL 的主从复制，会收集各个 TiDB 实例产生的 binlog，并按事务提交的时间排序，全局有序的将数据同步至下游。利用 TiDB Binlog 可以实现数据准实时同步到其他数据库，以及 TiDB 数据准实时的备份与恢复。TiDB Binlog 作为 TiDB 的核心组件之一，已经在上百家用户的生产环境中长时间稳定运行。\n\n为方便用户和开发者更加深入理解和使用 TiDB Binlog 组件，以及基于 TiDB Binlog 组件做二次开发用于更多的业务场景， 我们决定今天正式开源 TiDB Binlog 组件。\n\n## TiDB Binlog 适用的功能场景\n\n+ 准实时数据同步：同步 TiDB 数据到其他数据库或消息队列（如 TiDB/MySQL/MariaDB/Kafka）。\n+ 准实时备份和恢复：增量备份 TiDB 集群数据到外部系统，利用备份的数据在系统故障或者其他场景时可将数据恢复到任意时间点。\n\n## TiDB Binlog 架构\n\n![TiDB Binlog 架构](https://img1.www.pingcap.com/prod/1_117e788a05.png)\n\n<div class=\"caption-center\">TiDB Binlog 架构</div>\n\n## TiDB Binlog 核心特性\n\n+ 支持类似 MySQL ROW 复制模式。\n+ 准实时并按事务提交的时间顺序将数据同步至下游。\n+ 分布式架构设计，支持水平弹性扩容和服务高可用。\n+ 数据高可靠，系统实时将数据持久化到本地磁盘。\n+ 支持多种输出方式，如下：\n    - 文件：系统准实时将 binlog 写入文件系统作为增量备份，利用此增量备份文件可将数据恢复到任意时间点。\n    - 消息队列：按照 [binlog slave protocol](https://pingcap.com/docs-cn/tools/binlog/binlog-slave-client/) 输出到 Kafka。\n    - 下游目标数据库：TiDB/MySQL/MariaDB。\n\n## TiDB Binlog 代码及文档资源\n\n+ [TiDB Binlog 源代码](https://github.com/pingcap/tidb-binlog)\n+ [TiDB Binlog 使用手册](https://pingcap.com/docs-cn/tools/binlog/overview/)\n+ [深入理解 TiDB Binlog 组件实现原理](https://pingcap.com/blog-cn/tidb-ecosystem-tools-1/)\n+ [定制输出方式或者输出到其他下游存储系统](https://pingcap.com/docs-cn/tools/binlog/binlog-slave-client/)\n\n**欢迎大家一起参与 TiDB Binlog 的设计、研发、测试共同推进 TiDB Binlog 走向更成熟，更稳定。近期我们将发布 TiDB Binlog 源码阅读指南，敬请期待。**","date":"2019-05-06","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-binlog-open-source","file":null,"relatedBlogs":[]},{"id":"Blogs_54","title":"TiDB 2.1 GA Release Notes","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"2018 年 11 月 30 日，TiDB 发布 2.1 GA 版。相比 2.0 版本，该版本对系统稳定性、性能、兼容性、易用性做了大量改进。","body":"2018 年 11 月 30 日，TiDB 发布 2.1 GA 版。相比 2.0 版本，该版本对系统稳定性、性能、兼容性、易用性做了大量改进。\n\n## TiDB\n\n### SQL 优化器\n\n* 优化 `Index Join` 选择范围，提升执行性能\n* 优化 `Index Join` 外表选择，使用估算的行数较少的表作为外表\n* 扩大 Join Hint `TIDB_SMJ` 的作用范围，在没有合适索引可用的情况下也可使用 Merge Join\n* 加强 Join Hint `TIDB_INLJ` 的能力，可以指定 Join 中的内表\n* 优化关联子查询，包括下推 Filter 和扩大索引选择范围，部分查询的效率有数量级的提升\n* 支持在 `UPDATE` 和 `DELETE` 语句中使用 Index Hint 和 Join Hint\n* 支持更多函数下推：`ABS`/`CEIL`/`FLOOR`/`IS TRUE`/`IS FALSE`\n* 优化内建函数 `IF` 和 `IFNULL` 的常量折叠算法\n* 优化 `EXPLAIN` 语句输出格式, 使用层级结构表示算子之间的上下游关系\n\n### SQL 执行引擎\n\n* 重构所有聚合函数，提升 `Stream` 和 `Hash` 聚合算子的执行效率\n* 实现并行 `Hash Aggregate` 算子，部分场景下有 350% 的性能提升\n* 实现并行 `Project` 算子，部分场景有 74% 的性能提升\n* 并发地读取 `Hash Join` 的 `Inner` 表和 `Outer` 表的数据，提升执行性能\n* 优化 `REPLACE INTO` 语句的执行速度，性能提升 10x\n* 优化时间类型的内存占用，时间类型数据的内存使用降低为原来的一半\n* 优化点查的查询性能, Sysbench 点查效率提升 60%\n* TiDB 插入和更新宽表，性能提升接近 20 倍\n* 支持在配置文件中设置单个查询的内存使用上限\n* 优化 `Hash Join` 的执行过程，当 Join 类型为 `Inner Join` 或者 `Semi Join` 时，如果内表为空，不再读取外表数据，快速返回结果\n* 支持 [`EXPLAIN ANALYZE`](https://pingcap.com/docs-cn/dev/reference/performance/understanding-the-query-execution-plan/#span-id-explain-analyze-output-format-explain-analyze-输出格式-span) 语句，用于查看 Query 执行过程中各个算子的运行时间，返回结果行数等运行时统计信息\n\n### 统计信息\n\n* 支持只在一天中的某个时间段开启统计信息自动 ANALYZE 的功能\n\n* 支持根据查询的反馈自动更新表的统计信息\n\n* 支持通过 `ANALYZE TABLE WITH BUCKETS` 语句配置直方图中桶的个数\n\n* 优化等值查询和范围查询混合的情况下使用直方图估算 Row Count 的算法\n\n### 表达式\n\n* 支持内建函数：\n    * `json_contains`  \n    * `json_contains_path`\n    * `encode/decode`\n\n### Server\n\n* 支持在单个 tidb-server 实例内部对冲突事务排队，优化事务间冲突频繁的场景下的性能\n* 支持 Server Side Cursor\n* 新增 [HTTP 管理接口](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md)\n    * 打散 table 的 regions 在 TiKV 集群中的分布\n    * 控制是否打开 `general log`\n    * 在线修改日志级别\n    * 查询 TiDB 集群信息\n* [添加 `auto_analyze_ratio` 系统变量控制自动 Analyze 的阈值](https://pingcap.com/docs-cn/FAQ/#3-3-11-%E5%9C%A8-tidb-%E4%B8%AD-auto-analyze-%E7%9A%84%E8%A7%A6%E5%8F%91%E7%AD%96%E7%95%A5%E6%98%AF%E6%80%8E%E6%A0%B7%E7%9A%84)\n* [添加 `tidb_retry_limit` 系统变量控制事务自动重试的次数](https://pingcap.com/docs-cn/sql/tidb-specific/#tidb-retry-limit)\n* [添加 `tidb_disable_txn_auto_retry` 系统变量控制事务是否自动重试](https://pingcap.com/docs-cn/sql/tidb-specific/#tidb-disable-txn-auto-retry)\n* [支持使用 `admin show slow` 语句来获取慢查询语句](https://pingcap.com/docs-cn/sql/slow-query/#admin-show-slow-%E5%91%BD%E4%BB%A4)\n* [增加环境变量 `tidb_slow_log_threshold` 动态设置 slow log 的阈值](https://pingcap.com/docs-cn/sql/tidb-specific/#tidb_slow_log_threshold)\n* [增加环境变量 `tidb_query_log_max_len` 动态设置日志中被截断的原始 SQL 语句的长度](https://pingcap.com/docs-cn/sql/tidb-specific/#tidb_query_log_max_len)\n\n###  DDL\n\n* 支持 Add Index 语句与其他 DDL 语句并行执行，避免耗时的 Add Index 操作阻塞其他操作\n* 优化 `Add Index` 的速度，在某些场景下速度大幅提升\n* 支持 `select tidb_is_ddl_owner()` 语句，方便判断 TiDB 是否为 `DDL Owner`\n* 支持 `ALTER TABLE FORCE` 语法\n* 支持 `ALTER TABLE RENAME KEY TO` 语法\n* `Admin Show DDL Jobs` 输出结果中添加表名、库名等信息\n* [支持使用 `ddl/owner/resign` HTTP 接口释放 DDL Owner 并开启新一轮 DDL Owner 选举](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md)\n\n### 兼容性\n\n* 支持更多 MySQL 语法\n* `BIT` 聚合函数支持 `ALL` 参数\n* 支持 `SHOW PRIVILEGES` 语句\n* 支持 `LOAD DATA` 语句的 `CHARACTER SET` 语法\n* 支持 `CREATE USER` 语句的 `IDENTIFIED WITH` 语法\n* 支持 `LOAD DATA IGNORE LINES` 语句\n* `Show ProcessList` 语句返回更准确信息\n\n## PD\n\n### 可用性优化\n\n* 引入 TiKV 版本控制机制，支持集群滚动兼容升级\n* PD 节点间 [开启 `Raft PreVote`](https://github.com/pingcap/pd/blob/5c7b18cf3af91098f07cf46df0b59fbf8c7c5462/conf/config.toml#L22)，避免网络隔离后恢复时产生的重新选举\n* 开启 `raft learner` 功能，降低调度时出现宕机导致数据不可用的风险\n* TSO 分配不再受系统时间回退影响\n* 支持 `Region merge` 功能，减少元数据带来的开销\n\n### 调度器优化\n\n* 优化 Down Store 的处理流程，加快发生宕机后补副本的速度\n* 优化热点调度器，在流量统计信息抖动时适应性更好\n* 优化 Coordinator 的启动，减少重启 PD 时带来的不必要调度\n* 优化 Balance Scheduler 频繁调度小 Region 的问题\n* 优化 Region merge，调度时考虑 Region 中数据的行数\n* [新增一些控制调度策略的开关](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#config-show--set--)\n* 完善[调度模拟器](https://github.com/pingcap/pd/tree/release-2.1/tools/pd-simulator)，添加调度场景模拟\n\n### API 及运维工具\n\n* 新增 [`GetPrevRegion` 接口](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L40)，用于支持 TiDB reverse scan 功能\n* 新增 [`BatchSplitRegion` 接口](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L54)，用于支持 TiKV 快速 Region 分裂\n* 新增 [`GCSafePoint` 接口](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L64-L66)，用于支持 TiDB 并发分布式 GC\n* 新增 [`GetAllStores` 接口](https://github.com/pingcap/kvproto/blob/8e3f33ac49297d7c93b61a955531191084a2f685/proto/pdpb.proto#L32)，用于支持 TiDB 并发分布式 GC\n* pd-ctl 新增：\n    * [使用统计信息进行 Region split](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#operator-show--add--remove)\n    * [调用 `jq` 来格式化 JSON 输出](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#jq-格式化-json-输出示例)\n    * [查询指定 store 的 Region 信息](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#region-store-store_id)\n    * [查询按 version 排序的 topN 的 Region 列表](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#region-topconfver-limit)\n    * [查询按 size 排序的 topN 的 Region 列表](https://pingcap.com/docs-cn/dev/reference/tools/pd-control/#region-topsize-limit)\n    * [更精确的 TSO 解码](https://github.com/pingcap/pd/pull/1242)\n* [pd-recover](https://github.com/pingcap/docs-cn/blob/aea707820d683c0564bab28ca756d1c4a3eb62c2/v2.1/reference/tools/pd-recover.md) 不再需要提供 max-replica 参数\n\n### 监控\n\n* 增加 `Filter `相关的监控\n* 新增 etcd Raft 状态机相关监控\n\n### 性能优化\n\n* 优化处理 Region heartbeat 的性能，减少 heartbeat 带来的内存开销\n* 优化 Region tree 性能\n* 优化计算热点统计的性能问题\n\n## TiKV\n\n### Coprocessor\n\n* 新增支持大量内建函数\n* [新增 Coprocessor ReadPool，提高请求处理并发度](https://github.com/tikv/rfcs/blob/master/text/2017-12-22-read-pool.md)\n* 修复时间函数解析以及时区相关问题\n* 优化下推聚合计算的内存使用\n\n### Transaction\n\n* 优化 MVCC 读取逻辑以及内存使用效率，提高扫描操作的性能，Count 全表性能比 2.0 版本提升 1 倍\n* 折叠 MVCC 中连续的 Rollback 记录，保证记录的读取性能\n* [新增 `UnsafeDestroyRange` API 用于在 drop table/index 的情况下快速回收空间](https://github.com/tikv/rfcs/blob/master/text/2018-08-29-unsafe-destroy-range.md)\n* GC 模块独立出来，减少对正常写入的影响\n* kv_scan 命令支持设置 upper bound\n\n### Raftstore\n\n* 优化 snapshot 文件写入流程避免导致 RocksDB stall\n* [增加 LocalReader 线程专门处理读请求，降低读请求的延迟](https://github.com/tikv/rfcs/pull/17)\n* [支持 `BatchSplit` 避免大量写入导致产生特别大的 Region](https://github.com/tikv/rfcs/pull/6)\n* 支持按照统计信息进行 Region Split，减少 IO 开销\n* 支持按照 Key 的数量进行 Region Split，提高索引扫描的并发度\n* 优化部分 Raft 消息处理流程，避免 Region Split 带来不必要的延迟\n* 启用 `PreVote` 功能，减少网络隔离对服务的影响\n\n### 存储引擎\n\n* 修复 RocksDB `CompactFiles` 的 bug，可能影响 Lightning 导入的数据\n* 升级 RocksDB 到 v5.15，解决 snapshot 文件可能会被写坏的问题\n* 优化 `IngestExternalFile`，避免 flush 卡住写入的问题\n\n### tikv-ctl\n\n* [新增 ldb 命令，方便排查 RocksDB 相关问题](https://tikv.org/docs/3.0/reference/tools/tikv-ctl/#ldb-command)\n* compact 命令支持指定是否 compact bottommost 层的数据\n\n## Tools\n\n* 全量数据快速导入工具 [TiDB Lightning](https://docs.pingcap.com/zh/tidb/v4.0/tidb-lightning-overview)\n* 支持新版本 [TiDB Binlog](https://pingcap.com/docs-cn/v2.1/reference/tidb-binlog-overview/)\n\n## 升级兼容性说明\n\n* 由于新版本存储引擎更新，不支持在升级后回退至 2.0.x 或更旧版本\n* 新版本默认开启 `raft learner` 功能，如果从 1.x 版本集群升级至 2.1 版本，须停机升级或者先滚动升级 TiKV，完成后再滚动升级 PD\n* 从 2.0.6 之前的版本升级到 2.1.0 之前，最好确认集群中是否存在正在运行中的 DDL 操作，特别是耗时的 Add Index 操作\n* 因为 2.1 版本启用了并行 DDL，对于早于 2.0.1 版本的集群，无法滚动升级到 2.1，可以选择下面两种方案：\n    * 停机升级，直接从早于 2.0.1 的 TiDB 版本升级到 2.1\n    * 先滚动升级到 2.0.1 或者之后的 2.0.x 版本，再滚动升级到 2.1 版本","date":"2018-11-30","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-2.1-ga-release-notes","file":null,"relatedBlogs":[]},{"id":"Blogs_13","title":"TiDB 2.0 GA Release","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"2018 年 4 月 27 日，TiDB 发布 2.0 GA 版。相比 1.0 版本，对 MySQL 兼容性、系统稳定性、优化器和执行器做了很多改进。","body":"2018 年 4 月 27 日，TiDB 发布 2.0 GA 版。相比 1.0 版本，对 MySQL 兼容性、系统稳定性、优化器和执行器做了很多改进。\n\n\n## TiDB\n\n* SQL 优化器\n\n\t* 精简统计信息数据结构，减小内存占用\n\n\t* 加快进程启动时加载统计信息速度\n\n\t* 支持统计信息动态更新 [experimental]\n\n\t* 优化代价模型，对代价估算更精准\n\n\t* 使用 `Count-Min Sketch` 更精确地估算点查的代价\n\n\t* 支持分析更复杂的条件，尽可能充分的使用索引\n\n\t* 支持通过 `STRAIGHT_JOIN` 语法手动指定 Join 顺序\n\n\t* `GROUP BY`子句为空时使用 Stream Aggregation 算子，提升性能\n\n\t* 支持使用索引计算 `Max/Min` 函数\n\n\t* 优化关联子查询处理算法，支持将更多类型的关联子查询解关联并转化成 `Left Outer Join`\n\n\t* 扩大 `IndexLookupJoin` 的使用范围，索引前缀匹配的场景也可以使用该算法\n\n\n* SQL 执行引擎\n\n\t* 使用 Chunk 结构重构所有执行器算子，提升分析型语句执行性能，减少内存占用，显著提升 TPC-H 结果\n\n\t* 支持 Streaming Aggregation 算子下推\n\n\t* 优化 `Insert Into Ignore` 语句性能，提升 10 倍以上\n\n\t* 优化 `Insert On Duplicate Key Update` 语句性能，提升 10 倍以上\n\n\t* 下推更多的数据类型和函数到 TiKV 计算\n\n\t* 优化 `Load Data` 性能，提升 10 倍以上\n\n\t* 支持对物理算子内存使用进行统计，通过配置文件以及系统变量指定超过阈值后的处理行为\n\n\t* 支持限制单条 SQL 语句使用内存的大小，减少程序 OOM 风险\n\n\t* 支持在 CRUD 操作中使用隐式的行 ID\n\n\t* 提升点查性能\n\n* Server\n\n\t* 支持 Proxy Protocol\n\n\t* 添加大量监控项, 优化日志\n\n\t* 支持配置文件的合法性检测\n\n\t* 支持 HTTP API 获取 TiDB 参数信息\n\n\t* 使用 Batch 方式 Resolve Lock，提升垃圾回收速度\n\n\t* 支持多线程垃圾回收\n\n\t* 支持 TLS\n\n* 兼容性\n\n\t* 支持更多 MySQL 语法\n\n\t* 支持配置文件修改 `lower_case_table_names` 系统变量，用于支持 OGG 数据同步工具\n\n\t* 提升对 Navicat 的兼容性\n\n\t* 在 `Information_Schema` 中支持显示建表时间\n\n\t* 修复部分函数/表达式返回类型和 MySQL 不同的问题\n\n\t* 提升对 JDBC 兼容性\n\n\t* 支持更多的 `SQL_MODE`\n\n* DDL\n\n\t* 优化 `Add Index` 的执行速度，部分场景下速度大幅度提升\n\n\t* `Add Index` 操作变更为低优先级，降低对线上业务影响\n\n\t* `Admin Show DDL Jobs` 输出更详细的 DDL 任务状态信息\n\n\t* 支持 `Admin Show DDL Job Queries JobID` 查询当前正在运行的 DDL 任务的原始语句\n\n\t* 支持 `Admin Recover Index` 命令，用于灾难恢复情况下修复索引数据\n支持通过 `Alter` 语句修改 Table Options\n\n## PD\n\n* 增加 `Region Merge` 支持，合并数据删除后产生的空 Region [experimental]\n\n* 增加 `Raft Learner` 支持 [experimental]\n\n* 调度器优化\n\n\t* 调度器适应不同的 Region size\n\n\t* 提升 TiKV 宕机时数据恢复的优先级和恢复速度\n\n\t* 提升下线 TiKV 节点搬迁数据的速度\n\n\t* 优化 TiKV 节点空间不足时的调度策略，尽可能防止空间不足时磁盘被写满\n\n\t* 提升 balance-leader scheduler 的调度效率\n\n\t* 减少 balance-region scheduler 调度开销\n\n\t* 优化 hot-region scheduler 的执行效率\n\n* 运维接口及配置\n\n\t* 增加 TLS 支持\n\n\t* 支持设置 PD leader 优先级\n\n\t* 支持基于 label 配置属性\n\n\t* 支持配置特定 label 的节点不调度 Region leader\n\n\t* 支持手动 Split Region，可用于处理单 Region 热点的问题\n\n\t* 支持打散指定 Region，用于某些情况下手动调整热点 Region 分布\n\n\t* 增加配置参数检查规则，完善配置项的合法性较验\n\n* 调试接口\n\t\n\t* 增加 `Drop Region` 调试接口\n\n\t* 增加枚举各个 PD health 状态的接口\n\n* 统计相关\n\n\t* 添加异常 Region 的统计\n\n\t* 添加 Region 隔离级别的统计\n\n\t* 添加调度相关 metrics\n\n* 性能优化\n\n\t* PD leader 尽量与 etcd leader 保持同步，提升写入性能\n\n\t* 优化 Region heartbeat 性能，现可支持超过 100 万 Region\n\n## TiKV\n\n* 功能\n\t\n\t* 保护关键配置，防止错误修改\n\n\t* 支持 `Region Merge` [experimental]\n\n\t* 添加 `Raw DeleteRange` API\n\n\t* 添加 `GetMetric` API\n\n\t* 添加 `Raw Batch Put`，`Raw Batch Get`，`Raw Batch Delete` 和 `Raw Batch Scan`\n\n\t* 给 Raw KV API 增加 Column Family 参数，能对特定 Column Family 进行操作\n\n\t* Coprocessor 支持 streaming 模式，支持 streaming 聚合\n\n\t* 支持配置 Coprocessor 请求的超时时间\n\n\t* 心跳包携带时间戳\n\n\t* 支持在线修改 RocksDB 的一些参数，包括 `block-cache-size` 大小等\n\n\t* 支持配置 Coprocessor 遇到某些错误时的行为\n\n\t* 支持以导数据模式启动，减少导数据过程中的写放大\n\n\t* 支持手动对 region 进行对半 split\n\n\t* 完善数据修复工具 tikv-ctl\n\n\t* Coprocessor 返回更多的统计信息，以便指导 TiDB 的行为\n\n\t* 支持 ImportSST API，可以用于 SST 文件导入 [experimental]\n\n\t* 新增 TiKV Importer 二进制，与 TiDB Lightning 集成用于快速导入数据 [experimental]\n\n* 性能\n\n\t* 使用 ReadPool 优化读性能，`raw_get/get/batch_get` 提升 30%\n\n\t* 提升 metrics 的性能\n\n\t* Raft snapshot 处理完之后立即通知 PD，加快调度速度\n\n\t* 解决 RocksDB 刷盘导致性能抖动问题\n\n\t* 提升在数据删除之后的空间回收\n\n\t* 加速启动过程中的垃圾清理过程\n\n\t* 使用 `DeleteFilesInRanges` 减少副本迁移时 I/O 开销\n\n* 稳定性\n\n\t* 解决在 PD leader 发送切换的情况下 gRPC call 不返回问题\n\n\t* 解决由于 snapshot 导致下线节点慢的问题\n\n\t* 限制搬移副本临时占用的空间大小\n\n\t* 如果有 Region 长时间没有 Leader，进行上报\n\n\t* 根据 compaction 事件及时更新统计的 Region size\n\n\t* 限制单次 scan lock 请求的扫描的数据量，防止超时\n\n\t* 限制接收 snapshot 过程中的内存占用，防止 OOM\n\n\t* 提升 CI test 的速度\n\n\t* 解决由于 snapshot 太多导致的 OOM 问题\n\n\t* 配置 gRPC 的 `keepalive` 参数\n\n\t* 修复 Region 增多容易 OOM 的问题\n\n\n## TiSpark\n\nTiSpark 使用独立的版本号，现为 1.0 GA。TiSpark 1.0 版本组件提供了针对 TiDB 上的数据使用 Apache Spark 进行分布式计算的能力。\n\n* 提供了针对 TiKV 读取的 gRPC 通信框架\n\n* 提供了对 TiKV 组件数据的和通信协议部分的编码解码\n\n* 提供了计算下推功能，包含\n\n\t* 聚合下推\n\n\t* 谓词下推\n\n\t* TopN 下推\n\n\t* Limit 下推\n\n* 提供了索引相关支持\n\n\t* 谓词转化聚簇索引范围\n\n\t* 谓词转化次级索引\n\n\t* Index Only 查询优化\n\n\t* 运行时索引退化扫表优化\n\n* 提供了基于代价优化\n\n\t* 统计信息支持\n\n\t* 索引选择\n\n\t* 广播表代价估算\n\n* 多种 Spark Interface 的支持\n\n\t* Spark Shell 支持\n\n\t* ThriftServer/JDBC 支持\n\n\t* Spark-SQL 交互支持\n\n\t* PySpark Shell 支持\n\n\t* SparkR 支持\n\n\n**如今，在社区和 PingCAP 技术团队的共同努力下，TiDB 2.0 GA 版已发布，在此感谢社区小伙伴们长久以来的参与和贡献。**\n\n\n\n> 作为世界级开源的分布式关系型数据库，TiDB 灵感来自于 Google Spanner/F1，具备『分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活』等核心特性。TiDB 于 2015 年 5 月在 GitHub 创建，同年 12 月发布 Alpha 版本，而后于 2016 年 6 月发布 Beta 版，12 月发布 RC1 版， 2017 年 3 月发布 RC2 版，6 月发布 RC3 版，8 月发布 RC4 版，10 月发版 TiDB 1.0，并在 2018 年 3 月发版 2.0 RC1。","date":"2018-04-27","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-2.0-ga-release","file":null,"relatedBlogs":[]},{"id":"Blogs_233","title":"TiDB 1.1 Beta Release","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"2018 年 2 月 24 日，TiDB 发布 1.1 Beta 版。该版本在 1.1 Alpha 版的基础上，对 MySQL 兼容性、系统稳定性做了很多改进。","body":"2018 年 2 月 24 日，TiDB 发布 1.1 Beta 版。该版本在 1.1 Alpha 版的基础上，对 MySQL 兼容性、系统稳定性做了很多改进。\n\n## TiDB\n\n+ 添加更多监控项, 优化日志\n\n+ 兼容更多 MySQL 语法。\n\n+ 在 `information_schema` 中支持显示建表时间\n\n+ 提速包含 `MaxOneRow` 算子的查询\n\n+ 控制 Join 产生的中间结果集大小，进一步减少 Join 的内存使用\n\n+ 增加 `tidb_config` session 变量，输出当前 TiDB 配置\n\n+ 修复 `Union` 和 `Index Join` 算子中遇到的 panic 问题\n\n+ 修复 `Sort Merge Join` 算子在部分场景下结果错误的问题\n\n+ 修复 `Show Index` 语句显示正在添加过程中的索引的问题\n\n+ 修复 `Drop Stats` 语句失败的问题\n\n+ 优化 SQL 引擎查询性能，Sysbench 的 Select/OLTP 测试结果提升 10%\n\n+ 使用新的执行引擎提升优化器中的子查询计算速度。相比 1.0 版本，在 TPC-H 以及 TPC-DS 等测试中有显著提升\n\n## PD\n\n+ 增加 drop region 调试接口\n\n+ 支持设置 PD leader 优先级\n\n+ 支持配置特定 label 的节点不调度 raft leader\n\n+ 增加枚举各个 PD health 状态的接口\n\n+ 添加更多 metrics\n\n+ PD leader 尽量与 etcd leader 保持同步\n\n+ 提高 TiKV 宕机时数据恢复优先级和恢复速度\n\n+ 完善 data-dir 配置项的合法性较验\n\n+ 优化 region heartbeat 性能\n\n+ 修复热点调度破坏 label 约束的问题\n\n+ 其他稳定性问题修复\n\n## TiKV\n\n+ 使用 offset + limit 遍历 lock，消除潜在的 GC 问题\n\n+ 支持批量 resolve lock，提升 GC 速度\n\n+ 支持并行 GC，提升 GC 速度\n\n+ 使用 RocksDB compaction listener 更新 Region Size，让 PD 更精确的进行调度\n\n+ 使用 DeleteFilesInRanges 批量删除过期数据，提高 TiKV 启动速度\n\n+ 设置 Raft snapshot max size，防止遗留文件占用太多空间\n\n+ tikv-ctl 支持更多修复操作\n\n+ 优化有序流式聚合操作\n\n+ 完善 metrics，修复 bug\n\n源码地址：[https://github.com/pingcap/tidb](https://github.com/pingcap/tidb)\n\n**如今，在社区和 PingCAP 技术团队的共同努力下，TiDB 1.1 Beta 版已发布，在此感谢社区小伙伴们长久以来的参与和贡献。**\n\n\n\n> 作为世界级开源的分布式关系型数据库，TiDB 灵感来自于 Google Spanner/F1，具备『分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活』等核心特性。TiDB 于 2015 年 5 月在 GitHub 创建，同年 12 月发布 Alpha 版本，而后于 2016 年 6 月发布 Beta 版，12 月发布 RC1 版， 2017 年 3 月发布 RC2 版，6 月发布 RC3 版，8 月发布 RC4 版，并在 10 月发版 TiDB 1.0。","date":"2018-02-24","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-1.1-beta-release","file":null,"relatedBlogs":[]},{"id":"Blogs_208","title":"TiDB 1.1 Alpha Release","tags":["TiDB","Release"],"category":{"name":"公司动态"},"summary":"2018 年 1 月 19 日，TiDB 发布 1.1 Alpha 版。该版本对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量的工作。","body":"2018 年 1 月 19 日，TiDB 发布 1.1 Alpha 版。该版本对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量的工作。\n\n\n## TiDB\n\n- SQL parser\n\t- 兼容更多语法\n- SQL 查询优化器\n\t- 统计信息减小内存占用\n\t- 优化统计信息启动时载入的时间\n\t- 更精确的代价估算\n\t- 使用 Count-Min Sketch 更精确的估算点查的代价\n\t- 支持更复杂的条件，更充分使用索引\n- SQL 执行器\n\t- 使用 Chunk 结构重构所有执行器算子，提升分析型语句执行性能，减少内存占用\n\t- 优化 INSERT INGORE 语句性能\n\t- 下推更多的类型和函数\n\t- 支持更多的 SQL_MODE\n\t- 优化 `Load Data` 性能，速度提升 10 倍\n\t- 优化 `Use Database` 性能\n\t- 支持对物理算子内存使用进行统计\n- Server\n\t- 支持 PROXY protocol\n\n## PD\n\n- 增加更多的 API\n- 支持 TLS\n- 给 Simulator 增加更多的 case\n- 调度适应不同的 region size\n- Fix 了一些调度的 bug\n\n## TiKV\n\n- 支持 Raft learner\n- 优化 Raft Snapshot，减少 IO 开销\n- 支持 TLS\n- 优化 RocksDB 配置，提升性能\n- Coprocessor 支持更多下推操作\n- 增加更多的 Failpoint 以及稳定性测试 case\n- 解决 PD 和 TiKV 之间重连的问题\n- 增强数据恢复工具 TiKV-CTL 的功能\n- region 支持按 table 进行分裂\n- 支持 delete range 功能\n- 支持设置 snapshot 导致的 IO 上限\n- 完善流控机制\n\n源码地址：[https://github.com/pingcap/tidb](https://github.com/pingcap/tidb)\n\n\n\n**如今，在社区和 PingCAP 技术团队的共同努力下，TiDB 1.1 Alpha 版已发布，在此感谢社区的小伙伴们长久以来的参与和贡献。**\n\n\n\n> 作为世界级开源的分布式关系型数据库，TiDB 灵感来自于 Google Spanner/F1，具备『分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活』等核心特性。TiDB 于 2015 年 5 月在 GitHub 创建，同年 12 月发布 Alpha 版本，而后于 2016 年 6 月发布 Beta 版，12 月发布 RC1 版， 2017 年 3 月发布 RC2 版，6月份发布 RC3 版，8月份发布 RC4 版，并在 10 月发版 TiDB 1.0。","date":"2018-01-19","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-1.1-alpha-release","file":null,"relatedBlogs":[]}],"blogCategories":[{"name":"产品技术解读"},{"name":"公司动态"},{"name":"社区动态"},{"name":"案例实践"},{"name":"观点洞察"}],"blogRecommend":[{"blog":{"author":"黄东旭","summary":"PingCAP 联合创始人兼 CTO 黄东旭分介绍了 TiDB Serverless 作为未来一代数据库的核心设计理念，同时探讨了 TiDB Serverless 对于中国用户的价值。","title":"黄东旭：The Future of Database，掀开 TiDB Serverless 的引擎盖","date":"2023-07-24","customUrl":"the-future-of-database-2023"}},{"blog":{"author":"张翔","summary":"本次分享在介绍 Serverless Tier 的技术细节之余，全面解析了 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。","title":"TiDB Serverless 和技术生态全景","date":"2023-02-20","customUrl":"tidb-serverless-and-technology-ecology-overview"}},{"blog":{"author":"韩锋","summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","title":"金融业分布式数据库选型及 HTAP 场景实践","date":"2022-05-19","customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry"}},{"blog":{"author":"黄东旭","summary":"很多时候「品味」之所以被称为「品味」，就是因为说不清道不明，这固然是软件开发艺术性的一种体现，但是这也意味着它不可复制，不易被习得。本系列文章会试着总结一下好的基础软件体验到底从哪里来。作为第一篇，本文将围绕可观测性和可交互性两个比较重要的话题来谈。","title":"做出让人爱不释手的基础软件：可观测性和可交互性","date":"2021-10-15","customUrl":"how-to-develop-an-infrasoft-observability-and-interactivity"}},{"blog":{"author":"刘奇","summary":"我们更多时候是站在哲学层面思考整个公司的运转和 TiDB 这个产品的演进的思路。这些思路很多时候是大家看不见的，因为不是一个纯粹的技术层面或者算法层面的事情。","title":"势高，则围广：TiDB 的架构演进哲学","date":"2019-05-30","customUrl":"guiding-ideologies-in-the-evolution-of-tidb"}}],"blogMostPopular":[{"blog":{"author":"申砾","customUrl":"tidb-internal-1","date":"2017-05-15","summary":"数据库、操作系统和编译器并称为三大系统，可以说是整个计算机软件的基石。其中数据库更靠近应用层，是很多业务的支撑。这一领域经过了几十年的发展，不断的有新的进展。很多人用过数据库，但是很少有人实现过一个数据库，特别是实现一个分布式数据库。了解数据库的实现原理和细节，一方面可以提高个人技术，对构建其他系统有帮助，另一方面也有利于用好数据库。研究一门技术最好的方法是研究其中一个开源项目，数据库也不例外。单机数据库领域有很多很好的开源项目，其中 MySQL 和 PostgreSQL 是其中知名度最高的两个，不少同学都看过这两个项目的代码。但是分布式数据库方面，好的开源项目并不多。 TiDB 目前获得了广泛的关注，特别是一些技术爱好者，希望能够参与这个项目。由于分布式数据库自身的复杂性，很多人并不能很好的理解整个项目，所以我希望能写一些文章，自顶向下，由浅入深，讲述 TiDB 的一些技术原理，包括用户可见的技术以及大量隐藏在 SQL 界面后用户不可见的技术点。","title":"三篇文章了解 TiDB 技术内幕 - 说存储"}},{"blog":{"author":"申砾","customUrl":"tidb-internal-2","date":"2017-05-24","summary":"上一篇介绍了 TiDB 如何存储数据，也就是 TiKV 的一些基本概念。本篇将介绍 TiDB 如何利用底层的 KV 存储，将关系模型映射为 Key-Value 模型，以及如何进行 SQL 计算。","title":"三篇文章了解 TiDB 技术内幕 - 说计算"}},{"blog":{"author":"申砾","customUrl":"tidb-internal-3","date":"2017-06-06","summary":"任何一个复杂的系统，用户感知到的都只是冰山一角，数据库也不例外。前两篇文章介绍了 TiKV、TiDB 的基本概念以及一些核心功能的实现原理，这两个组件一个负责 KV 存储，一个负责 SQL 引擎，都是大家看得见的东西。在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。本篇文章介绍一下这个神秘的模块。这部分比较复杂，很多东西大家平时不会想到，也很少在其他文章中见到类似的东西的描述。我们还是按照前两篇的思路，先讲我们需要什么样的功能，再讲我们如何实现，大家带着需求去看实现，会更容易的理解我们做这些设计时背后的考量。","title":"三篇文章了解 TiDB 技术内幕 - 谈调度"}},{"blog":{"author":"PingCAP","customUrl":"introduction-of-open-source-license","date":"2021-10-20","summary":"PingCAP 从第一行代码开源，六年里积累了一些经验和教训，在《开源知识科普》栏目中，我们将与大家分享和交流在开源成长路径中的思考和感受，以及参与开源项目的正确姿势。本期话题就从开源的基础——开源许可证开始，希望对大家了解开源、参与开源有一定帮助。","title":"一文看懂开源许可证丨开源知识科普"}},{"blog":{"author":"唐刘","customUrl":"grpc","date":"2017-06-18","summary":"经过很长一段时间的开发，TiDB 终于发了 RC3。RC3 版本对于 TiKV 来说最重要的功能就是支持了 gRPC，也就意味着后面大家可以非常方便的使用自己喜欢的语言对接 TiKV 了。gRPC 是基于 HTTP/2 协议的，要深刻理解 gRPC，理解下 HTTP/2 是必要的，这里先简单介绍一下 HTTP/2 相关的知识，然后再介绍下 gRPC 是如何基于 HTTP/2 构建的。","title":"深入了解 gRPC：协议"}}],"allTags":[{"name":"TiDB","count":179},{"name":"社区","count":103},{"name":"TiKV","count":30},{"name":"社区动态","count":29},{"name":"TiDB 源码阅读","count":24},{"name":"TiKV 源码解析","count":21},{"name":"HTAP","count":20},{"name":"Release","count":17},{"name":"TiFlash","count":16},{"name":"Chaos Mesh","count":15},{"name":"TiDB Hackathon 2021","count":13},{"name":"Raft","count":11},{"name":"TiCDC","count":11},{"name":"TiDB 4.0 新特性","count":11},{"name":"DM 源码阅读","count":10},{"name":"Contributor","count":9},{"name":"TiDB Binlog 源码阅读","count":9},{"name":"TiFlash 源码阅读","count":9},{"name":"TiDB Hackathon 2022","count":8},{"name":"技术出海","count":8},{"name":"Serverless","count":7},{"name":"TiDB Hackathon 2020","count":7},{"name":"TiDB 性能调优","count":7},{"name":"分布式数据库","count":7},{"name":"DM","count":6},{"name":"SQL","count":6},{"name":"最佳实践","count":6},{"name":"架构","count":6},{"name":"Hackathon","count":5},{"name":"PD","count":5},{"name":"Rust","count":5},{"name":"TiDB Binlog","count":5},{"name":"TiDB Cloud","count":5},{"name":"TiDB Operator","count":5},{"name":"TiDB Operator 源码阅读","count":5},{"name":"TiSpark","count":5},{"name":"事务","count":5},{"name":"事务前沿研究","count":5},{"name":"新经济 DTC 转型","count":5},{"name":"DevCon","count":4},{"name":"Linux","count":4},{"name":"MySQL","count":4},{"name":"TiDB 易用性挑战赛","count":4},{"name":"TiKV 功能介绍","count":4},{"name":"分布式系统前沿技术","count":4},{"name":"备份恢复","count":4},{"name":"大促背后的数据库","count":4},{"name":"工具","count":4},{"name":"性能","count":4},{"name":"数据迁移","count":4},{"name":"Committer","count":3},{"name":"Go","count":3},{"name":"Kubernetes","count":3},{"name":"Percolator","count":3},{"name":"PingCAP 用户峰会","count":3},{"name":"Prometheus","count":3},{"name":"RocksDB","count":3},{"name":"TiDB Ecosystem Tools","count":3},{"name":"TiDB Serverless","count":3},{"name":"TiKV 源码阅读","count":3},{"name":"云原生","count":3},{"name":"分布式系统测试","count":3},{"name":"基础软件","count":3},{"name":"BR","count":2},{"name":"Cloud-TiDB","count":2},{"name":"Dumpling","count":2},{"name":"Flink","count":2},{"name":"K8s","count":2},{"name":"Key Visualizer","count":2},{"name":"MVCC","count":2},{"name":"PingCAP","count":2},{"name":"PingCAP  用户峰会","count":2},{"name":"Spanner","count":2},{"name":"TiDB 性能挑战赛","count":2},{"name":"TiDB-4.0","count":2},{"name":"TiUP","count":2},{"name":"WebAssembly","count":2},{"name":"gRPC","count":2},{"name":"优化器","count":2},{"name":"升级","count":2},{"name":"多业务融合","count":2},{"name":"带着问题读 TiDB 源码","count":2},{"name":"性能优化","count":2},{"name":"性能调优","count":2},{"name":"数据同步","count":2},{"name":"版本","count":2},{"name":"资源管控","count":2},{"name":"集群调度","count":2},{"name":"2PC","count":1},{"name":"AI","count":1},{"name":"Ansible","count":1},{"name":"CAP","count":1},{"name":"Chat2Query","count":1},{"name":"ChatGPT","count":1},{"name":"Cloud","count":1},{"name":"DNB","count":1},{"name":"Data Platform","count":1},{"name":"Database","count":1},{"name":"Database Branching","count":1},{"name":"Elasticsearch","count":1},{"name":"Failpoint","count":1},{"name":"Fintech","count":1},{"name":"Flink TiDB 物化视图","count":1},{"name":"GA","count":1},{"name":"Grafana","count":1},{"name":"HAProxy","count":1},{"name":"HTAP TiFlash","count":1},{"name":"Hadoop","count":1},{"name":"Horoscope","count":1},{"name":"Jepsen","count":1},{"name":"Kudu","count":1},{"name":"LSM-tree","count":1},{"name":"Lease Read","count":1},{"name":"Libbpf-tools","count":1},{"name":"Linearizability","count":1},{"name":"MPP","count":1},{"name":"Multi-Raft","count":1},{"name":"MySQL 架构演进","count":1},{"name":"NewSQL","count":1},{"name":"OpenAI","count":1},{"name":"OpenSource","count":1},{"name":"Oracle 迁移","count":1},{"name":"Partitioned Raft KV","count":1},{"name":"Partitioned-Raft-KV","count":1},{"name":"PiTR","count":1},{"name":"Redis","count":1},{"name":"Resource Control","count":1},{"name":"SMP","count":1},{"name":"SQL Plan Management","count":1},{"name":"SaaS","count":1},{"name":"Spark","count":1},{"name":"Syncer","count":1},{"name":"THP","count":1},{"name":"Talent Plan","count":1},{"name":"Test","count":1},{"name":"The Future of Database","count":1},{"name":"TiDB + Flink","count":1},{"name":"TiDB 4.0","count":1},{"name":"TiDB 4.0 捉虫竞赛","count":1},{"name":"TiDB Dashboard","count":1},{"name":"TiDB DevCon 2020","count":1},{"name":"TiDB Hackathon 2023","count":1},{"name":"TiDB 工具","count":1},{"name":"TiDB-DM","count":1},{"name":"TiDB-Lightning","count":1},{"name":"TiEM","count":1},{"name":"TiKV 性能优化","count":1},{"name":"TiPocket","count":1},{"name":"Tile","count":1},{"name":"Titan","count":1},{"name":"Tools","count":1},{"name":"futures","count":1},{"name":"java","count":1},{"name":"k8s","count":1},{"name":"knossos","count":1},{"name":"一致性","count":1},{"name":"主从","count":1},{"name":"全文检索","count":1},{"name":"内建函数","count":1},{"name":"分布式","count":1},{"name":"分布式SQL","count":1},{"name":"分布式事务","count":1},{"name":"分布式计算","count":1},{"name":"历史读","count":1},{"name":"可串行化","count":1},{"name":"合作伙伴生态","count":1},{"name":"在线 DDL","count":1},{"name":"垃圾回收","count":1},{"name":"备份","count":1},{"name":"多版本并发控制","count":1},{"name":"多租户","count":1},{"name":"大数据","count":1},{"name":"存储","count":1},{"name":"存储引擎","count":1},{"name":"安装部署","count":1},{"name":"容灾机制","count":1},{"name":"工程实践","count":1},{"name":"平凯数据库","count":1},{"name":"应用场景","count":1},{"name":"开源","count":1},{"name":"开源知识科普","count":1},{"name":"异构复制","count":1},{"name":"性能挑战赛","count":1},{"name":"悲观锁","count":1},{"name":"持续性能分析","count":1},{"name":"数字化转型","count":1},{"name":"数据分片","count":1},{"name":"数据库","count":1},{"name":"无锁快照","count":1},{"name":"智能制造","count":1},{"name":"服务可观察","count":1},{"name":"机器学习","count":1},{"name":"查询优化","count":1},{"name":"核心批量核算","count":1},{"name":"水平扩展","count":1},{"name":"测试","count":1},{"name":"测试工具","count":1},{"name":"混沌工程","count":1},{"name":"源码分析","count":1},{"name":"版本迁移","count":1},{"name":"用户实践","count":1},{"name":"监控","count":1},{"name":"线性一致","count":1},{"name":"自动化","count":1},{"name":"自动化测试","count":1},{"name":"计算","count":1},{"name":"调优","count":1},{"name":"调度","count":1},{"name":"跨数据中心","count":1},{"name":"运维","count":1},{"name":"金融","count":1},{"name":"隔离级别","count":1},{"name":"高并发","count":1}],"hotTags":[{"name":"TiDB","count":179},{"name":"社区","count":103},{"name":"TiKV","count":30},{"name":"社区动态","count":29},{"name":"TiDB 源码阅读","count":24},{"name":"TiKV 源码解析","count":21},{"name":"HTAP","count":20},{"name":"Release","count":17},{"name":"TiFlash","count":16},{"name":"Chaos Mesh","count":15},{"name":"TiDB Hackathon 2021","count":13},{"name":"Raft","count":11},{"name":"TiCDC","count":11},{"name":"TiDB 4.0 新特性","count":11},{"name":"DM 源码阅读","count":10},{"name":"Contributor","count":9},{"name":"TiDB Binlog 源码阅读","count":9},{"name":"TiFlash 源码阅读","count":9},{"name":"TiDB Hackathon 2022","count":8},{"name":"技术出海","count":8}]}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}