At Pinterest, HBase is one of the most critical storage backends, powering many online storage services like Zen (graph database), UMS (wide column datastore), and Ixia (near real time secondary indexing service). The HBase Ecosystem, though having various advantages like strong consistency at row level in high volume requests, flexible schema, low latency access to data, Hadoop integration, etc. cannot serve the needs of our clients for the next 3–5 years. This is due to high operational cost, excessive complexity, and missing functionalities like secondary indexes, support for transactions, etc.

After evaluating 10+ different storage backends and benchmarking three shortlisted backends with shadow traffic (asynchronously copying production traffic to non production environment) and in-depth performance evaluation, we have decided to use TiDB as the final candidate for Unified Storage Service.

The adoption of Unified Storage Service powered by TiDB is a major challenging project spanning over multiple quarters. It involves data migration from HBase to TiDB, design and implementation of Unified Storage Service, API migration from Ixia/Zen/UMS to Unified Storage Service, and Offline Jobs migration from HBase/Hadoop ecosystem to TiSpark ecosystem while maintaining our availability and latency SLA.

In this blog post, we will first learn the various approaches considered for data migration with their trade offs. We will then do a deep dive on how the data migration was conducted from HBase to TiDB for one of the first use cases having 4 TB table size serving 14k read qps and 400 write qps with zero downtime. Lastly we will learn how the verification was done to achieve 99.999% data consistency and how the data consistency was measured between the two tables.

本文介绍在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。

总篇120篇 2021年第11篇1. 背景介绍之家要求对核心业务做跨机房部署，当 A 机房整体故障时，业务可以快速切换到 B 机房继续提供服务，提升业务容灾能R

携程自2014年左右开始全面使用MySQL数据库，随着业务增长、数据量激增，单机实例逐渐出现瓶颈，如单表行数过大导致历史数据查询耗时升高，单库容量过大导致磁盘空间不足等。为应对这些问题，我们采取了诸多措施如分库分表的水平拆分、一主多从读写分离、硬件SSD升级、增加前端Redis缓存等，但同时也使得整个业务层架构更加复杂，且无法做到透明的弹性，因此开始将目光转移到分布式数据库以解决这些痛点。

近年来受到Spanner&F1的启发，基于CAP理论和Paxos、Raft协议作为工程实现的分布式数据库得到了蓬勃发展，从硅谷的CockroachDB到国产的TiDB都在社区产生了很强的影响力。携程也对这些产品从社区活跃度、用户规模、易用性等多个方面做了调研，最终选择了国产的TiDB。

TiDB是一个开源的NewSQL数据库，支持混合事务和分析处理（HTAP）工作负载，兼容大部分MySQL语法，并且提供水平可扩展性、强一致性和高可用性。主要由PingCAP公司开发和支持，并在Apache 2.0下授权。2018年11月我们开始TiDB的POC以及与携程现有运维平台的整合，2019年1月第一个线上应用正式接入，最初的目标只是保证数据库的可用性以及可以存储足够多的关系型数据。随着TiDB快速迭代，越来越多的功能进入社区，如HATP特性，让我们不局限于最初的目标，开始了新的探索。本文将介绍TiDB在携程业务场景中的运维实践，希望对读者有所帮助和参考。

本文主要介绍如何借助 TiDB SQL 解析自定义生成 SQL 指纹，采用了一种有别于 pt-fingerprint(https://www.percona.com/doc/percona-toolkit/3.0/pt-fingerprint.html) 的方式。

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用：参考资料【4】

摩拜亿级分布式数据库使用实践！