Lindorm:問題の概要

Lindorm-cli が LindormTable に接続できないのはなぜですか？

各項目を確認してください：

• パブリックネットワーク接続： パブリック IP アドレスを取得し、Lindorm ホワイトリストに追加してください。

• プロキシまたは VPN： プロキシの IP アドレスをホワイトリストに追加してください。

• ポートの到達性： telnet を使用して接続性をテストしてください。

• ECS 接続： Lindorm の接続問題と解決策をご参照ください。

LindormTable の一般的なポート番号は何ですか？

マイナーバージョンアップデートの影響は何ですか？どのくらい時間がかかりますか？

マイナーバージョンアップデートでは、ローリング再起動 (ノードを 1 台ずつ再起動) を実行します。各再起動の間、Region は短時間オフラインになり、その後オンラインに戻ります。アップデート後、システムは自動的に負荷を再分散します。

影響： 低負荷のインスタンスへの影響は最小限です。高負荷またはレイテンシに敏感なインスタンスでは、短時間の中断が発生する可能性があります。オフピーク時にアップデートをスケジュールしてください。

所要時間： Region 数と現在の負荷に応じて、ノードあたり 5～30 分です。

コンパクションの役割

コンパクションは、有効期限切れデータ (TTL (time-to-live)) のクリーンアップ、削除マーカーの削除、ホットデータのコールドストレージへのアーカイブ、およびストレージ使用量を削減するためのデータ圧縮を行います。

コンパクションの自動実行頻度

デフォルトの間隔は 20 日です。TTL を設定している場合は、デフォルトは min(TTL value, 20 days) です。

間隔を変更するには、次のいずれかの方法を使用します：

• SQL： ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000'; (単位：ミリ秒) を実行します。この例では、間隔を 2 日 (172,800,000 ms) に設定します。

• Lindorm Insight： クラスタ管理システム (Lindorm Insight) で、[テーブル変更管理] を使用して [Compaction period] を変更します。

コンパクションの手動トリガー

はい。execute major compaction SQL 文を使用します。

コンパクションによるパフォーマンスへの影響

コンパクションは複数スレッドで実行されます。スレッド数はインスタンス仕様に依存し、仕様が高いほど処理が速くなります。仕様が低い場合は、多数のタスクがキューに滞留する可能性があります。CPU に余裕がある場合、コンパクションは書き込みスループットへの影響を最小限に抑えつつ、読み取りパフォーマンスを向上させ、ストレージを解放します。

コンパクションの状態を確認するには、インスタンスモニタリングの [LindormTable メトリクス — クラスタ負荷] にある [Compaction queue length] を確認します：

• 正常： 値が継続的に減少する、または周期的に増加してから減少します。また、1 日以上にわたり増加し続けたり、横ばいのままになったりしません。

• 異常： 値が増加し続ける、または 1 日以上にわたり横ばいのままです。

CPU 使用率が 40% 未満の場合： LindormTable 2.6.5 以降では、コンパクションパラメータが自動調整されます。この自動調整を利用するには、新しいマイナーバージョンにアップデートしてください。

CPU 使用率が 40% を超える場合： LindormTable ノードを追加してください。

TTL 設定後もストレージが増え続ける理由

原因： コンパクションキューで滞留が発生している場合、期限切れデータのクリーンアップが遅れます。

解決策：

1. インスタンスモニタリングの [LindormTable メトリクス — クラスタ負荷] にある [Compaction queue length] を確認します。

2. キューが滞留している場合：

   • CPU が 40% 未満： パラメータ自動チューニングのため、LindormTable 2.6.5 以降にアップデートしてください。

   • CPU が 40% を超える： LindormTable ノードを追加してください。

3. キューが空でもストレージが増え続ける場合は、I/O 負荷が低い可能性があります。コンパクションを手動でトリガーするか、コンパクション間隔を短くしてください。たとえば、間隔を 2 日に設定するには、ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000'; を実行します。

圧縮によるストレージ領域の削減

テーブルの圧縮アルゴリズムを ZSTD に、コーデックを INDEX に設定し、その後 major compaction を実行します。

SQL

Lindorm-cli または Lindorm Insight を使用して接続し、次を実行します：

-- 圧縮を ZSTD に、エンコーディングを INDEX に設定
ALTER TABLE <tablename> SET 'COMPRESSION' = 'ZSTD', 'DATA_BLOCK_ENCODING' = 'INDEX';
ALTER TABLE <tablename> COMPACT;
-- Region 数が多いテーブルの場合、キューが空になるのを待ちます

HBase API

alter 'ns:tablename', {NAME=>'family', DATA_BLOCK_ENCODING => 'INDEX', COMPRESSION => 'ZSTD'}
major_compact 'ns:tablename'
-- Region 数が多いテーブルの場合、キューが空になるのを待ちます

Lindorm Insight

[テーブル変更管理] を使用して、圧縮を ZSTD に設定します。その後、[table Overview] ページに移動し、ページ下部までスクロールしてコンパクションの進行状況をモニタリングします。

インスタンスモニタリングの [Compaction queue length] で進行状況を追跡します。

ディスク容量が上限に達した場合の対処

次のいずれかの操作を行います：

• ホットストレージ容量をスケールアップします。

• DROP TABLE を実行して未使用のテーブルを削除し、直ちに領域を解放します。

• TRUNCATE TABLE を実行してテーブル内のデータをすべて削除し、直ちに領域を解放します。

ディスクが上限に達するとデータを削除できない理由

原因： LindormTable は書き込みスループットを優先します。DELETE 操作はデータを直ちに削除せず、クエリ結果からデータを非表示にする削除マーカーを書き込みます。物理削除はコンパクション中にのみ行われます。ディスクが上限に達すると、削除マーカーを含むすべての書き込みがブロックされます。削除マーカーを書き込めないため、コンパクションでパージする対象がなくなり、領域を解放できません。

解決策： DROP TABLE または TRUNCATE TABLE を使用して直ちに領域を解放するか、ホットストレージ容量をスケールアップしてください。

LindormTable でのノード数またはディスク容量のスケーリング

ノード数の変更はエンジンレベルの操作です。ディスク容量のスケーリングはインスタンスレベルの操作です。

一般的なテーブルプロパティの単位

テーブル作成時の NUMREGIONS の設定

NUMREGIONS を指定しない場合、テーブルは 1 つの Region で作成されます。目安として、NUMREGIONS を サーバーノード数 × 4 に設定します。

次の場合に Region は自動分割されます：

• Region のデータが 8 GB に達した場合、または

• Region の読み取り/書き込み QPS の合計が 1,000 を超えた場合 (システムがホットスポットを検出し、分割するかどうかを判断します)

ホットスポットの自己修復を強化するには、LindormTable 2.4.x 以降を使用してください。必要に応じて、新しいマイナーバージョンにアップデートしてください。

ALTER TABLE 実行時の動作

ALTER TABLE は、テーブルのすべての Region をクローズして再オープンします。影響は最小限です。アプリケーションがミリ秒単位の読み取りレイテンシを必要とする場合は、オフピーク時にこの操作をスケジュールしてください。

カラムサイズ制限エラーで書き込みに失敗する理由

エラー：

com.alibaba.lindorm.client.exception.IllegalDataException: Column [xxx] is too big, max length is 2097152 bytes but has 7621168 bytes.

原因： デフォルトの最大セルサイズは 2 MB (2,097,152 バイト) です。VARBINARY カラムにはサイズ制限がありません。その他の制限については、クォータと制限をご参照ください。

解決策： 負荷が低い場合、次のコマンドを使用して一時的に制限を引き上げます (本番環境では推奨されません)：

ALTER TABLE <tablename> SET 'MAX_NONPK_LEN'='4194304';  -- 単位：バイト

ノードメモリに応じて、次の範囲内に収めてください：

データ削除の方法と注意点

LindormTable は 2 つの削除方法をサポートしています：

• TRUNCATE TABLE： テーブル内のデータを直ちにすべて削除します。TRUNCATE TABLE を使用してください。

• 主キーによる行削除： 完全な主キーを使用して特定の行を削除します。範囲削除はサポートされていません。最初に完全な主キーをクエリで取得し、その後、完全一致条件で削除してください。

削除後、アプリケーションが読み取りレイテンシに敏感な場合は、major compaction を手動でトリガーしてください。それ以外の場合は、次のスケジュールされたコンパクションサイクルまで待ちます。

コールドストレージへのデータ移動の確認方法

同一の主キーを使用して 2 つのクエリ結果を比較します：

1. フルクエリを実行して、すべてのデータを取得します。

2. HINT を使用して、ホットデータのみのクエリを実行します。

両方のクエリが同じ結果を返す場合、データはまだホットストレージにあります。結果が異なり、ホットデータクエリからデータが欠落している場合、データはコールドストレージに移動しています。

クエリの前に、Lindorm Insight の [table Overview] ページで [cold storage] と [hot storage] のサイズを確認してください。アーカイブ前後でサイズを比較します。

データがコールドストレージに移動していない理由

コンパクション後にデータがコールドストレージに移動していない理由をご参照ください。

一般的な原因：

• フラッシュが実行されていません：コンパクションでデータをアーカイブする前に、データをディスクにフラッシュする必要があります。最初にflushを実行してください。

• コンパクションの滞留： インスタンスモニタリングの [LindormTable メトリクス — クラスタ負荷] にある [Compaction queue length] を確認します。値が 0 より大きいまま増加し続ける場合、滞留があります。スケールアウトまたは アップグレードして解消してください。

• データにタイムスタンプがある： カスタムまたは特殊なタイムスタンプを持つデータは、コールドストレージへのアーカイブ対象にならない場合があります。

セカンダリインデックスのクエリで NULL 値が返されない理由

主キーの並べ替えまたは複数カラムインデックスを使用する場合、システムは、最初の非主キーカラムが NULL のインデックスエントリをスキップします。そのカラムに実際の値 (非 NULL) がある行のみが、インデックステーブルに含まれます。

想定外のクエリ結果の原因

クエリ結果が想定と一致しない一般的な原因をご参照ください。

コールドストレージトークンメトリクスの意味

コールドストレージは、アクセス頻度の低いアーカイブデータ向けです。コールドストレージからの読み取りは最小限に抑えてください。コールドストレージトークンメトリクスは、コールドストレージアクセスのレート制限を追跡します。トークン数が継続的に減少している場合、一部のリクエストがスロットリングされています。

推奨されるモニタリング設定

モニタリングとアラートのベストプラクティスをご参照ください。

テーブルレベルのモニタリングに関する FAQ

テーブル名を変更した後にモニタリングメトリクスが更新されないのはなぜですか？

[Wide Table Engine] > [Table-level monitoring] のみが、名前変更を反映します。その他のメトリクス (システムレベルのメトリクスなど) は変更されません。

テーブルモニタリングでテーブルが見つからないのはなぜですか？

時間範囲を延長してください (例：1 時間から 24 時間)。それでもテーブルが表示されない場合、その期間に読み取りまたは書き込みのアクティビティがなかったため、モニタリングデータが報告されていません。

SQL テーブルと HBase テーブルの違い

SQL テーブルは、作成時にカラム名と型を定義する固定スキーマを持ち、SQL 操作のみをサポートします。HBase テーブルは固定スキーマを持たず、動的カラムをサポートし、HBase API を通じて書き込みます (ただし、SQL で読み取ることは可能です)。

テーブルが SQL テーブルか HBase テーブルかを確認するには、次を実行します：

SHOW TABLE VARIABLES FROM <database_name> LIKE 'IS_HBASE_LIKE';

• true：HBase テーブル

• false：SQL テーブル

ApsaraDB for HBase Performance-enhanced Edition は SQL をサポートしていますか？

はい。ApsaraDB for HBase Performance-enhanced Edition は、LindormTable エンジン (HBase または Cassandra と互換) を使用しており、SQL をサポートしています。Lindorm-cli を使用して接続します：

./lindorm-cli -url jdbc:lindorm:table:url=http://ld-bp17j28j2y7pm****-proxy-lindorm-pub.lindorm.rds.aliyuncs.com:30060 -username xxx -password xxx
# 接続後
lindorm:default> show databases;

オープンソースの HBase クライアントを使用する前に知っておくべきこと

オープンソースの HBase クライアントは、認証またはマルチゾーンデプロイをサポートしていません。LindormTable に接続する前に、HBase SDK をインストールしてください。

バッチ削除の有効化

-- バッチ削除を有効化
ALTER SYSTEM SET `lindorm.allow.range.delete`=TRUE;
-- 設定を確認
SHOW SYSTEM variables LIKE 'lindorm.allow.range.delete';

バッチ更新の有効化、または "Update's WHERE clause can only contain PK columns" エラーが発生する理由

原因： 単一行更新はデフォルトで有効ですが、バッチ更新は無効です。

解決策： SQL を使用してバッチ更新を有効にします。

-- バッチ更新を有効化
ALTER SYSTEM SET `lindorm.allow.batch.update`=TRUE;
-- 設定を確認
SHOW SYSTEM variables LIKE 'lindorm.allow.batch.update';

セカンダリインデックスを持つテーブルをバッチ更新した後にクエリがタイムアウトする場合は、セカンダリインデックスを持つテーブルのバッチ更新後のクエリタイムアウトをご参照ください。

バッチ削除後のクエリタイムアウト

原因： LindormTable は書き込みスループットを優先します。DELETE はデータを直ちに削除せず、削除マーカーを書き込みます。削除されたデータはクエリ結果には表示されなくなりますが、コンパクションが実行されるまでディスク上には物理的に残ります。大規模な削除では多数の削除マーカーが蓄積します。たとえば、ある範囲スキャンにおいて、100,000行の有効な行に加え、1,000,000行の削除済み行と1,000,000件の削除マーカーが混在している場合、システムは有効な結果を返すために約 2,100,000 レコードをスキャンする必要があり、読み取りレイテンシが大幅に増加します。

解決策： コンパクションを実行して削除マーカーと有効期限切れデータを恒久的に削除します。コンパクションは自動または手動でトリガーできます。コンパクションの仕組みをご参照ください。

セカンダリインデックスを持つテーブルのバッチ更新後のクエリタイムアウト

原因： セカンダリインデックスは独立したインデックステーブルです。その主キーは [インデックス対象カラムの値] + [主テーブルの RowKey] です。主テーブルのレコードが更新されると、LindormTable は古いインデックスエントリを自動的に削除 (削除マーカーを書き込み) し、新しいエントリを挿入します。インデックス対象カラムに対する大規模更新では、インデックステーブルに多数の削除マーカーが蓄積します。そのインデックスを使用するクエリは、対象値に対応するすべての RowKey をスキャンし、削除済みエントリをスキップする必要があります。有効なエントリが少ない場合、スキャンのオーバーヘッドが急増します。たとえば、ある範囲スキャンにおいて、100,000行の有効な行に加え、1,000,000行の削除済み行と1,000,000件の削除マーカーが混在している場合、システムは有効な結果を返すために約 2,100,000 レコードをスキャンする必要があります。

解決策： コンパクションを実行して削除マーカーと有効期限切れデータを恒久的に削除します。コンパクションは自動または手動でトリガーできます。コンパクションの仕組みをご参照ください。