Alles, was Sie vorschlagen, ist ein Rezept für Schmerzen und fehlgeschlagene Migrationen. Die Leute werden darüber schimpfen und schwärmen, wie schrecklich, langsam und unzuverlässig PostgreSQL ist, wenn Sie versuchen, diesen Ansatz zu verwenden. Es wäre ein großartiger politischer Schritt von jemandem, der SQL Server behalten wollte, aber keine gute Möglichkeit, zu PostgreSQL zu migrieren.
Für neuere Pg-Versionen wird es einen Read/Write Foreign Data Wrapper geben, der aber zunächst nur andere PostgreSQL-Server unterstützt. Die Unterstützung von MS SQL wäre aufgrund der Notwendigkeit, sqlstates und Fehlermeldungen, Suchbedingungen und mehr zu übersetzen, viel schwieriger, sodass jeder Wrapper zweifellos ziemlich begrenzt wäre und weniger als eine großartige Leistung hätte. Wie Sie sagen, ist die FDW-Unterstützung zu diesem Zeitpunkt ohnehin noch zu unausgereift.
Es gibt einfach so viele Dinge, die Sie verlieren, wenn Sie versuchen, einen Hybrid wie diesen zu erstellen:
-
Keine Erzwingung der Integrität von Fremdschlüsseln
-
Datentypen auf beiden Seiten verhalten sich möglicherweise nicht zu 100 % gleich, sodass die Daten auf der einen Seite in Ordnung sein können und auf der anderen nicht. Denken Sie an Zeitstempel/Daten.
-
Effiziente Verknüpfungen würden einen extrem ausgeklügelten Fremddaten-Wrapper erfordern - was normalerweise passiert, ist, dass die gesamte Tabelle abgerufen und dann lokal verknüpft wird. Die Leistung wird schrecklich sein.
-
Das Schreiben von Abfragen wird zu einem Albtraum, wenn Sie etwas anderes als die trivialste Aufgabe erledigen. Funktionsnamen unterscheiden sich usw.
-
Sie verlieren oder schwächen viele ACID-Eigenschaften und/oder müssen zweiphasiges Commit verwenden, was die Leistung beeinträchtigt.
Im Ernst, tun Sie das nicht.
Das Synchronisieren der DBs ist wahrscheinlich noch schlimmer - es sei denn, es ist eine Möglichkeit, es wird ein Rezept für verlorene Updates, das Wiederauftauchen gelöschter Zeilen und Schlimmeres sein. Die bidirektionale Synchronisierung ist extrem schwer.
Beginnen Sie damit, Ihre Apps auf einen Umzug vorzubereiten, indem Sie sie auf beiden Servern ausführen lassen, aber immer nur auf einem. Sobald Sie die App für die Ausführung auf Pg vorbereitet haben, beginnen Sie mit einigen Auslastungs- und Zuverlässigkeitstests mit einer migrierten Kopie der Live-Daten. dann Denken Sie über eine Migration nach, haben Sie jedoch Pläne, wie Sie den Umzug rückgängig machen können, wenn Sie in letzter Minute Probleme feststellen, die Sie zu einer Verzögerung zwingen.
Wenn Sie der App völlig neue Teile hinzufügen, kann es sinnvoll sein, sie in Pg zu haben, wenn sie überhaupt nicht mit den anderen Daten in der DB interagieren. Das ist jedoch ziemlich unwahrscheinlich, und Ihre Systemadministratoren werden Sie immer noch hassen, wenn Sie ihnen sagen, dass Sie jetzt einen atomaren Snapshot über zwei separate Datenbanken benötigen ...
