Warum basieren so viele MPP-Lösungen auf PostgreSQL anstelle von MySQL?

Astor Data, Greenplum und GridSQL ermöglichen die massive parallele Verarbeitung von SQL-Abfragen. Sie basieren alle auf der PostgreSQL-Technologie. Liegt das nur an Lizenzproblemen oder gibt es andere Gründe? Mir scheint, dass MyISAM nicht ACID-konform ist und daher nicht mit MVCC (wie hier zu sehen ) auf dieselben Probleme stößt, da PostgreSQL für den Aufbau von Hochleistungs-Data Warehouses weitaus besser geeignet ist. Immerhin erfordert das Laden von OLAP keine Transaktionen, soweit ich sehen kann.

Es handelt sich hauptsächlich um ein Lizenzproblem. Diese Entwicklungen führen dazu, dass der Code ziemlich stark gepatcht wird. Wenn Sie sich also mit MySQL befassen möchten, müssen Sie entweder Ihren Code als Open-Source-Code bereitstellen oder für die Dauer Ihres Geschäfts dem Firmeninhaber von MySQL ausgeliefert sein. Einige Angebote für MySQL umgehen dies, indem sie ihre Arbeit als Speicher-Engine implementieren, aber das bietet nicht die Flexibilität, die sie benötigen, und sie patchen immer auch den MySQL-Kern.

Ich kann zwei Gründe sehen:

1) In der Vergangenheit hatte PostgreSQL einen besseren Abfrageplaner und Statistikanalysator. Dies mag jetzt nicht zutreffen, aber vor einigen Jahren war PostgreSQL bei komplexen Abfragen, bei denen es sich um OLAP handelt, viel besser als MySQL.

2) PostgreSQL bietet bessere Funktionen / Trigger / etc Programmierunterstützung.

Wie Peter Eisentraut richtig hervorhob, handelt es sich in erster Linie um ein Lizenzproblem. Postgres ist unter einer BSD-ähnlichen Vereinbarung lizenziert, die es im Wesentlichen zu einem "kostenlosen für alle" macht, solange Sie die ursprünglichen Entwickler für Ihre abgeleiteten Arbeiten gutschreiben.

Die Debatte zwischen MVCC und Locking Scheduler war Gegenstand von mehr als ein paar "heiligen Kriegen" im Internet. Die Debatten über die Vorzüge verschiedener Speicher-Engines waren gleichermaßen umstritten.

Die Vorteile verschiedener Row-Major-Speicher-Engines (auch bekannt als Row-Store-Speicher-Engines) sind meiner Meinung nach aus zwei Gründen für MPP-RDBMS, die für analytische Workloads entwickelt wurden, weitgehend irrelevant:

1. Während die Besonderheiten der Speicher-Engine für die Verarbeitung von ACID-Transaktionen in Workloads vom Typ OLTP wichtig sind, müssen Sie in einer typischen Data Warehousing-Umgebung nur einen Typ von "Transaktion" unterstützen - ein Batch-Laden. Im Idealfall sollte die Batch-Ladung entweder vollständig erfolgreich sein oder vollständig fehlschlagen.
2. Analytische Datenbanken, die auf Spaltenspeicher-Speicher-Engines basieren, übertreffen in vielen Fällen jede Zeilenspeicher-Implementierung. Vertica war von Anfang an ein Spaltenspeicher. Teradata und Greenplum haben ihren Produkten kürzlich Funktionen für Spaltenspeicher hinzugefügt.

Ich habe ein MPP-System auf MySQL erstellt und das System aus zwei Gründen verworfen:

1) ist Oracle

2) ist das Fehlen von Hash-Joins - verschachtelte Schleifen- und Index-Joins skalieren nicht auf das in einem MPP-System erforderliche Niveau - wiederum, weil Oracle die versprochene Bereitstellung von Hash-Joins in der 5.x-Codezeile nach der Übernahme des Eigentums verhindert hat.

MPP-Big-Data-Systeme müssen Verknüpfungen aufweisen, die nicht geometrisch komplex sind. - Lineare oder logarithmische lineare Komplexitätsverknüpfungen müssen eine echte Präferenz für echte Big-Data-Systeme sein.

Ich habe Actian stattdessen vektorweise im neuen DeepCloud MPP-System bereitgestellt und dabei die Nieselregen- / MySQL-Kompatibilität auf Benutzerebene beibehalten.

Benutzer, die eine schnelle Big-Data-Analyse wünschen, können DeepCloud von http://www.deepcloud.co herunterladen