Postgres 9.1 vs MySQL 5.6 InnoDB?

Einfache Frage - Was wäre besser für eine mittelgroße / große Datenbank mit der Anforderung an die Kompatibilität mit ACID im Jahr 2012?

Ich habe alles (gut die meisten) über mySQL vs pgSQL gelesen, aber die meisten dieser Beiträge beziehen sich auf Version 4.5.1 bzw. 7.8 und sind ziemlich veraltet (2008, 2009). Es ist jetzt fast 2012, also könnten wir versuchen, das Problem neu zu betrachten.

Grundsätzlich würde ich gerne wissen, ob es in PostgreSQL etwas gibt, das die Benutzerfreundlichkeit, Verfügbarkeit und die größere Entwickler- / Wissensbasis von MySQL übertrifft.

Ist der Abfrageoptimierer von MySQL immer noch dumm? Ist es bei sehr komplizierten Abfragen immer noch sehr langsam?

Schieß los! :) :)

PS. Und schick mich nicht zu Brille oder Wiki. Ich suche nach wenigen spezifischen Punkten, nicht nach einer Übersicht + Ich vertraue StackOverflow mehr als einer zufälligen Seite, auf der 'kluger Kerl' sein Licht erstrahlt.

Nachtrag

Projektgröße : Nehmen wir ein Bestellsystem mit ungefähr 10-100 Bestellungen / Tag pro Konto, ein paar tausend Konten, schließlich kann jedes mehrere hundert bis mehrere tausend Benutzer haben.

Besser in : zukunftssicher und flexibel sein, wenn es um wachsende und sich ändernde Anforderungen geht. Leistung ist auch wichtig, um die Kosten in der Hardwareabteilung niedrig zu halten. Auch die Verfügbarkeit qualifizierter Arbeitskräfte wäre ein Faktor.

OLTP oder OLAP : OLTP

Ist der Abfrageoptimierer von MySQL immer noch dumm? Ist es bei sehr komplizierten Abfragen immer noch sehr langsam?

Alle Abfrageoptimierer sind manchmal dumm. PostgreSQL ist in den meisten Fällen weniger dumm. Einige der neueren SQL-Funktionen von PostgreSQL (Fensterfunktionen, rekursive WITH-Abfragen usw.) sind sehr leistungsfähig, aber wenn Sie ein dummes ORM haben, können sie möglicherweise nicht verwendet werden.

Größe des Projekts: Nehmen wir ein Bestellsystem mit ungefähr 10-100 Bestellungen / Tag pro Konto, ein paar tausend Konten, schließlich kann jedes mehrere hundert bis mehrere tausend Benutzer haben.

Klingt nicht so groß - in Reichweite einer großen Kiste.

Besser in: zukunftssicher und flexibel sein, wenn es um wachsende und sich ändernde Anforderungen geht.

PostgreSQL verfügt über ein starkes Entwicklerteam mit einer erweiterten Community von Mitwirkenden. Freigaberichtlinie sind streng und enthalten nur Bugfixes in den Punkt-Releases. Verfolgen Sie immer die neueste Version von 9.1.x für die Bugfixes.

MySQL war in der Vergangenheit etwas entspannter gegenüber Versionsnummern. Dies kann sich ändern, wenn Oracle verantwortlich ist. Ich bin mit den Richtlinien der verschiedenen Gabeln nicht vertraut.

Leistung ist auch wichtig, um die Kosten in der Hardwareabteilung niedrig zu halten.

Es würde mich wundern, wenn sich Hardware als Hauptbestandteil eines Projekts dieser Größe herausstellen würde.

Auch die Verfügbarkeit qualifizierter Arbeitskräfte wäre ein Faktor.

Das ist dein Schlüsselentscheider. Wenn Sie ein Team von erfahrenen Perl + PostgreSQL-Hackern haben, die im Leerlauf saßen, verwenden Sie das. Wenn Ihre Leute Lisp und MySQL kennen, verwenden Sie das.

OLTP oder OLAP: OLTP

PostgreSQL war schon immer stark in OLTP.

Mein persönlicher Standpunkt ist, dass die PostgreSQL-Mailingliste voller höflicher, hilfsbereiter und sachkundiger Personen ist. Sie haben direkten Kontakt zu Benutzern mit Terabyte-Datenbanken und Hackern, die wichtige Teile des Codes erstellt haben. Die Qualität des Supports ist wirklich hervorragend.

PostgreSQL ist in Bezug auf SQL-Funktionen viel weiter fortgeschritten.

Dinge, die MySQL noch nicht hat (und PostgreSQL hat):

• aufschiebbare Einschränkungen

• Einschränkungen überprüfen (MySQL 8.0. 16 hat sie hinzugefügt, MariaDB 10.2 hat sie)

• Vollständiger äußerer Join
  MySQL verwendet stillschweigend einen inneren Join mit einigen Syntaxvarianten:
  https://rextester.com/ADME43793
  

• seitliche Verbindungen

• reguläre Ausdrücke funktionieren nicht mit UTF-8 (behoben mit MySQL 8.0 )

• Reguläre Ausdrücke unterstützen weder Ersetzen noch Teilzeichenfolgen (eingeführt mit MySQL 8.0 ).

• Tabellenfunktionen ( select * from my_function())

• allgemeine Tabellenausdrücke (eingeführt mit MySQL 8.0 )

• rekursive Abfragen (eingeführt mit MySQL 8.0 )

• beschreibbare CTEs

• Fensterfunktionen (eingeführt mit MySQL 8.0 )

• funktionsbasierter Index

• Teilindex

• Zusätzliche Spalte in einen Index aufnehmen (z. B. für eindeutige Indizes)

• mehrspaltige Statistiken

• Volltextsuche in Transaktionstabellen (MySQL 5.6 unterstützt dies)

• GIS-Funktionen für Transaktionstabellen

• EXCEPT- oder INTERSECT-Operator (MariaDB hat sie)

• Sie können eine temporäre Tabelle nicht zweimal in derselben select-Anweisung verwenden

• Sie können die zu ändernde Tabelle (Aktualisieren / Löschen / Einfügen) nicht in einer Unterauswahl verwenden

• Sie können keine Ansicht erstellen, die eine abgeleitete Tabelle verwendet (möglich seit MySQL 8.0).

    create view x as select * from (select * from y);
  

• Lesekonsistenz auf Anweisungsebene. Wird benötigt für zB:
  update foo set x = y, y = xoder
  update foo set a = b, a = a + 100

• Transaktions-DDL

• DDL wird ausgelöst

• Ausschlussbeschränkungen

• Schlüssel- / Wertspeicher

• Indizierung vollständiger JSON-Dokumente

• SQL / JSON-Pfadausdrücke (seit Postgres 12)

• Bereichstypen

• Domänen

• Arrays (einschließlich Indizes für Arrays)

• Rollen (Gruppen) zum Verwalten von Benutzerrechten (MariaDB hat sie , eingeführt mit MySQL 8.0 )

• parallele Abfragen (seit Postgres 9.6 )

• parallele Indexerstellung (seit Postgres 11)

• benutzerdefinierte Datentypen (einschließlich Prüfbedingungen)

• materialisierte Ansichten

• benutzerdefinierte Aggregate

• benutzerdefinierte Fensterfunktionen

• richtiger booleanDatentyp
  _{(die Behandlung eines Ausdrucks, der in eine Zahl ungleich Null konvertiert werden kann, als "wahr" ist kein richtiger boolescher Typ)}

Wenn es um räumliche / GIS-Funktionen geht, ist Postgres mit PostGIS auch viel leistungsfähiger. Hier ist ein schöner Vergleich.

Sie sind sich nicht sicher, was Sie als "Benutzerfreundlichkeit" bezeichnen, aber es gibt mehrere moderne SQL-FunktionenIch bin , die ich nicht missen möchte (CTEs, Fensterfunktionen), die für mich "Benutzerfreundlichkeit" definieren.

Jetzt ist PostgreSQL nicht perfekt und wahrscheinlich das Unangenehmste, den gefürchteten VACUUM-Prozess für eine umfangreiche Schreibdatenbank zu optimieren.

Als Ergänzung zur Antwort @a_horse_with_no_name möchte ich einige Funktionen nennen, die mir in PostgreSQL so gut gefallen:

• Arrays Datentyp ;
• hstore-Erweiterung - sehr nützlich zum Speichern von key->valueDaten, um einen Index für Spalten dieses Typs zu erstellen;
• verschiedene Spracherweiterungen - Ich finde Python sehr nützlich, wenn es um unstrukturierte Datenverarbeitung geht.
• distinct on Syntax - Ich denke, dies sollte eine ANSI SQL-Funktion sein, sie sieht für mich sehr natürlich aus (im Gegensatz zur MySQL-Gruppe nach Syntax).
• zusammengesetzte Typen;
• Datensatztypen;
• Vererbung ;
• Funktionen von Version 9.3:
  • Lateral Joins - eine Sache, die ich von SQL Server vermisse (wo es Outer / Cross Apply heißt );
  • native JSON-Unterstützung ;
  • DDL-Trigger ;
  • rekursive , materialisierte , aktualisierbare Ansichten;

PostgreSQL ist eine ausgereiftere Datenbank, hat eine längere Historie, ist ANSI SQL-kompatibler und hat einen wesentlich besseren Abfrageoptimierer. MySQL verfügt über verschiedene Speicher-Engines wie MyISAM, InnoDB und In-Memory. Alle sind in dem Sinne inkompatibel, dass eine SQL-Abfrage, die auf einer Engine ausgeführt wird, bei Ausführung auf einer anderen Engine einen Syntaxfehler verursachen kann. Gespeicherte Prozeduren sind in PostgreSQL besser.