株式分析リポジトリの最初のバージョンでは分析を OLTP エンジン上で実行していましたが、2 番目のバージョンでは同じワークロードを OLAP スタック上で実行しています。私は一つの最適化のために OLAP スタックを選びましたが、その恩恵を受けるにはレイクハウス全体を理解する必要がありました。
InnoDB の設計には、初期の選択を形作った三つの保証があります。行のすべての列がまとめて格納されるため、一つの銘柄の一本のバーを取得するにはディスク上の一か所にアクセスするだけで済み、取り込みに適しています。ただし、二つの列しか必要としない指標でも、バッファプールを通じてすべての列を読み込みます。インデックスは読み取りを速めますが、書き込みを遅くします。書き込みのたびにテーブル内のすべての B ツリーを更新しなければならないからです。これは選択的な読み取りには優れていますが、書き込み負荷の高い取り込みには非常に不向きです。そのため、私の Raw* テーブルは主キーのみを持っています。
InnoDB はまた undo ログも使用し、並行した読み取りと書き込みを可能にしています。行が更新または削除されると古い値が保存され、他のセッションがそれを読み続けられるようになります。挿入では、より小さな undo ログが作られ、コミット時に消去されます。更新と削除の undo ログはグローバルな履歴リストに連なり、コミットより前に開始されたすべてのセッションが終了すると InnoDB がそれらを削除します。この仕組みが Multi-Version Concurrency Control、すなわち MVCC であり、読み取りをブロックせずに挿入と更新を行えるようにしています。
気づかないうちに、私は InnoDB データベースを OLAP の基本原則に基づいて設計していました。financialdata テーブルには日時と OHLC 価格が格納されていて、各テクニカル指標は日付を見つけるためにそのテーブルとの結合を必要としました。これは私の最悪のデータ設計の一つで、データベースが 100GB を超えるまで気づきませんでした。修正は非常に大変でした。
出典: Hacker News · 要約：HeadlinesBriefing