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 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. [Compaction queue length] を インスタンスモニタリングの [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 に設定します。次に、table Overview ページに移動し、ページ下部までスクロールしてコンパクションの進捗を監視してください。

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

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

次のいずれかを実施してください：

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

• 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 bytes) です。VARBINARY 列にはサイズ制限がありません。その他の制限については、quotas and limits をご参照ください。

解決策：負荷が低い場合は、次を使用して一時的に上限を引き上げることができます (本番環境では推奨しません)：

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

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

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

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

• TRUNCATE TABLE：テーブル内のデータをすべて即時に消去します。TRUNCATE TABLE を使用してください。

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

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

データがコールドストレージに移動したことの確認方法

同じプライマリキーを使用して、次の 2 つのクエリ結果を比較してください：

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

2. HINT を使用して、ホットデータのみのクエリを実行してください。

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

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

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

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

一般的な原因：

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

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

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

SHOW CREATE TABLE ステートメントで unknown command エラーが返される理由

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

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

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

セカンダリインデックスのクエリで 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 レコードをスキャンする必要があります。

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