一般に公開されパブリッククラウドとして2016年Jingdongはクラウドオブジェクトストレージ、主な機能JingdongはこのようなJingdongモールJingdongは内部の映像/画像ストレージクラウドとして一般的なビジネスシナリオで使用されるいくつか、など、信頼性の高い、安全で、大規模な、低コストであり、外部のパブリッククラウドサービスの開発者、および政府のため、民間企業向けクラウドサービス、さらにはハイブリッドクラウドサービスを曇らせます。
この記事では、アーキテクチャの進化Jingdongはクラウドオブジェクトストレージサービスのほか、TiKV体験への移行について説明します。
I.はじめにストレージをオブジェクトに
まず、ここでは「オブジェクト（Object）を」概念を説明するための例です。例えば、我々は、それはまた、デバイスデータを撮影、ユーザ（撮影者に関連するデータを（等データ長写真、最終更新時刻）メタ情報を含むべきである写真自体のバイナリデータに加えて、「オブジェクト」として写真を入れなど）。オブジェクトストレージは、変更が頻繁にないデータにより特徴付けられます。
数が絵を保存するための比較的小さい場合には、我々が使用するノード上でLVMのような似たような、複数のディスクを使用することができ、この方法は、一般的に絵1M〜10Mの大きさに適用されます。ビジネスは、より多くの写真を成長し、さらにはビデオ店、私たちは保存するために、分散ファイルシステムを使用するように、このアプローチは、DFS（下図参照）のアーキテクチャに基づいています。
このアプローチの前提は、単位容量であるデータは、複数のマシン上に格納されている必要があり、そして1つ以上の独立してノードがメタデータを格納し、メタデータは、ツリー構造を維持し、分割することは困難で、制限されています。しかし、アーキテクチャが10億のレベルにオブジェクトを格納するため、一般的に適しており、同時に2つの大きな問題があります。
- ノードがマスタ・データ・センターの存在は、比較的限られたデータ分散ストレージである場合、別のノードに、この機械は、無制限の拡大に移動しにくくなります。
- メタデータ管理は、それ自体が分散ストレージに適していない木、およびディレクトリ構造は、複数のアクセスを必要とし、SSD上に置くのに適していない、そしてメモリ内に、より適しており、その後、一般的な任務マスターノードリスト。HDFS基本的にも。
保存された千億のオブジェクトをするように頼まもしそうなら、どのようにそれを達成するには？最も明白なアプローチは、分散メタデータを格納するためにある別のマシン上に格納され、それはファイルシステムとして、ツリー構造であるが、平坦形状にしません。
第二に、オブジェクトストアメタデータ管理システム
回到上面的举例，针对一个图片对象我们主要有四类操作：上传（Put）、下载（Get）、删除（Delete），Scan。Scan 操作相对比较传统 ，比如查看当前有多少图片对象，获取所有图片名称。
1. 元数据管理系统 v1.0
上面是一个最简单、原始的方案，这里 Bucket 相当于名字空间（Namespace）。很多人最开始设计的结构也就是这样的，但后期数据量增长很快的时候会遇到一些问题，如下图。
第一个问题是，在初期数据量比较小的时候，可能只分了 4 个 Bucket 存储，随着业务增长，需要重新拆分到 400 个 Bucket 中，数据迁移是一个 Rehash 过程，这是一件非常复杂且麻烦的事情。所以，我们在思考对象存储连续的、跨数量级的无限扩展要怎么做呢？下图是一个相对复杂的解决方案，核心思想是把绝大部分数据做静态处理，因为静态的存储，无论是做迁移还是做拆分，都比较简单。比如每天都把前一天写入的数据静态化，合到历史数据中去。
针对第二个问题，如果单个 Bucket 数据量很大，那么在往 Stable Meta（上图中黄色部分）做静态化迁移时需要做深度拆分，单个 Bucket 的对象的数量非常多，在一个数据库里面存储不下来，需要存储在多个数据库里面，再建立一层索引，存储每个数据库里面存储那个区间的数据。同时，我们在运行的时候其实也会出现一个 Bucket 数量变多的情况，这种是属于非预期的变多，这种情况下我们的做法是弄了一大堆外部的监控程序，监控 Bucket 的量，在 Bucket 量过大的时候，会主动去触发表分裂、迁移等一系列流程。
这个解决方案有两个明显的问题，第一数据分布复杂，管理困难；第二，调度不灵活，给后期维护带来很大的困难。
所以，我们思考了这个事情本质其实是做一个全局有序 KV，并且需要“足够大”，能够弹性扩张。这样系统架构就会变得非常简单（如上图所示）。 当然最终我们找到了分布式 KV 数据库—— TiKV。
2. 基于 TiKV 的元数据管理系统
我们前期调研了很多产品，最终选择 TiKV 主要原因有以下四点：
- 全局有序 KV，可轻松⽔平扩展，功能上完全能够满⾜对象存储元数据管理的需求。
- 经过一些测试，性能上很好，能够满足要求。
- 社区活跃，文档和工具相对比较完善。这一点也很重要，TiKV 目前已经是CNCF（云原生计算基金会）的孵化项目，很多功能可以快速开发，产品迭代也很迅速。
- 相对于 TiDB Server 而言，TiKV
的代码更加简单，而且我们后续可以在 TiKV 的基础上做更多开发工作。
在上线之前，我们主要进行了以下几方面的测试：
- 功能测试：测试 TiKV 的基本功能是否满足业务需求。
- 性能测试：测试了常规的 QPS、Latency (Avg, TP90, TP99) 等指标。
- 异常测试：其实我们做数据存储的同学往往最关注的是各种异常故障的情况，性能倒是其次，而且分布式存储相比单机存储更为复杂。所以我们测试了各种机器/磁盘/网络故障，业务异常情况。更进一步的，我们将这些异常情况随机组合，并在系统内触发，再验证系统的正确性。
- 预发布环境验证：在大规模上线之前，我们会在相对不太重要的、实际业务上跑一段时间，收集一些问题和可优化的部分，包括运维上的调优等。
通过上面的测试我们认为 TiKV 无论是从性能还是系统安全性的角度，都能很好的满足要求，于是我们在 TiKV 基础之上，实现了对象元数据管理系统 v2.0，如下图所示。
将 v1.0 中一堆复杂的数据库和逻辑结构用 TiKV 替代之后，整个系统变得非常简洁。
三、业务迁移
很多用户可能直接将 MySQL 迁移到 TiDB 上，这个迁移过程已经非常成熟，但是由于迁移到 TiKV 前人的经验比较少，所以我们在迁移过程中也做了很多探索性的工作。
1. 迁移方案
上图是我们设计的迁移方案，首先线上的数据都必须双写，保证数据安全。第二，我们将存量数据设置为只读之后迁移到 TiKV 中，同时迁移过程中的增量数据直接写入 TiKV，每天将前一日的增量数据做静态化处理，然后与 MySQL 中的数据对比，验证数据正确性。另外，如果双写失败，会启用 MySQL backup。
下面详细介绍实际操作过程中的相关细节。
2. 切换
在存量数据切换方面，我们首先将存量数据静态化，简化迁移、数据对比、回滚的流程；在增量数据切换方面，首先将增量数据双写 TiKV & MySQL，并且保证出现异常情况时快速回滚至 MySQL，不影响线上的业务。值得一提的是，由于 TiKV 在测试环境下的验证结果非常好，所以我们采用 TiKV 作为双写的 Primary。
整个切换 过程分为三个步骤：
- 存量数据切换到 TiKV，验证读。
- 增量数据切换到 TiKV，验证读写。
- 验证 TiKV 中的数据正确性之后，就下线 MySQL。
3. 验证
数据验证过程最大的困难在于增量数据的验证，因为增量数据是每天变化的，所以我们双写了 MySQL 和 TiKV，并且每天将增量数据进行静态化处理，用 MySQL 中的记录来验证 TiKV 的数据是否可靠（没有出现数据丢失和错误），如下图所示。
因为同时双写 MySQL 和 TiKV 可能会出现一种情况是，写入 TiKV 就成功了，但是写入 MySQL 失败了，这两个写入不在同一个事务中，所以不能保证一定同时成功或者失败，尤其是在业务量比较大的情况下。对于这种不一致的情况，我们会通过业务层的操作记录，来判断是由于业务层的问题导致的，还是由 TiKV 导致的。
四、业务现状及后续优化工作
現在TiKV Jingdongはクラウドオブジェクトストレージ事業は、2019年末までに計画され、プライマリ・データベースで元のデータベースをオフラインに置きます。10+のために展開されたクラスタの総数は、40,000の単一クラスタ環境のQPSピーク生産（1読み：1）50万人以上の地域の、データクラスタの最大の単一量を200 +万人、レイテンシのための私達のメタデータ管理、ビジネス要件比較的高い電流レイテンシーを約10ミリ秒を保証することができます。また、当社は、ライン上に置くことができ2019年の第4四半期に予想される、TiKV 3.0をテストしています。
現在の業務のために、我々はいくつかのフォローアップの最適化を行います。
最初のポイントは、災害復旧で、我々はビジネス層に行っている現在では、ディザスタリカバリ、フォローアップは、この点で機能することができTiKV以降のバージョンを楽しみにしています、TiKV層の災害復旧に直接行うことができます。
第二の点は、クラスタサイズを最適化することで、オブジェクトストレージは、ストレージ集約型ビジネスであるため、我々は、そのような私たちは、その後の研究の学生をPingCAPこと8T、10Tディスク、または安価なディスクを使用し、使用することができるよう、ハードウェアのコストを圧縮したいと考えていますどのように最適化やアップグレード一緒に検討してください。
三点目は、地域のスケジューリングの最適化にあり、スケジュールは現在TiKV全体の複合体は、それがストレージ集約型ビジネスのためのより多くの手間がかかり、特に特に大きな下のデータの量は、我々はボラティリティデータのヒントを入れたくありません他のマシンに移行します。
TiDB TechDay 2019杭州駅で演説を終えた紙からチェ・チャン先生。
読み込み推奨
乾燥品を| TiDBオペレータは練習
DRDSとTiDB分析|呉服を
