- AWS võimaldab nüüd Aurora PostgreSQL-il lugeda Apache Icebergi ja Apache Parqueti andmeid S3 ja S3 tabelitest ilma neid kõigepealt andmebaasi laadimata.
- See funktsioon kasutab manustatud DuckDB mootorit, aurora_analytics laiendust ja IAM-rolli, millel on juurdepääs S3-le ja AWS Glue'ile.
- Toetatud versioonid on Aurora PostgreSQL 17.11 ja uuemad, ning Aurora PostgreSQL 18.6 ja uuemad, nii äri- kui ka GovCloudi piirkondades.
- Meeskonnad saavad ühendada reaalajas tehinguridu Lakehouse'i andmetega, vahemällu salvestada tulemusi ja materialiseerida kiireid andmekogumeid madala latentsusega lugemiseks.
Amazon Web Services on avanud uue tee Aurora PostgreSQL- klastritele, mis peavad segama igapäevaseid rakenduskirjeid andmejärves asuvate failidega. Hallatav andmebaas saab nüüd lugeda Apache Icebergi tabeleid ja Apache Parquet'i faile ilma neid eelnevalt Aurorasse kopeerimata, seega saab üks SQL-lause katta nii reaalajas töötavaid ridu kui ka arhiveeritud teavet. See samm on suunatud meeskondadele, kes on väsinud tööde loomisest ja hooldamisest, ekstraheerimisest, teisendamisest ja laadimisest ainult selleks, et vastata küsimustele, mis hõlmavad nii praeguseid kui ka ajaloolisi andmeid.
Selle asemel, et käsitleda andmejärve eraldi maailmana, võimaldab teenus olemasolevatel PostgreSQL-i klientidel, tööriistadel ja lõpp-punktidel järvemaja sisule ligi pääseda võõraste tabelite kaudu. See tähendab, et ajaloolise andmestiku duplikaat ei pea töötavas andmebaasis olema ja rakenduste arendajad saavad jätkata juba tuttava süntaksi kasutamist. AWS pakub seda kui viisi, kuidas vähendada torujuhtme hooldust, vähendada infrastruktuuri laienemist ja lihtsustada tehingute rikastamist vanema kontekstiga.
Mida uus Aurora PostgreSQL-i funktsioon muudab
See funktsioon ei ole eraldi analüütikatoode, mille kliendid peaksid mujale üles ehitama. See aktiveeritakse aurora_analytics laienduse ja AWS Identity and Access Management rolli kaudu, mis annab klastrile loa pääseda ligi Amazon S3-le ja AWS Glue Data Catalogile. Kui see roll ja laiendus on paigas, loovad administraatorid Icebergi või Parqueti andmetele osutavaid võõrtabeleid ja pärivad neid sarnaselt tavaliste PostgreSQL-tabelitega.
Arhitektuuri tähelepanuväärne osa on see, et DuckDB on otse Aurorasse integreeritud . Avatud lähtekoodiga analüütiline mootor tegeleb Lakehouse'i failide skaneerimisega, samal ajal kui Aurora jätkab operatiivsete töökoormuste teenindamist. Päringute töötlemine jääb andmebaasi keskkonda, mis väldib töö üleandmist eraldi klastrile ning aitab hoida latentsust ja võrgu üldkulu kontrolli all.
Toetatud allikate hulka kuuluvad AWS Glue andmekataloogis registreeritud Icebergi tabelid, Amazon S3 Parquet ja Iceberg objektid ning S3 tabelites hoitavad andmed. Iceberg REST kataloogi liidest järgivatele väliskataloogidele pääseb ligi ka Glue abil föderatsiooni kaudu, seega ei pea meeskonnad loobuma juba olemasolevatest kataloogiinvesteeringutest. Päringu abil saab ühendada Aurora ridu mitme kataloogi vahel hajutatud Icebergi tabelitega, andes rakendustele ühtse vaate ilma faile teisaldamata.
Versioonid, seadistamine ja toetatud teenused
Toetatud versioonid on Aurora PostgreSQL 17 alates versioonist 17.11 ja Aurora PostgreSQL 18 alates versioonist 18.6. Pärast klastri loomist või valimist lisab administraator IAM-rolli AuroraAnalyticsi funktsiooniga ja lülitab laienduse sisse. Seadistamise saab teha Amazon RDS-i konsooli või PostgreSQL-i kliendi (nt psql) kaudu.
Välistabeli definitsioone saab luua ükshaaval, kuid suuremates keskkondades saab AWS Glue Data Catalog andmebaasist mitme võõrtabeli loomiseks kasutada funktsiooni IMPORT FOREIGN SCHEMA . Parquet-failide puhul saab Aurora lugeda skeemi faili metaandmetest, mis välistab vajaduse iga veeru käsitsi sisestada. See detail on oluline meeskondade jaoks, kellel on suured või sageli muutuvad andmekogumid.
Lugemispäringuid saab käivitada kirjutaja eksemplaril või lugemiskoopial, seega saab analüütilise skaneerimise peamisest operatiivsest töökoormusest eemale viia. Käsklused, mis kirjutavad andmeid Aurorasse, näiteks CREATE TABLE AS SELECT, INSERT INTO … SELECT või MERGE INTO, käivituvad kirjutaja eksemplaril . See annab meeskondadele võimaluse materialiseerida Lakehouse'i kuumad andmed natiivsesse tabelisse, kui nad vajavad järjepidevalt kiireid vastuseid.
Päringu toimingute nägemiseks saavad administraatorid kutsuda funktsiooni aurora_analytics_stat_statements(). Funktsioon annab aru mõõdikutest, näiteks skannitud ridadest, Amazon S3-st loetud baitide arvust ja vahemälu tabamustest . Sageli kasutatavad andmed salvestatakse Aurora eksemplari vahemällu, seega saab korduv juurdepääs samadele Lakehouse'i objektidele kiiremini tagasi tulla ilma samu baite korduvalt objektisalvestusest hankimata.
Jõudlus, vahemälu ja madala latentsusega teed
Aurora rakendab predikaatide allapoole suunatud filtreerimist ja veergude kärpimist , mis tähendab, et andmejärvest taotletakse ainult asjakohaseid ridu ja veerge. Aluseks oleva andmestiku kasvades aitab see filtreerimine vältida päringute muutumist täielikeks skaneeringuteks. Vahemällu salvestatud tulemused ja päringu statistika annavad operaatoritele praktilise viisi töökoormuse reguleerimiseks, selle asemel et arvata, millele aega kulub.
Rakenduste puhul, mis nõuavad ühekohalise millisekundilise latentsusaega, pakub AWS materializationi väljapääsuks. Valitud andmejärve kirjeid saab tuttavate SQL-käskudega kopeerida natiivsesse Aurora PostgreSQL-tabelisse , misjärel neid päritakse nagu iga teist kohalikku tabelit. See hoiab kuumimate andmeteni kiire tee, jättes samal ajal kogu andmejärve laiemaks analüüsiks kättesaadavaks.
Ettevõte loetleb tüüpiliste kasutusjuhtudena reaalajas armatuurlaudu, ajaloolise kontekstiga rikastatud tehinguid ja tehisintellekti agente, kes peavad arutlema nii praeguste kui ka arhiveeritud kirjete üle. Ühine joon on töökoormus, mis ei saa oodata igaöist partiitöötlust ega pöörd-ETL-tööd. Lubades rakendusel küsida ühelt andmebaasilt nii värsket kui ka vana teavet, loodab AWS kõrvaldada korduva keerukuse allika.
Kättesaadavus ja hinnakujundus
AWS-i andmetel on see funktsioon saadaval kõigis kommerts-AWS-i piirkondades ja AWS GovCloudi (USA) piirkondades. Eraldi funktsioonitasu ei ole. Kliendid maksavad endiselt päringute poolt tarbitava Aurora täiendava arvutusvõimsuse ja Amazon S3 päringute kulude eest, mis on seotud andmejärve failide lugemisega. See hinnamudel hoiab sisenemispunkti madalal, kuigi intensiivne analüütiline kasutamine kajastub siiski arvel.
AWS on kavandanud turuletoomise osana laiemast püüdlusest tuua DuckDB jõudlus oma hallatavatesse teenustesse. DuckLabsi meeskond, kes haldab DuckDB projekti, liitus Amazoniga ja ettevõte ütleb, et avatud lähtekoodiga mootori tulevased täiustused võivad laieneda Aurorale ja teistele AWS-i pakkumistele. See seos viitab sellele, et integratsioon peaks arenema, mitte jääma ühekordseks funktsiooniks.
Andmebaaside meeskondade jaoks on praktiline eelis tuttav: vähem liikuvaid osi, vähem dubleeritud andmeid ja lühem tee küsimusest vastuseni. Kompromiss seisneb selles, et juurdepääsukontrolli, IAM-õiguste ja kataloogi konfiguratsiooniga tuleb endiselt ettevaatlikult ümber käia. Klaster, mis näeb nii tootmisridu kui ka Lakehouse'i faile, muutub võimsaks ühtseks päringupinnaks , seega jääb haldamine töö osaks.
Praktiline efekt on tihedam seos Aurora PostgreSQL-i ja andmejärve vahel. Praegused tehingud ja ajaloolised failid saavad kohtuda ühes SQL-päringus, DuckDB tegeleb analüütilise skaneerimisega ja materialiseerimine pakub vajadusel kiiret lahendust. Meeskonnad, kes on juba PostgreSQL-i tööriistadesse investeerinud, saavad analüütikamahukate töökoormuste jaoks veel ühe võimaluse, samas kui range turvalisuse või kulude kontrolliga meeskonnad soovivad enne laialdast juurutamist üle vaadata õigused, vahemällu salvestamise käitumise ja S3 kasutamise.
