データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

この記事は、Xiaohongshu のインフラストラクチャストレージチームである Kong Kong と Liu Bei によって共有されたもので、原題は「How Does Xiaohonshu Corpe with Challenge of兆-level social network relationship? The graph storage system REDtao is here!」です。が改訂され、変更されました。

1 はじめに

小紅書はコミュニティ属性に焦点を当てた製品で、さまざまな分野のライフコミュニティをカバーし、大規模なソーシャルネットワーク関係を保存します。

ソーシャルシナリオにおける超大規模データの更新とそれに伴う読み込みの問題を解決し、データベースの負荷とコストを削減するために、私たちは自社開発の超大規模ソーシャルネットワーク向けグラフストレージシステムREDtaoを開発しました。システムの安定性が大幅に向上します。このシステムは Facebook のグラフストレージシステム設計を利用し、キャッシュと基盤となるデータベースをカプセル化し、統合されたグラフクエリ API を外部に提供して、キャッシュ内でのアクセスの収束と効率的なエッジ集約を実現します。

この記事では、Xiaohongshu の超大規模ソーシャルネットワーク向けグラフストレージシステムである REDtao のアーキテクチャ設計と技術実践プロセスを共有します。

2. 著者について

Hollow: Xiaohonshu のインフラストラクチャストレージグループは、グラフストレージシステム REDtao と分散キャッシュの研究開発を担当しています。

Liu Bei: Xiaohonshu のインフラストラクチャストレージグループの責任者で、REDkv / REDtao / REDtable / REDgraph の全体的なアーキテクチャとテクノロジーの進化を担当します。

インフラストラクチャストレージグループは、Xiaohongshu の事業部門に安定した信頼性の高いストレージおよびデータベースサービスを提供し、ストレージ製品に対する企業の機能、パフォーマンス、コスト、安定性の要件を満たしています。現在は自社開発の分散KV、分散キャッシュ、グラフストレージシステム、グラフデータベース、テーブルストレージを担当。

オンラインストレージ製品には次のようなものがあります。

1) REDkv : 分散型高性能 KV。
2) REDtao : ワンホップクエリに対応する高性能グラフストレージデータベース。
3) REDtable : スキーマセマンティクスとセカンダリインデックスを提供するテーブルストレージ。
4) REDgraph : 2 ホップ以上のグラフセマンティッククエリデータベースを提供します。

3. 技術的背景

小紅書は主に若者向けの生活記録・共有プラットフォームで、ユーザーは短いビデオ、写真、テキストを通じて日常生活を記録し、ライフスタイルを共有することができます。

小紅書のソーシャル領域には、ユーザー、ノート、商品などのエンティティがあり、それらのエンティティ間にはさまざまな関係が存在します。

たとえば、ユーザーとノートの間には、「所有」(公開)、「いいね」、「収集」という 3 つの関係があり、「いいね」と「収集」など、対応する逆の関係も存在します。

Xiaohonshu のソーシャルグラフデータは 1 兆エッジの規模に達し、非常に急速に増加しています。ユーザーが小紅書にログインすると、各ユーザーには友達、ファン、いいね、コレクション、その他自分に合わせたコンテンツが表示されます。

この情報は高度に個人化されており、これらの膨大な社会関係データからユーザー関連情報をリアルタイムで読み取る必要があります。これは読み取り重視のプロセスであり、読み取りのプレッシャーは非常に高くなります。

以前は、これらのソーシャルグラフデータを、成熟した運用と保守を備えた MySQL データベースに保存していました。

ただし、1 秒あたり 100 万リクエストまでしかスケールしなかったにもかかわらず、MySQL の CPU 使用率は依然として 55% に達しました。ユーザーと DAU の爆発的な増加に伴い、MySQL データベースを継続的に拡張する必要があり、これにより多大なコストと安定性のプレッシャーが生じます。

これらの問題を解決するために、適切なオープンソースソリューションが存在しないことを考慮し、2021 年の初めに REDtao の 0 から 1 への自社開発プロセスを開始しました。

4. ソリューション調査とAPI設計

4.1 調査の計画

業界内の他のメーカーの導入状況を十分に調査した結果、ソーシャル属性が強い企業は基本的に自社開発のグラフストレージシステムを備えていることがわかりました (次の図を参照)。

例えば：

1) Facebook は、「TAO」と呼ばれる特殊な分散型ソーシャルグラフデータベースを実装し、それをコアストレージシステムとして使用しています。
2) Pinterest は Facebook に似ており、同様の画像ストレージシステムを実装しています。
3) ByteDance は ByteGraph 自体を開発し、それをコアのソーシャルグラフデータの保存に使用しています。
4) Linkedln は KV 上にソーシャルグラフサービスを構築しました。

当時すでにソーシャルグラフデータが MySQL データベースに保存されており、その規模が巨大だったことを考えると、ソーシャルグラフデータサービスは非常に重要なサービスであり、非常に高い安定性要件がありました。振り返ってみると、Facebook も私たちと同様の問題に直面しており、データは Memcache と MySQL に保存されていました。したがって、Facebook の Tao グラフストレージシステムを参照することは、実際の状況と既存の技術アーキテクチャにより一致しており、リスクが少なくなります。

4.2API設計

ソーシャルグラフへのアクセスは主にエッジ関係クエリです。

このグラフモデルは、関係を <key, value> ペアとして表します。ここで、key は (FromId、AssocType、ToId) の 3 つであり、value は属性の JSON 形式です。

たとえば、「ユーザー A」の後に「ユーザー B」が続き、REDtao にマップされるデータストレージ構造は次のようになります。

1<FromId: ユーザー A の ID、AssocType: Follow、ToId: ユーザー B の ID> -> 値 (属性の json フィールド)

ビジネスサイドのニーズを分析し、追加、削除、変更、検索などのニーズを満たすビジネスサイドが利用できる25個のAPIをグラフセマンティクスでカプセル化し、ビジネスサイドの利用方法を集約しました。

Facebook の Tao と比較して、ソーシャルグラフに必要なグラフセマンティクスも補完し、不正行為防止シナリオ用の追加のフィルターパラメーターを提供します。

同時に、キャッシュレベルで、さまざまなフィールドのキャッシュ内のローカルセカンダリインデックスの構成をサポートします。

典型的な使用シナリオをいくつか示します。

1) シナリオ 1: A をフォローするすべての通常のユーザーを取得します (および不正ユーザーを排除します)。

1getAssocs("注目するタイプ"、ユーザー A の ID、ページングオフセット、最大戻り値、通常のユーザーのみが返されます、時間の経過とともに新しいものから古いものになるかどうか)

2) シナリオ 2: A のファンの数を取得します (不正行為を行っているユーザーを排除します):

1getAssocCount("注目タイプ"、ユーザー A の ID、通常のユーザーのみが返されます)

5. 全体的なアーキテクチャ設計

REDtao のアーキテクチャ設計では、次の重要な要素が考慮されています。

全体的なアーキテクチャは 3 つの層に分かれています。

1)アクセス層。
2)キャッシュ層。
3)永続層。

ビジネス当事者は、REDtao SDK を通じてサービスにアクセスします。

以下に示すように:

このアーキテクチャでは: Facebook Tao とは異なり、キャッシュ層は独立した分散クラスターであり、その下の永続層から分離されています。キャッシュ層とその下の永続化層は独立して拡張・縮小可能キャッシュシャードとMySQLシャードを1対1で対応させる必要がなくなり、柔軟性が向上 MySQLクラスタもプラグイン可能で交換可能な永続サーバーとなった。

1) 読み取りプロセス:クライアントは読み取りリクエストをルーターに送信し、RPC リクエストを受信したルーターは、エッジタイプに応じて対応する REDtao クラスターを選択し、トリプレット (FromId、AssocType、 ToId) を通じて、一貫したハッシュを介してフォロワーノードがリクエストをこのノードに転送します。Follower ノードはリクエストを受信すると、まずローカルグラフキャッシュにクエリを実行し、ヒットした場合は結果を直接返します。ヒットがない場合、リクエストはリーダーノードに転送されます。同様に、リーダーノードがヒットした場合は返され、ヒットしなかった場合は、基になる MySQL データベースがクエリされます。

2) 書き込みプロセス:クライアントは書き込みリクエストをルーターに送信し、読み取りプロセスと同様に、対応するフォロワーノードに転送されます。フォロワーノードは書き込みリクエストをリーダーノードに転送し、リーダーノードはそれを MySQL に転送します。MySQL が書き込みが成功したことを返すと、リーダーはローカルマップキャッシュに対応するキーをクリアし、すべてのマップキャッシュに対応するキーをクリアします。データの最終的な整合性を確保するために、他のフォロワーも同時に実行します。

6. 高可用性設計

REDtao は、キャッシュ層と永続化層の 2 つの独立した層に分かれています。各層は高可用性を保証します。

1) 自社開発の分散キャッシュ:

私たちは、グラフセマンティクスを実装し、自動障害検出と回復、および水平方向の拡張と縮小をサポートする分散キャッシュクラスターを自社開発しました。

これは 2 層キャッシュであり、各シャードにはリーダーと複数のフォロワーがあります。すべてのリクエストは最初に外側のフォロワーに送信され、次にフォロワーによってリーダーに転送されます。この利点は、読み取りプレッシャーが高い場合に、Follower を水平方向に展開するだけで済むことです。また、Leader を 1 点で記述する方法により、複雑さが軽減され、データの整合性が容易になります。

1 つのレプリカに障害が発生した場合、システムは数秒以内に切り替わります。永続層に障害が発生した場合でも、分散キャッシュ層は外部読み取りサービスを提供できます。

2) 高可用性 MySQL クラスター:

MySQL クラスターは、自社開発のミドルウェアを通じてデータベースとテーブルのサブスキームを実装し、MySQL の水平拡張をサポートします。各 MySQL データベースには複数のスレーブデータベースがあり、社内の他の MySQL 運用および保守ソリューションと整合性があり、高可用性を確保します。

3) 電流制限保護機能:

キャッシュの故障により MySQL が大量のリクエストにバーストし、MySQL がクラッシュするのを防ぐために、マスターノードごとに同時 MySQL リクエストの最大数を制限することで MySQL を保護する電流制限を実装しています。同時リクエストの最大制限に達した後のリクエストは、既存のリクエストが処理されて返されるまで一時停止されます。あるいは、待機タイムアウトに達した後にリクエストは拒否され、MySQL への処理は続行されません。電流制限のしきい値はオンラインで調整でき、対応する制限は MySQL クラスターのサイズに応じて調整されます。

クローラーや不正なユーザーが同じデータを頻繁にブラッシングするのを防ぐために、REDtaoQueue を使用して同じエッジの書き込みまたはチェックのリクエストを順番に実行します。キューの長さは、多数の同じリクエストの実行を制御するために制限されます。同時に。単一のグローバルキューがすべてのリクエストを制御する方法と比較して、リクエストごとのキューは、他の通常のリクエストに影響を与えることなく、単一の同じリクエストを十分に制限できます。

7. 高性能設計

データ構造の設計は、REDtao の高いパフォーマンスを保証する重要な要素です。

3 層ネストされた HashTable 設計を採用し、特定の開始点 from_id に基づいて第 1 レベルの HashTable から REDtaoGraph を検索することにより、対応するすべてのアウトバウンドエッジ情報をすべてのタイプで記録しました。

次に、第 2 レベルの HashTable で、特定の type_id に基づいて、特定のタイプに対応する AssocType のすべての発信エッジのカウント、インデックス、およびその他のメタデータが見つかります。

最後に、最後のレベルの HashTable では、AssocType の特定の to_id を通じて最終的なサイド情報が見つかります。

作成時刻、更新時刻、バージョン、データ、REDtaoQueueを記録しており、time_indexは作成時刻によるリストのソートに相当します。

最後のレベルの HashTable とインデックス制限には、最新の 1000 個のエッジ情報が保存され、スーパーポイントが過剰なメモリを占有するのを制限しながら、クエリヒット率と最新のホットデータの効率の向上に重点を置いています。REDtaoQueue は、現在の関係の読み取りと書き込みをキューに入れるために使用され、最新の現在のリクエストのメタデータのみを記録します。

クエリまたは書き込みを行うたびに、REDtaoAssoc が最初にクエリされます。

1)キャッシュが存在しない場合は、REDtaoQueue のみを含むオブジェクトが最初に作成されます。
2)キャッシュがすでに存在する場合、キャッシュはキューのメタデータを更新し、それ自体をキュー内の最後のリクエストとして設定し、実行されるのを待ちます。

この多層ハッシュ + スキップリストの設計により、ポイント、エッジ、インデックス、時系列リンクリスト間の関係を効率的に整理できます。メモリの適用と解放は同じスレッド上で完了します。

オンライン環境では、当社のシステムは 16 コアのクラウドベンダー仮想マシン上で 1 秒あたり 150 万のクエリリクエストに達することができますが、CPU 使用率はわずか 22.5% です。以下はオンラインクラスターの監視グラフです。単一マシンの QPS は 3w に達し、各 RPC リクエストは 50 クエリを集約します。

8. 使いやすいデザイン

1) 豊富なグラフセマンティック API:

ビジネス側が使用できるように、REDtao で 25 個のグラフセマンティック API をカプセル化しました。これは、ビジネス側の追加、削除、変更、クエリのニーズを満たします。ビジネスパーティは、対応する操作を実装するために自分で SQL ステートメントを記述する必要がなく、使用方法がよりシンプルかつ集中的になります。

2) 統合アクセス URL:

コミュニティのバックエンドデータが大きすぎるため、さまざまなサービスと優先順位に従ってデータを複数の REDtao クラスターに分割しました。

ビジネス側がバックエンドのクラスター分割ロジックを認識しないようにするために、統合アクセス層を実装しました。

異なるビジネスパーティは、同じサービス URL を使用し、SDK を通じてアクセスレイヤにリクエストを送信するだけで済みます。アクセス層は、さまざまなビジネスパーティからグラフセマンティクスのリクエストを受信し、エッジタイプに基づいてそれらをさまざまな REDtao クラスターにルーティングします。コンフィグレーションセンターに加入することで、エッジのルーティング関係をリアルタイムに把握できるため、統一されたアクセスURLが実現し、ビジネス関係者が使いやすくなります。

9. データ整合性設計

ソーシャルグラフデータとして、データの一貫性は非常に重要です。データの最終的な整合性と、特定のシナリオの下での強力な整合性を厳密に保証する必要があります。この目的のために、私たちは次の措置を講じました。

1) キャッシュ更新の競合の解決:

REDtao は、書き込みリクエストごとに、グローバルに増加する一意のバージョン番号を生成します。MySQL データを使用してローカルキャッシュを更新する場合、バージョン番号を比較する必要があります。バージョン番号がキャッシュされたデータのバージョンよりも低い場合、競合を避けるために更新リクエストは拒否されます。

2) 読み取り後書き込みの一貫性:

プロキシは、同じ fromId を持つポイントまたはエッジリクエストを同じ読み取りキャッシュノードにルーティングして、読み取りデータの一貫性を確保します。

3) マスターノード異常シナリオ:

リーダーノードは更新リクエストを受信すると、更新リクエストを無効化キャッシュリクエストに変換し、他のフォロワーに非同期で送信して、フォロワー上のデータが最終的に一貫していることを確認します。異常な状況下で、リーダーによって送信されたキューがいっぱいで無効化キャッシュ要求が失われると、他のすべてのフォロワーキャッシュがクリアされます。

リーダーが失敗した場合、新しく選出されたリーダーも他のフォロワーにキャッシュをクリアするよう通知します。

さらに、Leader は、個々のシャードのキャッシュがクリアされても MySQL がクラッシュしないように、MySQL にアクセスするリクエストのフローを制限します。

4) 少数の強力な一貫性のあるリクエスト:

MySQL のスレーブライブラリは読み取りサービスも提供するため、強い一貫性が必要な少数の読み取りリクエストの場合、クライアントは特別なフラグでリクエストを染色できます。REDtao はフラグを透過的に送信し、データベースプロキシ層は読み取りリクエストを次のサーバーに転送します。データの強力な一貫性を確保するために、フラグデータベースに基づいて MySQL マスターを作成します。

10. クロスクラウドのマルチアクティビティ設計

クロスクラウドのマルチアクティビティは同社の重要な戦略であり、REDtao がサポートする重要な機能です。

REDtao の全体的なクロスクラウドマルチアクティブアーキテクチャは次のとおりです。

これは Facebook Tao のクロスクラウドマルチアクティブ実装とは異なります。Facebook Tao のクロスクラウドマルチアクティブ実装は次の図に示されています。

Facebook のソリューションは、DTS レプリケーションを通じて実行される、基礎となる MySQL マスター/スレーブレプリケーションに依存しています。MySQL のネイティブマスター/スレーブレプリケーションは独自の機能ですが、DTS サービスには MySQL のマスター/スレーブレプリケーションは含まれていません。このソリューションでは、MySQL と DTS に特定の変更を加える必要があります。前述したように、キャッシュ層と永続層は分離されており、アーキテクチャが異なります。

そこでREDtaoのクロスクラウドマルチアクティブアーキテクチャは独自のシナリオに基づいた設計であり、既存のMySQLの機能を変更することなくクロスクラウドマルチアクティブ機能を実現します。

1)永続化レイヤーでは、MySQL のネイティブのマスター/スレーブビンログを使用して、データを他のクラウドのスレーブライブラリに同期します。他のクラウド上の書き込みリクエストと少数の強力な一貫性のある読み取りはメインデータベースに転送されます。通常の読み取りリクエストは、読み取りリクエストのレイテンシ要件を満たすために、この領域の MySQL データベースを読み取ります。

2)キャッシュレイヤーのデータの一貫性は、MySQL DTS サブスクリプションサービスを通じて実現され、この領域の REDtao キャッシュレイヤーの古いデータをクリーンアップするために、ビンログが無効化キャッシュリクエストに変換されます。読み取りリクエストはこの領域内の MySQL データベースをランダムに読み取るため、DTS サブスクリプションは遅延サブスクリプション機能を使用して、最も遅いバイナリログ同期を使用してノードからログが読み取られるようにし、DTS の無効化キャッシュリクエストとこの領域の読み取りキャッシュを回避します。ミスリクエストが競合し、データの不整合が発生します。

11. クラウドネイティブ実装

REDtao のクラウドネイティブ機能は主に、柔軟なスケーリング、マルチ AZ およびリージョンのデータ分散のサポート、異なるクラウドベンダー間の製品移行などのいくつかの側面に反映されています。REDtao は、最初から弾性的な拡張と収縮、自動障害検出と回復をサポートするように設計されました。

Kubernetes のクラウドネイティブテクノロジがますます成熟するにつれて、私たちは k8s の機能を使用してデプロイメントと仮想マシンを分離し、クラウドネイティブをさらに促進し、異なるクラウドベンダー間でのデプロイメントと移行を容易にする方法についても考えています。

REDtao は、Kubernetes クラスター上で実行される Operator を実装し、障害が発生したマシンの迅速な導入、拡張、交換を実現します。

k8s がクラスターシャードの割り当てを認識し、異なるホスト上の同じシャードにある Pod のスケジューリングを制御するために、クラスターグループのシャード割り当ては k8s Operator によってレンダリングされ、DuplicateSet (自己開発された k8s リソース) の作成を制御します。 Xiaohonshu によって開発されたオブジェクト)。

REDtao はマスター/スレーブを作成し、Operator によってレンダリングされたシャード情報に基づいてクラスターを作成します。単一のポッドに障害が発生して再起動した場合、クラスター全体を再作成することなくクラスターに再参加します。クラスターがアップグレードされると、オペレーターはマスターとスレーブの割り当てを感知して最初にスレーブ、次にマスターの順序を制御し、シャード割り当ての順序でアップグレードをロールして、アップグレード中のオンラインへの影響を軽減します。

12. 旧サービスのスムーズなバージョンアップの実践

どのような変化も簡単ではありません。新しい REDtao の実装は比較的簡単な部分にすぎません。

Xiaohongshu のソーシャルグラフデータサービスは長年にわたり MySQL 上で実行されており、さまざまなビジネスが MySQL 上で実行されているため、小さな問題があれば、Xiaohongshu のオンラインユーザーに影響を及ぼします。したがって、既存のサービスを中断することなくREDtaoに移行する方法が非常に大きな課題となっています。

移行作業には 2 つの重要なポイントがあります。

1)古い大規模な MySQL クラスターを優先度に従って 4 つの REDtao クラスターに分割します。このようにして、まず優先度の最も低いサービスを REDtao クラスターに移行し、次に十分なグレースケールの後に優先度の高いクラスターを移行できます。

2) Tao Proxy SDK は、デュアル書き込みとデュアル読み取り、元の MySQL クラスターと REDtao クラスターのデータ検証と比較をサポートするために特別に開発されました。

移行中:まず、DTS サービスを通じて優先度の低いデータを MySQL から REDtao クラスターに移行し、ビジネス SDK をアップグレードしました。DTS サービスは常に増分データを同期します。ビジネス側 SDK は構成センターで構成変更をサブスクライブし、Tao Proxy SDK が MySQL クラスターと REDtao クラスターを同時に読み書きできるように構成を変更し、DTS サービスを終了します。このとき、MySQL クラスターの結果がユーザーに返されます。

DTS サービスを停止する場合: DTS を通じて同期された新しい MySQL データが存在する可能性があり、REDtao クラスターの新しく書き込まれたデータが同期された古いデータによって上書きされます。そこで、DTS サービスをシャットダウンした後、二重書き込み開始から DTS サービスがシャットダウンするまでの間、ツールを使用してバイナリログを読み取り、データの検証と修復を行います。

修復完了後: Tao Proxy SDK の二重読み取りにより、両側で一貫性のないデータ量が表示され、一貫性のない二重書き込み遅延による一貫性のないデータを含むリクエストが除外されます。グレースケール期間の後、差分の数が基本的に 0 であることが観察されたため、Tao Proxy SDK の構成が新しい REDtao クラスターに対して読み取り/書き込み専用に変更されました。

最後に:小紅樹のすべてのコアソーシャルグラフの兆エッジレベルデータの移行と正確性の検証を 2022 年初頭に完了し、移行サービス全体を知覚できないようにし、移行プロセス中に障害は発生しませんでした。

13. 新しい画像保管システムがもたらす効果と利点

ソーシャルグラフデータアクセスでは、リクエストの 90% 以上が読み取りリクエストであり、ソーシャルグラフデータには非常に強い時間的局所性があります (つまり、最も最近更新されたデータが最もアクセスしやすい)。REDtao がオンラインになった後、90% 以上のキャッシュヒット率を達成し、MySQL の QPS を 70% 以上削減し、MySQL の CPU 使用率を大幅に削減しました。MySQL レプリカの数を減らした後、全体のコストは 21.3% 削減されました。‍

すべてのビジネスアクセス方法は、REDtao が提供する API インターフェイスに集約されました。移行プロセス中、MySQL データベースにアクセスするいくつかの古くて不合理な方法や、特定のフィールドをカスタマイズして特別な意味を与えるという不合理な慣行も管理しました。REDtao を通じてデータアクセスを標準化します。

2022 年の初めと 2023 年の初めを比較すると、DAU の増加に伴い、ソーシャルグラフのリクエストは 250% 以上増加しました。古い MySQL アーキテクチャの場合、拡張リソースは基本的にリクエストの増加率に比例し、少なくとも拡張には 1 倍のリソースコストが必要です (数万コア)。

REDtao システムの存在とその 90% のキャッシュヒット率のおかげで、2.5 倍のリクエストの増加を処理するために、実際に全体のコストは 14.7% (数千コア) しか増加しませんでした。コストと安定性が大幅に向上しました。

14. 今後の展望

私たちは、ソーシャルグラフの関係データの急速な増加の問題を解決するために、自社開発のグラフストレージシステム REDtao を短期間で開発しました。

REDtao は FaceBook Tao の論文を参考にし、全体的なアーキテクチャとクロスクラウドのマルチアクティビティに多くの改良を加え、新たに高性能の分散グラフキャッシュを実装しました。同時に、k8s の機能を使用してクラウドネイティブ化をさらに実現します。

DAU が増加し続けるにつれて、数兆のデータの規模も拡大し続けており、より多くの技術的な課題にも直面しています。

現在、社内の OLTP グラフシナリオは主に 3 つの部分に分かれています。

1)ソーシャルグラフデータサービス：自社開発のグラフストレージシステムREDtaoは、ソーシャルシナリオにおける超大規模データの更新とそれに伴う読み取りの問題を解決します。何兆もの関係が保存されています。

2)リスク制御シナリオ:自社開発のグラフデータベース REDgraph を通じて、マルチホップリアルタイムオンラインクエリが満たされます。現在、数千億のポイントとエッジの関係が保存されており、2 ホップ以上のクエリを満たしています。

3)社会的推奨:この領域は主に 2 ホップのクエリです。すべてのデータは Hive を通じて毎日バッチでインポートされ、更新されたデータは DTS サービスを通じてほぼリアルタイムで書き込まれます。オンラインシナリオであるため、レイテンシの要件が非常に高く、現在の REDgraph ではそのような高い要件を満たすことができないため、ビジネス側では主に REDkv をストレージに使用しています。

上記のシナリオの場合:ビジネスニーズに迅速に対応するために、REDtao、REDgraph、REDkv という 3 つの異なる自社開発ストレージシステムを使用しています。

明らかに、これらのグラフ関連のシナリオを解決するには、3 セットのストレージシステムと比較して、統合されたアーキテクチャとシステムを使用する方が適切です。

将来: REDgraph と REDtao を統合データベース製品に統合して、業界トップのグラフテクノロジを作成し、社内でより多くのシナリオを実現する予定です。

[2] テンセント技術共有: ソーシャルネットワーク画像の帯域幅圧縮技術の進化

[3] ソーシャルネットワークを基盤とする Yelp は、大量のユーザー画像の可逆圧縮をどのように実現しているのでしょうか?

[4] ソーシャルソフトウェア赤い封筒技術の復号化 (1): QQ 赤い封筒技術ソリューションの包括的な復号化 - アーキテクチャ、技術実装など。

[5] ソーシャルソフトウェアレッドエンベロープ技術の復号化(6)：WeChatレッドエンベロープシステムのストレージ層アーキテクチャ進化実践

[6] ソーシャルソフトウェア赤封筒技術の解読(9)：モバイルQQ赤封筒の機能ロジック、ディザスタリカバリ、運用保守、アーキテクチャなどについて語る

[7] れんれんからの脱却：インターネットソーシャルプロダクトを10年経験した者によるレビューと考察

[8] 中国におけるインターネット社会化の 20 年: 国民全体が目撃したインターネット起業家の物語

【9】モバイルインターネット時代のソーシャルプロダクトの進化の歴史を振り返る（前編）：担当者は？

[10] モバイルインターネット時代のソーシャルプロダクトの進化の歴史を振り返る（後編）：グレートウェーブ