Architektura nowoczesnych systemów danych przechodzi fundamentalną zmianę. Zapytaj dewelopera, jak budują systemy danych dzisiaj, a odpowiedź coraz częściej wygląda tak: Postgres dla aplikacji, jezioro dla analityki i nauki o danych. Postgres, od dawna preferowany dla obciążeń transakcyjnych, rozwinął się w ogólnodostępną bazę danych operacyjnych. Jest wiarygodny, elastyczny i głęboko rozszerzalny, obsługujący wszystko od transakcji klientów i aplikacji CRUD, do pulpitów w czasie rzeczywistym i funkcji produktów wspieranych przez sztuczną inteligencję. ), dane geoprzestrzenne (PostGIS), wyszukiwanie wektorowe i pełnotekstowe (pgvector i pgvectorscale) i więcej. TimescaleDB Jednocześnie wzrost technologii otwartych jezior zdefiniował, w jaki sposób organizacje zarządzają danymi i analizują je na skalę.Degregowane magazynowanie, formaty otwartych tabel, takie jak Iceberg, strukturalne katalogi danych i kompostowalne silniki zapytań umożliwiły precyzyjną i kontrolną analizę danych o skali petabajtów. Organizacje coraz częściej muszą obsługiwać obciążenia operacyjne (napędzane bazami danych) i nieoperacyjne obciążenia (napędzane jeziorami), często wykorzystując dane z tych samych źródeł – ludzi, maszyn, systemów cyfrowych lub agentów. W rzeczywistości uważamy, że powstaje nowa, bardziej spójna architektura: ta, która traktuje Postgres i jezioro nie jako odrębne światy, ale jako odrębne warstwy pojedynczego, modułowego systemu, zaprojektowanego w celu zaspokojenia całego spektrum potrzeb operacyjnych i analitycznych. Granice OLTP vs Dichotomia OLAP Stary sposób myślenia o bazach danych był prosty: OLTP do transakcji, OLAP do analizy. Używaliście Postgres do zasilania aplikacji i wysyłaliście nocne prace ETL do magazynu danych dla wewnętrznych raportów i pulpitów.Ta tradycyjna różnica służyła nam dobrze, gdy aplikacje były prostsze, a wewnętrzne raportowanie mogło żyć o wiele wolniej. Nowoczesne aplikacje są obciążone danymi, ukierunkowane na klienta i w czasie rzeczywistym. 
 
 
 
 Aplikacja finansowa może uruchamiać silnik handlowy, który potrzebuje milisekundowego dostępu do portfeli klientów, jednocześnie dostarczając raporty o ryzyku w czasie rzeczywistym i wewnętrzne tablice kontrolne. Aplikacja SaaS nie przechowuje tylko kliknięć – oblicza metryki użytkowania, wyzwala alerty i obsługuje spersonalizowane modele. Przemysłowy system monitorowania może pochłaniać dziesiątki milionów odczytów czujników na godzinę, napędzać wykrywanie anomalii i logikę ostrzegania oraz archiwizować lata telemetrii do długoterminowej analizy i szkolenia modeli AI. Te przypadki użytkowania nie są wyjątkami – szybko stają się normą. We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. Mimo że właścicielstwo tych typów systemów jest podzielone – zespoły inżynieryjne odpowiadające za systemy operacyjne zasilające ich produkty i zespoły danych odpowiedzialne za zarządzanie systemami jeziora jako usługami organizacyjnymi – obie nadal muszą ze sobą rozmawiać. Architektura operacyjna Medallion Jednym z wzorców, które widzimy w uzyskaniu ciągłości, jest to, co nazywamy Zainspirowany modelami medali popularyzowanymi w świecie inżynierii danych, ten wzór zawiera również warstwy brązu, srebra i złota – nie tylko do analiz wewnętrznych, ale także do zasilania systemów w czasie rzeczywistym, zorientowanych na użytkownika. Architektura operacyjna Medallion Oto jak to wygląda: 
 
 
 
 Brązowa warstwa: Surowe dane żyją w plikach Parquet lub Iceberg na AWS S3 lub podobnych systemach pamięci masowej o niskich kosztach. Te dane są zazwyczaj niezmienne, tylko w załączniku i mogą być wyszukiwane przez cokolwiek: silniki zapytań, takie jak AWS Athena, DuckDB, Trino, ClickHouse lub Polars, a nawet bezpośrednio z bazy operacyjnej, takiej jak Postgres. Operacyjna warstwa srebra: Czyszczone, filtrowane, walidowane i deduplikowane dane są zapisywane w Postgres, aby zasilać analizę w czasie rzeczywistym, tablicy kontrolne lub logikę aplikacji produktów ukierunkowanych na użytkownika. Operacyjna warstwa złota: Preagregowane dane nad danymi srebrnymi (takie jak zmaterializowane widoki firmy Postgres lub ciągłe agregaty TimescaleDB) służą doświadczeniom produktów o niskim opóźnieniu i wysokiej konkurencyjności. Ważne jest, że każda warstwa jest kwerendowana, a ten ruch danych jest dwukierunkowy. Możesz wyciągnąć surowe lub przekształcone dane z S3 bezpośrednio do Postgres (zgodnie z ściśle zintegrowanymi odwrotnymi ETL). Możesz przewijać agregaty z Iceberg do tabel Postgres (przez pojedyncze lub stojące zapytania przeciwko plikom Iceberg z Postgres). Możesz nieustannie synchronizować pełny schemat lub pojedynczą tabelę z bazy danych do jeziora. Podobnie jak brązowe (lub przekształcone) dane można odczytać z warstwy przechowywania jeziora na S3 do bazy danych, srebro i złoto w bazie danych można zapisać do tych formatów przechowywania jeziora. Jednym ze wspólnych wzorców, które zaobserwowaliśmy w aplikacjach wymagających nowych danych, jest pisanie z systemu strumieniowego w górę, takiego jak Kafka lub Kinesis. Następnie te srebrne tabele i późniejsze agregaty złota w bazie danych są ponownie wyeksportowane do S3, dzięki czemu zespoły danych mają teraz dostęp do „podstawowych danych prawdy”, które zostały dostarczone klientom. Równolegle Baza operacyjna może być uruchomiona zamknięta - zarówno dla użytkowników, jak i dla nieprzyjaznych zapytań - podczas gdy dane są nadal dostępne jako część otwartego jeziora, gdziekolwiek jest to potrzebne w org. Dlaczego teraz? siły techniczne napędzające zmianę Kilka wydarzeń napędza to przesunięcie z baz operacyjnych i jezior do zintegrowanych. Po pierwsze, Iceberg dojrzał do stabilnego i elastycznego formatu tabeli, który obsługuje ewolucję schematu, transakcje ACID i efektywną kompresję. Umożliwia on wieloma silnikom obliczeniowym czytanie i pisanie do tych samych zbiorów danych - z warstwami katalogów, które śledzą metadane i egzekwują zarządzanie w całym stosie. Po drugie, Postgres nadal ewoluował jako platforma. Dzięki rozszerzeniom do przechowywania kolumn, danych z serii czasowej oraz wyszukiwania wektorowego i hybrydowego – co budujemy w Timescale od lat – Postgres obsługuje teraz wiele produktów, które bezpośrednio zawierają analizy w czasie rzeczywistym i przepływy pracy agentów. Jest to nie tylko warstwa pamięci podręcznej danych dla danych wstępnie obliczonych, ale pełna baza danych SQL do dalszych agregacji, wzbogacania lub dołączania w czasie zapytania. now acts as the serving layer for products incorporating both transactional and analytical data Po trzecie, deweloperzy oczekują kompostowalności. Niektóre organizacje mogą być uwięzione w swoich tradycyjnych monolitycznych platformach danych, ale większość deweloperów i naukowców danych chce elastyczności w tworzeniu własnych stosów, integrując znane narzędzia w sposób odzwierciedlający potrzeby ich aplikacji. Put differently: the market is moving toward modular, open, developer-friendly architectures. Co przyjdzie później Wierzymy, że przyszłość infrastruktury danych będzie kształtowana przez systemy, które głębiej integrują warstwy operacyjne i analityczne – systemy, które traktują Postgres i jezioro jako dwie strony tej samej monety. Pochodzi z ostrożnych interfejsów – synchronizacji stopniowej, wspólnych katalogów, zjednoczonych powierzchni zapytań – i z filozofii architektonicznej, która przyjmuje heterogenizm, a nie walczy z nim. Coś, co opiera się na mocnych stronach Postgres i Iceberg, ściśle integruje się z istniejącymi systemami jezior i znacznie ułatwia budowę pełnych systemów danych z wiarygodnością operacyjną i analityczną. Nie chodzi o wykorzystanie ETL do przenoszenia danych z dawnych systemów do nowych systemów – chodzi o budowanie spójnej nowoczesnej architektury danych, która służy zarówno przypadkom użytkowania operacyjnego, jak i nieoperacyjnego. Zostań w tunelu.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Ten dźwięk jest produkowany w oryginalnym języku historii!

Za długo; Czytać

Make resilience your competitive advantage

Postgres i Lakehouse stają się jednym systemem - oto, co przychodzi dalej

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

The Blockchain Social Experiment: Enforced Logic

Google's Gemini AI: A Thought Experiment in Deception

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

Verified Writers

The Blockchain Social Experiment: Enforced Logic

Google's Gemini AI: A Thought Experiment in Deception

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

Verified Writers

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps