このページは英語からの機械翻訳を使用しており、誤りや不明瞭な表現が含まれている可能性があります。最も正確な情報については、オリジナルの英語版をご覧ください。頻繁な更新のため、一部のコンテンツはオリジナルの英語になっている可能性があります。Crowdinでの取り組みに参加して、このページの翻訳改善にご協力ください。 (Crowdin translation page, Contributing guide)

ノードストレージの最適化

カイアv2.1.0は、ディスク容量を大幅に削減できる2つの補完的なストレージ最適化機能を導入しています：

• データベース圧縮：繰り返しブロックデータを圧縮してストレージを削減
• FlatTrie State Scheme：アーカイブ・ノードのステート・データベース・サイズを大幅に削減する実験的機能

このガイドでは、Kaiaノードにこれらの最適化を適用する方法を説明します。

データベースの圧縮

データベース圧縮はLevelDBに内蔵されたSnappy圧縮を使用し、ブロックヘッダ、トランザクションボディ、レシートのサイズを縮小するもので、ABIエンコードされたトランザクションのゼロパディングのような繰り返しデータを含むことが多い。

予想貯蓄額：*。

• フルノード：～2TB削減（メインネットの～4.2TBから～2TBへ）

前提条件

• カイアv2.1.0以上
• 手動コンパクションの場合：十分なディスク空き容量と持続的なディスクI/Oを受け入れる能力（以下のリソースへの影響セクションを参照）

新規インストールで圧縮を有効にする

v2.1.0から、圧縮はデフォルトで有効になりました。 ノードをスタートさせるだけだ：

**パッケージのインストール

# Configure network in kend.conf

sudo vi /etc/kend/conf/kend.conf

# Set: NETWORK=mainnet or NETWORK=kairos

# Start node (compression enabled by default in v2.1.0+)

kend start

# Verify

kend status

tail -f /var/kend/logs/kend.out

新しく書き込まれたデータはすべて自動的に圧縮される。

既存のノードの圧縮を有効にする

v2.1.0以前のバージョンからアップグレードする場合：

ステップ1：バージョンを確認する。

ken version

ステップ2: v2.1.0以降の場合

圧縮はデフォルトで有効になっている。 新しいデータは自動的に圧縮される。 既存のデータを圧縮する場合は、ステップ4に進んでください。

ステップ3：v2.1.0以前のバージョンのみ。

設定に圧縮フラグを追加する：

**パッケージのインストール

sudo vi /etc/kend/conf/kend.conf

# Add to ADDITIONAL variable:

ADDITIONAL="--db.leveldb.compression 2"

圧縮フラグの値は以下の通り：

• 0:圧縮しない
• 1:レシートのみを圧縮する
• 2:ヘッダ、ボディ、レシートを圧縮する（推奨）
• 3:ステートトライを含む全てのテーブルを圧縮する (推奨されない)

備考

ステートトライのデータはうまく圧縮されない（ランダムに見える）ので、オプション3を推奨する。

それから再スタートする：

kend stop

kend start

ステップ4：既存のデータを圧縮する（オプションだが推奨）*。

RPC経由でデータベースのコンパクションをトリガーする。 ノードコンソールに取り付ける：

ken attach --datadir /var/kend/data

コンソールで、"allbutstate "プリセットを使ってコンパクションをトリガーする：

> debug.chaindbCompact({ "preset": "allbutstate" })

null

利用可能なプリセット：*。

• デフォルト"`：すべてのデータベースコンポーネントのフルレンジコンパクション
• allbutstate"`：状態のトライを除いた選択的な圧縮 (圧縮に推奨)
• custom"`：特定のデータベーステーブルのカスタム範囲を定義する

コンパクションはバックグラウンドで実行される。 ノードのログで進捗状況を監視する：

tail -f /var/kend/logs/kend.out | grep -i Compact

というようなログ・エントリーが表示されるはずだ：

INFO[07/25,12:50:17 Z] [3] Compacting database started range=0x48-0x49

INFO[07/25,12:55:17 Z] [3] Compacting database completed range=0x48-0x49 elapsed=5m0.085s

ノードはコンパクション中もブロックの処理を続ける。

予想所要時間: メインネットのフルノードで約10時間（～4TBのデータでSSDの場合）。 所要時間はハードウェアとデータサイズによって異なる。

**資源への影響

• 高いディスクI/O（ピーク時：読み取り400MiB/秒以上、書き込み300MiB/秒以上）
• 高いディスクIOPS（しばしば>2000オペレーション/秒）
• ノードは稼働を続け、ブロックの同期を続ける

備考

コンパクション中もノードは稼動しているが、I/Oのピーク時にはクエリのパフォーマンスに影響が出る可能性がある。 本番用RPCノードの場合は、メンテナンス・ウィンドウまたはトラフィックの少ない時間帯にコンパクションのスケジュールを設定します。

事前圧縮されたChaindataスナップショットを使用する（未定）

事前圧縮されたチェーンデータのスナップショットは、将来のリリースで計画されていますが、まだ利用できません。 入手可能になれば、Chaindataスナップショットページに掲載されます。

現在、あなたはどちらかでなければならない：

• v2.1.0+の新規インストールで圧縮を有効にする（新規データは自動圧縮）
• 既存のノードで手動コンパクションを実行する（上記参照）

圧縮スナップショットの可用性に関する更新については、スナップショットページを定期的にチェックしてください。

圧縮が有効であることを確認する

ノードの起動ログに圧縮設定がないか確認してください：

grep "compressionType" /var/kend/logs/kend.out

state-trie以外のテーブルでcompressionType=snappyを示すログ・エントリを探します。

モニタリングとトラブルシューティング

**ディスク使用量の削減をチェックする。

du -h --max-depth=1 /var/kend/data/klay/chaindata

圧縮前と圧縮後を比較する。 ブロック本体とレシートを含むディレクトリのストレージが大幅に削減されるはずだ。

**よくある問題

1. **コンパクションに失敗しました：十分なディスク容量を確保してください。 コンパクションは、一時的にデータを書き換えるための追加スペースを必要とする。
2. **FlatTrieが起動しません：FlatTrie は空のデータベースを必要とします。 既存のデータに関するエラーが表示された場合は、chaindataディレクトリを削除し、genesisから同期してください。
3. メルクル証明 API エラー：FlatTrieは eth_getProof をサポートしていません。 このAPIが必要な場合は、従来のノードを使用する。

フラットトライ・ステート・スキーム（実験的）

FlatTrieは、Erigonイーサリアムクライアントから転用された実験的な状態保存スキームである。 アカウントの状態をフラットな構造で保存し、最新のブロックの完全なMerkle Patricia Trie（MPT）のみを保持し、オンデマンドで過去のトライを再構築する。

予想貯蓄額：*。

• 総収納量：~75％削減（カイロス・テストネットの結果から予測）
• カイロス・テストネット4.3TB → 1TB
• メインネット~35TB → ~10TB（比例削減による見積もり）

警告

FlatTrieはv2.1.0の実験的機能です。 本番での使用は推奨されていない。 今後のリリースでは、潜在的な安定性の問題、パフォーマンスのボトルネック、破壊的な変更が予想されます。 テストおよび開発環境でのみ使用する。

前提条件

• カイアv2.1.0以上
• **ジェネシスからの同期が必要です。
• 空のデータ・ディレクトリ

現在の制限

FlatTrieを有効にする前に、これらの制限を理解してください：

サポートされない機能：*。

• バッチ剪定とライブ剪定
• ブロックの巻き戻し (--start-block-number フラグと debug_setHead API)
• Merkle 証明生成 (eth_getProof API)

非適合性：*。

• 既存のデータベースから移行できない（ジェネシスから始める必要がある）
• FlatTrieモードと非FlatTrieモードの切り替えができない
• FlatTrieを使用するデータベースと使用しないデータベースに互換性はありません。

FlatTrieを有効にする

ステップ1：空のデータディレクトリを用意する。

# Ensure clean data directory

sudo rm -rf /var/kend/data

sudo mkdir -p /var/kend/data

ステップ2：FlatTrieフラグでノードを起動し、genesisから同期する。

# Mainnet

ken --state.experimental-flat-trie

# Kairos testnet

ken --state.experimental-flat-trie --kairos

備考

FlatTrieが有効な場合、アーカイブモードは --gcmode と --state.block-interval フラグに関係なく、自動的に有効になる。 FlatTrieを使用する場合、これらのフラグは無視される。

ステップ3：完全な同期を待つ。

ノードはジェネシスからすべてのブロックを同期させる。 ハードウェアやネットワークによっては数週間かかる場合もあります。

FlatTrieがアクティブであることを確認する

ノードの起動ログをチェックして、FlatTrieモードを確認します：

grep -i "flat" /var/kend/logs/kend.out | head -20

エクスペリメンタル・フラット・トライがアクティブであることがわかるはずだ。

FlatTrieのパフォーマンスをモニターする

FlatTrieは、従来のステート・ストレージとは異なるリソース・プロファイルを使用する：

**期待される特性

• CPU使用率の低下
• メモリ使用量が多い（～30GB）
• 高いゴルーチン数（～900～1000）
• ブロック確定時間の短縮

ノードのPrometheusメトリクスエンドポイントまたはGrafanaダッシュボードでこれらのメトリクスを監視します。

FlatTrieのトラブルシューティング

Cannot start FlatTrie on existing database: FlatTrie cannot be enabled on non-empty data を示すエラーが表示された場合は、genesis から起動する必要があります。 chaindataディレクトリを削除し、--state.experimental-flat-trieフラグで完全同期を行う。

Merkle proof API fails: FlatTrieはeth_getProofと関連するMerkle proof APIをサポートしていません。 アプリケーションにこれらのAPIが必要な場合は、代わりに従来のノードを使用してください。

High memory usage: 同期中のFlatTrieノードのメモリ使用量は約30GBと予想されます。 システムに十分なRAMがあることを確認してください。 チームは将来のバージョンでこれを減らすための最適化に取り組んでいる。

遅い同期速度: FlatTrieの初期同期は、従来のノードと同等です。 同期が著しく遅い場合は、確認してください：

• ディスクI/O性能（SSDを強く推奨）
• ネットワーク帯域幅
• CPU使用率

ベストプラクティス

1. 大きな変更の前には必ずバックアップを取ってください：特に手動コンパクションを実行する前に。
2. **ディスクの空き容量を監視してください：コンパクションの前に十分な空き容量があることを確認してください。 コンパクションは一時的にデータベース・ファイルを書き換えるための追加領域を必要とする。
3. **トラフィックの少ない時間帯にコンパクションをスケジュールする：パブリックRPCエンドポイントを実行している場合。
4. 本番ノードにはSSDを使用してください：圧縮もFlatTrieも、高速なランダムI/Oから恩恵を受けます。
5. 実験的機能の計画：FlatTrieはv2.1.xでは実験的な機能です。 本番使用前に十分にテストすること。
6. 常にアップデートしてください：今後の最適化とFlatTrieが実験的ステータスを卒業する時期については、リリースノートをご確認ください。