何兆もの淘宝網注文レコードを処理するストレージエンジン - ApsaraDB RDS

Taobaoの履歴注文レコードは、X-Engineに基づくPolarDB-Xクラスターでサポートされています。これにより、HBaseデータベースの使用によって引き起こされる既知の問題が修正され、ストレージコストが削減され、ユーザーは常に注文レコードをクエリできるようになります。

背景情報

淘宝網は、Alibaba Cloudによって開発された中国で人気のあるオンラインショッピングプラットフォームです。淘宝網は数億人のアクティブユーザーにサービスを提供しています。

このプラットフォームは、物理的および仮想的な商品に関する約100万件の取引を毎日サポートしています。各トランザクションプロセスには、会員情報検証、商品ライブラリ照会、注文作成、在庫削減、割引、注文支払い、物流情報更新、支払い確認などのさまざまなフェーズが含まれます。各フェーズには、データベースレコードの作成とステータスの更新が含まれます。プロセス全体には数百のデータベーストランザクションが必要であり、データベースクラスター全体では毎日数百億のトランザクションによる読み取りおよび書き込み操作が実行されます。データベースチームは、データベースシステムの安定したパフォーマンスを確保しながら、毎日生成されるデータ量が増加するため、ストレージコストが高くなるという課題に直面しています。

注文レコードは、トランザクションプロセス全体で最も重要な情報であり、注文の問い合わせと紛争解決に必要です。したがって、注文レコードはデータベースに永続的に保存する必要があります。淘宝網は2003年に設立されて以来、注文に関連する数兆のデータベースレコードが生成され、レコードはペタバイトのディスクスペースを占有しています。

次のセクションでは、ユーザーがストレージコストを増加させることなく注文レコードをクエリするときに、Taobaoが低レイテンシを保証する方法について説明します。

アーキテクチャの進化

注文レコードデータベースのアーキテクチャは、トラフィックが増加するにつれて4つのフェーズを経て進化しました。

フェーズ1
このフェーズでは、トラフィックが少なく、TaobaoはOracleデータベースを使用してすべての注文情報を保存しました。注文作成および履歴注文クエリは、同じデータベースで実行されました。
フェーズ2
履歴注文データの量が増加するにつれて、Oracleデータベースはパフォーマンスと容量の要件を同時に満たすことができなくなりました。したがって、データベースはオンラインデータベースと履歴データベースに分割されました。 3か月前に生成された履歴注文レコードは、履歴データベースに移行されました。ただし、このフェーズでは、履歴データベースに大量のデータが含まれているため、過去3か月間の履歴注文レコードのみをクエリできます。
フェーズ3
ストレージコストと過去の注文レコードクエリに関連する問題を修正するために、Taobaoは過去の注文レコードをHBaseデータベースに移行しました。
HBaseは、プライマリテーブルとインデックステーブルを提供します。ユーザーは、購入者または販売者のIDに基づいて、注文の詳細のプライマリテーブルと注文IDのインデックステーブルを照会できます。しかしながら、注文レコードは、時系列順に履歴データベースに移行されなくてもよく、いくつかのタイプの注文レコードは、データベースに移行されない。結果として、注文レコードは、時間によってソートされ得ない。ユーザーが注文レコードをクエリする場合、クエリ結果の注文レコードは厳密には時系列でリストされません。
フェーズ4
履歴データベースは、X-Engineに基づくPolarDB-Xクラスターに組み込まれています。これにより、ストレージコストが削減され、アウトオブタイムオーダーの問題が修正されます。

ビジネス上の問題点

アーキテクチャの進化は、過去のデータベースが導入されてから過去10年間に、ビジネスチームとデータベースチームが次の問題点に苦しんでいたことを示しています。

ストレージコスト
毎日大量のデータが書き込まれます。低コストのストレージが必要です。
クエリのパフォーマンス
時間によるクエリや注文タイプによるクエリなど、特定の要件を満たすにはさまざまなクエリ機能が必要です。データベースは、データの一貫性とパフォーマンスを確保できるセカンダリインデックスをサポートする必要があります。
クエリ待ち時間
ユーザーエクスペリエンスを確保するには、クエリの待ち時間を短くする必要があります。たとえば、90日前の過去の注文レコードに対するクエリは、過去90日間の過去の注文レコードに対するクエリよりもはるかに少ないですが、必要なレイテンシは低くなります。

X-Engineに基づく履歴注文データベースソリューション

取引注文システムは、オンラインデータベースと履歴データベースが分離されたアーキテクチャの観点から10年間繰り返されてきました。ほとんどのサービスコードはこのアーキテクチャと互換性があり、これもソリューションで継承されます。このアーキテクチャは、サービスコードの再構築および移行によって引き起こされるリスクを低減する。最初に、HBaseクラスターは、X-Engineに基づくPolarDB-Xクラスターに置き換えられます。

オンラインデータベースは、InnoDBストレージエンジンに基づくMySQLクラスターに引き続きデプロイされ、過去90日間の注文レコードのみが保存されます。データ量が少ないため、高いキャッシュヒット率が保証され、読み取りおよび書き込みのレイテンシが削減されます。
90日前に生成された注文レコードは、データ同期を使用してオンラインデータベースから履歴データベースに移行され、オンラインデータベースから削除されます。
履歴データベースのストレージエンジンがX-engineに変更されました。データベースには、90日前に生成されたすべての注文レコードが格納され、注文レコードの読み取りおよび書き込み操作を実行するために使用されます。

新しいソリューションを使用した後のストレージコストは、HBaseデータベースの使用時に発生するストレージ料金と同じになります。履歴データベースはオンラインデータベースと互換性があり、2つのデータベースで同一のインデックスを作成できます。これにより、アウトオブタイムオーダーの問題が修正されます。履歴データベースでは、ホットデータはコールドデータから分離され、読み取りレイテンシを削減します。

概要

淘宝網の注文記録は合理化モードで保存されます。最近書き込まれたレコードは、最初は頻繁にアクセスされ、時間の経過とともにアクセス頻度が低下する。 X-Engineはホットデータとコールドデータを分離し、このアクセスシナリオに適しています。これらのアクセスシナリオには、X-Engineに基づく単一のデータベースクラスターで十分です。

たとえば、新規または既存のビジネスでは、多数のストリームラインレコードを保存する必要があります。ホットデータとコールドデータがビジネスレイヤーで分離されていない場合は、X-Engineに基づく分散PolarDB-Xクラスターを使用して、ストレージコストを増加させずにスケーラビリティを確保することを推奨します。

X-EngineはAlibaba Cloudで利用できます。ビジネス要件に基づいてX-Engineを購入できます。詳細については、「ApsaraDB RDS For MySQLインスタンスの作成」をご参照ください。