DynamoDB depolama dahili yapısı nasıl çalışır

DynamoDB, değerleri sıralı ağaçlar olan, üç Availability Zone'daki makinelere yayılmış bir hash tablosudur. İki veri yapısı işin neredeyse tamamını yapar: partition key üzerindeki bir hash bir makine seçer, sort key üzerindeki bir B-tree içindeki item'ları sıralar.

DynamoDB verilerini nasıl depolar?

DynamoDB, verilerinizi değerleri sıralı B-tree'ler olan devasa bir dağıtık hash tablosu olarak depolar. Partition key üzerindeki bir hash tek bir depolama node'u seçer; bir B-tree ise içindeki item'ları sort key'e göre sıralar. Her yazma, onaylamadan önce senkron olarak üç Availability Zone'daki üç node'a kopyalanır.

• Partition key hash'lenir, aranmaz. DynamoDB, o partition'ı tutan tek depolama node'unu bulmak için PK'n üzerinde bir hash fonksiyonu çalıştırır — tablo boyutundan bağımsız, O(1) bir sıçrama.
• Sort key bir B-tree'de yaşar. Bir partition'ın içinde item'lar SK'ya göre leksikografik sıralı bir B-tree'de saklanır, ki bu yüzden aralık okumaları (begins_with, between) ucuz ve Scan değil.
• Her yazma ack'lemeden önce üç node'a çarpar. Bir yazma, diğer AZ'lerdeki iki eşe senkron replike eden bir leader'a gider — dayanıklılık, PutItem'in dönmesinden önce satın alınır.
• Erişim-deseni kurallarının var olma nedeni budur. Hash-sonra-ağaç yalnızca key'e göre okuduğunda hızlıdır. Key yok, hızlı yol yok — ağacı taramaya geri dönersin.

API'yle değil, veri yapısıyla başla

SQL'den geliyorsan, bir tabloyu diskteki satırlar olarak, index seçen bir sorgu planlayıcısıyla resmedersin. DynamoDB'nin planlayıcısı yoktur. Depolama düzeni sözleşmenin kendisidir — neyin hızlı neyin ayak kapanı olduğu, ikisi de doğrudan iki yapıdan çıkar.

Dev bir dağıtık harita resmet. Key, partition key'inin bir hash'idir. Değer tek bir item değil — o partition key'ini paylaşan, sort key'e göre sıralı item'ların tüm bir B-tree'sidir.

Başka her şey — sorgu semantiği, 10 GB uyarıları, eksik bir key'in neden bir Scan zorladığı — o tek cümlenin sonucudur.

Node'u bulmak için partition key'i hash'le

Bir istek geldiğinde, DynamoDB partition-key değerine dahili bir hash fonksiyonu uygular. Hash deterministik olarak tek bir depolama node'una eşlenir — o item'lara sahip fiziksel partition. AWS bunu, tablo boyutundan bağımsız sabit-zamanlı key aramalarının arkasındaki mekanizma olarak belgeler.

İşte O(1) adımı budur. 10 TB'lık bir tablo ve 10 KB'lık bir tablo bulmak için aynı maliyettedir: hash, sıçra, bitti. Node'u bulmak için bir index taraması yok, istatistik yok, plan yok.

Püf nokta diğer yüzdür. Partition key'i sağlamazsan, DynamoDB'nin sıçrayacağı bir node'u yoktur — her partition'ı gezmek zorundadır. Bu bir Scan'dir ve O(1) ile tüm tabloyu okumak arasındaki farktır.

İstek tam olarak tek bir partition'a hash'lenir, sonra o partition'ın sort-key B-tree'sini item'a iner — bir tablo gezme yerine iki ucuz adım.

Item'ları partition başına bir B-tree'de sırala

Tek bir partition'ın içinde, item'lar bir heap değildir. Sort key'e göre key'lenmiş, leksikografik sıralı bir B-tree'de tutulurlar. Bir B-tree araması O(log n)'dir ve kritik olarak o n, tüm tablonun değil, tek bir partition'daki item'lardır.

Sort-key aralık okumalarının ucuz olmasının tüm nedeni budur. Her cihazın okumalarının tek bir partition key altında yaşadığı bir filo-telemetri tablosu ele al:

B-tree sıralı olduğundan, "08:00 ile 09:00 arasındaki tüm okumalar" başlangıç değerine bir ağaç inişi artı sıralı bir gezmedir — cihazın gönderdiği her okuma üzerinde bir filtre değil. Yalnızca eşleşen aralığı okursun.

O sıralama ayrıca neden bir begins_with(SK, "READING#2026-06-23") sorgusunun hızlı olduğudur, bir key olmayan attribute üzerinde filtrelemenin ise olmadığı. Ağaç SK'ya göre arama yapabilir; başka bir şeye göre arama yapamaz. O key koşullarını güvenle birleştirmek için, string'leri elle birleştirmek yerine onları DynamoDB Expression Builder içinde oluştur:

KeyConditionExpression  PK = :pk AND begins_with(SK, :day)

Her yazmayı üç AZ'ye replike et

Bir partition tek bir makine değildir. Her biri üç Availability Zone'daki üç node'a replike edilir — soyu 2007 Amazon Dynamo makalesinin replikasyon modeline kadar uzanan bir tasarım.

Bir node, partition için leader'dır. Bir yazma leader'a gider, leader yerel olarak yazar ve iki eşine replike eder. Leader, node'ların dayanıklı bir çoğunluğu (quorum) ona sahip olduğunda yazmayı ack'ler — dolayısıyla AZ'ler arası dayanıklılık, PutItem'in dönmesinden önce ödenir.

Okumaların bir seçeneği var. Bir güçlü tutarlı okuma leader'a gider ve en son commit edilen yazmayı görür. Bir nihai tutarlı okuma, üç node'dan herhangi biri tarafından sunulabilir, ki biri birkaç milisaniye geride olabilir — daha ucuz, daha erişilebilir okumalar için takas ettiğin gecikme budur.

Aynı async-yayılma fikri, bir GSI okumasının neden bayat olabileceğidir — bkz. GSI'ler nihai tutarlıdır.

Kuralları yapıdan oku

Neredeyse her DynamoDB "kuralı" yalnızca depolama fiziğidir:

• Her zaman partition key'i sağla. Key yok, hash hedefi yok — tüm haritayı tarıyorsun. Bu Query vs Scan'in özüdür.
• Birlikte okuduğun şeyi tek bir partition key altında bir araya getir, böylece tek bir hash + ağaç-gezme tüm item koleksiyonunu döndürür. Bu single-table design'in temelidir.
• Partition'ları sınırlı tut. Bir partition, sonlu bir node kümesi üzerinde tek bir B-tree'dir; kaçak bir hot key ya da bir LSI'nin 10 GB tavanı, ikisi de o fiziksel partition'ın limitleridir.

Hash-sonra-B-tree şeklini gördüğünde, erişim-deseni disiplini keyfî olmaktan çıkar — yalnızca her okumayı hızlı yolda tutuyorsun.

Sonraki adımlar

Key'lerini yapıyla eşleşecek şekilde sort key stratejileri ve single-table design ile modelle, sonra gerçek expression'ları DynamoDB Expression Builder içinde birleştir. Bu okumaların kendi tablolarına karşı çalışmasını izlemek ve bir key koşulunun tam olarak hangi item'ları geri çektiğini görmek için DynoTable'ı dene.