製品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データベースは分散型データベースとして、業務アプリケーションがデータベースに接続する際、従来のデータベースと何か違いはありますか？

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

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

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

• 柔軟な拡張性

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

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

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

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

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

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

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

• 高可用性

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

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

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

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

  OceanBaseデータベースのストレージエンジンはLSM-Treeアーキテクチャに基づいており、データはMemTable（MemStoreとも呼ばれる）とSSTableの二部分に分かれています。MemTableは読み書きを提供し、SSTableは読み取り専用です。ユーザーが挿入・削除・更新するデータはまずMemTableに書き込まれ、Redo Logによってトランザクション性が保証されます。Redo Logは三つのレプリカ間でPaxosプロトコルを使用して同期され、単一のServerがダウンした場合でも、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データベースはマルチテナントをサポートする分散型データベースであり、一つのクラスタが複数の業務システムをサポートすることができます。これが一般的に言われているマルチテナント機能です。

  マルチテナントアーキテクチャの利点は、システムリソースを最大限に活用できることであり、同じリソースでより多くの業務をサービスできることです。ピーク時とオフピーク時の異なる業務システムを一つのクラスタにデプロイすることで、システムリソースの最大限の利用を実現します。テナントのアプリケーション面では、テナント間の隔離性が保証されます。データセキュリティ面では、テナント間のデータアクセスが許可されないため、ユーザーのデータ資産が漏洩するリスクがありません。リソース使用面では、テナントは「専有」的にリソースクォータを持ち、そのテナントに対応するフロントエンドアプリケーションは、応答時間や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データベースでは、一度のメモリ割り当て時にどのような制限がチェックされますか？

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

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

OceanBaseデータベースのKVCacheはGV$OB_KVCACHEビューで照会できます。主な種類は以下の通りです：

• BloomFilter Cache：OceanBaseデータベースの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ノード内の上限値を確認できます。その後、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ノードのバージョンでは、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の応答が遅くなったり、キューが積み上がったりする問題が発生する可能性があります。