de.wedoany.com-Bericht: Der verteilte PostgreSQL-Anbieter pgEdge hat die Beta-Version von ColdFront vorgestellt, eine PostgreSQL-native Architektur zur Trennung von heißen und kalten Daten. Diese ermöglicht die automatische Migration älterer Daten in den Apache-Iceberg-Objektspeicher, während PostgreSQL die einzige Datenbank bleibt, mit der Anwendungen interagieren müssen.
Seit Jahren unterhalten Unternehmen getrennte Systeme für Transaktionsverarbeitung (OLTP) und Analyse (OLAP), auch wenn dies den Datentransfer zwischen beiden erfordert. Der Aufstieg autonomer Agenten und KI-Anwendungen, die sofortigen Datenzugriff erfordern und große Mengen operativer Daten erzeugen, hat die Kosten und Komplexität der Aufrechterhaltung separater Systeme offengelegt. Die Branche reagiert schnell: Datenlager- und Datenbankanbieter schlagen verschiedene Wege vor, um Datensilos aufzubrechen. In den letzten Wochen haben Databricks LTAP und EDB konvergente Analysen eingeführt, während Snowflake Ende letzten Jahres pg_lake veröffentlichte – alle bieten unterschiedliche Ansätze zur Integration von Transaktions-, Analyse- und KI-Workloads.
ColdFront von pgEdge verwendet eine heiße/kalte Datenschichtung, wobei „heiß" und „kalt" sich auf neuere bzw. ältere Daten beziehen. Laut Phillip Merrick, Mitbegründer von pgEdge, werden Abfragen aktueller Daten weiterhin auf PostgreSQL ausgeführt, während Anfragen zu älteren Datensätzen transparent über die eingebettete Analyse-Engine von DuckDB erfolgen. Anwendungen verwenden dasselbe SQL, ohne dass ETL-Pipelines, separate Abfragepfade oder Anwendungsänderungen erforderlich sind. Ältere, in Iceberg gespeicherte Datensätze können auch über PostgreSQL aktualisiert werden, was Merrick als „beschreibbare Kalt-Schicht" bezeichnet.
Ashish Chaturvedi, Executive Research Lead bei HFS Research, erklärt, dass ColdFront Iceberg lediglich als transparente Speicherschicht hinter PostgreSQL betrachtet, die ältere Daten automatisch aus der Datenbank verschiebt, während Anwendungen dieselben Tabellen und dasselbe SQL verwenden. Im Gegensatz dazu verbindet Databricks‘ LTAP operative Anwendungen mit dem Lakehouse, EDB nutzt PostgreSQL als operative Datenquelle und stellt Daten über Iceberg bereit, während Snowflakes pg_lake PostgreSQL-Daten direkt in Iceberg schreibt, sodass sowohl PostgreSQL als auch Snowflake dieselben Daten abfragen können.
Amit Chandak, Chief Analytics Officer der IT-Beratungsfirma Kanerika, weist darauf hin, dass Unternehmen aus Prüfungs- und Regulierungsgründen historische operative Daten von KI-Anwendungen aufbewahren müssen. Daher ist es entscheidend, Datensätze auch nach der Verschiebung in günstigeren Speicher korrigieren, löschen oder ändern zu können, um Datenschutz- und Privatsphärengesetze einzuhalten. Chaturvedi sagt, ColdFront könne diesen Prozess vereinfachen: „In den meisten Schichtungssystemen sind kalte Daten schreibgeschützt; GDPR-Löschanfragen erfordern Wiederherstellung-Löschen-Neuarchivierung, was einen halben Tag dauert. ColdFront erlaubt UPDATE- und DELETE-Operationen auf archivierte Datenzeilen mit einer einzigen SQL-Anweisung." Igor Ikonnikov, Research Fellow bei Info-Tech Research Group, betont, dass Unternehmen in den Bereichen Finanzen, Gesundheitswesen und Regierung sensible operative Daten auf kundenkontrollierter Infrastruktur halten und gleichzeitig die Möglichkeit zur Änderung historischer Aufzeichnungen bewahren möchten – die Architektur von ColdFront sei hierfür besonders wichtig.
Ikonnikov stellt fest, dass alle Ansätze auf DuckDB angewiesen sind: „ColdFront verwendet DuckDB für Abfragen auf Iceberg-Daten, Snowflakes pg_lake leitet Iceberg-Abfragen über pgduck_server, und Databricks‘ Lakebase ist intern ebenfalls auf DuckDB angewiesen. DuckDB entwickelt sich zur De-facto-eingebetteten Analyse-Engine für die neue PostgreSQL-Iceberg-Architektur." Diese Abhängigkeit birgt ein Konzentrationsrisiko: Sollte DuckDB mit Lizenzänderungen, Sicherheitslücken oder Leistungsengpässen konfrontiert werden, wären mehrere Produkte betroffen. Daher sollten CIOs den Reifegrad und die Roadmap dieser gemeinsamen Komponenten verstehen.
Michael Leone, Principal Analyst bei Moor Insights & Strategy, ist der Ansicht, dass die meisten Unternehmen bereits etablierte Datenarchitekturen haben. CIOs sollten diese Plattformen basierend auf dem Standort ihrer Daten, Entwickler und operativen Workflows bewerten. Er empfiehlt Unternehmen, zunächst Iceberg zu standardisieren, da alle vier Architekturen das offene Tabellenformat unterstützen. Unternehmen könnten so Flexibilität bewahren und bei einem zukünftigen Austausch der Frontend-Datenbank oder Analyseplattform keine zugrunde liegenden Daten migrieren müssen. Ikonnikov warnt vor Problemen bei der Iceberg-Katalogverwaltung: Die vier Methoden verwenden unterschiedliche Kataloge, und die Interoperabilität zwischen Anbietern ist noch nicht gelöst. Wenn Agenten aus verschiedenen Systemen dieselbe Iceberg-Tabelle abfragen müssen, wird die Katalogföderation zur praktischen Herausforderung.
Dieser Artikel wurde von Wedoany übersetzt und bearbeitet. Bei jeglicher Zitierung oder Nutzung durch künstliche Intelligenz (KI) ist die Quellenangabe „Wedoany“ zwingend vorgeschrieben. Sollten Urheberrechtsverletzungen oder andere Probleme vorliegen, bitten wir Sie, uns unverzüglich zu benachrichtigen. Wir werden den entsprechenden Inhalt umgehend anpassen oder löschen.
E-Mail: news@wedoany.com
