Lindorm:問題の概要

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

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

• これはパブリックネットワーク接続ですか？もしそうであれば、パブリック IP アドレスを取得し、それを Lindorm ホワイトリストに追加してください。

• VPN などのプロキシを使用していますが、それをホワイトリストに追加していませんか？

• サービスポートは利用可能ですか？telnet コマンドを使用して Lindorm ポートへの接続性をテストできます。

• ECS を使用して LindormTable に接続する場合、「Lindorm の接続に関する問題と解決策」をご参照ください。

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

マイナーバージョンの更新による影響と所要時間はどのくらいですか？

マイナーバージョンの更新により、一度に 1 つのノードが短時間切断される可能性があります。各サーバーはローリングリスタートを実行します。更新中、リージョンはオフラインになり、その後オンラインに戻ります。更新が完了すると、システムは負荷を再分散します。

影響評価：低負荷のインスタンスへの影響は最小限です。高負荷または遅延の影響を受けやすいインスタンスは影響を受ける可能性があります。更新はオフピーク時間に実行してください。

推定時間：ノードあたり約 5〜30 分です。実際の時間はリージョンの数と現在の負荷によって異なります。

コンパクション操作

TTL を設定してもストレージ使用量が増え続けるのはなぜですか？

インスタンスのモニタリングを使用して、LindormTable のメトリック — クラスター負荷の [コンパクションキューの長さ (カウント)] を確認します。多くのタスクがキューに入っている場合、データのクリーンアップが遅れます。CPU 使用率が 40% 未満の場合、LindormTable バージョン 2.6.5 以降では負荷に基づいてパラメーターを自動的に調整します。単に新しいマイナーバージョンに更新してください。CPU 使用率が 40% を超える場合は、LindormTable ノードを追加してください。

キューが空の場合、コンパクションは正常に実行されます。I/O 負荷が低い場合は、手動でコンパクションをトリガーするか、major compaction の間隔を調整します。たとえば、2 日に設定するには、次のようにします：ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000';。

デフォルトの間隔は 20 日です。TTL シナリオでは、デフォルトの間隔は min(ttl,20 days) です。

圧縮アルゴリズムとコーデックを設定してストレージ領域を削減するにはどうすればよいですか？

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

詳細：

• SQL：Lindorm-cli を使用して LindormTable に接続するか、クラスター管理システム (Lindorm Insight) を使用して SQL 文を実行します。

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

  インスタンスのモニタリングを使用して、LindormTable のメトリック — クラスター負荷の [コンパクションキューの長さ (カウント)] を確認して進行状況を追跡します。

• HBase API：テーブルの作成とデータの挿入

  alter 'ns:tablename', {NAME=>'family', DATA_BLOCK_ENCODING => 'INDEX',COMPRESSION => 'ZSTD'}
  // テーブルに多くのリージョンがある場合は待機します
  major_compact 'ns:tablename'
  // テーブルに多くのリージョンがある場合は待機します

  インスタンスのモニタリングを使用して、LindormTable のメトリック — クラスター負荷の [コンパクションキューの長さ (カウント)] を確認して進行状況を追跡します。

• クラスター管理システム (Lindorm Insight) の使用：

  テーブル変更管理を使用して圧縮を ZSTD に設定します。その後、[概要] ページに移動してテーブルの詳細を表示します。一番下までスクロールすると、コンパクションタスクの詳細が表示されます。

ディスク (ストレージ領域) が容量に達した場合、どうすればよいですか？

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

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

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

• TRUNCATE TABLE を使用してテーブルからすべてのデータをクリアし、ストレージ領域を即座に解放します。

ディスク (ストレージ領域) が容量に達した後、データを削除できないのはなぜですか？

データを直接削除するために DELETE を使用しないでください。理由は次のとおりです：

Lindorm は書き込みパフォーマンスを優先します。削除操作は最初にデータを読み取りません。代わりに、削除マーカー (Delete Marker) を書き込み、データがクエリに見えなくなります。データは、次の compaction 操作中にのみ物理的に削除されます。トリガー間隔については、「コンパクション操作の自動トリガー間隔」をご参照ください。

また、ディスクが容量制限に達すると、システムは削除マーカーを含むすべてのデータ書き込みを禁止します。削除マーカーを書き込めないため、削除対象のデータは Compaction 操作でパージできません。したがって、この操作ではすぐに領域を解放できません。

LindormTable はノード数の変更やディスク容量のスケーリングをサポートしていますか？

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

• ローカルディスクとクラウドディスクの両方のインスタンスが LindormTable ノード数の変更をサポートしています。

• ローカルディスクインスタンスはディスク容量のスケーリングをサポートしていません。クラウドディスクインスタンスはホットストレージ容量のスケーリングとコールドストレージ容量のスケーリングをサポートしています。スケールダウンにはデータのコピーが必要で時間がかかります。お待ちください。

一般的なテーブルプロパティにはどの単位を使用すればよいですか？

• major compaction 間隔：COMPACTION_MAJOR_PERIOD パラメーターは major compaction 間隔を設定します。単位はミリ秒 (ms) です。major compaction 間隔を使用してテーブルを作成するときにこの間隔を指定できます。

• タイムスタンプ：単位はミリ秒 (ms) です。一部のヒントでは秒 (s) を使用します。例：/*+ _l_ts_(%s) */。

• TTL (Time To Live)：単位は秒 (s) です。データの有効期限を使用してテーブルを作成するときに TTL を指定できます。

テーブル作成時に NUMREGIONS パラメーターを設定するにはどうすればよいですか？

NUMREGIONS を指定しない場合、デフォルトは 1 パーティションです。最初に NUMREGIONS を サーバーノード数 × 4 に設定することをお勧めします。パーティションはデータが 8 GB に達すると自動的に分割されます。または、パーティションの読み取り/書き込み QPS の合計が 1000 を超えると、システムはホットスポットを検出し、分割するかどうかを決定します。

より良いホットスポット自己修復のために、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.

VARBINARY 列には長さの制限はありません。その他の制限については、「クォータと制限」をご参照ください。

デフォルトでは、単一のセルは 2 MB を超えることはできません。インスタンスの負荷とストレージ領域を考慮してください。負荷が低い場合は、SQL を使用して最大非プライマリキー列サイズを一時的に増やすことができます (非推奨)：ALTER TABLE <tablename> SET 'MAX_NONPK_LEN'='4194304'; (単位：バイト)。

データを削除する方法と注意点は何ですか？

Lindorm は 2 つの方法でデータを削除できます：TRUNCATE TABLE を使用してテーブルからすべてのデータをクリアするか、完全なプライマリキーを使用して特定の行を削除します。削除後、アプリケーションが読み取り RT に敏感な場合は、手動で major compaction を実行します。そうでない場合は、スケジュールされた compaction サイクルを待ちます。

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

• まず、プライマリキーを指定して検証対象のすべてのデータをクエリし、次に同じプライマリキーを使用してHINT を使用してホットデータのみをクエリします。クエリ結果を比較します：同じであれば、データはコールドストレージに入っていません。すべてのデータをクエリした結果とHINT を使用してホットデータのみをクエリした結果が異なり、すべてのデータをクエリしたときにコールドデータが見つからない場合、これはデータがコールドストレージに入ったことを示します。

• 検証する前に、クラスター管理システム (Lindorm Insight) と [概要] ページを使用して、[コールドストレージ] と [ホットストレージ] のサイズを確認します。アーカイブ前後のサイズを比較します。

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

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

主な理由には次のものがあります：

• Flush が実行されなかった

  flush を実行してデータをディスクに書き込んでからコンパクションを実行します。

• コンパクションのバックログ

  スケールアウトまたはスペックアップによって CPU リソースを増やすことで、コンパクションのバックログ問題を解決できます。

  説明

  モニタリング情報の表示でモニタリング情報を表示することで、コンパクションのバックログが発生したかどうかを判断できます。具体的には、LindormTable のメトリック – クラスター負荷 > コンパクションキューの長さ (項目) です。値が 0 より大きいままで増加し続ける場合、コンパクションのバックログが発生しています。

• データにタイムスタンプがある

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

プライマリキーの並べ替えと複数列インデックスを使用する場合、最初の非プライマリキー列の値が NULL の場合、システムはセカンダリインデックスを構築しません。実際の値を持つ非プライマリキー列のみがインデックステーブルに表示されます。

クエリ結果が予期しないものになる原因は何ですか？

クエリ結果が期待と一致しない一般的な理由

モニタリングにおけるコールドストレージトークンメトリックは何を意味しますか？

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

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

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

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

SQL テーブルと HBase テーブルの違いは何ですか？どのように見分けますか？

SQL テーブルと HBase テーブルは、構造とデータ操作が異なります。SQL テーブルは固定スキーマ (事前に定義された列名と型) を持ち、SQL 操作のみをサポートします。HBase テーブルは固定スキーマを持たず (動的カラムをサポート)、HBase API を使用します (ただし、SQL クエリも許可されます)。それらを区別するには：

• 作成方法

  • HBase テーブル：hbase shell または他の HBase 同期ツールを使用して作成されます (「ワイドテーブル」とも呼ばれます)。

  • SQL テーブル：SQL コマンドを使用して作成されます (SQL は HBase テーブルを作成できません)。

• 構造的特徴

  • HBase テーブル：スキーマなし。動的カラムをサポートします。

  • SQL テーブル：固定スキーマ。列の型が厳密に定義されています。

• 操作制限

  • HBase テーブル：HBase API を通じてのみ書き込み可能 (SQL で読み取り可能、Htype マッピングドキュメントを参照)。

  • SQL テーブル：SQL API を通じてのみ読み書き可能。

• 検証方法
  この SQL コマンドを実行して IS_HBASE_LIKE プロパティを確認します：
  
  

  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 と互換) を使用します。その使用法は LindormTable と一致します。SQL をサポートしています。Lindorm-cli を使用して LindormTable に接続できます：

./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 をインストールしてください。

一括削除を有効にするにはどうすればよいですか？

一括削除の設定を有効にして確認するには、次のコマンドを使用します。

-- SQL を使用して有効または無効にする
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';

テーブルの一括削除後のクエリタイムアウト

• 削除の仕組み
  Lindorm は高い書き込みスループットを優先します。削除操作はデータをすぐに消去しません。代わりに、削除マーカーを書き込みます。これはユーザーには透明です — 削除されたデータは読み取りには見えませんが、システムは読み取り中にマーカーと削除されたデータをスキップする必要があります。通常の削除では問題はほとんど発生しません。大規模な削除は多くの削除マーカーを蓄積します。例：100,000 の有効な行、1,000,000 の削除された行、1,000,000 の削除マーカーを持つ範囲を読み取ると、システムは約 210 万レコードをスキャンして有効な結果をフィルタリングする必要があります。これにより、読み取り時間が大幅に増加し、タイムアウトが発生する可能性があります。
  
  

• クエリがタイムアウトする理由
  多くの保留中の削除がある範囲をスキャンするクエリは、多くの deleteMarker を生成します。それらをスキップするとオーバーヘッドが増加し、タイムアウトが発生します。
  
  

• 解決策
  コンパクションを実行して、期限切れのデータと deleteMarker を永続的に削除します。コンパクションは自動または手動でトリガーされます。詳細については、「コンパクション操作」をご参照ください。
  
  

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

• クエリがタイムアウトする理由

  セカンダリインデックスは別のインデックステーブルです。そのプライマリキーのフォーマットは [インデックス付き列の値] + [プライマリテーブルの RowKey] です。プライマリテーブルのレコードが更新または削除されると、Lindorm は自動的に：

  古いインデックスエントリを削除し (削除マーカーを書き込み)、新しいインデックスエントリを挿入します (該当する場合)。

  そのため、インデックス付き列への大規模な更新は、インデックステーブルに多くの削除マーカーを作成します。インデックスを使用するクエリは、ターゲットのインデックス値のすべての RowKey をスキャンし、削除されたエントリをスキップする必要があります。有効なエントリが少ない場合、スキャンとフィルタリングのオーバーヘッドが急激に増加します。これにより、クエリレイテンシが増加し、スループットが低下します。

• 削除の仕組み
  Lindorm は高い書き込みスループットを優先します。削除操作はデータをすぐに消去しません。代わりに、削除マーカーを書き込みます。これはユーザーには透明です — 削除されたデータは読み取りには見えませんが、システムは読み取り中にマーカーと削除されたデータをスキップする必要があります。通常の削除では問題はほとんど発生しません。大規模な削除は多くの削除マーカーを蓄積します。例：100,000 の有効な行、1,000,000 の削除された行、1,000,000 の削除マーカーを持つ範囲を読み取ると、システムは約 210 万レコードをスキャンして有効な結果をフィルタリングする必要があります。これにより、読み取り時間が大幅に増加し、タイムアウトが発生する可能性があります。
  
  

• 解決策
  コンパクションを実行して、期限切れのデータと deleteMarker を永続的に削除します。コンパクションは自動または手動でトリガーされます。詳細については、「コンパクション操作」をご参照ください。