AWS, veri gölünde depolanan Apache Iceberg ve Apache Parquet verilerinin Amazon Aurora PostgreSQL içindeki operasyonel verilerle birlikte doğrudan sorgulanabilmesini sağlayan bir özellik eklediğini duyurdu. Yeni özellik, uygulamaların PostgreSQL söz dizimini ve mevcut araçları kullanarak güncel ve geçmiş kayıtları tek bir sorguda birleştirmesine olanak tanıyor; verilerin ETL hatlarıyla veritabanına kopyalanması gerekmiyor.
Pratikte ne değişti?
İşlev, doğrudan Aurora PostgreSQL içine gömülü DuckDB motoruna dayanıyor. Böylece tek bir sorgu, yazılmamış işlemler de dahil olmak üzere operasyonel verileri okuyabildiği gibi Amazon S3'teki Iceberg tablolarını veya Parquet dosyalarını da okuyabiliyor. AWS Glue Data Catalog, Amazon S3 ve S3 Tables'ın yanı sıra Glue'daki federation mekanizması üzerinden Iceberg REST Catalog ile uyumlu kataloglar da destekleniyor.
Kullanıcının bir Aurora PostgreSQL kümesi oluşturması, AuroraAnalytics özelliğini içeren bir IAM rolü ilişkilendirmesi ve ardından aurora_analytics uzantısını etkinleştirmesi gerekiyor. Bundan sonra harici verilere işaret eden foreign table'lar oluşturulabilir veya meta verilerden veri şemasının otomatik olarak çıkarılmasıyla birden fazla tabloyu otomatik biçimde oluşturmak için IMPORT FOREIGN SCHEMA kullanılabilir.
Bu haber neden önemli?
Aurora'daki güncel işlemlerle S3'teki geçmiş kayıtları birleştiren uygulamaların, genellikle verileri reverse ETL yoluyla kopyalaması gerekiyordu; bu da senkronizasyon işlemleri, işletme maliyeti ve mühendislik karmaşıklığı ekliyordu. Artık bu birleştirme sorgunun kendisi sırasında gerçekleştirilebiliyor. Bu durum, geçmiş bağlama ihtiyaç duyan gösterge panoları, işlemi önceki bir kayıtla ilişkilendiren uygulamalar ve operasyonel bir veritabanı ile veri gölü arasında dağıtılmış verilerle çalışan sistemler için yararlı.
Bu nokta, yapay zekâ ajanlarını kullanan uygulamalarda daha da önem kazanıyor; çünkü ajanın ihtiyaç duyabileceği her veri kümesini önceden tahmin edip operasyonel bir veritabanına kopyalamak zor. Doğrudan erişim, her kullanım senaryosu için ayrı bir kopya oluşturmadan kullanılabilir verilerin kapsamını genişletiyor.
Performans ve erişim seçenekleri
Aurora, filtreleri veri kaynağına iletme ve okunan sütunları azaltma gibi optimizasyonlar uyguluyor; ayrıca sık kullanılan verileri Aurora örneği içinde önbelleğe alıyor. Her sorgunun davranışı, taranan satır sayısı, S3'ten okunan veri miktarı ve önbellekten yararlanma sayısı gibi göstergeleri sunan aurora_analytics_stat_statements() işlevi üzerinden incelenebiliyor.
Sorgular, yazar ve okumaya ayrılmış kopyalar dahil olmak üzere küme içindeki farklı Aurora örneklerinde kullanılabiliyor; bu da analitik tarama işlemlerinin operasyonel yükten uzaklaştırılmasını sağlıyor. Yanıt sürelerinin milisaniyenin binde biri mertebesinde olması gereken durumlarda ise veriler CREATE TABLE AS SELECT, INSERT INTO ... SELECT veya MERGE INTO kullanılarak yerel bir Aurora tablosunda somutlaştırılabiliyor. Somutlaştırmadan kaynaklanan yazma işlemleri yazar örneğinde gerçekleştiriliyor.
Kullanılabilirlik ve maliyet
Bu özellik, Aurora PostgreSQL'in 17.11'den itibaren 17. sürümünü ve 18.6'dan itibaren 18. sürümünü destekliyor. Özellik, özelliğin kendisi için ek ücret alınmadan tüm AWS ticari bölgelerinde ve AWS GovCloud (US) bölgelerinde kullanılabiliyor. Maliyet ise sorguların tükettiği ek Aurora işlem gücüyle ve veri gölü dosyalarının okunması için gereken Amazon S3 istek ücretleriyle bağlantılı olmaya devam ediyor.
certi.news'in değerlendirmesi: Temel değişiklik yeni bir depolama biçiminin eklenmesi değil, operasyonel veritabanı ile veri gölü arasındaki mesafenin azaltılması. Bununla birlikte bu durum iş yükü tasarımıyla ilgili hususları ortadan kaldırmıyor: Doğrudan sorgu, verilere esnek erişim için uygunken yanıt sürelerinin son derece düşük olması öncelik olduğunda somutlaştırmaya hâlâ ihtiyaç duyuluyor. Ayrıca Aurora işlem gücü ve S3 isteklerinin tüketimi, sorgu düzenine ve veri hacmine göre ölçülmesi gereken bir etken olmaya devam edecek.