製品FAQ

プロダクトアーキテクチャと特徴に関するFAQ

インスタンスは1つ必要ですか、それとも複数必要ですか？

複数のサブシステムがあり、各サブシステム間でデータベースレベルでの相互作用がない場合、各サブシステムごとに異なるインスタンスを使用することを推奨します。

ユーザーはOceanBaseデータベースをどのように利用しますか？

従来のデータベースと同様に、OceanBaseデータベースはSQLインターフェースを提供しており、ユーザーはSQL言語を使用してデータベースにアクセスし、操作を実行できます。

OceanBaseデータベースはJPAと競合しますか？

JPA（Java Persistence API）は、Java標準におけるORM仕様の一つです。JPA技術を利用すると、アノテーションやXMLを用いてオブジェクトとリレーショナルテーブル間のマッピング関係を記述し、エンティティオブジェクトをデータベースに永続化することができます（Object ModelとData Model間のマッピングを実現）。一方、OceanBaseデータベースは、AlibabaとAnt Groupが任意のオープンソース製品に依存せず、完全に独自開発したネイティブ分散型リレーショナルデータベースソフトウェアです。両者は競合するものではありません。

データファイルはどのレベルのデータベース管理に対応していますか？

OceanBaseデータベースでは現在、2種類のデータファイルがあり、どちらのファイルもクラスタレベルに属します。

• Dataファイル：各パーティションのデータを保存し、各パーティションのチェックポイントも含まれます。
• clog関連：clog（Redo LogまたはWALログとも呼ばれる）とそのインデックスファイルを含みます。

OceanBaseデータベースはHTAPをどのようにサポートしていますか？

OceanBaseデータベース独自の分散コンピューティングエンジンにより、システム内の複数のコンピューティングノードがOLTP型アプリケーションと複雑なOLAP型アプリケーションを同時に実行できるようになりました。これにより、単一のコンピューティングエンジンで混合ワークロードを同時にサポートする能力が実現され、ユーザーは単一のシステムで80%の問題を解決できます。これにより、ユーザーのコンピューティングリソースを最大限に活用し、追加のハードウェアリソースやソフトウェアライセンスの購入に伴うコストを削減できます。

インスタンスとテナントとは何ですか？ その関係はどのようなものですか？

OceanBaseデータベースはマルチテナントシステムです。1つのインスタンスは、OceanBaseクラスタ内の1つのテナントに相当します。テナント間ではデータに相互にアクセスすることはできません。

OceanBaseデータベースの性能とマシン台数の関係はどのようなものですか？

OceanBaseデータベースのTPC-Cレポートによると、同じシナリオでは基本的に線形スケーリングが示されています。

OceanBaseデータベースを使用した開発において、特に注意すべき点は何ですか？

以下は開発プロセスにおける注意事項です。参考までにご覧ください。

• 大量データのインポートでは、メモリ使用状況に特に注意する必要があります。
• インデックスの反映には時間がかかるため、テーブル作成時にインデックス文を一緒に含めることを推奨します。
• mysql-connector-javaのバージョンは5.1.30以降を推奨します。
• 列型の変更には大きな制限があります。Varchar型の長さは短くすることは可能ですが、長くすることはできません。
• 接続が15分以上アイドル状態の場合、サーバー側が自動的に切断します。接続プールを使用する際には、接続の最大アイドル時間を設定する必要があります。例えば、DruidのminEvictableIdleTimeMillisを15分未満に設定します。

OceanBaseデータベースは、なぜ従来のデータベースよりもスペース効率が優れていますか？

OceanBaseデータベースは、データエンコーディング圧縮技術により高い圧縮率を実現しています。データエンコーディングは、データベースのリレーショナルテーブルにおける異なるフィールドの値域と型情報に基づいて生成される一連のエンコーディング方式であり、一般的な圧縮アルゴリズムよりもデータを深く理解しているため、より高い圧縮効率を実現できます。

OceanBaseデータベースのAP機能で処理できるデータ量は、おおよそどの程度ですか？

具体的なデータ量は業務要件によって異なり、100GBからPBレベルまで無制限です。APはOceanBaseデータベースが提供する機能の一つです。データ量が少ない場合は並列数を小さく設定し、使用する計算リソースを抑えます。データ規模が大きい場合は、計算リソースを多めに設定します。本質的に量的な制限はありません。AP機能の能力は、主にマシンのハードウェアリソースを十分に活用する能力や、効率的な並列計画を生成する能力などに体現されています。

OceanBaseデータベースの最新バージョンにおける標準SQLのサポートレベルはどの程度ですか？

実際のアプリケーションシナリオでは、MySQLモードのほとんどの業務はスムーズに移行できます。Oracleモードでは基本的なOracle機能もサポートされており、わずかな変更でOracleデータベースからOceanBaseデータベースへのスムーズな移行が可能です。

以前MySQL上で稼働していた業務をOceanBaseデータベースに移行するコストはどのようなものですか？

OceanBaseデータベースは、一般的なMySQL機能およびMySQLのプロキシ/クライアントプロトコルと互換性があります。業務を一切変更するか、わずかに変更するだけで、MySQLからOceanBaseデータベースへ移行できます。

TPを得意とするデータベースとして、OceanBaseデータベースのAP計算能力はどのようなものですか？

APでは主に行列混合ストレージ、コンパイル実行、ベクトルエンジン、コストベースのクエリリライトおよび最適化などの技術が採用されています。さらに、OceanBaseデータベースの優れた拡張性により、AP分野におけるリアルタイム分析能力は業界をリードしています。また、オフラインのビッグデータ処理については、Sparkなどのビッグデータソリューションの方が適しています。

分散型データベースとして、OceanBaseデータベースに業務APPが接続する際、従来のデータベースとは異なりますか？

OceanBaseデータベースは分散型データベースとして、レプリカが異なるマシンに分散配置される可能性があります。マシン間のデータアクセスを可能な限り削減するため、OceanBaseデータベースはobproxyを提供しています。obproxyは、OceanBase分散リレーショナルデータベース専用のリバースプロキシサーバーとして、フロントエンドユーザーのリクエストに対して高性能で高精度のルーティング転送サービスを提供し、バックエンドServerサービスに高可用性で拡張性のある災害復旧保証を提供します。他のデータベースのプロキシサーバーと比較して、obproxyは実際の単一マシン環境とOceanBaseのマルチクラスタデプロイメントの特性に基づき、非同期フレームワークとストリーミング転送の設計を採用し、FastParseとLockFreeのメモリソリューションを採用しています。これにより、限られたリソース使用状況下での百万QPSの能力と、大量デプロイメント下での豊富で便利な運用保守サポート能力を備えています。

OceanBaseデータベースの技術アーキテクチャにはどのような技術的特徴がありますか？

OceanBaseデータベースは、ネイティブ分散型データベースとして、以下の技術的特徴を備えています：

• エラスティックスケーリング

  OceanBaseデータベースはオンラインでのエラスティックスケーリングをサポートしています。クラスタのストレージ容量や処理能力が不足した場合、いつでも新しいOBServerを追加でき、システムは自動的にデータ移行を行い、マシンの処理能力に応じて適切なデータパーティションを新しく追加されたマシンに移行します。同様に、システムの容量が十分で処理能力に余裕がある場合は、マシンをオフラインにしてコストを削減することもできます。例えば、ダブル11の大規模セールなどのイベントでは、優れた弾性スケーリング能力を発揮できます。

• ロードバランシング能力

  OceanBaseデータベースは、多数のOBServerノードを管理して1つのOBServerクラスタを形成し、複数のテナントにデータサービスを提供します。OceanBaseクラスタが管理するすべてのOBServerノードは、巨大な「リソースケーキ」と見なすことができます。リソース割り当て時には、テナント作成時に申請されたリソースに応じて必要に応じて配分されます。OceanBaseデータベースのロードバランシング能力により、複数のテナントがOceanBaseクラスタ全体で申請するリソースの使用量が相対的に均等に保たれ、動的なシナリオ（例えば、OBServerの追加・削除、テナントの追加・削除、増減過程でのパーティションデータ量の偏りなど）でも、ロードバランシングアルゴリズムは既存ノード上でリソースを均衡させることができます。

  OceanBaseデータベースはRoot Serviceを通じて各ノード間のロードバランシングを管理します。異なるタイプのレプリカはそれぞれ異なるリソースを必要とするため、Root Serviceがパーティション管理操作を実行する際に考慮する要素には、各OBServerノード上のCPU、ディスク使用量、メモリ使用量、IOPSの使用状況が含まれます。これにより、同一テーブルのパーティションが少数のOBServerに集中するのを防ぎます。また、メモリ消費量の多いレプリカと少ないレプリカを同一マシン上に配置することを避け、ディスク容量を多く消費するレプリカと少ないレプリカも同一マシン上に配置することを避けます。ロードバランシングを経て、最終的にはすべてのマシンの各種リソース使用量が比較的均衡した状態になり、各マシンの全リソースが最大限に活用されます。

• 分散トランザクションのACID能力

  OceanBaseデータベースアーキテクチャにおけるトランザクションのACID実装方法は以下の通りです：

  • 原子性：2段階コミットを使用して、スナップショットトランザクションの原子性を保証します。
  • 一貫性：トランザクションの一貫性を保証します。
  • 分離性：マルチバージョンメカニズムを使用して並行制御を行います。
  • 永続性：トランザクションログはPaxosプロトコルを使用してマルチレプリカ同期を行います。

• 高可用性

  OceanBaseデータベースでは、各パーティションに複数のレプリカが維持されており、これらのパーティションの複数レプリカ間ではPaxosプロトコルを用いてログが同期されます。各パーティションとそのレプリカは独立したPaxosグループを構成し、そのうち1つのレプリカがリーダー（Leader）、他のレプリカがフォロワー（Follower）となります。各OBServerサーバーでは、一部のパーティションがリーダー、一部のパーティションがフォロワーとなります。OBServerノードに障害が発生した場合、フォロワーパーティションは影響を受けませんが、リーダーパーティションの書き込みサービスは短時間影響を受けます。これは、Paxosプロトコルによってそのパーティションのフォロワーのうち1つを新しいリーダーとして選出されるまでの間です。このプロセスは30秒を超えません。Paxosプロトコルを導入することで、データの強整合性を保ちながら、極めて高い可用性と性能を実現します。

  同時に、OceanBaseデータベースはプライマリ/スタンバイデータベースアーキテクチャもサポートしています。OceanBaseクラスタのマルチレプリカメカニズムは豊富な災害復旧能力を提供し、マシンレベル、データセンターレベル、都市レベルの障害状況下で自動切り替えを実現し、データ損失を防ぎます（即ちRPO = 0）。プライマリクラスタで計画的または計画外の（多数派レプリカの障害）による利用不能が発生した場合、スタンバイクラスタがサービスを引き継ぎ、無損失切り替え（RPO = 0）と損失あり切り替え（RPO > 0）の2種類の災害復旧能力を提供し、サービス停止時間を最大限に短縮します。

  OceanBaseデータベースは、1つまたは複数のスタンバイクラスタの作成、メンテナンス、管理、監視をサポートしています。スタンバイクラスタは本番データベースデータのホットバックアップです。管理者はリソース集約的なレポート操作をスタンバイクラスタに割り当てることを選択でき、システムの性能とリソース利用率を向上させることができます。

• 高効率なストレージエンジン

  OceanBaseデータベースのストレージエンジンはLSM-Treeアーキテクチャに基づいており、データはMemTable（MemStoreとも呼ばれる）とSSTableの2つの部分に分かれています。そのうちMemTableは読み書きを提供し、SSTableは読み取り専用です。ユーザーが挿入・削除・更新するデータはまずMemTableに書き込まれ、トランザクション性はRedoログによって保証されます。RedoログはPaxosプロトコルを用いて3つのレプリカ間で同期され、単一のサーバーがダウンした場合でもPaxosプロトコルによってデータの整合性が保証され、短時間の復旧時間でデータの高可用性が確保されます。

  MemTableのサイズが一定のしきい値を超えると、MemTable内のデータをMini SSTableに転送してメモリを解放する必要があります。このプロセスをMini Compactionと呼びます。ユーザーデータの書き込みに伴い、Mini SSTableの数は増え続けます。Mini SSTableの数が一定のしきい値を超えると、バックグラウンドで自動的にMinor Compactionがトリガーされます。このダンプ（Mini Compaction）により新しいMini SSTableが生成されます。ダンプ（Mini Compaction）の回数が一定のしきい値を超えた場合、または毎日の業務の閑散期に、システムはベースラインSSTable（Major SSTable）とその後のダンプによって生じた増分SSTable（Mini/Minor SSTable）を統合して新しいMajor SSTableを作成します。このプロセスをメジャーコンパクションと呼びます。OceanBaseデータベースは、ダンプとメジャーコンパクションのプロセスを通じて、データストレージ容量の基盤を最適化し、効率的な読み書きサービスを提供するとともに、トランザクション性とデータの整合性を保証します。

• マルチテナント

  OceanBaseデータベースはマルチテナントをサポートする分散型データベースであり、1つのクラスタで複数の業務システムをサポートできます。これが一般的に言われているマルチテナント機能です。

  マルチテナントアーキテクチャの利点は、システムリソースを最大限に活用できることであり、同じリソースでより多くの業務をサポートできます。ピーク時とオフピーク時の業務システムを1つのクラスタにデプロイすることで、システムリソースの最大限の利用を実現します。テナントのアプリケーション面では、テナント間の隔離性が保証されます。データセキュリティ面では、テナント間のデータアクセスが許可されないため、ユーザーのデータ資産が漏洩するリスクがありません。リソース使用面では、テナントは自身のリソースクォータを「専有」し、そのテナントに対応するフロントエンドアプリケーションは、応答時間やTPS/QPSが比較的安定しており、他のテナントの負荷の影響を受けません。

• Oracle互換性とMySQL互換性

  OceanBaseデータベースはOracle互換モードとMySQL互換モードをサポートしており、ユーザーは異なるニーズに応じてモードを選択できます。

メモリに関するFAQ

OceanBaseデータベースのメモリ領域は何ですか？

OceanBaseデータベースには主に以下のメモリ領域があります：

• kv cache：LSM-Tree内のSSTableやデータベーステーブルスキーマなどをキャッシュします。
• memory store：LSM-Tree内のMemStoreのメモリです。
• sql work area：テナントがSQLを実行する過程で各Operatorのワークエリアが占有するメモリで、これを超える分は通常ディスクプロセスへと流れます。
• system memory：Net IO、Disk IO、Election、ロードバランシングなど様々な機能のために予約されたメモリです。

OceanBaseデータベースのリソースは、テナント間で共有されるものと共有されないものは何ですか？

メモリについて言えば、sql work area、memory storeおよびkv cacheなどのリソースはテナント専用です。system memoryは複数のテナントで共有されます。スレッドについて言えば、sql workerはテナント間で分離されています。Net IO、Disk IOおよびclog Writerなどのリソースはテナント間で分離されていません。

OceanBaseデータベースのメモリ使用にはどのような特徴がありますか？

OceanBaseデータベースは起動時に約数GBのメモリをロードする必要があり、実行中は必要に応じて徐々にメモリを追加申請し、memory_limitに達します。一度OBServerノードがOSからメモリを申請すると、通常は解放されたりOSに返却されたりすることはなく、メモリ管理の使用リストとFree Listに維持されます。これはOceanBaseデータベースの設計において確立されたメモリ管理メカニズムです。

一定期間運用した後、OceanBaseデータベースの使用メモリがmemory_limitに近づいた場合、これは正常ですか？

OceanBaseデータベースのクラスタを一定期間運用した後、メモリ消費がmemory_limitの水準に近づき、低下しないのは想定通りです。

例外として、パラメータmemory_chunk_cache_sizeが設定されている場合、OBServerノードはFree Listでmemory_chunk_cache_sizeを超えるメモリブロックをOSに返却し、OceanBaseデータベース内部でのFree Listの再利用率を高め、メモリ操作の遅延によるRPCタイムアウトのリスクを低減します。通常はmemory_chunk_cache_sizeの設定は不要ですが、特定のシナリオではOceanBaseデータベースサポートと連携してシナリオ分析を行い、memory_chunk_cache_sizeの動的調整が必要かどうかを判断する必要があります。

OBServerノードのメモリ上限は動的に調整できますか？

OBServerノードのメモリ上限は、memory_limitまたはmemory_limit_percentageを調整することで動的に実現できます。調整前にはメモリリソースが十分であるか確認し、OBServerノードのメモリ上限目標がすでに全テナントおよび500テナントのメモリ割り当て（テナント作成時に割り当てられる）の合計を下回っていないことを確認する必要があります。memory_limitの単位はMBです。例えば、memory_limitパラメータを調整してOBServerノードのメモリ上限を64Gに設定するには、memory_limit ='64G'ステートメント、またはmemory_limit = 65536を使用して指定できます。

一方、OBServerノードの使用中には、memory_limitによってOBServerノードのメモリを制限する有効なパラメータが存在する可能性があります。memory_limitを0に設定すると、memory_limit_percentageを用いて比率の形でOBServerノードのメモリ使用状況をより柔軟に制約することもできます。

OceanBaseデータベースでリソースユニットおよびリソースプールを定義する際、メモリのオーバーコミットは許可されますか？

OceanBaseデータベースV4.xバージョンでは、メモリのオーバーコミットはサポートされなくなりました。メモリのオーバーコミットを導入すると、テナントの動作が不安定になる可能性があります。

OceanBaseデータベースで1回のメモリ割り当て時にはどのような制限がチェックされますか？

OceanBaseデータベースのカーネルは、1回のメモリ申請が4Gを超えないよう制限しています。この制限はユーザーには可視化されません。メモリの最適化と、カーネル内での不合理なメモリ割り当てを避けるために追加された制限です。その他、OceanBaseデータベースのカーネルでは、毎回メモリ申請時に以下のチェックが行われます。対応するエラーが発生した場合は、該当するエラーメッセージに基づいて具体的に分析してください：

OceanBaseデータベースのKVCacheにはどのようなものがあり、それぞれどのような役割を果たしますか？

OceanBaseデータベースのKVCacheはGV$OB_KVCACHEビューでクエリできます。大まかに以下の種類があります：

• BloomFilter Cache：OceanBaseデータベースのBloomFilterはマクロブロック上に構築され、必要に応じて自動的に構築されます。あるマクロブロック上の空検索回数が特定のしきい値を超えると、自動的にBloomFilterが構築され、そのBloomFilterはCacheに格納されます。
• Row Cache：具体的なデータ行をキャッシュします。Get/MultiGetクエリを実行する際、対応するデータ行をRow Cacheに格納することがよくあります。これにより、ホットスポット行のクエリ時のパフォーマンスが大幅に向上します。
• Block Index Cache：マイクロブロックのインデックスをキャッシュします。これはBtreeの中間層に似ています。中間層は通常大きくないため、Block Index Cacheのヒット率は一般的に高くなります。
• Block Cache：OceanBaseデータベースのBuffer Cacheであり、具体的なデータブロックをキャッシュします。実際にはBlock Cacheには解凍されたマイクロブロックがキャッシュされています。
• Partition Location Cache：パーティションの位置情報をキャッシュし、クエリのルーティングを支援します。
• Schema Cache：データテーブルのメタ情報をキャッシュし、実行計画の生成およびその後のクエリに使用されます。
• clog Cache：clogデータをキャッシュし、特定の状況下でのPaxosログの取得を高速化します。

KV Cacheの動的スケーリングはどのように実現されており、どのようなエージェント規則が適用されていますか？

動的にスケーラブルなメモリの大部分はKV Cacheであり、OceanBaseデータベースでは、ほとんどすべてのKV形式のキャッシュがKV Cacheに統合され、そこで管理されています。

KV Cacheは通常、設定を行う必要はありません。特殊なシナリオでは、パラメータを通じて各種KVの優先順位を制御できます。優先順位が高いKVは、優先順位が低いKVに比べてCache内に保持されやすくなります。デフォルトのKV Cache関連の優先順位の設定を調整する場合は、OceanBaseデータベースの技術サポートエンジニアにお問い合わせください。

OceanBaseデータベースのメモリに関する一般的な質問と、その可能性のある原因は何ですか？

OceanBaseデータベースのメモリに関する一般的な質問は以下のとおりです：

• ワークエリア（work area）メモリ不足エラー

  ワークエリアメモリは limit = テナントメモリ * ob_sql_work_area_percentage（デフォルト5%） です。リクエストの同時実行量が多く、かつ各リクエストが消費するワークエリアメモリが多い場合、ワークエリアメモリ不足のエラーが発生する可能性があります。頻繁に発生するシナリオには、union、sort、group byなどがあります。

  ウォークエリアのシステム変数を適切に増やすことで回避できます。例えば、set global ob_sql_work_area_percentage = 10 とします。

• モジュールのメモリ上限超過

  クライアントからエラー "Over tenant memory limits" が発生し、エラーコードは4030です。通常は、現在のメモリ消費状況をさらに分析する必要があります。

  GV$OB_MEMORY ビュー、または observer.log のログを確認することで、どのモジュールが絶対的に大きな割合のメモリを消費しているかを確認できます。

• MemStoreメモリ枯渇

  書き込み速度がダンプ速度を上回り、MemStoreが枯渇します。例えば、大量の高並行性データのインポートでは、MemStoreの書き込み操作が速すぎてシステムがタイムリーにダンプできず、MemStoreが使い果たされ、ユーザーにエラー4030が返されます。

  ダンプ速度の遅延ボトルネックを分析し、ダンプ速度を向上させるか、書き込み速度を遅らせることで、このような問題を緩和・解決できます。

• OBServerノード全体のメモリ使用量が上限を超過

  OBServerノードプロセスは起動時に、設定されたパラメータに基づいて、現在のプロセスが使用できる物理メモリの上限を計算します。memory_limit の設定値がある場合、OBServerノードのメモリは直接 memory_limit を取ります。memory_limit が0の場合は、物理メモリ * memory_limit_percentage によってメモリ使用量の上限が計算されます。

  OBServerノードのメモリ使用量が上限を超えていることが観測された場合、_all_virtual_server_stat を照会することで、実際のOBServerノード内のlimitを確認できます。その後、memory_limit、memory_limit_percentage の2つのパラメータが正しく設定されているか再度確認してください。それでもメモリが上限を超え、全体的な傾向が継続的に増加している場合は、メモリリークが発生している可能性があります。OceanBaseデータベースの技術サポートエンジニアにお問い合わせいただき、調査と解決をお願いいたします。

マルチテナントスレッド FAQ

OceanBaseデータベースは実行時にシングルプロセスかマルチプロセスか？

OceanBaseデータベースはシングルプロセスデータベースです。実行時の主要なスレッドは以下のとおりです：

• election worker：選挙スレッド。
• net io：ネットワークI/Oを処理するスレッド。
• disk io：ディスクI/Oを処理するスレッド。
• clog writer：clogを書き込むスレッド。
• misc timer：複数のバックグラウンドタイマースレッドを含み、主にリソースのクリーンアップを担当します。
• compaction worker：Minor MergeおよびMajor Mergeを処理するスレッド。
• sql worker と transaction worker：SQLおよびトランザクションリクエストを処理するスレッド。

OBServerノードにはどのようなバックグラウンドスレッドがあり、主に何をしていますか？

ほとんどの場合、ユーザーはバックグラウンドスレッドの実装詳細を気にする必要はありません。OBServerノードのバージョンアップデートに伴い、バックグラウンドスレッドも更新されることがあります。

以下に、OBServerノードの一般的なバックグラウンドスレッドとその関連機能を示します。

OBServerノードのマルチテナントアーキテクチャでは、CPUリソースの効果的な分離はどのように実現されていますか？

現在リリースされているOBServerノードでは、CPU消費は主にアクティブスレッド数（実際にCPUリソースを消費するスレッド）を制御することで管理されています。OBServerノードはテナント作成時にテナントリソースプールを指定し、リソースプールで定義された max_cpu によってテナントレベルでの最大アクティブスレッド数が制限され、これによりテナント間のCPU使用量の分離が実現されます。OBServerノードの最新バージョンでは、カーネルにcgroupのサポートが追加され、CPU、メモリ、その他のリソースを効果的に制御および制限できるようになりました。

OBServerワーカースレッドの数はどのように確認できますか？OBServerノードは負荷が高い場合、動的に新しいスレッドを起動して負荷を処理しますか？

observer.logファイル内の dump tenant info をキーワードとするログセグメントには、現在のワーカースレッドの数値とその上限値が記述されています。具体的には以下のようになります：

tocken_count = そのテナントに割り当てられた cpu_count (>min_cpu&&<max_cpu)  _cpu_quota_concurrency。

具体的な例を挙げると、OceanBaseデータベースがインストールされたマシンで、テナントT1の unit_min_cpu = 2, unit_max_cpu=8 が設定されている場合、そのマシンのCPUリソースにオーバーコミットがあるとします。T1に実際に割り当てられるCPU数は5です。この場合、token_count = 5_ cpu_quota_concurrency となります。

ダイアラグクエリのCPUリソース割り当てポリシーは何ですか？OLAPとOLTPが同時に存在する場合、CPUリソースの競合が発生することはありますか？

OceanBaseを使用する際、パラメータ large_query_threshold を設定することで、実行時間が一定のしきい値を超えるクエリ操作をダイアラグクエリと定義できます。システム内で大規模クエリと小規模クエリが同時に実行されている場合、OceanBaseデータベースはCPUリソースの一部を大規模クエリに割り当てます。また、パラメータ large_query_worker_percentage（デフォルト値は30%）を設定することで、大規模クエリが使用できるテナントのアクティブワーカースレッド数を制限できます。

OceanBaseデータベースは、大規模クエリが使用できるテナントのアクティブワーカースレッド数を制限することで、大規模クエリが使用するCPUリソースを制約し、システムがOLTP（例：取引型の小規模トランザクション）負荷を実行するための十分なCPUリソースを確保します。この方法により、応答時間に敏感なOLTP負荷が十分なCPUリソースを確保し、迅速に実行されることが保証されます。なお、OceanBaseデータベースは大規模クエリとOLTPのリソース割り当てを実現しているため、large_query_threshold パラメータも適切な範囲内に設定する必要があります。過度に大きな値に設定すると、大規模クエリがシステムのCPUリソースを奪い合い、OLTPの応答が遅くなったり、キューが積み上がる問題が発生する可能性があります。