Arkitekturen af moderne datasystemer gennemgår en grundlæggende forandring. Spørg en udvikler, hvordan de bygger datasystemer i dag, og svaret ser i stigende grad sådan ud: Postgres for applikationen, et søhus for analysen og data videnskaben. Postgres, længe foretrukket for transaktionsarbejdsbelastninger, har udviklet sig til en generel operationel database. Det er pålidelig, fleksibel og dybt udvidelig, der giver strøm til alt fra kundetransaktioner og CRUD-apps til realtids dashboards og AI-støttede produktfunktioner. dets økosystem er vokset til at understøtte realtidsanalyse ( ), geospatial data (PostGIS), vektor og fuldtekst søgning (pgvector og pgvectorscale), og mere. TimescaleDB Desaggregeret lagring, åbne tabelformater som Iceberg, strukturerede datakataloger og komposterbare forespørgselsmotorer har gjort det muligt at analysere petabyte-skala data med præcision og kontrol. Denne arkitektur kan tilbyde styring, undgå leverandørlåsning og stadig give data teams fleksibilitet i deres valg af værktøjer. Organisationer har i stigende grad brug for at understøtte både operationelle arbejdsbyrder (drevet af databaser) og ikke-operative arbejdsbyrder (drevet af søhuse), ofte ved hjælp af data fra de samme kilder – mennesker, maskiner, digitale systemer eller agenter. Faktisk mener vi, at en ny, mere sammenhængende arkitektur er ved at dukke op: en, der behandler Postgres og søhuset ikke som separate verdener, men som separate lag af et enkelt, modulært system, der er designet til at opfylde hele spektret af operationelle og analytiske behov. Grænserne for OLTP vs OLAP Dichotomy Den gamle måde at tænke på databaser på var enkel: OLTP til transaktioner, OLAP til analyse. Du brugte Postgres til at drive din app, og sendte ETL-jobs om natten til et datalager til interne rapporter og dashboards. Denne traditionelle sondring tjente os godt, når applikationer var enklere, og intern rapportering kunne leve på en meget langsommere cadence. Moderne applikationer er data-tunge, kunde-faced, og real-time af design. 
 
 
 
 En finansiel app kan køre en handelsmotor, der har brug for millisekund adgang til kundeporteføljer, samtidig med at den leverer realtidsrisikorapporter og interne dashboards. En SaaS-app gemmer ikke kun klik – den beregner brugsmålinger, udløser advarsler og leverer personlige modeller. Et industrielt overvågningssystem kan indtage titusinder af millioner af sensorlæsninger i timen, drive anomali detektion og advarsel logik, og arkiv år af telemetri til langsigtet analyse og AI model træning. Disse tilfælde af brug er ikke outliers - de bliver hurtigt normen. We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. Men selv om ejerskabet af disse typer systemer er splittet – produktteknikteams, der er ansvarlige for de operativsystemer, der driver deres produkter, og datateams, der er ansvarlige for at styre lakehouse-systemer som organisatoriske tjenester – behøver de to stadig at tale med hinanden. En operationel medaljearkitektur Et mønster, vi ser få trækkraft, er det, vi kalder en Inspireret af de medaljongmodeller, der er populære i datateknikverdenen, indeholder dette mønster også bronze-, sølv- og guldlag – ikke kun til intern analyse, men også til at drive realtids- og brugerorienterede systemer. Operativ medaljearkitektur Her er hvad det ser ud til: 
 
 
 
 Bronze Layer: Rå data lever i Parquet- eller Iceberg-filer på AWS S3 eller lignende billige bundløse lagringssystemer. Disse data er typisk uforanderlige, kun vedhæftede og kan søges af noget: forespørgselsmotorer som AWS Athena, DuckDB, Trino, ClickHouse eller Polars, eller endda direkte fra en operationel database som Postgres. Operativt sølvlag: Rensede, filtrerede, validerede og deduplicerede data skrives i Postgres for at drive realtidsanalyse, dashboards eller applikationslogik af brugerorienterede produkter. Operational Gold Layer: Pre-aggregerede data over sølvdata (såsom Postgres materialiserede visninger eller TimescaleDB's kontinuerlige aggregater) tjener lav-latens, høj-konkurrence produktoplevelser. Du kan trække rå eller transformerede data fra S3 direkte ind i Postgres (tilpasset tæt integreret omvendt ETL). Du kan rulle aggregeringer fra Iceberg op i Postgres tabeller (ved engangs- eller stående forespørgsler mod Iceberg filer fra Postgres). Du kan kontinuerligt synkronisere et fuldt diagram eller en enkelt tabel fra databasen til søhuset. Ligesom bronze (eller transformerede) data kan læses fra lageret lageret lageret på S3 til databasen, sølv og guld i databasen kan skrives til disse lageret lageret formater. Et almindeligt mønster, vi har observeret i applikationer, der kræver friske data, er at skrive fra et upstream streaming-system som Kafka eller Kinesis til både S3 (for række, umodificerede bronzedata) og Postgres (afhængig af databasesystemer og begrænsninger for datavalidering). Så eksporteres disse sølvtabeller og efterfølgende guldaggregater i databasen igen til S3, så data teams nu har adgang til de "jordiske sandhedsdata", der var blevet serveret til kunder. Parallelt med Den operationelle database kan køre låst ned - både til brugere og uvenlige forespørgsler - mens data stadig stilles til rådighed som en del af det åbne søhus, hvor det er nødvendigt i org. Tekniske kræfter, der driver skiftet Flere udviklinger driver denne skift fra de operationelle databaser og søhuse fra at blive siloed til integreret. For det første har Iceberg modnet til et stabilt og fleksibelt tabelformat, der understøtter skemaevolution, ACID-transaktioner og effektiv komprimering. Det gør det muligt for flere beregningsmotorer at læse fra og skrive til de samme datasæt – med kataloglag, der sporer metadata og håndhæver styring på tværs af stakket. For det andet har Postgres fortsat med at udvikle sig som en platform. Med udvidelser til kolonneopbevaring, tidsseriedata og vektor- og hybridsøgning – hvad vi har bygget på Timescale i årevis – tilbyder Postgres nu mange produkter, der integrerer realtidsanalyse og agentiske arbejdsprocesser direkte. Og med den nye støtte til forespørgsel efter S3- og Iceberg-data direkte fra Postgres, er det i stigende grad muligt at integrere S3-hostede data direkte. Dette er ikke kun et data caching lag for forudberegnede data, men en fuldstændig SQL-database til yderligere aggregeringer, berigelse eller JOINs på forespørgselstidspunktet. now acts as the serving layer for products incorporating both transactional and analytical data For det tredje forventer udviklere komposibilitet. Nogle organisationer kan være fastholdt med deres arvede monolitiske dataplatforme, men de fleste udviklere og dataforskere ønsker fleksibilitet til at komponere deres egne stacks, integrere velkendte værktøjer på måder, der afspejler deres applikations behov. Put differently: the market is moving toward modular, open, developer-friendly architectures. Hvad kommer næste Vi mener, at fremtidens datainfrastruktur vil blive formet af systemer, der integrerer operationelle og analytiske lag dybere – systemer, der behandler Postgres og søhuset som to sider af samme mønt. Det vil komme fra omhyggelige grænseflader - incrementel synkronisering, delte kataloger, unificerede forespørgselsoverflader - og fra en arkitektonisk filosofi, der omfavner heterogenitet i stedet for at bekæmpe det. Vi arbejder på noget nyt i dette rum, som bygger på styrkerne i Postgres og Iceberg, integrerer tæt med eksisterende søhussystemer og gør det dramatisk nemmere at opbygge full-stack datasystemer med operationel og analytisk troværdighed. Det handler ikke om at bruge ETL til at flytte data fra gamle systemer til nye systemer – det handler om at opbygge en sammenhængende moderne dataarkitektur, der tjener både operationelle og ikke-operative brugssager. Hold dig tunet.

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

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Denne lyd er produceret på historiens originalsprog!

For langt; At læse

Make resilience your competitive advantage

Postgres og Lakehouse bliver ét system - her er hvad der kommer næste

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Timescale: HackerNoon Company of the Week

Meet MinIO: The HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Timescale: HackerNoon Company of the Week

Meet MinIO: The HackerNoon Company of the Week

Meet Octopus Network: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps