製品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分散リレーショナルデータベース専用のリバースプロキシサーバーとして、フロントエンドユーザーのリクエストに対して高性能かつ高精度なルーティング転送サービスを提供し、バックエンドサーバーサービスに対して高可用性と容易なスケーラビリティを備えた災害復旧保証を提供します。他のデータベースのプロキシサーバーと比較して、obproxyは実際の単一マシン環境とOceanBaseのマルチクラスタ構成の特徴に基づき、非同期フレームワークとストリーミング転送設計を採用し、FastParseおよびLockFreeのメモリソリューションを採用しています。これにより、限られたリソース使用量でも100万QPSを実現でき、大量デプロイメント時にも豊富で便利な運用保守サポート機能を備えています。

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

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

• 柔軟なスケーリング

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

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

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

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

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

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

  • Atomicity：2段階コミットを使用して、スナップショットトランザクションの原子性を保証します。
  • Consistency：トランザクションの一貫性を保証します。
  • Isolation：マルチバージョンメカニズムを使用して並行制御を行います。
  • Durability：トランザクションログは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です。例えば、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が構築され、その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リソースを制約し、システムに十分なCPUリソースが残り、OLTP（例：トランザクション型の小規模トランザクション）の負荷を処理できるようにします。このようにして、応答時間に敏感なOLTP負荷が十分なCPUリソースを確保し、迅速に実行されるようにします。さらに注意すべき点として、OceanBaseデータベースは大規模クエリとOLTPのリソース割り当てを実現できるため、large_query_thresholdパラメータも適切な範囲内に設定する必要があります。過大な値に設定すると、大規模クエリがシステムのCPUリソースを奪い取り、OLTPの応答が遅くなったり、キューが積み込まれたりする問題を引き起こす可能性があります。