データベースカンファレンス VLDB 2023 論文解釈 - Krypton: バイトダンスリアルタイムサービス分析 SQL エンジンの設計

「クリプトンはDCユニバースのクリプトンに由来します。スーパーマンの故郷であり、クリプトン元素にちなんで名付けられました。」

導入

近年、Byte の社内業務では、複雑な分析要件に加えて、リアルタイムデータのオンラインサービス機能に対するより高い要件も提示されています。ほとんどの企業は、さまざまなワークロードに対処するために複数のシステムを使用する必要があります。ニーズは満たせますが、異なるシステム間でのデータの一貫性の問題も生じます。複数のシステム間の ETL は多くのリソースを浪費します。同時に、研究開発にとっても困難です。人材の面でも、複数のシステムを保守する方法を学ばなければなりません。この問題を解決するために、私たちは複雑なビジネス向けの新世代のリアルタイムサービス分析システム (HSAP: Hybrid Serving and Analytical Processing) である Krypton プロジェクトを開始しました。これは、複雑なビッグデータ分析シナリオに対処しながら、ニーズを満たすことを期待しています。リアルタイムデータオンラインサービスに対するビジネスニーズ。

論文リンク: https://www.vldb.org/pvldb/vol16/p3528-chen.pdf

背景と紹介

上の図は Byte の典型的な広告バックエンドアーキテクチャで、データは Kafka を通じてさまざまなシステムに流れます。オフラインリンクの場合、データは通常、計算のために Spark/Hive に流れ、結果は ETL を通じて HBase/ES/ClickHouse などのシステムにインポートされ、オンラインクエリサービスを提供します。リアルタイムリンクの場合、データは HBase/ES に直接入力され、高同時実行性と低遅延のオンラインクエリサービスを提供します。一方、データは ClickHouse/Druid に流れてオンラインクエリ集約サービスを提供します。これが引き起こす問題は、冒頭で述べたとおりで、データが複数のコピーに冗長的に保存されるため、多くの一貫性の問題が発生し、リソースが大量に浪費されます。この問題を解決するために、私たちは Krypton (HSAP) を設計しました。システムの設計目標には、いくつかの主要なポイントがあります。

調整可能。さまざまなワークロードに対応できるシステムを設計したいと考えており、さまざまなワークロードに合わせて、システムの各コンポーネントを自由に拡張できます。
高い同時実行性と低い遅延。オンラインサービスシナリオのニーズに対応するには、システムは 100 万レベルの同時実行性とミリ秒レベルの遅延要件を満たす必要があります。
データには強い一貫性があります。当社の顧客は、データがアトミックにインポートされ、スナップショット読み取りがサポートされることを望んでいます。
高い適時性。ほとんどのユーザーは、1 秒未満のレベルでデータを表示する必要がありますが、一部のサービス提供シナリオでは、ユーザーはミリ秒レベルでデータを表示する必要があります。
高スループットのインポート。ビッグデータのシナリオでは、インポートのパフォーマンスが非常に重要です。
標準 SQL サポート。多くのユーザーが MySQL などのシステムから移行しているため、ANSI SQL のサポートはユーザーの移行にとって重要です。

システム概要

データ・モデル

図に示すように、Krypton は 2 つのレベルのパーティショニングをサポートしています。第 1 レベルはパーティションと呼ばれ、第 2 レベルはタブレットと呼ばれます。各レベルは、レンジ/ハッシュ/リストパーティショニング戦略をサポートしています。各タブレットには行セットのセットが含まれており、各行セットの内部データはスキーマで定義されたソートキーに従ってソートされます。Rowset にはバージョン番号の概念があります。同じ主キーに対応する行は、異なる Rowset 内の複数のコピーに存在する場合があります。読み取り時には、異なるマージアルゴリズムに従って、複数のバージョンのデータが 1 つのコピーにマージされます。タブレットのコミットバージョンは、タブレットの行セットの最大バージョン番号です。たとえば、上図のタブレット 2 のコミットバージョンは、行セット 5 のバージョン番号 21 です。各クエリには、スナップショット読み取りを実現するためのデータのバージョン番号が含まれます。

さまざまな結合アルゴリズムに従って、Krypton は 3 つのテーブルモデルをサポートします。

重複テーブル: 同じ行のコピーが複数あります。
一意のテーブル: システムは主キー (PK) を定義する必要があります。同じ PK のコピーは 1 つだけ存在し、上位のバージョンが下位のバージョンを上書きします。
集計テーブル: 一意のテーブルと同様に、PK を定義する必要がありますが、同じ PK と異なる列を持つ複数の行の結合アルゴリズムはカスタマイズできます。

建築

上の図に示すように、Krypton のアーキテクチャには次の特徴があります。

記憶と計算の分離
1. Krypton のデータは、HDFS、標準オブジェクトストレージインターフェイス S3 などのクラウドストアに保存され、メタデータは、ZK や分散 KV システムなどの外部ストレージシステムにも保存されます。
読み取りと書き込みの分離
1. インジェストサーバーはデータのインポートを担当し、コンパクションサーバーはデータを定期的にマージすることを担当します。データがインポートされた後、取り込みサーバーは WAL を書き込み、データはメモリバッファに入ります。バッファがいっぱいになると、列にフラッシュされてクラウドストア上のファイルに保存され、新しいデータが保存されます。メタサーバーに登録され、関連するタブレットのコミットバージョンが更新されます。
2. コーディネーターとデータサーバーは読み取りリンクを形成します。コーディネーターはメタサーバーにアクセスしてスキーマとデータの最新バージョン番号を取得し、分散実行プランを生成してデータサーバーに送信します。データサーバーはクエリプランの実行を担当します。Krypton のクエリプロセッサは MPP 実行モードを採用しています。
3. データの可視性を向上させるために、ダーティリード機能がサポートされています。これは、データサーバーが取り込みサーバーメモリ内のデータに直接アクセスできることを意味し、ミリ秒レベルのデータ可視性を提供します。
キャッシュ
1. オンラインサービスの低遅延要件をサポートするために、コーディネーターのメタデータキャッシュ、プランキャッシュ、および結果キャッシュをサポートします。Data Server は、DRAM、PMEM、SSD メディアを含むデータのマルチレベルキャッシュを内部的にサポートします。不具合を軽減するために、キャッシュ予熱機能もサポートしており、新しいデータはメタサーバーに登録される前にロードされるようにデータサーバーに通知されます。

マテリアライズドビュー

マテリアライズドビュー (MV) は、サービス提供シーンと AP シーンの両方で非常に重要な役割を果たします。Krypton は、独自のアーキテクチャ機能に基づいて、単一テーブルのリアルタイムの強力な一貫性のある MV 戦略を実装しており、MV はベーステーブルと同じパーティション化戦略を維持する必要がありません。

MVのメンテナンス

インジェストサーバー内で、ベーステーブルメモリ内のデータをフラッシュする必要がある場合、MV クエリが実行されてメモリデータのこの部分が MV データに変換され、MV データとベーステーブルデータはアトミックにフラッシュされます。を実行すると、メタサーバーに登録され、ベーステーブルと MV のバージョン番号がアトミックに更新され、MV とベーステーブル間のデータの一貫性が確保されます。

クエリリライト

ここでは、比較的特殊な書き換えシナリオを紹介します。これも Byte の社内業務から来ています。元のクエリは、次の SQL のように、時間枠内のデータを集計します。

集約する必要があるデータ量が比較的大きいため、このようなクエリレイテンシに対するオンライン要件が比較的高いため、MV を使用してこのクエリの実行を高速化します。具体的な方法は次のとおりです。

元のテーブルに対して 2 つの MV を作成します。1 つは日ごとに集計され、もう 1 つは時間ごとに集計されます。
クエリの時間ウィンドウを 3 つの部分に分割します。
1. 2022-05-01 00:00:00 - 2022-05-09 00:00:00
2. 2022-05-09 00:00:00 - 2022-05-09 14:00:00
3. 2022-05-09 14:00:00 - 2022-05-09 14:12:15
タイムウィンドウ 2.a については、日レベルの MV、タイムウィンドウ 2.b を直接クエリし、時間レベルの MV をクエリし、タイムウィンドウ 2.c をクエリして、詳細テーブルをクエリし、最後にその結果をマージします。 3つの部分を一緒に。

クエリの書き換え全体は、ユーザーが意識することなく、オプティマイザーによって自動的に完了します。

データモデルの自動導出

また、特殊なテーブルとして、MV は異なるテーブルモデルを使用することも選択でき、Base table のテーブルモデルと MV Query を基に Krypton が自動的に MV テーブルモデルを導出することができ、ユーザーの負担を軽減します。

クエリプロセッサ

Krytpon は、Push ベースのベクトル化エンジンを実装し、Coroutine ベースの非同期スケジューリング実行フレームワークを採用しています。上図を例に、クエリの実行プロセスを示します。コーディネーターは、最適化されたクエリからフラグメントを生成し、それらをデータサーバーのグループに配信して実行します。たとえば、上の図のクエリは、フラグメント 0 とフラグメント 1 の 2 つのフラグメントセットを生成します。フラグメント 1 は、2 つのテーブルのスキャンの実行とコロケート結合の実行を担当します。生成された結果は、フラグメント 0 が配置されているデータサーバーにシャッフルされます。フラグメント 0 は、データを集約し、定期的にコーディネーターからデータを取得します。フラグメント 1 は内部で複数の Pipe に分割され、各 Pipe は Operator のセットで構成され、これらの Pipe の実行ロジックはブロックされません。異なるパイプは Local Exchanger オペレーターを介して接続され、異なるパイプは異なる同時実行度を設定できます。

統計とクエリキャッシュ

クエリキャッシュ
1. キャッシュの保守:期限切れのデータの使用を防ぐために、バージョン番号情報がキャッシュキーに追加され、バックグラウンドのスレッドがそれをメタサーバー内のデータバージョンと定期的に比較し、期限切れのキャッシュエントリを削除します。
2. プラン/統計/結果キャッシュ:クエリプランはコーディネーターにキャッシュされます。一部のクエリフラグメントの選択性推定情報もキャッシュされます。最後に、クエリ実行の結果もキャッシュされます。これは通常、データが保存されている場合に使用されます。頻繁に更新されない同一のクエリが多数存在するシナリオ。さらに、Krypton はクエリ実行の中間結果もキャッシュし、他のクエリでより効果的に使用できます。
統計
1. 増分統計: Krypton はテーブルの行数と列の NDV を動的に維持します。NDV は、HLL を使用してデルタ計算を実行します。インジェストサーバーがデータをフラッシュすると、メモリ内のデータの行数と HLL NDV が計算され、メタサーバーに送信されます。
2. 動的サンプリング:フィルター選択性の推定のために、クリプトンは計画段階でサンプルクエリプランフラグメントを直接送信して統計情報を収集します。TPCH-1T テストセットでは、サンプルデータの統計的推定とサポートされるデータの統計値が収集されます。データの違いが 1% だけである場合、サンプルクエリによって実行されるオーバーヘッドは実行時間の 2% を超えません。さらに、クエリの実行後、いくつかの軽量の統計情報を収集し、その結果をコーディネーターに返し、オプティマイザによる統計情報の更新を支援します。

同時実行制御

Krypton は、静的メソッドと動的メソッドを組み合わせてクエリ実行の同時実行性を決定します。

計画フェーズでは、オプティマイザーはデータサーバーの数に基づいてフラグメントレベルとパイプレベルの同時実行性を決定します。これにより、計画の動的変更による追加のオーバーヘッドを回避し、ローカルエクスチェンジャーを可能な限り削除できます。データのシャッフルを避けるため。
実行フェーズでは、各パイプは実行タスクに対応し、タスクは実行のために対応する Coro スレッドに渡されます。特定の実行同時実行性と実行順序は、現在のシステムに基づいて基礎となる Coro スケジューラによって動的に決定されます。条件。タスクごとに異なる優先度を設定でき、優先度の高いタスクに遭遇すると、Coro-scheduler は進行中のタスクに対応する Coro スレッドの数を動的に減らします。さらに、Coro-thread は pthread と比較して、コンテキストスイッチのオーバーヘッドが大幅に少なく、IO 操作が非同期で実行できるため、CPU を最大限に活用できます。

リソースの分離

Serving と AP のワークロードはまったく異なるため、混合ワークロードシナリオではリソースの分離が非常に重要です。Krypton は 2 レベルのリソース分離戦略を実装しています。

1.DSインスタンスの詳細なリソース分離

Krypton はクラウドネイティブデプロイメントモデルを採用しているため、各 DS インスタンスはコンテナーに対応するため、DS インスタンスを複数のリソースグループに分割でき、さまざまなワークロードがリソースグループを通じて分離されます。Krypton のストレージと計算の分離の特性により、複数のリソースグループが 1 つのデータを共有できます。一部の一時的な ETL クエリの場合、Krypton は処理のためにいくつかのリソースを迅速に取得し、処理後にリソースを解放できます。

2. DS内での Coro ベースのリソース分離

同じリソースグループ内では、異なるクエリも分離する必要があります。Krypton は、Coroutine に基づいた公平なスケジューリング戦略を提供します。図 6 に示すように、各コアは、それに割り当てられたすべてのタスクを管理するタスクグループにバインドされています。ここで、各タスクは Coro スレッドに対応します。実行中、タスクはローカルタスクキューに送信されて待機します。実行後、時間 t が経過すると、未完了のローカルタスクがグローバルタイムスライシングキューに入れられます。ローカルタスクキューが空の場合、対応するタスクグループはグローバルキューからタスクをフェッチします。グローバルキューの優先順位は、各タスクが消費する CPU 時間に基づいています。これが公平なスケジューリングアルゴリズムの基本原理です。

サービス提供シナリオに固有の最適化

1.軽量API

サービス提供シナリオでは、通常、各クエリはそれほど複雑ではなく、返される結果の数は多くありません。したがって、コーディネーターは、単一ノードプランが生成されたことを検出すると、対応する DS のライトウェイト API を直接呼び出して結果を取得します。軽量 API は、大規模なクエリ下での複数の RPC 通信の問題を回避し、大量のスレッドの切り替えを回避します。

2.ダーティリード

高い適時性要件が要求されるシナリオのために、ダーティリード機能が提供されます。コーディネーターがコミットされたバージョンとともにクエリを DS に送信した後、DS は取り込みサーバーのメモリに移動して非コミットデータを取得し、返された後にそれをコミットデータとマージします。インジェストサーバーは、メモリ内のデータを HDFS にフラッシュした後、ダーティリードリクエストがコミットされたバージョンの後のデータの一部を確実に取得できるようにするために、データのこの部分を一定期間キャッシュします。データホールはありません。

マルチレベルキャッシュ

パフォーマンス要件を満たすために、Krypton はデータサーバー内にマルチレベルキャッシュを実装し、キャッシュの記憶媒体として DRAM、PMEM、SSD を使用できます。以下の図に示すように、キャッシュモジュールには、キャッシュインデックス、置換ポリシー、キャッシュストレージエンジンの 3 つの部分が含まれています。

交換ポリシー

AP は多くの場合、大量のデータをスキャンする必要がありますが、サービス提供には明らかなデータアクセスの局所性があります。なぜなら、サービスのパフォーマンスを保証するために、キャッシュ置換戦略には「アンチスキャン」特性が必要だからです。

キャッシュ置換戦略として SLRU を選択しました。「アンチスキャン」機能に加えて、この戦略では、すでにキャッシュ内にあるデータにアクセスするために再ロックする必要がありません。MemCached の SLRU と比較して、ロックフリーのハッシュテーブルを使用してキャッシュインデックスを保存し、ロックをさらに削減します。バンドの今後の出費について FIFO 戦略と比較して、サービス提供シナリオでは、私たちの戦略では P99 レイテンシーが 28% 改善されました。

NUMA 対応の非同期 PMem 書き込み

PMem には読み取りレイテンシーとスループットの点で利点がありますが、書き込み帯域幅がパフォーマンスのボトルネックになります。PMem 書き込み帯域幅は DRAM 書き込み帯域幅のわずか 6 分の 1 であり、読み取り帯域幅の同時アクセスレベルよりも低く、NUMA ノード間でアクセスするとパフォーマンスが大幅に低下します。

Krypton は、PMem 書き込みパフォーマンスを向上させるために、NUMA ベースの非同期書き込み戦略を実装しています。上の図に示すように、各 PMem デバイスには対応する書き込みスレッドプールがあり、この PMem デバイスへのすべての書き込みを担当する NUMA ノードにバインドされています。非同期書き込みタスクは、処理のために対応するスレッドプールに割り当てられます。テスト後、各スレッドプールに 3 つのスレッドがある場合、PMem の書き込みパフォーマンスは 23% 向上しました。

ZonedStoreベースのSSDキャッシュ

SSD キャッシュにより、Krypton は可能な限り多くのデータをローカルにキャッシュできるようになり、システムの再起動時にすぐにウォームアップできます。内部的には、ほとんどの SSD キャッシュは、Rocksdb と同様の LSM ツリーアーキテクチャを備えた KV ストレージを使用しますが、LSM ツリーは SSD キャッシュ用に設計されていないため、大量のスペースの無駄が発生し、読み取りと書き込みの増幅が発生します。この問題を解決するために、ZonedStore を設計しました。

ZonedStore は、SSD を複数の等しいサイズのゾーンに分割し、そのうち 1 つのゾーンのみが書き込み可能です。新たに書き込まれたデータは、現在書き込み可能なゾーンに順次追加され、SSD 内の書き込み増幅を軽減できます。ZonedStore のほとんどのキャッシュ項目は 4kb より大きいため、これによりすべての項目のインデックスをメモリに配置してクエリを高速化し、読み取り増幅を減らすことができます。再起動時のインデックスリカバリの速度を向上させるために、ゾーンの最後に概要セグメントを書き込みます。

ZonedStore は、ゾーンの粒度に従ってスペースを再利用します。各ゾーンのガベージ率とアクセス頻度はメモリ内のゾーンメタデータに記録され、GC 戦略により、ガベージ率が高く、アクセス率が低いゾーンがリサイクルのために選択されます。削除されたキャッシュアイテムについては、それらを論理的に削除済みとしてマークします。クリプトンのキャッシュデータは不変であるため、これらのキャッシュアイテムは、リサイクルされる前に引き続きオンラインサービスを提供するために使用できます。GC による書き込み増幅を制御するために、ZoneStore はリサイクルされた Zone の有効なデータを直接破棄します。

上の図からわかるように、レイテンシーやスループットなど、ワークロードの種類に関係なく、ZonedStore は RocksDB と比較して比較的大きな改善が見られます。

保存形式

サービス提供と AP の両方のワークロードに対処するために、Krypton は独自のストレージファイル形式を設計しました。データページ（1MB）はデータの読み書きの基本単位で、ファイル全体はデータ、インデックス、メタの3つの部分に分かれており、それぞれがカラムごとに区切られています。クエリを処理するときは、まずインデックスを使用して、読み取る必要があるデータページを除外してから、データページにアクセスします。

エンコーディングとインデックスアルゴリズム

Krypton は、スキャンと列挙を高速化するために、さまざまなデータエンコーディングとインデックスを使用します。データの物理的な場所をすばやく見つけるために、ユーザーは DDL で適切なインデックスを選択できます。Krypton がサポートするインデックスは次のとおりです。

順序インデックス: 行番号に基づいて目的のデータページをすばやく見つけます。
スパースインデックス: 最小/最大、ブルームフィルター、およびリボンフィルターを使用して、無効なデータページをすばやく除外できます。
ショートキーインデックス: ソートキーの最初の 36 バイトをインデックスキーとして使用してインデックスを構築します。これは特別なスパースインデックスです。
BitMap Index: 同等の述語に基づいて行番号をすばやくフィルタリングできます。
インデックスをスキップ: データページ内のデータの場所をすばやく見つけることができます。

入れ子になった型の処理

Krypton は、複合データ型の処理において Dremel とは異なります。Dremel はリーフノードのみを格納しますが、Krypton はすべてのフィールドを B ツリー方式で編成し、すべてのフィールドのデータを順番に独立して格納します。非リーフノードには子ノードの発生(Occurrence)と有効性(Validity)に関する情報が格納され、リーフノードにはデータが格納されます。出現回数（Occurrence）は、サブフィールドの出現回数のプレフィックスの合計を表すため、繰り返されるデータのオフセットと長さを取得する際の計算量は O(1) になります。したがって、ネストされた繰り返しデータの場合でも、O(m) の検索効率を達成できます。ここで、m はスキーマツリーの深さです。有効性は、このフィールドが空か NULL かを区別するために使用されます。NULL フィールドにはデータを保存しないため、スパースデータの保存効率が向上します。Dremel と比較して、私たちのアルゴリズムには 2 つの利点があります。

疎フィールドはストレージ効率が高くなります。
複合繰り返しタイプの Seek 効率が向上しました。

クエリエンジンの統合

Krypton のストレージ形式の設計はクエリ実行と深く結びついており、IO をできる限り削減するために、遅延実体化と述語プッシュダウンが多用されています。述語フィルタリングと列プルーニングは、プッシュダウンランタイムフィルタ述語およびファイルインデックスとともにフォーマット層で処理されます。読み取りプロセス中、まずインデックスに一致する述語を使用して、選択された行番号のセット (選択ベクトル) がフィルターで除外されます。次に、式フレームワークを使用して、インデックスと一致しない述語を実行し、選択した行数をさらに減らし、列の枝刈りを実行します。最後に、選択ベクトルの行番号に基づいてデータを具体化します。さらに、Krypton はエンコードされたデータの直接計算もサポートしており、このとき、Format はエンコードされたデータを QE に直接返します。

TPC-H データセットと Magnus データセットで Parquet 形式との比較テストを行いました。Magnus は、複合データ型を広範囲に使用する Byte 内の ML シナリオのデータセットです。上の表からわかるように、Parquet と比較して、Krypton Format の読み取りパフォーマンスは TPCH で 21%、Magnus で 40% 向上しました。データサイズの点では、TPC-H では Krypton が 13% 向上しました。ただし、Magnus では、クリプトンは 8% 削減されます。これは主に複合型での効率的なストレージの恩恵を受けます。

実験

環境

実験環境： YCSB ワークロード C + TPC-H 1T
実稼働環境: Zhuxiaobang (注: ByteDance のワンストップホームデコレーションおよびホームサービスプラットフォーム) シナリオこれは典型的な機能サービスシナリオであり、特定のユーザーの機能について任意の時間枠内での総予算が必要です。継続的なデータインポート、リアルタイムクエリ、クエリQPS 10K/s
クラスター構成: 8 台の物理マシン (2.4GHz、48 コア、96 vCPU、128G DRAM、512G PMEM、2TB NVME、25G NIC)

Coordinators：2 台
データサーバー: 3
Compaction Server：1 台
Ingestion Server：1 台
Metadata Server：1 台

ハイブリッドパフォーマンス

リソースグループの分離

YCSB と TPCH のワークロードをそれぞれ運ぶ 2 つのリソースグループを作成しました。表 4 と図 9 からわかるように、YCSB と TPCH-1T を別々に実行する場合と比較して、分離にリソースグループを使用した後でも明らかなパフォーマンスの低下はありません。

公平なスケジューリング

同じリソースグループ内のリソース競合を解決するフェアスケジューリングの効果を検証するために、同じリソースグループでそれぞれ短いクエリと長いクエリを表す TPCH-Q6 と Q21 を実行しました。

すべてのクエリは 1 クライアントから始まり、Q6 のクライアント数は 1、2、4、8 と増加します。

図 10 から次のことがわかります。

公平なスケジューリングを使用しないと、第 6 四半期の同時実行性が増加するため、第 21 四半期のパフォーマンスが大幅に低下します。
公平なスケジューリングの後、第 21 四半期と第 6 四半期にそれぞれ 20% と 80% のリソースを割り当てましたが、第 21 四半期のレイテンシはクライアント数に応じてわずかに増加するだけでした。

図 11 からわかるように、Q6 が実行を開始すると、Q6 はそれ自身のリソース (80%) を完全に使い果たさず、約 53% のみが使用され、Fair Scheduling は残りの 27% のリソースを適応的に割り当てることができます。走る。Q6 クライアントの数が増加すると、Q6 と Q21 の両方が独自のリソースを消費します。

適応型並列処理制御

適応型同時実行制御の効果を検証するために、4 つのクライアント (G0 ～ G3) を使用し、各クライアントは最大同時実行数に従って Q6 を繰り返し送信します。図 12 から、G0 のみが存在し、十分な CPU リソースがある場合、最大同時実行数に従って実行できることがわかります。G1 ～ G3 が開始されると、CPU リソースの競合が発生し、最終的には各クライアントで実行される Coro スレッドも動的に変化します。

生産実績

時間範囲クエリの最適化の効果

MV を使用して時間範囲クエリを書き換える効果をテストするために、Online Live Xiaobang の実際のワークロードを使用しました。クエリは次のとおりです。

終了時刻を固定し、開始時刻を動的に変更しました。全体の時間範囲は 10 分から 10 時間の範囲でした。

軽量APIの効果

オンラインで 10K QPS 未満のレイテンシを比較およびテストしたところ、Lightweight API をオンにした後、クエリ P99 レイテンシは 45% 減少しました。

ストリーミング取り込みのデータの鮮度

データの鮮度は、データがインポートされてからクエリが可能になるまでの時間間隔として定義されます。図 15 からわかるように、Data Freshness P99 のレイテンシーは常に約 15 ミリ秒に維持されており、インポートレートが増加しても変化しません。

本番環境での読み取り/書き込みシナリオ

Zhuxiaobang は典型的な読み取りと書き込みの混合シナリオです。毎日 18:00 ～ 22:00 がピーク時間帯です。この期間中、インポートレートは 460% 増加し、クエリ QPS は 300% 増加します。クリプトンは読み取り図 16 に示すように、書き込み分離アーキテクチャでは、クエリ P99 のレイテンシはピーク期間中にあまり変化せず、60 ミリ秒以内に留まります。

要約する

クリプトンの設計、開発、打ち上げのプロセス全体を通じて、私たちは多くの有益な経験を学びました。

クリプトン社のビジネス関係者のほとんどは以前はドリスを使用しており、ドリスを取り巻く環境に優しいツールも比較的充実しています。したがって、インターフェイスレベルとデータモデルは Doris と完全に互換性があると最初から決めていました。そのおかげで、後続のユーザーはDorisから移行する際に特に大きな抵抗を受けることはなく、以前のエコシステムの一部も引き続き利用できるようになりました。
ユーザーシナリオで最適化の機会を見つけます。たとえば、一部のユーザーは QPS が高いことがわかりましたが、クエリモードは基本的に固定されていますが、一部のフィルタリング条件が異なります。このとき、Result/Plan Cache が大きな役割を果たしています。圧縮をサポートする WAL や完全非同期書き込みリンクなど、高速書き込みシナリオで大きな役割を果たすテクノロジーもあります。
オンライントラフィックでテストします。クリプトンは非常に複雑なシステムであり、ユーザーは新しいシステムの安定性について懐疑的なことがよくあります。そこで、オンライントラフィック用のデュアル読み取りおよびデュアル書き込みフレームワークを開発し、グレースケールのオンライントラフィックは Krypton に送信され、システムが安定して動作した後にトラフィックが切り替えられます。