MySQLの代わりにPostgreSQLをベースにした非常に多くのMPPソリューションがあるのはなぜですか？
Astor Data、Greenplum、GridSQLはすべて、SQLクエリの大規模な並列処理を可能にします。これらはすべてPostgreSQLテクノロジーを中心に構築されています。これは、ライセンスの問題が原因ですか、それとも他の理由がありますか？私には、MyISAMがACIDに準拠していないため、MVCCで同じ問題が発生しないようです（ ここ のように）。PostgreSQLは、高性能データウェアハウスの構築にはるかに適しているためです。結局、OLAP負荷は、私が見る限りトランザクションを必要としません。
主にライセンスの問題です。これらの開発は最終的にコードにかなりのパッチを適用することになるため、MySQLに対処する場合は、コードをオープンソースにするか、ビジネスの全期間にわたってMySQLの企業所有者のなすがままにする必要があります。 MySQLのいくつかのオファーは、仕事をストレージエンジンとして実装することでそれを回避しますが、必要な柔軟性をすべて提供するわけではなく、MySQLコアにも常にパッチを適用します。
私には2つの理由があります。
1）歴史的に、PostgreSQLにはより優れたクエリプランナーと統計アナライザーがありました。これは今は真実ではないかもしれませんが、数年前のPostgreSQLは、複雑なクエリでのMySQLよりもはるかに優れていました。OLAP ones.
2）PostgreSQLの機能/トリガー/その他のプログラミングサポートが向上しています。
Peter Eisentrautが正しく指摘したように、何よりもまずライセンスの問題です。 PostgresはBSDライクな契約に基づいてライセンスされているため、派生物に元の開発者を認めている限り、本質的に「すべての人にとって無料」です。
MVCCとロッキングスケジューラの議論は、オンラインでの「聖戦」の対象となっています。さまざまなストレージエンジンのメリットについての議論は、同様に物議を醸しています。
さまざまな行優先（行ストア）ストレージエンジンのメリットは、次の2つの理由で分析ワークロード用に構築されたMPP RDBMSに関しては、IMHOとはほとんど関係ありません。
- ストレージエンジンの特性はOLTPタイプのワークロードでACIDトランザクションを処理するために重要ですが、一般的なデータウェアハウジング環境では、1つのタイプの「トランザクション」、つまりバッチロードのみをサポートする必要があります。理想的には、完全に成功するか、完全に失敗するのは、バッチロードです。
- 列ストアストレージエンジンに基づく分析データベースは、多くの場合、行ストア実装よりも優れています。 Verticaは当初から列ストアでしたが、TeradataとGreenplumは最近、製品に列ストア機能を追加しました。
MySQLでMPPシステムを構築し、2つの理由でシステムを破棄しました。
1）Oracleです
2）ハッシュ結合の欠如です-ネストされたループとインデックス結合はMPPシステムで必要なレベルにスケーリングされません-所有権を取得した後、Oracleは5.xコード行でハッシュ結合の約束された配信を禁止したためです。
MPPビッグデータシステムには、幾何学的に複雑でない結合が必要です。 -線形または対数線形の複雑性結合は、真のビッグデータシステムに強く優先する必要があります。
ユーザーレベルで霧雨/ MySQLの互換性を維持しながら、代わりに新しいDeepCloud MPPシステムにActian vectorwiseをデプロイしました。
高速なビッグデータ分析を必要とするユーザーは、DeepCloudを http://www.deepcloud.co からダウンロードできます。