DynamoDB'de erişim desenlerine göre veri modelleme

DynamoDB'de modelleme neden ilişkisel veritabanından farklıdır?

Amazon DynamoDB, anahtar-değer ve belge modeline dayanan, tam yönetilen bir NoSQL veritabanıdır. İlişkisel veritabanında önce verinin yapısını normalleştirirsiniz, sonra sorguları sonradan düşünürsünüz; çünkü SQL esnektir ve birleştirme ile hemen her soruyu cevaplayabilir. DynamoDB'de ise sıra tersine döner: önce uygulamanın hangi soruları soracağını (erişim desenlerini) belirler, tabloyu bu sorulara hızlı cevap verecek şekilde tasarlarsınız.

Bunun nedeni, DynamoDB'nin birleştirme ve esnek sorgu sunmaması, karşılığında yüksek hacimde bile öngörülebilir ve düşük gecikmeli erişim vermesidir. Verimli sorgu için verinin, sorgulanacağı biçimde, anahtarlar üzerinden erişilebilir olması gerekir. Yani modelleme hatası, sonradan sorguyla düzeltilemez; tasarım aşamasında doğru yapılmalıdır. Bu yüzden DynamoDB'de en önemli beceri, ilişkisel modelleme alışkanlıklarından bilinçli olarak ayrılabilmektir.

Çalışma modeli: tablo, öğe, bölüm anahtarı, sıralama anahtarı

DynamoDB'de veri tablolarda, tablolar öğelerden (satır benzeri), öğeler ise niteliklerden oluşur. Her tabloda öğeyi benzersiz tanımlayan birincil anahtar bulunur. Birincil anahtar ya yalnızca bölüm anahtarından ya da bölüm anahtarı ile sıralama anahtarının birleşiminden oluşur.

Bölüm anahtarı verinin fiziksel olarak hangi bölüme dağılacağını belirler; sistem bu değere bakarak ilgili öğeyi doğrudan bulur. Sıralama anahtarı, aynı bölüm anahtarına sahip öğeleri sıralı tutar ve aralık sorgularına (belirli bir değerle başlayan, bir aralıktaki öğeler gibi) izin verir. Bölüm ve sıralama anahtarının birleşimi, DynamoDB'de modelin omurgasıdır. Bir müşterinin siparişlerini getirmek istiyorsanız, bölüm anahtarı müşteri, sıralama anahtarı sipariş zamanı ya da sipariş tanımlayıcısı olabilir; böylece tek sorguyla müşterinin tüm siparişlerini sıralı alırsınız.

Erişim deseni analizi: modelin başlangıç noktası

Modelleme çalışması bir erişim deseni listesiyle başlar. Uygulamanın her ekranı ve her arka plan işi için şu soruları yazın: hangi veriyi okumak ya da yazmak istiyoruz, hangi anahtarla, hangi sırayla, ne sıklıkta ve hangi tutarlılık gereksinimiyle?

Örneğin bir e-ticaret uygulamasının desen listesi şöyle olabilir: bir müşterinin profilini getir, müşterinin son siparişlerini listele, bir siparişin kalemlerini getir, bir ürünün güncel stok durumunu oku, belirli durumdaki siparişleri bul. Her desen için bir anahtar stratejisi çıkar. Listedeki bir desenin anahtarlarla karşılanamadığını fark ederseniz, ya ek bir indeks ya da veri kopyası gerekir. Erişim desenlerini yazıya dökmek hem tasarımı doğrular hem de ekip içi ortak bir referans oluşturur. Desenler sonradan değişirse model de gözden geçirilir; bu yüzden esnek kalmak için desenleri baştan eksiksiz toplamak gerekir.

Tek tablo tasarımı

Tek tablo tasarımı, birbirinden farklı türdeki varlıkları (müşteri, sipariş, ürün gibi) aynı tabloda, ortak bir anahtar şemasıyla saklama yaklaşımıdır. Anahtar nitelikleri genelleştirilir ve değerler türü belirten önekler taşır. Böylece ilişkili öğeler aynı bölüm anahtarında toplanır ve tek bir sorguyla birlikte getirilir; ilişkisel veritabanında birleştirmenin yaptığı iş, burada veri yerleşimiyle yapılır.

Bu yaklaşımın avantajı, birden çok varlığı tek istekte okumaktır; bedeli ise okunabilirlik ve esnekliktir. Tek tablo, yeni erişim desenleri eklemeyi zorlaştırabilir ve ekibin modeli anlaması için disiplin ister. Her proje için en doğru çözüm değildir; küçük ya da hızla değişen bir uygulamada birden çok tablo daha anlaşılır olabilir. Karar verirken şunu sorun: ilişkili öğeleri tek istekte almak gerçekten ölçülebilir bir kazanç sağlıyor mu, ekip bu modeli yıllarca sürdürebilir mi?

İkincil indeksler ve veri kopyalama

Birincil anahtar yalnızca tek bir erişim biçimini kapsar. Başka bir anahtarla sorgulama gerektiğinde ikincil indeksler devreye girer. Genel ikincil indeks (GSI) tamamen farklı bir bölüm ve sıralama anahtarı tanımlamanıza izin verir; yerel ikincil indeks ise aynı bölüm anahtarı ile farklı bir sıralama anahtarı sunar. İndeks, tablodaki verinin seçtiğiniz anahtarlarla yeniden düzenlenmiş bir kopyası gibi çalışır.

İndekslerin maliyeti vardır: her indeks yazma işlemlerini etkiler ve ek depolama kullanır. Bu yüzden her desen için indeks açmak yerine desenleri gruplayıp mümkün olduğunca az indeksle karşılamaya çalışın. İndekse hangi niteliklerin yansıtılacağı da önemlidir; yalnızca gerekli nitelikleri yansıtmak maliyeti düşürür. Seyrek indeks tekniği, yalnızca belirli bir niteliğe sahip öğeleri indeksleyerek küçük ve ucuz bir indeks elde etmenin yoludur. Sık erişilen ancak anahtarla bulunamayan verileri, uygun bir kopyalama stratejisiyle (aynı veriyi farklı anahtar altında saklamak) sunabilirsiniz.

Kapasite, tutarlılık ve işlemler

DynamoDB'de kapasiteyi farklı modlarda yönetebilirsiniz: isteğe bağlı mod, ölçülen istek kadar ödemeyi ve yükün öngörülemediği durumları rahatlatmayı sağlar; ön tahsisli mod ise öngörülebilir yüklerde kapasiteyi önceden tanımlamanıza ve otomatik ölçeklemeyle ayarlamanıza izin verir. Seçim, yükün ne kadar öngörülebilir olduğuna ve maliyet hassasiyetine göre yapılır. Yoğun trafiği tek bir bölüm anahtarına yığmak, sıcak bölüm sorununa yol açar; anahtarları yükü yayacak biçimde seçmek bu yüzden modelin parçasıdır.

Okumalarda nihai tutarlı ve güçlü tutarlı seçenekler vardır; güçlü tutarlılık gerektiğinde bunu isteğe belirtirsiniz ve bu seçenek farklı maliyet taşır. Birden çok öğeyi tek bir atomik işlemde yazmanız gerekiyorsa işlem (transaction) API'leri kullanılır. Koşullu yazma, bir öğenin yalnızca belirli bir koşul doğruyken değiştirilmesini sağlar; eşzamanlı güncellemelerde veri bütünlüğünü korumak için temel araçtır. Ömrü dolan verileri otomatik silmek için süre sonu özelliği, değişiklikleri izleyip başka sistemlere aktarmak için akış özelliği gibi gelişmiş yetenekler de bulunur.

Sık yapılan hatalar ve öğrenme yolu

• Erişim desenlerini çıkarmadan tabloyu tasarlamak: Sonradan sorgu yazılamaz hâle gelir.
• İlişkisel modeli olduğu gibi taşımak: Her varlık için ayrı tablo ve birleştirme beklemek verimsizdir.
• Tarama (scan) işlemine güvenmek: Büyük tablolarda yavaş ve pahalıdır; sorgulara dönüştürün.
• Düşük çeşitlilikli bölüm anahtarı: Yükü tek bölgeye toplar.
• Gereksiz indeks açmak: Yazma maliyetini ve depolamayı artırır.
• Maliyeti izlememek: Okuma ve yazma birimleri ile depolama zamanla birikir.

Öğrenme yolu için sıra şudur: önce anahtar kavramları (bölüm ve sıralama anahtarı) ve tek bir tabloda sorgu yapmayı kavrayın, sonra bir uygulama için erişim desenleri çıkarıp küçük bir model tasarlayın, ardından indeksleri ve tek tablo tasarımını deneyin, en son kapasite modlarını, işlemleri ve maliyet optimizasyonunu çalışın. Gerçek bir uygulama senaryosunu baştan sona modellemek, kavramları en çabuk yerleştiren alıştırmadır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Amazon DynamoDB ile NoSQL Veri Modelleme programı, bu sayfadaki akışa uygun başlıklar taşır: DynamoDB Temelleri ve Çalışma Modeli, Erişim Deseni Analizi, Tek Tablo Tasarımı, İndeks Stratejileri, Kapasite Yönetimi ve Ölçekleme, Gelişmiş Özellikler, İşlemler, Tutarlılık ve Veri Bütünlüğü ile Maliyet Optimizasyonu ve Modelleme Projesi.