- AWS artık Aurora PostgreSQL'in Apache Iceberg ve Apache Parquet verilerini önce veritabanına yüklemeden S3 ve S3 Tables'tan okumasına olanak tanıyor.
- Bu özellik, yerleşik bir DuckDB motoru, aurora_analytics uzantısı ve S3 ile AWS Glue'ya erişim sağlayan bir IAM rolü kullanır.
- Desteklenen sürümler, ticari ve GovCloud bölgelerinde Aurora PostgreSQL 17.11 ve üzeri ile Aurora PostgreSQL 18.6 ve üzeridir.
- Ekipler, canlı işlemsel satırları lakehouse verileriyle birleştirebilir, sonuçları önbelleğe alabilir ve düşük gecikmeli okumalar için sıcak veri kümelerini somutlaştırabilir.
Amazon Web Services, günlük uygulama kayıtlarını veri gölünde bulunan dosyalarla karıştırması gereken Aurora PostgreSQL kümeleri için yeni bir yol açtı . Yönetilen veritabanı artık Apache Iceberg tablolarını ve Apache Parquet dosyalarını önce Aurora'ya kopyalamadan okuyabiliyor; böylece tek bir SQL sorgusu hem canlı operasyonel satırları hem de arşivlenmiş bilgileri kapsayabiliyor. Bu hamle, mevcut ve geçmiş verileri kapsayan soruları yanıtlamak için sürekli olarak ayıklama, dönüştürme ve yükleme (ETL) işleri oluşturmaktan ve bunları yönetmekten yorulmuş ekipleri hedefliyor.
Veri gölünü ayrı bir dünya olarak ele almak yerine, bu hizmet mevcut PostgreSQL istemcilerinin, araçlarının ve uç noktalarının yabancı tablolar aracılığıyla veri gölü içeriğine erişmesine olanak tanır. Bu, geçmiş veri kümesinin yinelenen bir kopyasının operasyonel veritabanında bulunmasına gerek olmadığı ve uygulama geliştiricilerinin zaten bildikleri sözdizimini kullanmaya devam edebilecekleri anlamına gelir. AWS bunu, işlem hattı bakımını azaltmanın, altyapı yayılımını düşürmenin ve işlemleri eski bağlamla zenginleştirmeyi kolaylaştırmanın bir yolu olarak sunuyor.
Yeni Aurora PostgreSQL özelliğinin değiştirdiği şeyler nelerdir?
Bu özellik, müşterilerin başka bir yerde kurması gereken ayrı bir analiz ürünü değildir. aurora_analytics uzantısı ve kümenin Amazon S3 ve AWS Glue Veri Kataloğuna erişmesine izin veren bir AWS Kimlik ve Erişim Yönetimi rolü aracılığıyla etkinleştirilir . Bu rol ve uzantı yerleştirildikten sonra, yöneticiler Iceberg veya Parquet verilerine işaret eden yabancı tablolar oluşturur ve bunları tıpkı sıradan PostgreSQL tabloları gibi sorgular.
Mimari yapının dikkat çekici bir özelliği, DuckDB'nin doğrudan Aurora'ya entegre edilmiş olmasıdır . Açık kaynaklı analitik motor, lakehouse dosyaları üzerinde tarama işlemlerini gerçekleştirirken Aurora operasyonel iş yüklerine hizmet vermeye devam eder. Sorgu işleme, veritabanı ortamında kalır; bu da işin ayrı bir kümeye devredilmesini önler ve gecikmeyi ve ağ yükünü kontrol altında tutmaya yardımcı olur.
Desteklenen kaynaklar arasında AWS Glue Veri Kataloğu'nda kayıtlı Iceberg tabloları, Amazon S3'teki Parquet ve Iceberg nesneleri ve S3 Tablolarında tutulan veriler yer almaktadır. Iceberg REST Katalog arayüzünü izleyen harici kataloglara da Glue ile federasyon yoluyla erişilebilir, böylece ekiplerin halihazırda sahip oldukları katalog yatırımlarından vazgeçmeleri gerekmez. Bir sorgu, Aurora'daki satırları birden fazla kataloğa yayılmış Iceberg tablolarıyla birleştirerek, uygulamalara dosyaları taşımadan birleşik bir görünüm sağlayabilir.
Sürümler, kurulum ve desteklenen hizmetler
Aurora PostgreSQL 17, 17.11 sürümünden itibaren ve Aurora PostgreSQL 18, 18.6 sürümünden itibaren desteklenen sürümlerdir. Bir küme oluşturulduktan veya seçildikten sonra, yönetici AuroraAnalytics özelliğine sahip bir IAM rolü ekler ve uzantıyı etkinleştirir. Kurulum, Amazon RDS konsolu veya psql gibi bir PostgreSQL istemcisi aracılığıyla yapılabilir.
Yabancı tablo tanımları tek tek oluşturulabilir, ancak daha büyük ortamlarda AWS Glue Veri Kataloğu veritabanından tek adımda birçok yabancı tablo oluşturmak için IMPORT FOREIGN SCHEMA kullanılabilir . Parquet dosyaları için Aurora, şemayı dosya meta verilerinden okuyabilir; bu da her sütunu manuel olarak belirtme ihtiyacını ortadan kaldırır. Bu ayrıntı, geniş veya sık sık değişen veri kümelerine sahip ekipler için önemlidir.
Okuma sorguları yazıcı örneğinde veya okuma kopyasında çalıştırılabilir, böylece analitik taramalar birincil operasyonel iş yükünden uzaklaştırılabilir. CREATE TABLE AS SELECT, INSERT INTO … SELECT veya MERGE INTO gibi Aurora'ya veri yazan komutlar yazıcı örneğinde çalışır . Bu, ekiplere sürekli olarak hızlı yanıtlar gerektiğinde sıcak lakehouse verilerini yerel bir tabloya aktarma olanağı sağlar.
Yöneticiler, bir sorgunun ne yaptığını görmek için aurora_analytics_stat_statements() işlevini çağırabilirler. Bu işlev, taranan satır sayısı, Amazon S3'ten okunan bayt sayısı ve önbellek isabetleri gibi ölçümleri raporlar . Sık kullanılan veriler Aurora örneğinde önbelleğe alınır, bu nedenle aynı lakehouse nesnelerine tekrar tekrar erişim, nesne depolamasından aynı baytları tekrar tekrar çekmeden daha hızlı sonuç verebilir.
Performans, önbellekleme ve düşük gecikmeli yollar
Aurora, koşullu veri işleme ve sütun budama yöntemlerini uygular ; bu da veri gölünden yalnızca ilgili satır ve sütunların istenmesi anlamına gelir. Temel veri kümesi büyüdükçe, bu filtreleme sorguların tam taramalara dönüşmesini önlemeye yardımcı olur. Önbelleğe alınmış sonuçlar ve sorgu istatistikleri, operatörlere zamanın nerede harcandığını tahmin etmek yerine iş yüklerini optimize etmenin pratik bir yolunu sunar.
Tek haneli milisaniyelik gecikme süresi gerektiren uygulamalar için AWS, somutlaştırmayı (materialization) bir çıkış yolu olarak gösteriyor. Seçilen veri gölü kayıtları, bilindik SQL komutlarıyla yerel bir Aurora PostgreSQL tablosuna kopyalanabilir ve ardından diğer yerel tablolar gibi sorgulanabilir. Bu, en sık kullanılan veriler için hızlı bir yol sağlarken, veri gölünün tamamının daha geniş analizler için kullanılabilir kalmasını sağlar.
Şirket, gerçek zamanlı gösterge panellerini, geçmiş bağlamla zenginleştirilmiş işlemleri ve hem güncel hem de arşivlenmiş kayıtlar üzerinde akıl yürütmesi gereken yapay zeka aracılarını tipik kullanım örnekleri olarak sıralıyor. Ortak nokta, gece çalıştırılan bir toplu işleme veya ters ETL işine bekleyemeyen bir iş yüküdür. AWS, bir uygulamanın hem yeni hem de eski bilgiler için tek bir veritabanından bilgi istemesine izin vererek, işlem hattı karmaşıklığının tekrar eden bir kaynağını ortadan kaldırmayı umuyor.
Kullanılabilirlik ve fiyatlandırma
AWS'ye göre bu özellik tüm ticari AWS Bölgelerinde ve AWS GovCloud (ABD) Bölgelerinde mevcuttur. Ayrı bir özellik ücreti yoktur. Müşteriler, sorguların tükettiği ek Aurora işlem gücü ve veri gölü dosyalarını okumaya bağlı Amazon S3 istek maliyetleri için ödeme yapmaya devam eder . Bu fiyatlandırma modeli giriş noktasını düşük tutar, ancak yoğun analitik kullanım yine de faturada görünecektir.
AWS, bu lansmanı DuckDB performansını yönetilen hizmetlerine entegre etme çabasının bir parçası olarak sundu. DuckDB projesini sürdüren DuckLabs ekibi Amazon'a katıldı ve şirket, açık kaynaklı motorun gelecekteki iyileştirmelerinin Aurora ve diğer AWS tekliflerine de yansıyabileceğini söylüyor. Bu bağlantı, entegrasyonun tek seferlik bir özellik olarak kalmaktan ziyade gelişmeyi amaçladığını gösteriyor.
Veritabanı ekipleri için pratik cazibesi tanıdık: daha az hareketli parça, daha az yinelenen veri ve sorudan cevaba daha kısa bir yol. Dezavantajı ise erişim kontrollerinin, IAM izinlerinin ve katalog yapılandırmasının yine de dikkatle ele alınması gerektiğidir. Hem üretim satırlarını hem de lakehouse dosyalarını görebilen bir küme, güçlü bir tek sorgu yüzeyi haline gelir , bu nedenle yönetişim işin bir parçası olmaya devam eder.
Pratik etkisi, Aurora PostgreSQL ile veri gölü arasında daha sıkı bir bağlantı kurulmasıdır. Güncel işlemler ve geçmişe ait dosyalar tek bir SQL sorgusunda bir araya gelebilir, DuckDB analitik taramayı üstlenir ve materyalizasyon gerektiğinde hızlı bir yol sunar. PostgreSQL araçlarına zaten yatırım yapmış ekipler, analitik ağırlıklı iş yükleri için başka bir seçenek kazanırken, sıkı güvenlik veya maliyet kontrolleri olanlar, geniş çapta kullanıma sunmadan önce izinleri, önbellekleme davranışını ve S3 kullanımını gözden geçirmek isteyeceklerdir.
