JSON ShreddingPublic Preview
JSON shreddingは、従来の行ベースストレージを最適化された列ベースストレージに変換することでJSONクエリを高速化します。データモデリングの柔軟性を維持しながら、Zilliz Cloudはバックグラウンドで列ベースの最適化を実行し、アクセスおよびクエリ効率を劇的に向上させます。
JSON shreddingは、ほとんどのJSONクエリシナリオに有効です。パフォーマンスの利点は以下の場合により顕著になります:
-
より大きく複雑なJSONドキュメント - ドキュメントサイズが大きくなるほどパフォーマンスの向上が大きくなります
-
読み取り中心のワークロード - JSONキーの頻繁なフィルタリング、ソート、または検索
-
混合クエリパターン - 異なるJSONキーにわたるクエリはハイブリッドストレージ方式から利益を得ます
仕組み
JSON shreddingプロセスは、高速な取得のためにデータを最適化する三つの異なる段階で行われます。
段階1:インジェストおよびキー分類
新しいJSONドキュメントが書き込まれる際、Zilliz Cloudはそれらを継続的にサンプリングおよび分析してJSONキーごとに統計情報を構築します。この分析には、キーの出現率と型の安定性(ドキュメント全体でデータ型が一貫しているか)が含まれます。
これらの統計情報に基づき、JSONキーは最適なストレージ用に以下のように分類されます。
JSONキーのカテゴリ
キーの種類 | 説明 |
|---|---|
型付きキー | ほとんどのドキュメントに存在し、常に同じデータ型を持つキー(例:すべて整数またはすべて文字列)です。 |
動的キー | 頻繁に出現するが、混合データ型を持つキー(例:場合により文字列または整数)です。 |
共有キー | 設定可能な頻度のしきい値を下回る、出現頻度が低いまたはネストされたキーです。 |
例:分類
以下のJSONキーを含むサンプルJSONデータを検討してください:
{"a": 10, "b": "str1", "f": 1}
{"a": 20, "b": "str2", "f": 2}
{"a": 30, "b": "str3", "f": 3}
{"a": 40, "b": 1, "f": 4} // bが混合型になる
{"a": 50, "b": 2, "e": "rare"} // eが低頻度で出現
このデータに基づき、キーは以下のように分類されます:
-
型付きキー:
aおよびf(常に整数) -
動的キー:
b(混合型の文字列/整数) -
共有キー:
e(出現頻度が低いキー)
段階2:ストレージ最適化
段階1の分類結果は、ストレージレイアウトを決定します。Zilliz Cloudはクエリに最適化された列ベースの形式を使用します。

-
分割列: 型付きキーおよび動的キーについて、データは専用の列に書き込まれます。この列ベースストレージにより、クエリ時の高速直接スキャンが可能になり、Zilliz Cloudは指定されたキーのデータのみを処理する必要があり、ドキュメント全体を処理する必要がありません。
-
共有列: すべての共有キーは、単一のコンパクトなバイナリJSON列に一緒に保存されます。共有キーの逆インデックスがこの列に構築されます。このインデックスは、指定されたキーを含む行のみに検索範囲を効果的に絞り込むことで、低頻度キーのクエリを高速化する上で不可欠です。
段階3:クエリ実行
最終段階では、最適化されたストレージレイアウトを活用して、各クエリ条件に最速のパスを賢く選択します。
-
高速パス: 型付き/動的なキーのクエリ(例:
json['a'] < 100)は専用の列に直接アクセスします -
最適化パス: 共有キーのクエリ(例:
json['e'] = 'rare')は逆インデックスを使用して関連ドキュメントを迅速に特定します
パフォーマンスベンチマーク
テストでは、異なるJSONキー型およびクエリパターンで著しいパフォーマンス向上が確認されました。
テスト環境および方法論
-
ハードウェア: 1コア/8GBクラスター
-
データセット: JSONBench から100万ドキュメント
-
平均ドキュメントサイズ: 478.89バイト
-
テスト期間: QPSおよびレイテンシを測定した100秒
結果:型付きキー
このテストでは、ほとんどのドキュメントに存在するキーのクエリ時のパフォーマンスを測定しました。
クエリ式 | キーの値の型 | QPS(shreddingなし) | QPS(shreddingあり) | パフォーマンス向上 |
|---|---|---|---|---|
| 整数 | 8.69 | 287.50 | 33倍 |
| 文字列 | 8.42 | 126.1 | 14.9倍 |
結果:共有キー
このテストでは、"共有"カテゴリに分類されるスパースなネストされたキーのクエリに焦点を当てました。
クエリ式 | キーの値の型 | QPS(shreddingなし) | QPS(shreddingあり) | パフォーマンス向上 |
|---|---|---|---|---|
| ネストされた整数 | 4.33 | 385 | 88.9倍 |
| ネストされた文字列 | 7.6 | 352 | 46.3倍 |
主な知見
-
共有キークエリは最も劇的な改善を示します(最大89倍高速)
-
型付きキークエリは一貫した15-30倍のパフォーマンス向上を提供します
-
すべてのクエリ型は、パフォーマンスの低下なしにJSON Shreddingの恩益を受けます
よくある質問
-
JSON shreddingとJSONインデックスの選択肢をどう選べばよいですか?
-
JSON shreddingはドキュメント内に頻繁に出現するキーに最適で、特に複雑なJSON構造に適しています。列ベースストレージと逆インデックスの利点を組み合わせており、多くの異なるキーをクエリする読み取り中心のシナリオに適しています。ただし、非常に小さなJSONドキュメントには推奨されません。shreddingによるパフォーマンス最適化の恩益は、JSONドキュメント全体に対するキー値の割合が小さいほどよく得られます。
-
JSONインデックスは特定のキーベースクエリのターゲット最適化に適しており、ストレージオーバーヘッドが低くなります。単純なJSON構造に適しています。JSON shreddingは配列内のキーに対するクエリをカバーしないことに注意してください。そのため、それらを高速化するにはJSONインデックスが必要です。
詳細についてはJSONフィールドの概要を参照してください。
-