同じ仕事、2つのエンジン：InnoDBとIcebergの内部構造
Same Job, Two Engines: InnoDB and Iceberg Internals
OLTPエンジンのInnoDBからOLAPスタックのIcebergへと分析基盤を移行した経験を、両者の内部構造の違いから解説する。InnoDBのMVCCやB-treeインデックス、Icebergのマニフェストとデータファイルによる多層的なクエリ最適化を比較し、分析ワークロードに適したエンジン選択の重要性を説く。
5年目にして、自分の分析作業はテーブルごとに2、3列しか使っていないのに、毎回すべての列を読まされていることに気づいた。
- sgarland
> InnoDBの3つの保証
行はすべてのカラムをまとめて保存する
これは保証されていない。DYNAMIC（デフォルト）およびCOMPRESSED行フォーマット[0]では、可変長カラムのより大きな値をオフページレコードに移動させることがある。与えられた例ではこれは起こらないだろうが、それ自体は保証ではない。これはおおよそPostgresのTOASTに相当するが、PostgresのTOASTのデフォルトしきい値はページの1/4（デフォルトの8 KiBページサイズで2 KiB）であるのに対し、InnoDBはページの1/2（デフォルトの16 KiBページサイズで8 KiB）である。
0: https://dev.mysql.com/doc/refman/9.7/en/innodb-row-format.ht...
- wood_spirit
新しいことを学び、それを共有する個人的な旅を垣間見ることができて良いですね。
次のステップとしては、代わりにDuckDBを試してみることをお勧めします。私の推測では、この規模ではSparkなどを圧倒するでしょう。データランドスケープの異なる角落を学ぶのは常に良いことです。