現在、2種類のテーブルにmysqlを使用しています。大規模な参照テーブル用のmysqlの代替方法
最初のセットは、トランザクションベースの典型的なテーブルです。
第2のテーブルは、通常1回書き込まれ、何度も読み込まれる履歴データを格納するテーブルです。それらは大きく、数億またはそれ以上の行があり、インデックスがいくつかあります。
これらの表にはいくつか問題があります。
は、我々はそれがこれらの問題を緩和するだろう欠けているのMySQLのすべての機能はありますか？ MariaDBにはテーブル全体をロックしない列を追加する方法があることがわかりましたが、他の問題は解決しません。
私たちは、問題を解決する可能性のある他の製品も利用しています。何か案は？
なぜ履歴データに列を追加する必要がありますか？とにかく、あなたは '古い'行にどのような値を割り当てますか。
カラムを追加する代わりに、「並列」テーブル（別名「バーチャルパーティショニング」）を作成することもできます。新しいテーブルは元のものと同じPRIMARY KEYを持ちます（AUTO_INCREMENT宣言を除く）。両方のテーブルから列を取得するにはLEFT JOINを使用し、「古い」行は「新しい」列にNULLsを与えることを理解してください。
ヒストリカルデータのもう1つの有用なことは、データウェアハウスのファクトテーブルのように扱うことです。一般的な「レポート」タイプのクエリを大幅に高速化するために、「サマリーテーブル」を構築して維持します。
より新しいバージョンのMySQL/MariaDBでは、ALTER TABLE ... ADD COLUMN ... ALGORITHM=INPLACEがパフォーマンスの痛みのほとんどを取り除きます。
列を追加することは、多くの悪い性質を持つEAVスキーマに向かって移動することによっても解決されます。だから、そのように向かって途中で移動してください。つまり、フィルタリングと並べ替えに使用する5〜10個のメイン列を実際の列として保持し、残りのキー値の迷惑メールをJSON列に配置します。 MySQLとMariaDBの両方にこのような違いがありますが、MariaDBには "Dynamic Columns"があります。
"が、それは他の問題は解決しない" - などを??
履歴テーブルに列を追加する理由は、今後新しい情報を保存する必要があるためです。この新しいデータのために新しいテーブルを追加する問題は、比較的大きなキーを格納することになります（3つのvarcharカラムと日付カラムが主キーを作成します） – bpeikes
何百万という 'NULLs 'もスペースをとります。 （与えられたスペースはあまりありません）それはトレードオフです。あなたは、既存の歴史のための 'SHOW CREATE TABLE'と新しい列の定義を提供することに気をつけますか？それは、私たちがデータのタイプと「比較的大きな」PKを感じるのに役立ちます。助ける他のヒントがあるかもしれません。 –