web-dev-qa-db-ja.com

Postgres 9.1対Mysql 5.6 InnoDB？

簡単な質問-2012年にACIDとの互換性が要求される中規模/大規模のデータベースには何が良いでしょうか。

私はmySQLとpgSQLのすべて（ほとんど）を読みましたが、それらの投稿のほとんどはそれぞれバージョン4,5.1と7,8に関連しており、かなり古くなっています（2008,2009）。ほぼ2012年になりましたので、この問題を再確認してみてください。

基本的に、PostgreSQLの使いやすさ、可用性、およびMySQLのより大きな開発者/知識ベースを上回るものがあるかどうかを知りたいと思います。

MySQLのクエリオプティマイザーはまだ愚かですか？非常に複雑なクエリではまだ非常に遅いですか？

ピンときた！ :)

PS。また、ゴーグルやウィキに送らないでください。概要ではなく、いくつかの特定のポイントを探しています+私はStackOverflowを、「スマートな男」が光を放つランダムページよりも信頼しています。

補遺

プロジェクトのサイズ：アカウントごとに約10〜100注文/日、数千アカウント、最終的にはそれぞれが数百の注文システムがあるとします数千人のユーザーに。

Better at：要件の拡大と変更に関して、将来の保証と柔軟性を備えています。パフォーマンスは、ハードウェア部門のコストを低く抑えるためにも重要です。また、熟練した労働力の確保も要因となります。

OLTPまたはOLAP：OLTP

mysqlpostgresql
69
RandomWhiteTrash

MySQLのクエリオプティマイザーはまだ愚かですか？非常に複雑なクエリではまだ非常に遅いですか？

Allクエリオプティマイザーは時々愚かです。ほとんどの場合、PostgreSQLは愚かではありません。 PostgreSQLの最近のSQL機能の一部（ウィンドウ関数、再帰的なWITHクエリなど）は非常に強力ですが、ダムORMを使用している場合は使用できない可能性があります。

プロジェクトのサイズ：1アカウントあたり約10〜100注文/日、数千アカウント、最終的にはそれぞれが数百から数千のユーザーを持つことができる注文システムを考えます。

大きな音はしません-大きな箱に届く範囲です。

優れた点：要件の成長と変化に関して、将来の保証と柔軟な対応。

PostgreSQLには強力な開発者チームがあり、貢献者のコミュニティが広がっています。 リリースポリシー は厳密であり、ポイントリリースではバグ修正のみです。バグ修正のために9.1.xの最新リリースを常に追跡してください。

MySQLの過去のバージョン番号に対する態度はやや緩和されていました。これは、Oracleが担当することで変わる可能性があります。私はさまざまな分岐のポリシーに精通していません。

パフォーマンスは、ハードウェア部門のコストを低く抑えるためにも重要です。

ハードウェアがこのサイズのプロジェクトの主要なコンポーネントであることが判明した場合、私は驚くでしょう。

また、熟練した労働力の確保も要因となります。

それがあなたの重要な決定者です。経験豊富なPerl + PostgreSQLハッカーのチームがアイドル状態で座っている場合は、それを使用してください。人々がLISPとMySQLを知っているなら、それを使用してください。

OLTPまたはOLAP：OLTP

PostgreSQLは常にOLTPに強いです。

私の個人的な観点では、PostgreSQLのメーリングリストには礼儀正しく、親切で知識豊富な人々がた​​くさんいます。コードの大部分を構築したテラバイトのデータベースとハッカーを持つユーザーと直接連絡を取ります。サポートの質は本当に優れています。

57
Richard Huxton

PostgreSQLは、SQL機能に関してはるかに高度です。

MySQLにはまだないもの（そしてPostgreSQLにはあるもの）：

  • 遅延可能な制約
  • チェック制約 （MySQL 8.0。16はそれらを追加しました。MariaDB10.2にはあります）

  • 完全外部結合
    MySQLは、いくつかの構文バリエーションを持つ内部結合をサイレントに使用します。
    https://rextester.com/ADME4379

  • 横結合

  • 正規表現 機能しない UTF-8 （ MySQL 8. で修正）
  • 正規表現は置換または部分文字列をサポートしていません （ MySQL 8. で導入）
  • テーブル関数（select * from my_function()）
  • 共通テーブル式 （ MySQL 8. で導入）
  • 再帰クエリ （ MySQL 8. で導入）
  • 書き込み可能なCTE
  • ウィンドウ関数 （ MySQL 8. で導入）
  • 関数ベースのインデックス
  • 部分インデックス
  • マルチカラム統計
  • トランザクションテーブルでの全文検索 （MySQL 5.6はこれをサポートします）
  • トランザクションテーブルのGIS機能
  • EXCEPTまたはINTERSECT演算子
  • 同じselectステートメントで一時テーブルを2回使用することはできません
  • サブセレクトで変更中のテーブル（更新/削除/挿入）を使用することはできません。

  • 派生テーブルを使用するビューを作成することはできません（MySQL 8.0以降で可能）

     create view x as select * from (select * from y);
  • 文レベルの読み取り一貫性。以下に必要：
    update foo set x = y, y = xまたは
    update foo set a = b, a = a + 100
  • トランザクションDDL
  • DDLトリガー
  • 除外制約
  • キー/値ストア
  • 完全なJSONドキュメントのインデックス作成
  • 範囲タイプ
  • ドメイン
  • 配列（配列のインデックスを含む）
  • ユーザー特権を管理するロール（グループ） （MariaDB 持っている 、 MySQL 8.0で導入 ）
  • 並列クエリ（Postgres9.6以降）
  • ユーザー定義のデータ型（チェック制約を含む）
  • マテリアライズドビュー
  • カスタム集計
  • カスタムウィンドウ関数
  • 適切なbooleanデータ型
    （ゼロ以外の数値に変換できる式を「true」として扱うことは、not適切なブール型です）

Spatial/GIS機能に関しては、PostGISを備えたPostgresの方がはるかに優れています。 ここ はすてきな比較です。

あなたが「使いやすさ」と呼んでいるものはわかりませんが、私にとって「使いやすさ」を定義するいくつかの 現代のSQL機能 があります。

現在、PostgreSQLは完璧ではなく、恐らく最も不快なことは、恐ろしいVACUUMプロセスを大量の書き込みデータベースに合わせて調整することです。

73
a_horse_with_no_name

@ a_horse_with_no_name answer の追加として、PostgreSQLでとても気に入っている機能に名前を付けたいと思います。

10
Roman Pekar

PostgreSQLはより成熟したデータベースであり、長い歴史があり、ANSI SQLに準拠しています。クエリオプティマイザーは非常に優れています。 MySQLには、MyISAM、InnoDB、インメモリなどのさまざまなストレージエンジンがあり、1つのエンジンで実行されるSQLクエリが別のエンジンで実行されると構文エラーが発生する可能性があるという意味で、すべて互換性がありません。 PostgreSQLではストアドプロシージャの方が優れています。

2
Sergey Grigoriev