Deep Dive sa Amazon Aurora and Its Innovations (DAT441)

Mga Tala ng Sesyon

Pangkalahatang-ideya ng Aurora

• Ang Amazon Aurora ay isang cloud-native relational database
• Pinagsasama ang bilis at pagkakaroon ng mga high-end na komersyal na database na may pagiging simple at pagiging epektibo sa gastos ng open source
• Ganap na pinamamahalaan, tugma sa MySQL at PostgreSQL
• May kasamang mga tool para sa pagsasama sa mga application na walang server at machine learning
• Walang mga pagbabago sa application na kailangan para magamit ang Aurora
• Sinusuportahan ang mga extension para sa PostgreSQL
• Kamakailang karagdagan: Aurora DSQL (Ibinahagi SQL)
• Aurora Architecture:
• Gumagamit ng mga 3 availability zone
• Nagtatampok ng Aurora storage na sumasaklaw sa lahat ng 3 availability zone
• Pinangangasiwaan ng mga storage node ang mga talaan ng log na na-convert sa mga pahina ng database

Mga Pangunahing Tampok ng Aurora Storage

• Walang tradisyunal na isyu sa database tulad ng mga checkpoint, full page writes, double write buffer, o log archival
• Ang data ay paulit-ulit na nakaimbak na may 6 mga kopya sa lahat ng 6 storage node sa 3 availability zone
• Awtomatikong pag-aayos ng peer-to-peer para sa mga sirang o napalampas na talaan ng log o nabigong storage node
• Pamamahala ng Replica:
• Kakayahang magdagdag ng hanggang 15 read-only na mga replika nang walang consistency lag
• Asynchronous na invalidation at update sa pagitan ng mga head node
• Maaaring may iba't ibang laki at uri ng instance ang mga replika (hal., Graviton, Intel)
• Awtomatikong lumalawak ang storage hanggang 256 terabytes
• Automatic Failover:
• Pag-promote ng isang replica sa read-write node kapag nabigo
• DNS-based na pagbabago sa endpoint para sa pag-rerouting ng application
• Available ang mga advanced na mabilis na driver para sa mas mabilis (hanggang 66% mas mabilis) Failover
• Multi-Region Capabilities:
• Asynchronous na pagtitiklop ng storage sa mga rehiyon (Global Database)
• Ang pagkopya ay pinangangasiwaan ng Aurora, hindi nangangailangan ng mga pagbabago sa application
• Posible ang mababang latency na rehiyon-lokal na pagbabasa sa pamamagitan ng pagpapatakbo ng mga application sa mga pangalawang rehiyon
• Hanggang 10 mga rehiyon ang maaaring gamitin para sa pandaigdigang pag-setup ng database ng
• Teknikal na Tala:
• Ang mga node ng ulo ay hindi kasama sa proseso ng pagtitiklop
• Ang mga read-only na replika sa mga pangalawang rehiyon ay nagpapanatili ng malapit-madaling pagpapakita ng data na may karaniwang RPO lag na wala pang isang segundo

Pandaigdigang Endpoint at Failover

• Ang pandaigdigang endpoint ay isang DNS na pangalan na tumuturo sa kasalukuyang rehiyon ng manunulat
• Sa kaso ng isang problema sa pangunahing rehiyon, isang failover na operasyon ay inisyu
• Ang Failover ay nagpo-promote ng replica sa ibang rehiyon sa writer node
• Maaaring mangyari ang potensyal na pagkawala ng data dahil sa asynchronous na pagtitiklop
• DNS ang pangalan para sa pandaigdigang endpoint ay ina-update sa pamamagitan ng Route 53 data plan API
• Global Database Switchover:
• Ang paglipat ay nangyayari kapag ang parehong mga rehiyon ay malusog, at ang manunulat ay inilipat para sa mga dahilan ng pagpapatakbo
• Binawasan ng mga kamakailang pagpapabuti ang oras ng paglipat mula 5 minuto hanggang 30 segundo
• Gumagamit ng log-based na arkitektura upang makamit ang zero na pagkawala ng data (RPO ng 0) at 30 segundong oras ng pagbawi (RTO ng 30 segundo)
• Lokal na Pagpapasa ng Pagsusulat:
• Nagbibigay-daan sa pagsusulat mula sa pangalawang availability zone na maipasa sa writer node
• Hindi kino-convert ang system sa isang aktibong-aktibong pagsasaayos
• Ang mga pagsusulat mula sa availability zone 2 ay ipinapasa sa writer node sa availability zone 1, na naisakatuparan, at ibinabalik ang mga resulta
• Pinapahusay ang kakayahang umangkop sa pagpapatakbo nang hindi nakompromiso ang integridad ng data o
• mga Consistency Mode ng disenyo ng system sa Aurora:
• Available ang tatlong magkakaibang consistency mode/visibility mode
• Ang default na mode ay visibility ng session, na naghihintay para sa mga update na kilalanin bago magpatuloy sa mga pagbabasa
• Ang panghuling consistency mode ay hindi naghihintay ng mga update, na posibleng humahantong sa mga pagbabasa na hindi nagpapakita ng mga pinakabagong pagsusulat
• Ang global consistency mode ay naghihintay para sa lahat ng mga update sa buong cluster bago magpatuloy, tinitiyak na ang mga pagbabasa ay sumasalamin sa lahat ng mga pagsusulat ng
• Local Write Forwarding:
• Nagbibigay-daan sa pagsusulat mula sa pangalawang availability zone na maipasa sa writer node
• Pinapanatili ang parehong pare-parehong mga mode at pagsasaalang-alang gaya ng mga lokal na operasyon
• Ang mga pagkakaiba sa cross-region na latency ay isang salik sa pandaigdigang pagpapasa ng pagsulat ng
• Aurora Storage Node Operations:
• Ang bawat storage node ay nagpapatakbo ng "storage demon" na nagpapadali sa komunikasyon sa pagitan ng engine at storage
• Ang mga talaan ng log ay isinusulat sa isang papasok na pila, pinatuyo sa isang mainit na log sa disk, at pagkatapos ay kinikilala
• Ang mga nawawalang talaan ng log (hal., dahil sa mga pagkaantala sa transit) ay maaaring makuha ng peer-to-peer mula sa iba pang mga storage node
• Ang mga talaan ng log ay pinagsama-sama sa mga pahina ng database, na tinitiyak na ang mga kahilingan sa pagbabasa ay naihahatid na may kaunting epekto sa latency
• Ang patuloy na pag-backup sa S3 ay nagbibigay-daan para sa mga point-in-time na pag-restore sa loob ng huling 35 araw

IO Optimization Configuration

• Pagsasaayos ng mga opsyon sa pagsasaayos upang mapahusay ang throughput para sa mga IO-intensive na application.
• Binabago ang driver ng storage para sa mas agresibong batching, kapaki-pakinabang para sa IO-heavy application.
• Paggamit ng mga modernong bersyon ng engine para sa karagdagang pag-optimize.
• Ang pagpapalit ng papasok na pila sa isang matibay na pila upang mabawasan ang latency at jitter, pagpapabuti ng pagganap.
• Aurora PostgreSQL Compatibility and Updates:
• Ang Aurora PostgreSQL ay ganap na katugma sa PostgreSQL.
• Regular na pagsasama ng mga update ng PostgreSQL mula sa upstream.
• Suporta para sa PostgreSQL hanggang sa bersyon 17.6.
• Pagkatugma sa uri ng instance na RAG sa lokal na disk.
• Maraming mga pagpapahusay sa pagganap mula sa upstream kabilang ang nauugnay na subquery cache, adaptive na pagsali, atbp.
• Pagpapakilala ng shared plan cache para sa kahusayan ng memorya.
• Pinahusay na kakayahang mabasa para sa malalaking pagkakataon at replika.
• Pagpapatupad ng FIPS 140-3 security encryption.
• Mga update sa iba't ibang extension, lalo na ang PG vector.
• Suporta para sa mga volume na hanggang 256 terabytes.
• Pagsusuri ng Pagganap ng Aurora PostgreSQL:
• Pagsusuri sa throughput sa iba't ibang henerasyon ng instance.
• Halimbawa ng pagsubok:
• CPU-b4Xlarge (mas lumang instance) kumpara sa R7i.48Xlarge (mas bago, mas malaking instance) na nagpapakita ng 2.1 times na pagpapabuti ng performance.
• Panimula ng R8G (bersyon ng Graviton, susunod na henerasyon) na nagpapakita ng 2.7 beses na pagpapabuti sa baseline, na nagpapahiwatig ng mas mahusay kaysa sa linear na scaling.
• Ang ibig sabihin ng Better-than-linear scaling ay ang isang system o proseso ay nagpapabuti sa pagganap o kahusayan nito nang di-proporsiyonal habang ang mga mapagkukunan (tulad ng laki ng data o mga node) ay tumataas, na kadalasang nakikita sa logarithmic na paglago o mga espesyal na arkitektura, na naiiba sa linear na paglago (doble ang output kung doble ang input) o sub-linear scaling (lumiliit na mga pagbabalik, pag-compute ng performance ng Amdahl sa data at visual na pagganap), kasama ang.

Aurora PostgreSQL Dynamic Data Masking

• Bagong feature para sa pagprotekta ng sensitibong data sa Aurora.
• Kasama sa sensitibong data ang mga numero ng account, pangalan ng may-ari ng account, at impormasyong nagbibigay ng personal na pagkakakilanlan (PII).
• Dynamic Data Masking sa Aurora PostgreSQL:
• Idinisenyo para sa pagprotekta sa sensitibong data sa pamamagitan ng pagbibigay ng mga bilugan o naka-mask na bersyon ng data.
• Ipinatupad sa pamamagitan ng bagong PG column mask extension sa Aurora.
• Nagbibigay-daan sa kahulugan ng mga patakaran sa pag-mask para sa mga partikular na talahanayan at column.
• Halimbawa:
• Tinatakpan ang customer ID bilang mga balanse ng X at rounding account.
• Nalalapat ang mga patakaran sa mga tinukoy na tungkulin (hal., 'analyst') na may mga tinukoy na timbang para sa paglutas ng salungatan.
• Ipinatupad sa query rewrite layer para sa mahusay na pagganap nang hindi naaapektuhan ang mga index.
• Mga Detalye ng Pagpapatupad ng Dynamic Data Masking:
• Ang masking function ay inilapat sa panahon ng query rewrite phase, hindi post-fetch.
• Tinitiyak ang mahusay na pagganap at nagpapanatili ng index functionality.
• Nakikita sa output ng paglalarawan ng query kung saan inilalapat ang mask function sa mga naka-target na column.
• Mga Update ng Aurora MySQL:
• Kamakailang paglabas ng bersyon 3.11 na may MySQL 8.0.43 compatibility.
• Pagpapakilala ng isang 3.10.0 pangmatagalang bersyon ng suporta na may mga pinahusay na feature.
• In-memory relay log cache para sa hanggang 40% pinahusay na log replication throughput.
• Suporta para sa ODBC sa mga advanced na mabilis na driver para sa MySQL. Ang ODBC (Open Database Connectivity) ay isang API na nagbibigay-daan sa mga application na ma-access ang data mula sa iba't ibang sistema ng pamamahala ng database gamit ang isang karaniwang wika, SQL. Ito ay gumaganap bilang isang tulay, na nagpapahintulot sa isang application na kumonekta sa iba't ibang mga database, tulad ng SQL Server, MySQL, o Oracle, nang hindi kailangang muling isulat para sa bawat isa.
• Tumaas na dami ng suporta hanggang sa 256 terabytes.
• Global database pangalawang mambabasa para sa pinahusay na read availability sa panahon ng mga pandaigdigang isyu.

Aurora Serverless

• Inirerekomendang uri ng instance para sa streamline na pamamahala ng fleet.
• Awtomatikong inaayos ang CPU at memorya batay sa mga hinihingi sa workload.
• Pinalitan ang pangalan mula sa Aurora Serverless V2 sa Aurora Serverless na lang pagkatapos ng katapusan ng buhay para sa V1.
• Nag-aalok ng nababanat na uri ng instance para sa flexible na paglalaan ng mapagkukunan.
• Mga Feature at Benepisyo ng Aurora Serverless:
• Awtomatikong sinusuri ang memorya, CPU, at network nang walang pag-reboot ng engine.
• Nagaganap ang pag-scale bawat segundo, sinusukat sa Aurora Capacity Units (ACUs), bawat isa ay kumakatawan sa 2 GB ng RAM at mga nauugnay na mapagkukunan.
• Mga scale bilang tugon sa mga function ng Lambda o mga trabaho sa analytics, pagsasaayos ng mga ACU batay sa demand.
• Presyo sa bawat segundo, ang mga gumagamit ay nagbabayad lamang para sa mga mapagkukunang aktwal na ginamit.
• Mekanismo ng Pag-scale sa Aurora Serverless:
• Gumagana gamit ang isang scaling bucket na pana-panahong napupuno ng mga credit, na nagbibigay-daan sa pag-scale hanggang sa isang nakatakdang maximum na ACU na limitasyon.
• Kinukonsumo ang mga kredito kapag kailangan ang pag-scale, kasama ang bucket na muling pinupuno sa paglipas ng panahon.
• Kasama sa mga kamakailang pagpapahusay ang mas mabilis na mga tugon sa pag-trigger (sa ilalim ng 1 segundo), mas malaking paunang laki ng bucket, at mas mabilis na mga rate ng refill.
• Mga Pagpapahusay sa Pagganap gamit ang Bersyon ng Platform 3:
• Nag-aalok ng hanggang 30% pinahusay na pagganap nang hindi nangangailangan ng anumang pagpili o karagdagang configuration.
• Available para sa lahat ng bagong cluster, naa-access sa pamamagitan ng pag-restore mula sa backup, pag-clone, o paggawa ng bagong cluster.
• Mga Halimbawa ng Pagganap:
• Ang mga pagsubok na naghahambing sa bersyon ng platform na 2 na may at walang mabilis na pag-scale ay nagpakita ng 3.6 na beses na mas mahabang panahon ng peak performance at 9% mas kaunting ACU na oras na ginamit sa mabilis na pag-scale.
• Ang mga pagsubok na may bersyon ng platform na 3 (kasama ang mabilis na pag-scale) ay nagpakita ng 20% na pagbawas sa runtime at ACU na oras na ginamit kumpara sa bersyon ng platform na 2, na humahantong sa 20% mas mababang pagsingil.
• Ang parehong mas mabilis na pag-scale at bersyon ng platform 3 ay awtomatikong inilalapat sa mga bagong cluster, na nag-aalok ng pinahusay na pagganap at kahusayan sa gastos nang walang labis na pagsisikap mula sa user.

Lumikha gamit ang Express Configuration

• Mabilis na paglikha ng mga kumpol ng database sa ilang segundo.
• Naka-target sa mga user na madalas na gumagawa ng mga cluster, gaya ng mga nasa CI/CD pipelines o agentic AI application.
• Pinapagana ang paglikha ng isang bagong database para sa bawat pakikipag-ugnayan, pagpapahusay ng liksi at bilis.
• Mga Tampok ng Lumikha gamit ang Express Configuration:
• Nag-aalok ng flexible at nae-edit na configuration, simula sa 16 ACUs (Aurora Capacity Units).
• Nagbibigay-daan sa pagbabago ng karamihan sa mga setting pagkatapos ng paggawa, kabilang ang kakayahang baguhin ang mga ACU at iba pang mga configuration.
• Secure bilang default na may encryption at naka-enable ang IAM (Identity and Access Management).
• Sinusuportahan ang halos lahat ng feature ng Aurora, kabilang ang mga global database at zero ETL.
• Walang VPC na Kinakailangan:
• Ipinakilala ang Aurora Internet Access Gateway, isang bagong bahagi na nagpapadali sa pag-access sa cluster ng database nang hindi nangangailangan ng VPC (Virtual Private Cloud).
• Ang Internet Access Gateway ay isang available na endpoint na tugma sa PostgreSQL wire protocol, na nagpapaliit ng latency.
• Nagbibigay-daan sa pag-access sa DB cluster mula sa kahit saan, binabawasan ang pangangailangan para sa mga VPN at pinapasimple ang proseso para sa mga developer.
• Sumasama sa Amazon IAM at AWS Shield para sa mga pinahusay na feature ng seguridad tulad ng proteksyon sa panloloko at pag-iingat ng data.
• Ang AWS Shield ay isang pinamamahalaang serbisyo para sa pagprotekta sa mga application na tumatakbo sa Amazon Web Services (AWS) mula sa mga pag-atake ng Distributed Denial of Service (DDoS). Nag-aalok ito ng dalawang tier: ang libreng AWS Shield Standard, na awtomatikong nagpapagaan ng mga karaniwang pag-atake sa layer ng network, at ang bayad na AWS Shield Advanced, na nagbibigay ng proteksyon laban sa mas sopistikadong pag-atake, advanced na feature, at suporta ng eksperto.

Integrasyon ng Aurora sa Agentic AI

• Ang Aurora ay maaaring magsilbi bilang memorya para sa mga sistemang ahenteng AI, mahalaga para sa paggana ng mga AI loop.
• Halimbawa gamit ang "Letter" framework: paggawa ng DB cluster na may express configuration, pagpapagana ng PG vector extension para sa vector embeddings, at pagturo ng Letter framework sa PostgreSQL endpoint.
• Maaaring gamitin ang Aurora PostgreSQL para sa genetic AI memory sa iba't ibang frameworks tulad ng LangChain.
• Ang mga server ng MCP (Model Context Protocol), na open-sourced ng AWS, ay nagbibigay-daan sa mga natural na query sa wika na nakakaunawa sa schema ng isang Aurora database, na ginagawang SQL query. Ito ay kapaki-pakinabang para sa parehong mga bagong user na naggalugad sa database at mga power user na naghahanap ng kahusayan.
• Pag-patching at Pag-upgrade sa Aurora:
• Nag-aalok ang Aurora ng pinamamahalaang karanasan para sa pag-patch at pag-upgrade ng mga cluster, na may mga nakabinbing pagkilos sa pagpapanatili na makikita sa console.
• Ang mga OS patch ay inilalapat sa isang rolling fashion sa maraming node sa isang cluster, na nagpapahusay sa availability.
• Maaaring magtakda ang mga user ng palugit sa pagpapanatili para sa mga update at makatanggap ng mga abiso tungkol sa mga pagkilos sa pagpapanatili.
• Opsyonal ang pag-automate ng mga pagkilos sa pagpapanatili, na nagpapahintulot sa mga user na kontrolin ang mga pag-upgrade sa pamamagitan ng sarili nilang mga system tulad ng Terraform.
• Para sa mga fleet ng cluster, ang pagkakasunud-sunod ng mga upgrade sa buong development, QA, at production environment ay mahalaga.
• Mga Sequential Upgrade para sa Aurora Clusters:
• Kahalagahan ng sequencing upgrade sa iba't ibang environment (dev, QA, prod) para bigyang-daan ang pagsubok at oras ng reaksyon.
• Hamunin ang mga random na anunsyo sa pagpapanatili na posibleng mag-upgrade ng mga QA na kapaligiran bago ang dev, salungat sa gustong order.

AWS Patakaran sa Pagpapalabas ng Pag-upgrade ng Organisasyon

• Ipinakilala upang tugunan ang isyu sa pagkakasunud-sunod, na nagbibigay-daan sa mga pag-upgrade na masira sa mga alon (ika-1, ika-2, huli).
• Kasama sa proseso ang pag-abiso sa mga user, paghihintay sa window ng pagpapanatili ng unang wave, pag-upgrade sa mga pagkakataong iyon, pagbe-bake (panahon ng pagsubok), at pagkatapos ay magpatuloy sa susunod na wave.
• Nagbibigay ng sapat na oras para sa mga user na mag-react o mag-opt out kung may mga isyu.
• Ang mga pag-upgrade ay nagpapatuloy sa pagkakasunud-sunod anuman ang araw ng linggo ang isang update ay inilabas.
• Pagpapatupad ng Patakaran sa Pag-upgrade ng Roll-Out:
• Nangangailangan ng pagpapagana ng mga AWS Organisasyon at paglalagay ng mga account sa loob ng organisasyon.
• Kasama sa normal na pag-setup ang pagpapagana ng mga awtomatikong pag-upgrade ng menor de edad na bersyon at pagtatakda ng window ng pagpapanatili.
• Ang patakaran ay itinakda sa pamamagitan ng pag-uugnay ng mga tag sa mga mapagkukunan; halimbawa, ang pag-tag ng mga mapagkukunan gamit ang "env=prod" para sa huling wave.
• Ang mga mapagkukunan na walang kinikilalang mga tag ay default sa isang tinukoy na wave (hal., second wave).
• Maaaring piliin ng mga user na huwag gumamit ng mga tag at tanggapin ang mga default para sa isang beses na pag-upgrade sa lahat ng mapagkukunan.
• Paglalapat ng Patakaran sa Pag-upgrade ng Roll-Out:
• Pagkatapos gawin ang patakaran, maaari itong i-attach sa buong organisasyon (root) o mga indibidwal na account para sa piling aplikasyon.
• Sa panahon ng pag-upgrade, makikita ng mga user ang mga notification sa mga nakabinbing pagkilos sa pagpapanatili at AWS Health, na nagsasaad ng wave kung saan magaganap ang upgrade.

Blue-Green Deployment para sa Mga Pangunahing Pag-upgrade sa Bersyon

• Ang mga blue-green na deployment ay mahalaga para sa mga pangunahing pag-upgrade ng bersyon na hindi tugma sa kasalukuyang bersyon at nangangailangan ng downtime kung gagawin sa lugar.
• Kasama sa proseso ang paglikha ng kumpletong kopya ng kapaligiran ng produksyon (ang "berde" na kapaligiran), pag-sync ng data gamit ang lohikal na pagtitiklop, at pagpapanatiling naka-sync hangga't tumatakbo ang asul-berdeng deployment.
• Nagbibigay-daan para sa masusing pagsubok sa na-upgrade na kapaligiran bago lumipat.
• Ang paglipat, na pinadali sa pamamagitan ng CLI o console, ay pinapalitan ang pangalan ng AWS na mga mapagkukunan at inililipat ang endpoint sa berdeng kapaligiran, na tinitiyak na walang pagkawala ng data at minimal na downtime (karaniwang wala pang isang minuto).
• Nagbibigay ng pagpipiliang fallback kung nag-time out ang paglipat, awtomatikong babalik sa orihinal (asul) na kapaligiran.
• Kapaki-pakinabang hindi lamang para sa mga pag-upgrade ng bersyon kundi pati na rin para sa mga pagbabago sa schema, mga pagbabago sa static na parameter, at mga update sa pagpapanatili na itinuturing na masyadong mapanganib para sa mga pagbabago sa lugar.
• Blue-Green Deployment para sa mga Global Database:
• Ang kamakailang suporta para sa mga pandaigdigang database ay nagbibigay-daan para sa mga pangunahing pag-upgrade ng bersyon sa mga rehiyon gamit ang mga blue-green na deployment.
• Sinasalamin ng proseso ang mga pag-deploy ng solong rehiyon, na may lohikal na pagtitiklop na tinitiyak ang pag-synchronize ng data at kaunting downtime (mga 1 minuto para sa paglipat).
• Pinapagana ang isang pangunahing bersyon ng pag-upgrade ng buong global cluster na may zero na pagkawala ng data (RPO ng 0) at isang layunin sa oras ng pagbawi (RTO) na humigit-kumulang 1 minuto.

Aurora's Zero ETL Feature

• Pinapadali ang paglipat ng data na mababa ang latency mula sa Aurora PostgreSQL patungo sa Redshift nang hindi pinamamahalaan ang isang ETL pipeline.
• Nakamit sa pamamagitan ng isang CLI command na lumilikha ng pipeline sa pagitan ng Aurora at Redshift cluster.
• Nag-aalok ng replication lag na 5 hanggang 12 na segundo, na tinitiyak ang mabilis na pagkakaroon ng data sa Redshift.
• Namamahala ng data seeding, maintenance, at change data capture (CDC) streaming, na nagpapagaan sa mga user sa mga kumplikadong ito.
• Sinusuportahan ang pagsasama ng maraming Aurora cluster (parehong MySQL at PostgreSQL) sa iisang Redshift cluster o data lake.
• Nagbibigay-daan din sa daloy ng data mula sa Aurora MySQL hanggang SageMaker gamit ang parehong teknolohiya.
• Pinagbabatayan na Teknolohiya ng Zero ETL:
• Gumagamit ng parallel na direktang pag-export sa layer ng storage para mabilis na maglagay ng data sa Redshift nang hindi naaapektuhan ang performance.
• Gumagamit ng mga pinahusay na bin log (para sa MySQL) o katumbas para sa PostgreSQL, na naka-embed sa storage, upang makuha ang lohikal na replication logs.
• CDC ang mga streaming server ay direktang nagbabasa ng mga log mula sa storage, naglalapat ng mga filter at mga pagbabago bago itulak ang data sa Redshift, na tinitiyak na walang epekto sa performance sa head node.
• Mga Uri ng Imbakan ng Aurora:
• Aurora Standard: Default na uri ng storage na nag-aalok ng pangunahing pagganap at mga katangian ng gastos.

Detalyadong Paliwanag ng Mga Gastos at Pagganap ng Pag-iimbak ng Aurora

• Magbasa ng mga pagpapatakbo: Kung ang data ay naka-cache, may kaunting gastos (ilang millisecond ng instance running time). Kung napalampas ang cache, babasahin ang data mula sa storage, na nagkakahalaga ng fraction ng isang sentimo kada 8K o 16K na pahina ng database, depende sa database engine.
• Mga operasyon sa pagsulat: Hanggang sa 4 kilobytes ay nagkakahalaga ng isang fraction ng isang sentimo. Ang mas malalaking pagsusulat ay maaaring batched sa hanggang 4 I/Os, na ang bawat batch ay nagkakahalaga ng fraction ng isang sentimo, depende sa laki nito.
• Aurora I/O Optimized Storage:
• Mag-alok ng mas predictable na pagpepresyo at potensyal na mas mahusay na performance.
• Isang cluster-level na configuration na maaaring piliin sa paggawa ng cluster o ilipat online.
• Binabago ang pagganap at arkitektura ng system, kabilang ang mga pagbabago sa panig ng imbakan.
• Inirerekomenda para sa mga user na ang Aurora bill ay nagpapakita ng I/O na proporsyon na higit sa 25%, dahil malamang na nag-aalok ito ng pagtitipid sa gastos at mas mahusay na performance.
• Available sa lahat ng modernong bersyon ng makina mula sa huling 18 buwan at tugma sa mga plano sa pagtitipid sa database.
• Modelo ng Gastos ng I/O Optimized Storage:
• Ang mga user ay nagbabayad ng kaunting premium para sa pag-compute at storage ngunit walang halaga para sa mga I/O, na ginagawang mas simple at mas predictable ang pagsingil.
• Tamang-tama para sa mga workload na may makabuluhang I/O na mga operasyon, dahil ang premium na gastos para sa pag-compute at storage ay na-offset ng pag-aalis ng mga gastos sa I/O.
• Pagpapahusay ng Pagganap gamit ang I/O Optimized:
• Ipinakita sa pamamagitan ng isang pagsubok sa isang 16X malaking instance, na nagpapakita ng 1.9x na pagpapabuti sa throughput na may I/O na naka-optimize na naka-enable sa isang R6I 16X malaking instance na tumatakbong bersyon 14.
• Ang karagdagang pagpapabuti (isang karagdagang 10%) ay naobserbahan kapag nag-a-upgrade sa isang R7I instance na may bersyon na 16 PostgreSQL.

Latency at Throughput Improvements na may I/O Optimized

• Latency Test: Nagpapakita ng makabuluhang pagpapabuti sa latency, na may 3 na beses na pagpapabuti sa low end at 6.4 beses na pagpapabuti sa high end kapag gumagamit ng I/O na na-optimize sa isang R8G 48X malaking instance na tumatakbong bersyon 17 PostgreSQL.
• Throughput Test: Nagpapakita ng 5 na beses na pagpapabuti sa throughput sa parehong mga kundisyon, na itinatampok ang dalawahang benepisyo ng I/O na na-optimize para sa parehong latency at throughput.
• Mga Pansamantalang Bagay at Lokal na Imbakan ng NVMe:
• Ang lokal na imbakan ng NVMe ay tumutukoy sa napakabilis, physically attached solid-state drives (SSDs) sa loob ng isang server o cloud instance, na nag-aalok ng napakababang latency at mataas na throughput, perpekto para sa hinihingi na mga app (AI/ML, mga database) na nangangailangan ng pansamantala, mataas na performance na scratch space.
• Bilis: Gumagamit ng PCIe bus, lumalampas sa mga bottleneck ng network/controller para sa sub-millisecond latency at napakalaking IOPS.
• Direktang Attachment: Pisikal na nasa loob ng server/instance chassis (tulad ng AWS EC2 o Azure VMs).
• Pansamantala: Ang data ay pansamantala; hindi ito nakaligtas sa instance na pagwawakas, pagkabigo, o kung minsan ay nagre-restart/maintenance.
• Paggamit ng mga pansamantalang bagay sa PostgreSQL para sa mga operasyon tulad ng index rebuild o malalaking uri, na maaaring lumampas sa memorya at nangangailangan ng disk storage.
• Sa isang normal na sistema, ang disk na ito ay isang EBS disk, na nagpapakilala ng mga pagsasaalang-alang sa pagganap.
• Sa mga D instance tulad ng RAGD, ginagamit na lang ang lokal na NVMe instance storage, na nagbibigay-daan sa hanggang 6 na beses ang laki ng memory na ilaan para sa mga spill, makabuluhang binabawasan ang latency at pagpapabuti ng performance para sa mga workload gamit ang mga pansamantalang bagay na ito.
• Epekto ng I/O na Na-optimize sa Pansamantalang Imbakan ng Bagay:
• Binabawasan ng I/O optimized ang alokasyon para sa mga pansamantalang bagay mula sa 6 na beses sa memory hanggang sa 2 na beses sa memory, nagbibigay pa rin ng pagpapalakas ng pagganap ngunit gumagamit ng mas kaunting espasyo sa imbakan.
• Ang pagtitipid sa espasyo ng imbakan ay ginagamit para sa isang tampok na tinatawag na tiered cache, na idinisenyo upang higit pang mapahusay ang pagganap sa pamamagitan ng pagbibigay ng karagdagang layer ng caching.

Naka-tier na Cache

• Ginagamit ang naka-save na espasyo mula sa pagbabawas ng pansamantalang paglalaan ng imbakan ng bagay sa ilalim ng I/O optimized.
• Nilalayon na pahusayin ang performance sa pamamagitan ng pagdaragdag ng karagdagang layer ng caching, kahit na ang mga partikular na detalye sa kung paano gumagana ang tiered cache ay hindi ibinigay sa sipi.
• Proseso ng Regular na Pagbasa:
• Paunang pag-check in sa mga nakabahaging buffer; kung ang data ay natagpuan, ito ay binabasa nang walang karagdagang pagkilos na kailangan.
• Kung wala ang data sa mga shared buffer, babasahin ito mula sa storage papunta sa mga shared buffer at pagkatapos ay ibibigay sa engine.
• Mga Na-optimize na Read na may D Instances:
• Naglalaan ng 4 beses ang memorya sa disk para sa tiered na cache, na ginagamit na katulad sa mga nakabahaging buffer.
• Ginagamit ang metadata upang matukoy kung ang hiniling na data ay nasa cache ng disk.
• Ang data na nabasa mula sa imbakan ay inilalagay sa mga nakabahaging buffer; kapag puno na ang mga buffer, ie-evict ang data sa isang tiered na cache na may pagsubaybay sa metadata.
• Pangangasiwa ng Mga Update gamit ang Tiered Cache:
• Ang mga update ay nagpapawalang-bisa ng data sa tiered na cache sa pamamagitan ng pag-flip ng metadata bit, pag-iwas sa madalas na pagsusulat sa tiered na cache.
• Elastic at Dynamic na Tiered Cache:
• Kakayahang ayusin ang laki ng naka-tier na cache kumpara sa mga pansamantalang bagay batay sa mga pangangailangan sa workload.
• Pinapataas ang temp space para sa disk spill-heavy workloads at binabawasan ito para sa mas malaking tiered cache post-workload.

R8GD Pagganap ng Halimbawa

• Bagong uri ng instance na may parehong presyo gaya ng R6GD ngunit nag-aalok ng 165% na pagpapabuti ng performance.
• Hinihikayat para sa mga gumagamit ng tiered na cache at sa mga isinasaalang-alang ang paggamit nito.
• Pagpapahusay ng Pagganap gamit ang Tiered Cache:
• Nabawasan ang latency sa mga read operation, lalo na para sa data na lampas sa kapasidad ng memory.
• Para sa isang 340 GB na pagsubok, ang naka-tier na cache ay nagpapakita ng 1.5% na pagtaas sa latency kumpara sa memorya, at isang 3 beses na deficit kumpara sa isang 8 na beses na pagtaas nang walang tiered na cache.
• Ang pareto random distribution test ay nagpapakita ng mas mahusay na performance, na may 1.4 times lang na pagbabawas ng latency para sa malalaking pagsubok.
• Real-world Use Case:
• Ang PG vector benchmark ay nagpapakita ng higit sa 3.5 na beses na pagpapabuti sa mga query sa bawat segundo na may mga na-optimize na pagbabasa (R7GD vs. R8G).
• Ang paghahambing ng R6GD sa 8GD (parehong nasa parehong presyo) ay nagbubunga ng 1.6x na pagpapabuti sa pagganap ng vector.
• R: Nagsasaad ng memory-optimized na instance family.
• 7: Nagsasaad ng kasalukuyang henerasyon (ika-7 henerasyon).
• g: Isinasaad na ang instance ay gumagamit ng AWS Graviton processors (Arkitektura ng Arm).
• d: Isinasaad ang pagsasama ng lokal na NVMe-based SSD storage.
• Amazon EC2 R8g instance, na pinapagana ng AWS Graviton 4 processors, na kumakatawan sa pinakabagong henerasyon ng AWS ng memory-optimized instance para sa hinihingi, in-memory na mga workload tulad ng malalaking database, real-time na analytics.
• Pangkalahatang-ideya ng Aurora PostgreSQL vs. Aurora MySQL:
• Aurora PostgreSQL: Ganap na katugma sa PostgreSQL, gumagamit ng solong arkitektura ng manunulat na may implicit o tahasang pag-lock para sa sabay-sabay na pagsusulat.
• Aurora MySQL: Gumagamit ng aktibong-aktibong mga processor ng query para sa maraming pagsusulat, na gumagamit ng optimistikong kontrol ng concurrency upang pamahalaan ang mga salungatan.
• Ang pag-scale sa Aurora PostgreSQL ay nagsasangkot ng pagdaragdag ng mga replika na may asynchronous na pagtitiklop, pagtataas ng mga tanong sa pagkakapare-pareho at paggamit ng caching para sa pagganap.
• Mga Pangunahing Pagkakaiba:
• Concurrency Handling: Gumagamit ang PostgreSQL ng locking; Gumagamit ang MySQL ng optimistic concurrency control.
• Sumulat ng Arkitektura: Ang PostgreSQL ay may iisang manunulat; Sinusuportahan ng MySQL ang maraming aktibong manunulat.
• Mga Mekanismo ng Pag-scale: Mga kaliskis ng PostgreSQL sa pamamagitan ng mga replika; Ang MySQL ay sumusukat sa pamamagitan ng karagdagang mga processor ng query.

Detalyadong Paghahambing ng Aurora PostgreSQL at Aurora MySQL

• Aurora PostgreSQL: Gumagamit ng active-passive architecture na may iisang manunulat at tahasang pag-lock para sa concurrency. Sinusuportahan ang pag-scale sa pamamagitan ng pagdaragdag ng mga replika at gumagamit ng asynchronous na pagtitiklop.
• Aurora MySQL (DSQL): Gumagamit ng aktibong-aktibong arkitektura na may maraming mga processor ng query para sa pagsusulat, gamit ang optimistikong kontrol ng concurrency. Independiyenteng sumusukat para sa mga pagbabasa na may nakabahaging block store.
• Proseso ng Pagbasa at Pagsulat sa Aurora:
• Nabasa: Kinukuha ang data mula sa mga server ng imbakan sa mga availability zone (AZ) ng isang piniling processor ng query.
• Nagsusulat: Ang processor ng query ay ini-spool ang mga pagpapatakbo ng pagsulat hanggang sa gumawa ng transaksyon. Sa pag-commit, ipinapadala ang mga pagsusulat sa mga tagahatol (para sa paglutas ng salungatan) at pagkatapos ay sa mga journal (para sa pag-iimbak ng log sa mga AZ), na nag-a-update ng mga naapektuhang storage shards.
• Multi-region Operation:
• Aurora PostgreSQL: Gumagamit ng asynchronous replication para sa cross-region data, na nagreresulta sa in-region commit latency.
• Aurora MySQL: Ang mga commit ay sabay-sabay na ginagaya sa mga rehiyon, na humahantong sa cross-region commit latency bilang isang pangunahing pagkakaiba.