300万語！ネットワーク全体で最も完全なビッグデータ学習インタビューコミュニティがあなたを待っています!

ユーザー規模の急速な拡大に伴い、企業内で統合分析基盤を構築するためにApache Dorisを利用するユーザーが増えている一方で、Apache Dorisには大規模なビジネスを含むより大きなビジネス規模の処理や分析を行うことが求められています。一方で、これまでの統計レポート、アドホッククエリ、インタラクティブ分析などの典型的なOLAPシナリオから、レコメンデーション、リスクコントロールなど、より多くのビジネスシーンへの拡大など、企業のより多様なデータ分析需要に応える必要があることも意味しています。、タグポートレート、IoT、データサービス (Data Serving) は代表的な要件の 1 つです。

データサービスとは通常、ユーザーまたは企業顧客にデータアクセスサービスを提供することを指します。ユーザーがより頻繁に使用するクエリモードは、キーに従って 1 つ以上のデータ行をクエリすることです。次に例を示します。

注文内容照会
商品詳細のお問い合わせ
物流状況照会
お取引内容照会
ユーザー情報の問い合わせ
ユーザーのポートレート属性のクエリ
...

大規模なデータのスキャンと計算を目的としたアドホックとは異なり、データサービングは通常、実際のビジネスでは同時実行ポイントの高いクエリとして表されます。クエリによって返されるデータの量は少なく、通常は 1 行または少数のデータのみです。のデータ行が返されますが、クエリを使用するため、時間に非常に敏感で、ミリ秒以内にクエリ結果を返すことが期待されており、超高同時実行性という課題に直面しています。

以前は、このようなビジネス要件に直面した場合、通常、対応するクエリアクセスを実行するためにさまざまなシステムコンポーネントが使用されていました。OLAP データベースは通常、列指向ストレージエンジンに基づいて構築されており、ビッグデータシナリオ向けに設計されたクエリフレームワークです。システム機能は通常、データスループットによって測定されます。そのため、データサービングの同時実行性の高いポイントクエリシナリオのパフォーマンスは、多くの場合それほど良くありません。ユーザーの期待として。これに基づいて、ユーザーは通常、ポイントクエリを処理するために Apache HBase などの KV システムを導入し、高い同時実行性によって引き起こされるシステムの負荷を共有するためにキャッシュレイヤーとして Redis を導入します。ただし、このようなアーキテクチャは複雑であることが多く、ストレージの冗長化やメンテナンスコストの高さといった問題があります。

統合分析パラダイムの統合により、Apache Doris が実行できるワークロードに課題が生じました。また、このようなシナリオでユーザーのビジネスニーズをより適切に満たす方法について、より体系的に考えることができるようになりました。上記の考慮事項に基づいて、次期バージョン 2.0 では、オリジナルの機能に基づいた一連のポイント指向のクエリ最適化手法を導入し、単一ノードで数万 QPS の超高同時実行に達することができ、大幅に拡張されます。適用可能なシナリオの能力境界。

# 同時実行クエリ数が多い場合はどのように対処すればよいでしょうか?

高い同時実行性は、常に Apache Doris の利点の 1 つです。同時実行性の高いクエリの場合、中核となるのは、限られたシステムリソースの消費と同時実行によって生じる高負荷のバランスをとる方法です。つまり、単一の SQL 実行時の CPU、メモリ、IO のオーバーヘッドを最小限に抑える必要があります。重要なのは、基になるデータのスキャンとその後のデータ計算を減らすことにあります。主な最適化方法は次のとおりです。

パーティションバケットのプルーニング

Apache Doris は 2 レベルのパーティション分割を採用しており、最初のレベルはパーティションであり、通常は時間をパーティションキーとして使用できます。2 番目のレベルはバケットで、読み取りの並列性を向上させ、読み取りスループットをさらに向上させるために、ハッシュを通じてデータを各ノードに分散します。バケットを合理的に分割することでクエリのパフォーマンスを向上させることができます。例として次のクエリステートメントを取り上げます。

select * from user_table where id = 5122 and create_date = '2022-01-01'

ユーザーはcreate_time、ID をパーティションキーとして、ID をバケットキーとして使用し、10 個のバケットを設定し、パーティション分割とバケット化を行った後、不要なパーティションデータをすばやくフィルタリングし、最後に少量のデータのみを読み込むだけで済みます。 1 つのパーティションの 1 つのバケットなど、バケットはクエリ結果をすばやく見つけて、スキャンされるデータの量と 1 つのクエリの遅延を最小限に抑えることができます。

索引

Doris は、パーティショニング、バケット化、プルーニングに加えて、データの読み取りとフィルタリングを高速化するための豊富なインデックス構造も提供します。インデックスの種類はスマートインデックスとセカンダリインデックスに大別され、スマートインデックスは Doris データの書き込み時にユーザーの介入なしに自動的に生成されます。

スマートインデックスには、プレフィックスインデックスとゾーンマップインデックスが含まれます。

接頭辞スパースインデックス (ソートされたインデックス) は、ソートされた構造に基づいて構築されたインデックスです。Doris によってファイルに保存されたデータは、ソート列に従って順番に保存され、Doris はソートされたデータに対して 1024 行ごとにスパースインデックスアイテムを作成します。インデックスのキーは、現在の 1024 行の最初の行のプレフィックスソート列の値です。ユーザーのクエリ条件にこれらのソート列が含まれる場合、プレフィックススパースインデックスを通じて開始行をすぐに見つけることができます。
ZoneMap インデックスは、セグメントレベルとページレベルで構築されるインデックスです。ページ内の各列の最大値と最小値が記録され、同様にセグメントレベルでも各列の最大値と最小値が記録されます。このようにして、同等のクエリまたは範囲クエリを実行するときに、MinMax インデックスを使用して、読み取る必要のない行を迅速に除外できます。

セカンダリインデックスは、ブルームフィルターインデックス、ビットマップインデックス、バージョン 2.0 で新しく追加された反転反転インデックスと NGram ブルームフィルターインデックスなど、手動で作成する必要があるインデックスです。ここでは詳しく説明しませんが、次のことを学ぶことができます。最初に公式ウェブサイトのドキュメントからそれを参照し、その後に解釈のための一連の記事があります。

公式ウェブサイトのドキュメント:

逆索引: https://dris.apache.org/zh-CN/docs/dev/data-table/index/inverted-index
NGram BloomFilter インデックス: https://dris.apache.org/zh-CN/docs/dev/data-table/index/ngram-bloomfilter-index

例として次のクエリを考えてみましょう。

select * from user_table where id > 10 and id < 1024

テーブル作成時に指定したキーとしてIDを指定すると、MemtableとディスクがIDに従って整然と整理され、クエリ時にフィルター条件にプレフィックスフィールドが含まれる場合、プレフィックスインデックスを使用できます素早くフィルタリングします。主要なクエリ条件はストレージ層で複数の Range に分割され、プレフィックスインデックスに従って二分探索が実行され、対応する行番号の範囲が取得されますが、プレフィックスインデックスはスパースであるため、大まかな移動範囲しか特定できません。次に、ZoneMap、Bloom Filter、Bitmap などのインデックスを使用して、スキャンする必要がある行の数をさらに減らします。インデックス作成により、スキャンする必要がある行の数が大幅に減り、CPU と IO への負荷が軽減され、システム全体の同時実行能力が大幅に向上します。

マテリアライズドビュー

マテリアライズドビューは、空間を時間に交換するという典型的なアイデアであり、その本質は、事前定義された SQL 分析ステートメントに基づいて事前計算を実行し、計算結果をユーザーには透過的だが実際のストレージを持つ別のテーブルに永続化することです。集計データと詳細データを同時にクエリする必要があり、異なるプレフィックスインデックスを照合する必要があるシナリオでは、マテリアライズドビューに到達したときにより高速なクエリ応答を取得でき、オンサイトで大量の計算を実行できます。回避できるため、パフォーマンスが向上し、リソースの消費が削減されます。

// 对于聚合操作， 直接读物化视图预聚合的列
create materialized view store_amt as select store_id, sum(sale_amt) from sales_records group by store_id;
SELECT store_id, sum(sale_amt) FROM sales_records GROUP BY store_id;

// 对于查询， k3满足物化视图前缀列条件， 走物化视图加速查询
CREATE MATERIALIZED VIEW mv_1 as SELECT k3, k2, k1 FROM tableA ORDER BY k3;
select k1, k2, k3 from table A where k3=3;

ランタイムフィルター

クエリデータのフィルタリングを高速化するための上記のインデックスに加えて、Doris は動的フィルタリングメカニズム、つまりランタイムフィルタも追加しました。マルチテーブル関連付けクエリでは、通常、右側のテーブルを BuildTable、左側のテーブルを ProbeTable と呼びますが、左側のテーブルのデータ量は右側のテーブルのデータ量よりも多くなります。実装に関しては、最初に右のテーブルのデータが読み取られ、メモリ上に HashTable (Build) が構築されます。次に、左側のテーブルの各行のデータの読み取りを開始し、HashTable で接続マッチングを実行して、接続条件を満たすデータ (プローブ) を返します。ランタイムフィルターは、右側のテーブルでハッシュテーブルを構築する際に、接続列のフィルター構造を生成します。これには、最小/最大、IN、その他のフィルター条件を指定できます。次に、フィルター列構造を左側のテーブルにプッシュダウンします。このようにして、左側のテーブルはこのフィルタリング構造を使用してデータをフィルタリングすることができるため、プローブノードが送信および比較する必要があるデータの量が削減されます。ほとんどの結合シナリオでは、ランタイムフィルターは自動ノードペネトレーションを実現し、フィルターペネトレーションを最下位のスキャンノードまたは分散シャッフル結合にプッシュダウンできます。

関連するクエリランタイムフィルターのほとんどは、データ読み取りの影響を大幅に軽減できるため、クエリ全体が高速化されます。

TOPN最適化テクノロジー

特定の条件が満たされた場合に最後の 100 個のデータをクエリする、複数の商品の最高または最低価格をクエリするなど、データベース内の最大または最小のデータをクエリするための幅広いアプリケーションシナリオがあります。パフォーマンスこのようなクエリをどのように分析するかは、リアルタイム分析にとって非常に重要です。TOPN 最適化は、ビッグデータシナリオにおける高い IO、CPU、メモリリソースの消費を解決するために Doris に導入されました。

まず、スキャナー層からソートフィールドとクエリフィールドを読み取り、ヒープソートを使用して TOPN 個のデータを保持し、現在既知の最大または最小のデータ範囲をリアルタイムで更新し、動的にスキャナーにプッシュダウンします。
スキャナー層はインデックスを使用して、範囲条件に応じてファイルとデータブロックのスキップを高速化し、読み取られるデータ量を大幅に削減します。
幅の広いテーブルでは、ユーザーは通常、多数のフィールドをクエリする必要があります。TOPN シナリオでは、実際に有効なデータは N 個だけです。読み取りを 2 つの段階に分割することで、最初の段階では少数のフィールドに基づいて行番号を見つけます。列と条件列のソートとソートの第 2 段階では、ソートと TOPN の結果に従って、行番号逆引きクエリデータを取得でき、スキャンのオーバーヘッドを大幅に削減できます。

上記の一連の最適化手法により、不要なデータを削除し、読み取ってソートするデータ量を削減し、システム IO、CPU、メモリリソースの消費を大幅に削減できます。さらに、SQL キャッシュ、パーティションキャッシュ、結合の最適化メソッドなどのキャッシュメカニズムを使用して同時実行性をさらに向上させることもできますが、スペースの都合上、ここでは詳しく説明しません。

# Apache Doris 2.0 の新機能が明らかに

前の段落で紹介した内容を通じて、Apache Doris は単一ノード上で数千の QPS の同時サポートを実現しました。ただし、超高同時実行要件 (数万 QPS など) を伴う一部のデータサービスシナリオでは、依然としてボトルネックが存在します。

列指向ストレージエンジンは行レベルのデータの読み取りには適しておらず、ワイドテーブルモデルの列指向ストレージ形式はランダム読み取り IO を大幅に増幅します。
OLAP データベースの実行エンジンとクエリオプティマイザーは、一部の単純なクエリ (ポイントクエリなど) には重すぎるため、そのようなクエリを処理するにはクエリプランニングで短いパスを計画する必要があります。
SQL リクエストへのアクセスとクエリプランの解析と生成は、Java 言語を使用する FE モジュールによって処理されます。同時実行性の高いシナリオで多数のクエリ実行プランを解析して生成すると、CPU オーバーヘッドが高くなります。
……

上記の問題を念頭に置いて、Apache Doris は、SQL メモリ IO オーバーヘッドの削減、クエリ実行効率の向上、SQL 解析オーバーヘッドの削減という 3 つの設計ポイントに基づいて一連の最適化を実行します。

行ストア形式

列指向のストレージ形式とは異なり、行ベースのストレージ形式はデータサービスシナリオでより使いやすいです。データは行に格納され、一度にデータ行全体を取得する方が効率的であり、データ数を大幅に削減できます。ディスクアクセスの数。したがって、Apache Doris バージョン 2.0 では、行ストレージをエンコードして別の列に格納し、追加のスペースに格納する行ストレージ形式を導入しました。ユーザーは、テーブル作成ステートメントのプロパティで次のプロパティを指定して、行ストレージを有効にすることができます。

"store_row_column" = "true"

主に次の考慮事項により、行ストレージのエンコード形式として JSONB を選択します。

スキーマの変更は柔軟です。データが変更されると、それに応じてテーブルのスキーマも変更される可能性があります。行ストレージ形式がこれらの変更を処理する柔軟性を提供することは非常に重要です。たとえば、ユーザーがフィールドを削除したり、フィールドタイプを変更したりする場合、データの変更は適時に行ストレージに同期される必要があります。エンコード方式として JSONB を使用し、列を JSONB フィールドとしてエンコードすると、フィールドの拡張や属性の変更が非常に便利になります。
パフォーマンスの向上: 行ストア形式での行へのアクセスは、データが単一行に格納されるため、列ストア形式よりも高速になります。これにより、同時実行性が高いシナリオでのディスクアクセスのオーバーヘッドを大幅に削減できます。さらに、各列 ID を JSONB 内の対応する値にマッピングすることで、個々の列への高速アクセスを実現できます。
ストレージスペース: 行ストレージ形式としての JSONB のコーデックも、ディスクストレージコストの削減に役立ちます。コンパクトなバイナリ形式では、ディスクに保存されるデータの合計サイズを削減できるため、コスト効率が高くなります。

JSONB エンコードおよびデコード行ストレージ形式を使用すると、同時実行性の高いシナリオで直面するパフォーマンスとストレージの問題を解決できます。行はストレージエンジンの非表示列 ( )DORIS_ROW_STORE_COLとして保存され、Memtable フラッシュ中に各列が JSONB でエンコードされ、この非表示列にキャッシュされます。データを読み取るときは、列 ID で列を特定し、行番号で特定の行を特定し、各列を逆シリアル化します。

関連PR: https://github.com/apache/dris/pull/15491

ポイントクエリのショートパス最適化（ショートサーキット）

通常、SQL ステートメントの実行には 3 つのステップを経る必要があります。まず、SQL パーサーによってステートメントを解析し、抽象構文ツリー (AST) を生成し、次にクエリオプティマイザーによって実行可能プラン (Plan) を生成し、最後に計算を取得します。計画を実行することによって結果が得られます。大量のデータを含む複雑なクエリの場合、クエリオプティマイザーによって生成された実行プランは間違いなくより効率的な実行効果をもたらしますが、待ち時間が短く同時実行性の要件が高いポイントクエリの場合、クエリオプティマイザーの最適化プロセスを経るのは適していません。クエリオプティマイザー全体で、不必要な追加のオーバーヘッドが発生します。

この問題を解決するために、クエリオプティマイザーと PlanFragment をバイパスして SQL 実行プロセスを簡素化し、高速かつ効率的な読み取りパスを直接使用して必要なデータを取得する、ポイントクエリのショートパス最適化を実装しました。

クエリが FE によって受信されると、プランナによってポイントクエリの物理計画として適切な短絡計画が生成されます。Plan は非常に軽量であり、同等の変換、論理最適化、物理最適化を必要とせず、AST ツリー上でいくつかの基本的な分析を実行し、対応する固定プランを構築し、オプティマイザーのオーバーヘッドを削減するだけです。

たとえば、単純なプライマリキーポイントクエリの場合、select * from tbl where pk1 = 123 and pk2 = 456単一のタブレットのみが関与するため、軽量の RPC インターフェイスを使用して StorageEngine と直接対話できるため、複雑なフラグメントプランの生成が回避され、MPP クエリフレームワークのパフォーマンスに基づいてスケジューリングを実行する必要がなくなります。オーバーヘッド。RPC インターフェースの詳細は次のとおりです。

message PTabletKeyLookupRequest {
    required int64 tablet_id = 1;
    repeated KeyTuple key_tuples = 2;
    optional Descriptor desc_tbl = 4;
    optional ExprList  output_expr = 5;
}

message PTabletKeyLookupResponse {
    required PStatus status = 1;
    optional bytes row_batch = 5;
    optional bool empty_batch = 6;
}
rpc tablet_fetch_data(PTabletKeyLookupRequest) returns (PTabletKeyLookupResponse);

上記の table_id は、主キーの文字列形式である主キー条件列から計算されます。key_tuples上記の例では、key_tuples['123', '456'] に似ており、主キーのストレージとしてエンコードされます。 key_tuplesBE がリクエストを受信した後、主キーインデックスに従ってセグメントファイル内のキーの行番号を識別し、対応する行がその中にあるかどうかを確認しdelete bitmap、存在する場合はその行番号を返し、存在しない場合は返しますNotFound。この行番号は、__DORIS_ROW_STORE_COL__列に対して直接ポイントクエリを実行するために使用されます。そのため、必要なのは、その列内の行を見つけて、生の値を JSONB 形式で取得し、後続の出力関数によって計算された値として逆シリアル化することだけです。

関連PR: https://github.com/apache/dris/pull/15491

プリペアドステートメントの最適化 (PreparedStatement)

同時実行性の高いクエリの CPU オーバーヘッドは、FE 層の分析と SQL 解析のための CPU 計算に部分的に起因する可能性があります。この問題を解決するために、FE 側で MySQL プロトコルと完全に互換性のあるプリペアドステートメント (Prepared Statements) を提供します。CPU が主キー列挙のパフォーマンスのボトルネックになった場合、Prepared Statement が効果的に役割を果たし、4 倍を超えるパフォーマンスの向上を実現します。

Prepared Statement の動作原理は、事前に計算された SQL と式をセッションメモリのハッシュマップにキャッシュし、キャッシュされたオブジェクトを後続のクエリで直接再利用することです。

Prepared Statement は、トランスポートプロトコルとしてMySQL バイナリプロトコル(https://dev.mysql.com/doc/dev/mysqlserver/latest/page_protocol_binary_resultset.html#sect_protocol_binary_resultset_row) を使用します。プロトコルはmysql_row_buffer.[h|cpp] ファイルに実装されており、標準の MySQL バイナリエンコーディングに準拠しています。JDBC クライアントなどのこのプロトコルクライアントを通じて、最初の段階でPREPAREMySQL コマンドを送信して、プリコンパイルされたステートメントを FE に送信し、FE が解析し、ステートメントを分析してキャッシュします。それを上図の HashMap に変換すると、クライアントはEXECUTEMySQL コマンドを使用してプレースホルダーを置き換え、バイナリ形式にエンコードして FE に送信します。このとき、FE は MySQL プロトコルに従ってデシリアライズして、プレースホルダー内の値を取得します対応するクエリ条件を生成します。

FE でステートメントをキャッシュすることに加えて、事前に割り当てられた計算ブロック、クエリ記述子、出力式など、再利用された構造を BE でキャッシュする必要もあります。これらの構造はシリアル化および逆シリアル化中に CPU ホットスポットを引き起こすため、これらの構造はキャッシュされた。クエリされた PreparedStatement ごとに、CacheID と呼ばれる UUID が付加されます。BE がポイントクエリを実行すると、関連する CacheID に従って対応する再利用クラスが検索され、BE で式を計算および実行するときに上記の構造が再利用されます。

JDBC で PreparedStatement を使用する例を次に示します。

1. JDBC URLを設定し、サーバー側でPreparedStatementを有効にします。

url = jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true

2. 準備済みステートメントの使用

// use `?` for placement holders, readStatement should be reused
PreparedStatement readStatement = conn.prepareStatement("select * from tbl_point_query where key = ?");
...
readStatement.setInt(1234);
ResultSet resultSet = readStatement.executeQuery();
...
readStatement.setInt(1235);
resultSet = readStatement.executeQuery();
...

関連PR: https://github.com/apache/dris/pull/15491

ラインキャッシュ

Doris にはページレベルのキャッシュがあり、各ページには特定の列のデータが格納されるため、ページキャッシュは列のキャッシュです。

上記の行キャッシュは、行に複数列のデータが含まれており、大規模なクエリによってキャッシュがフラッシュされる可能性があるため、行キャッシュのヒット率を高めるためには、別途行キャッシュ(Row Cache)を導入する必要があります。。

ラインキャッシュは、Doris の LRU キャッシュメカニズムを再利用します。メモリしきい値は起動時に初期化され、メモリしきい値を超えると古いキャッシュラインが削除されます。主キーのクエリステートメントの場合、ストレージレイヤー上の行キャッシュにヒットする場合とヒットしない場合との間には、数十倍のパフォーマンスギャップ (ディスク IO とメモリアクセスの間のギャップ) が存在する可能性があるため、行キャッシュを導入すると、ポイントクエリのパフォーマンスが大幅に向上します(特にキャッシュヒットが多いシナリオで)。

ラインキャッシュを有効にするには、BE で次の設定項目を設定して有効にします。

disable_storage_row_cache=false //是否开启行缓存， 默认不开启
row_cache_mem_limit=20% // 指定row cache占用内存的百分比， 默认20%内存

関連PR: https://github.com/apache/dris/pull/15491

＃基準

上記の一連の最適化に基づいて、データ提供シナリオにおける Apache Doris のパフォーマンスがさらに向上しました。Yahoo! Cloud Serving Benchmark (YCSB) の標準パフォーマンステストツールに基づいてベンチマークテストを実施しました。環境構成とデータ規模は次のとおりです。

マシン環境: シングル 16 コア 64G メモリ 4*1T ハードディスククラウドサーバー
クラスターサイズ: 1 FE + 3 BE
データ規模: 合計 1 億個のデータ (1 行あたり平均約 1K) がテスト前にウォームアップされました。
対応するテストテーブルの構造とクエリステートメントは次のとおりです。

// 建表语句如下：

CREATE TABLE `usertable` (
  `YCSB_KEY` varchar(255) NULL,
  `FIELD0` text NULL,
  `FIELD1` text NULL,
  `FIELD2` text NULL,
  `FIELD3` text NULL,
  `FIELD4` text NULL,
  `FIELD5` text NULL,
  `FIELD6` text NULL,
  `FIELD7` text NULL,
  `FIELD8` text NULL,
  `FIELD9` text NULL
) ENGINE=OLAP
UNIQUE KEY(`YCSB_KEY`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`YCSB_KEY`) BUCKETS 16
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"in_memory" = "false",
"persistent" = "false",
"storage_format" = "V2",
"enable_unique_key_merge_on_write" = "true",
"light_schema_change" = "true",
"store_row_column" = "true",
"disable_auto_compaction" = "false"
);

// 查询语句如下：

SELECT * from usertable WHERE YCSB_KEY = ?

最適化を有効にした場合 (つまり、ラインストレージ、ショートパス、および PreparedStatement を同時にチェックした場合) と有効にしていない場合のテスト結果は次のとおりです。

上記の最適化項目を有効にした後、平均クエリ時間消費量は 96% 削減され、99 パーセンタイルのクエリ時間消費量は前のクエリ時間のわずか 1/28 になりました。QPS 同時実行数は1400 から 3w に増加し、さらに増加しました。全体的なパフォーマンスと同時負荷の実現データは、飛躍的な進歩を遂げました。

＃ベストプラクティス

現在の段階で実装されているポイントクエリの最適化はすべて Unique Key 主キーモデルで実行され、使用前に Merge-on-Write と Light Schema Change を有効にする必要があることに注意してください。ポイントクエリシナリオのテーブル作成ステートメント:

CREATE TABLE `usertable` (
  `USER_KEY` BIGINT NULL,
  `FIELD0` text NULL,
  `FIELD1` text NULL,
  `FIELD2` text NULL,
  `FIELD3` text NULL
) ENGINE=OLAP
UNIQUE KEY(`USER_KEY`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`USER_KEY`) BUCKETS 16
PROPERTIES (
"enable_unique_key_merge_on_write" = "true",
"light_schema_change" = "true",
"store_row_column" = "true",
);

知らせ：

オンにする
light_schema_change
JSONB 行ストレージエンコーディングをサポートするには ColumnID
store_row_column を有効にする
行フォーマットを保存するには

テーブル作成操作の完了後、行の格納形式とショートパスの実行により、次のような主キーに基づくクエリ SQL のパフォーマンスが大幅に向上します。

select * from usertable where USER_KEY = xxx;

同時に、JDBC のプリペアドステートメントを通じてポイントクエリのパフォーマンスをさらに向上させることができます。十分なメモリがある場合は、BE 構成ファイルでラインストレージキャッシュを有効にすることもできます。使用例は上に示したので、ここでは繰り返しません。

# 要約する

行ベースのストレージ形式、ポイントクエリのショートパス最適化、プリペアドステートメント、および行ストアキャッシュを導入することで、Apache Doris はノードあたり数万 QPS という超高同時実行性を実現し、数十倍のパフォーマンス向上を達成しました。クラスター規模の水平方向の拡張とマシン構成の改善により、Apache Doris はハードウェアリソースを使用してコンピューティングの高速化を実現することもでき、独自の MPP アーキテクチャーも水平方向および線形に拡張する機能を備えています。したがって、Apache Doris は、単一のアーキテクチャの下で高スループットの OLAP 分析と同時実行性の高いデータ提供オンラインサービスを同時に満たす能力を真に備えており、混合ワークロードの下で技術アーキテクチャを大幅に簡素化し、複数のシナリオ。

上記の機能の実現は、Apache Doris コミュニティの開発者の共同の努力と、SelectDB エンジニアの継続的な貢献の恩恵を受けており、現在本格的にリリースが進められており、近い将来バージョン 2.0 がリリースされる予定です。

この記事が参考になったら「いいね」 「いいね」 「お気に入り」を3回忘れずに！