- AWS tagad ļauj Aurora PostgreSQL nolasīt Apache Iceberg un Apache Parquet datus no S3 un S3 tabulām, vispirms tos neielādējot datubāzē.
- Funkcija izmanto iegultu DuckDB dzinēju, aurora_analytics paplašinājumu un IAM lomu ar piekļuvi S3 un AWS Glue.
- Atbalstītās versijas ir Aurora PostgreSQL 17.11 un jaunākas versijas, kā arī Aurora PostgreSQL 18.6 un jaunākas versijas komerciālajos un GovCloud reģionos.
- Komandas var apvienot tiešraides transakciju rindas ar Lakehouse datiem, kešatmiņā saglabāt rezultātus un materializēt aktuālos datu kopumus lasīšanai ar zemu latentumu.
Amazon Web Services ir pavēris jaunu ceļu Aurora PostgreSQL klasteriem, kuriem nepieciešams apvienot ikdienas lietojumprogrammu ierakstus ar failiem, kas atrodas datu ezerā. Pārvaldītā datubāze tagad var lasīt Apache Iceberg tabulas un Apache Parquet failus, vispirms tos nekopējot Aurora, tāpēc viens SQL priekšraksts var aptvert gan tiešraides darbības rindas, gan arhivēto informāciju. Šis solis ir paredzēts komandām, kurām ir apnicis veidot un pieskatīt uzdevumus, izgūt, pārveidot un ielādēt tikai tāpēc, lai atbildētu uz jautājumiem, kas aptver pašreizējos un vēsturiskos datus.
Tā vietā, lai datu ezeru uzskatītu par atsevišķu pasauli, pakalpojums ļauj esošajiem PostgreSQL klientiem, rīkiem un galapunktiem piekļūt ezera saturam, izmantojot svešas tabulas. Tas nozīmē, ka operatīvajā datubāzē nav jāatrodas vēsturiskā datu kopuma dublikātam , un lietojumprogrammu izstrādātāji var turpināt izmantot jau zināmo sintaksi. AWS piedāvā šo iespēju, lai samazinātu cauruļvada uzturēšanu, samazinātu infrastruktūras izplešanos un atvieglotu darījumu bagātināšanu ar vecāku kontekstu.
Ko maina jaunā Aurora PostgreSQL iespēja
Šī funkcija nav atsevišķs analītikas produkts, kas klientiem jāievieš citur. To iespējo aurora_analytics paplašinājums un AWS Identity and Access Management loma, kas piešķir klasterim atļauju piekļūt Amazon S3 un AWS Glue Data Catalog. Kad šī loma un paplašinājums ir ieviesti, administratori izveido svešas tabulas, kas norāda uz Iceberg vai Parquet datiem, un veic vaicājumus tajās līdzīgi kā parastās PostgreSQL tabulas.
Ievērojama arhitektūras daļa ir tā, ka DuckDB ir tieši iegults Aurora . Atvērtā pirmkoda analītiskais dzinējs apstrādā Lakehouse failu skenēšanu, kamēr Aurora turpina apkalpot operatīvās darba slodzes. Vaicājumu apstrāde notiek datubāzes vidē, kas ļauj izvairīties no uzdevuma nodošanas atsevišķam klasterim un palīdz kontrolēt latentumu un tīkla noslodzi.
Atbalstītie avoti ietver Iceberg tabulas, kas reģistrētas AWS Glue datu katalogā, Parquet un Iceberg objektus Amazon S3, kā arī datus, kas glabājas S3 tabulās. Ārējiem katalogiem, kas seko Iceberg REST Catalog saskarnei, var piekļūt arī, izmantojot federāciju ar Glue, tāpēc komandām nav jāatsakās no jau esošajiem katalogu ieguldījumiem. Vaicājums var apvienot rindas no Aurora ar Iceberg tabulām, kas izkliedētas vairākos katalogos, nodrošinot lietojumprogrammām vienotu skatu, nepārvietojot failus.
Versijas, iestatīšana un atbalstītie pakalpojumi
Atbalstītās versijas ir Aurora PostgreSQL 17, sākot ar versiju 17.11, un Aurora PostgreSQL 18, sākot ar versiju 18.6. Pēc klastera izveides vai izvēles administrators pievieno IAM lomu ar AuroraAnalytics funkciju un ieslēdz paplašinājumu. Iestatīšanu var veikt, izmantojot Amazon RDS konsoli vai PostgreSQL klientu, piemēram, psql.
Ārzemju tabulu definīcijas var izveidot pa vienai, bet lielākās vidēs var izmantot IMPORT FOREIGN SCHEMA , lai vienā solī ģenerētu daudzas ārvalstu tabulas no AWS Glue Data Catalog datubāzes. Parquet failiem Aurora var nolasīt shēmu no failu metadatiem, kas novērš nepieciešamību manuāli izvadīt katru kolonnu. Šī detaļa ir svarīga komandām ar plašiem vai bieži mainīgiem datu kopumiem.
Lasīšanas vaicājumus var palaist rakstīšanas instancē vai lasīšanas replikā, tāpēc analītiskās skenēšanas var novirzīt no primārās operacionālās darba slodzes. Komandas, kas raksta datus Aurora, piemēram, CREATE TABLE AS SELECT, INSERT INTO … SELECT vai MERGE INTO, palaistas rakstīšanas instancē . Tas dod komandām iespēju materializēt aktuālos Lakehouse datus vietējā tabulā, kad tām ir nepieciešamas konsekventi ātras atbildes.
Lai redzētu, ko vaicājums dara, administratori var izsaukt funkciju aurora_analytics_stat_statements(). Funkcija ziņo par tādiem rādītājiem kā skenētās rindas, no Amazon S3 nolasītie baiti un kešatmiņas trāpījumi . Bieži izmantotie dati tiek kešatmiņā saglabāti Aurora instancē, tāpēc atkārtota piekļuve vieniem un tiem pašiem Lakehouse objektiem var atgriezties ātrāk, atkārtoti neizvelkot tos pašus baitus no objektu krātuves.
Veiktspējas, kešatmiņas un zema latentuma ceļi
Aurora izmanto predikātu izstumšanu uz leju un kolonnu apgriešanu , kas nozīmē, ka no datu ezera tiek pieprasītas tikai atbilstošās rindas un kolonnas. Pieaugot pamatā esošajam datu kopumam, šī filtrēšana palīdz novērst vaicājumu pārvēršanos pilnos skenējumos. Kešatmiņā saglabātie rezultāti un vaicājumu statistika sniedz operatoriem praktisku veidu, kā pielāgot darba slodzes, nevis minēt, kur tiek pavadīts laiks.
Lietojumprogrammām, kurām nepieciešama viencipara milisekundes latentums, AWS norāda uz materializāciju kā izeju. Atlasītos datu ezera ierakstus var kopēt vietējā Aurora PostgreSQL tabulā, izmantojot pazīstamās SQL komandas, pēc tam tie tiek vaicāti tāpat kā jebkura cita lokālā tabula. Tas nodrošina ātru ceļu uz aktuālākajiem datiem, vienlaikus atstājot pilnu datu ezeru pieejamu plašākai analīzei.
Uzņēmums kā tipiskus lietošanas gadījumus uzskaita reāllaika informācijas paneļus, ar vēsturisku kontekstu bagātinātus darījumus un mākslīgā intelekta aģentus, kuriem ir jāizvērtē gan pašreizējie, gan arhivētie ieraksti. Kopīgā iezīme ir darba slodze, kas nevar gaidīt ikdienas paketi vai apgriezto ETL uzdevumu. Ļaujot lietojumprogrammai pieprasīt no vienas datubāzes gan jaunu, gan vecu informāciju, AWS cer novērst atkārtotu cauruļvada sarežģītības avotu.
Pieejamība un cenas
Saskaņā ar AWS sniegto informāciju, šī iespēja ir pieejama visos komerciālajos AWS reģionos un AWS GovCloud (ASV) reģionos. Par funkciju nav atsevišķas maksas. Klienti joprojām maksā par papildu Aurora skaitļošanas jaudu, ko patērē vaicājumi, un par Amazon S3 pieprasījumu izmaksām, kas saistītas ar datu ezera failu lasīšanu. Šis cenu noteikšanas modelis uztur zemu sākuma cenu, lai gan rēķinā joprojām būs redzama intensīva analītiskā izmantošana.
AWS ir ietvēris šo palaišanu kā daļu no plašākiem centieniem ieviest DuckDB veiktspēju savos pārvaldītajos pakalpojumos. DuckLabs komanda, kas uztur DuckDB projektu, pievienojās Amazon, un uzņēmums apgalvo, ka atvērtā pirmkoda dzinēja turpmākie uzlabojumi var tikt ieviesti Aurora un citos AWS piedāvājumos. Šī saistība liek domāt, ka integrācijai ir jāattīstās, nevis jāpaliek par vienreizēju funkciju.
Datu bāzu komandām praktiskā pievilcība ir pazīstama: mazāk kustīgu daļu, mazāk dublētu datu un īsāks ceļš no jautājuma līdz atbildei. Kompromiss ir tāds, ka piekļuves kontrole, IAM atļaujas un kataloga konfigurācija joprojām ir jāapstrādā uzmanīgi. Klasteris, kas var redzēt gan ražošanas rindas, gan Lakehouse failus, kļūst par jaudīgu vienotu vaicājumu virsmu , tāpēc pārvaldība joprojām ir daļa no darba.
Praktiskais efekts ir ciešāka saikne starp Aurora PostgreSQL un datu ezeru. Pašreizējās transakcijas un vēsturiskie faili var satikties vienā SQL vaicājumā, DuckDB apstrādā analītisko skenēšanu, un materializācija piedāvā ātru risinājumu, kad tas nepieciešams. Komandas, kas jau ir ieguldījušas PostgreSQL rīkos, iegūst vēl vienu iespēju analītikas ziņā lielām darba slodzēm, savukārt tās, kurām ir stingra drošības vai izmaksu kontrole, pirms plašas ieviešanas vēlēsies pārskatīt atļaujas, kešatmiņas darbību un S3 lietojumu.
