Lindorm:問題の概要

Lindorm-cli が LindormTable への接続に失敗するのはなぜですか?

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

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

• プロキシまたは VPN： プロキシ IP をホワイトリストに追加します。

• ポートの可用性： telnet を使用して接続性をテストします。

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

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

マイナーバージョンの更新による影響は何ですか? どのくらい時間がかかりますか?

マイナーバージョンの更新では、ローリングリスタート (1 ノードずつ) が実行されます。各リスタート中、リージョンは一時的にオフラインになり、その後オンラインに戻ります。更新後、システムは自動的に負荷を再分散します。

影響： 低負荷のインスタンスへの影響は最小限です。高負荷またはレイテンシに敏感なインスタンスでは、短時間の中断が発生する可能性があります。オフピーク時間帯に更新をスケジュールすることを推奨します。

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

コンパクションは何をしますか?

コンパクションは、期限切れデータ (TTL (Time-To-Live)) をクリーンアップし、削除マーカーを削除し、ホットデータとコールドデータをアーカイブし、データを圧縮してストレージ使用量を削減します。

コンパクションは自動的にどのくらいの頻度で実行されますか?

デフォルトの間隔は 20 日です。TTL (Time-To-Live) シナリオでは、デフォルトは min(TTL 値, 20 日) です。

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

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

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

コンパクションを手動でトリガーできますか?

はい。メジャーコンパクションの実行 SQL ステートメントを使用します。

コンパクションによるビジネスへの影響は何ですか?

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

コンパクションのステータスを確認するには、インスタンスモニタリングの [LindormTable メトリクス — クラスターの負荷]の下にある [コンパクションキューの長さ] を確認します：

• 正常： 値が着実に減少するか、定期的に上昇してから下降し、1 日以上上昇し続けたり横ばいになったりしない。

• 異常： 値が 1 日以上上昇し続けるか、横ばいになる。

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

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

TTL を設定した後もストレージが増え続けるのはなぜですか?

原因： コンパクションキューに大きなバックログがある場合、データのクリーンアップがデータの有効期限に追いつかなくなります。

解決策：

1. インスタンスモニタリングの [LindormTable メトリクス — クラスターの負荷]の下にある [コンパクションキューの長さ] を確認します。

2. キューにバックログがある場合：

   • CPU が 40% 未満： 自動パラメータ調整のために LindormTable 2.6.5 以降に更新してください。

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

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

圧縮を使用してストレージ領域を削減するにはどうすればよいですか?

テーブルの圧縮アルゴリズムを ZSTD に、コーデックを INDEX に設定してから、メジャーコンパクションを実行します。

SQL：

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

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

HBase API：

alter 'ns:tablename', {NAME=>'family', DATA_BLOCK_ENCODING => 'INDEX', COMPRESSION => 'ZSTD'}
major_compact 'ns:tablename'
-- リージョンが多いテーブルの場合、キューが空になるまで待機

Lindorm Insight：

テーブル変更管理を使用して圧縮を ZSTD に設定します。次に、テーブル概要ページに移動し、下にスクロールしてコンパクションの進行状況を監視します。

インスタンスモニタリングの [コンパクションキューの長さ] で進行状況を追跡します。

ディスク容量がいっぱいになった場合、どうすればよいですか?

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

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

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

• TRUNCATE TABLE を実行して、テーブル内のすべてのデータをクリアし、領域を即座に解放します。

ディスクがいっぱいの場合、データを削除できないのはなぜですか?

原因： LindormTable は書き込みスループットを優先します。DELETE 操作はデータを即座に削除しません。クエリからデータを隠す削除マーカーを書き込みます。物理的な削除はコンパクション中にのみ行われます。ディスクがいっぱいの場合、システムはすべての書き込み (削除マーカーを含む) をブロックします。削除マーカーを書き込めないため、コンパクションはパージするものがなく、領域を解放できません。

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

LindormTable はノードのスケーリングまたはディスク容量のスケーリングをサポートしていますか?

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

一般的なテーブルプロパティではどの単位を使用しますか?

テーブル作成時にNUMREGIONSを設定するにはどうすればよいですか?

NUMREGIONS が指定されていない場合、テーブルは 1 つのパーティションから始まります。目安として、NUMREGIONS を サーバーノード数 × 4 に設定します。

次の場合、パーティションは自動的に分割されます：

• パーティションデータが 8 GB に達した場合、または

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

ホットスポットの自己修復をより効果的に行うには、LindormTable 2.4.x 以降を使用してください。必要に応じて 新しいマイナーバージョンに更新してください。

ALTER TABLEを実行するとどうなりますか?

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

書き込みがカラムサイズ制限エラーで失敗するのはなぜですか?

エラー：

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 を使用してください。

• プライマリキーによる行削除： 完全なプライマリキーを使用して特定の行を削除します。範囲削除はサポートされていません。まず完全なプライマリキーをクエリしてから、正確な条件を使用して削除してください。

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

データがコールドストレージに移動されたことを確認するにはどうすればよいですか?

同じプライマリキーを使用した 2 つのクエリの結果を比較します：

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

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

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

クエリを実行する前に、Lindorm Insight の テーブル概要ページで [コールドストレージ]と [ホットストレージ]のサイズを確認してください。アーカイブ前後のサイズを比較してください。

データがコールドストレージに移動されないのはなぜですか?

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

一般的な原因：

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

• コンパクションのバックログ： インスタンスモニタリングの [LindormTable メトリクス — クラスターの負荷]の下にある [コンパクションキューの長さ] を確認してください。値が 0 を超えて増え続ける場合、バックログが存在します。スケールアウトまたは アップグレードして解決してください。

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

SHOW CREATE TABLE ステートメントが不明なコマンドエラーを返すのはなぜですか?

SHOW CREATE TABLE ステートメントを実行すると、次のエラーが返されます：java.lang.IllegalArgumentException: unknown command。

SHOW CREATE TABLE ステートメントは、Lindorm ワイドテーブルエンジンにのみ適用されます。Lindorm SQL バージョンは 2.6.3.2 以降、ワイドテーブルエンジンバージョンは 2.6.2 以降である必要があります。

インスタンスが上記のバージョン要件を満たしていることを確認してください。バージョンが要件を満たしていない場合は、インスタンスをアップグレードして再試行してください。

セカンダリインデックスクエリが NULL 値を返さないのはなぜですか?

プライマリキーの並べ替えまたはマルチカラムインデックスを使用する場合、システムは最初の非プライマリキーカラムが NULL であるインデックスエントリをスキップします。そのカラムに実際の (NULL 以外の) 値を持つ行のみがインデックステーブルに表示されます。

クエリ結果が想定と異なる一般的な原因は何ですか?

クエリ結果が期待と一致しない一般的な理由をご参照ください。

コールドストレージトークンメトリクスの意味は何ですか?

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

推奨されるモニタリング設定は何ですか?

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

テーブルレベルのモニタリングに関するよくある質問

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

[Wide Table Engine] > [テーブルレベルのモニタリング] のみが名前の変更を反映します。システムレベルのメトリクスなど、その他のメトリクスは変更されません。

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

時間範囲を拡張してください (例：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 件のレコードをスキャンする必要があります。

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