DynoTable
İleri6 dakikalık okuma

DynamoDB Paralel Scan'ler

Paralel bir scan, tek bir Scan'i N bağımsız Scan isteğine böler; her biri tablonun bir Segment'ini alır, böylece birden fazla worker aynı anda okur. Scan API'nin tüm tabloyu tek bir partition'ın throughput'unun izin verdiğinden daha hızlı okumanın tek yoludur.

DynamoDB paralel scan nedir?

Bir DynamoDB paralel scan, tek bir Scan'i Segment ve TotalSegments ile tablonun bir Segment'ini talep eden N bağımsız isteğe böler; worker'lar eşzamanlı okur. Scan API'nin tüm tabloyu tek partition throughput'undan hızlı okumanın tek yoludur — ama yine de tam bir okumadır, taradığın her öğe için ödersin.

  • Sıralı bir Scan partition'ları tek tek okur — hızı tablonun boyutu ne olursa olsun tek bir partition'ın throughput'uyla sınırlıdır.
  • Segment + TotalSegments okumayı shard'lar; her worker kendi dilimini paralel tarar.
  • DynamoDB segment atamak için 'i hash'ler, bu yüzden dilimler dengesiz olabilir — daha fazla worker her zaman daha hızlı demek değildir.
  • Hâlâ bir Scan'dir: her öğeyi okumak için ödersin ve şişkin bir paralel scan canlı trafiğinin altından tablonun throughput'unu boşaltabilir.

Sıralı Scan neden yavaştır

SQL'den geliyorsan tam tablo okuması tek bir streaming işlem gibi gelir. DynamoDB'de öyle değildir. Tablonun verisi birçok fiziksel partition'a yayılır ama tek bir Scan onları tek tek gezer, sayfa başına 1 MB.

Yani düz bir Scan bir anda yalnızca bir partition'ın throughput bütçesinden çekebilir — tablo düzinelerce boş kapasiteli partition'a yayılmış olsa bile. Tablo büyüdükçe sürünme uzar. (AWS: Paralel scan)

Okumayı Segment ve TotalSegments ile böl

Paralel scan darboğazı çözer. Bir worker sayısı seçersin, TotalSegments'i o sayıya ayarlarsın ve her worker'a sıfır tabanlı ayrı bir Segment verirsin. Her worker kendi Scan'ini yollar; DynamoDB onları eşzamanlı sunar.

Worker 0 →  Scan  Segment=0  TotalSegments=4
Worker 1 →  Scan  Segment=1  TotalSegments=4
Worker 2 →  Scan  Segment=2  TotalSegments=4
Worker 3 →  Scan  Segment=3  TotalSegments=4

Her worker hâlâ LastEvaluatedKey ile bağımsız sayfalar — segmentini ilk sayfadan sona kadar sahiplenir. Uygulama dört akışı birleştirir. Artık bir yerine dört partition'lık throughput okuyorsun.

İşlenmiş örnek: gece export'u

Diyelim bir telemetri tablosu çalıştırıyorsun, sensor-readings. Her öğe bir saha cihazından bir okumadır:

PK = "DEVICE#a83f"          (partition key — the device id)
SK = "TS#2026-06-22T03:14"  (sort key — ISO timestamp)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

Her gece bir cron tüm tabloyu analytics warehouse için S3'e döker. 80 GB'lık sıralı bir Scan saatler sürer ve provisioned okuma kapasiteni zar zor yer. Sekiz worker'a yayarsın:

Scan  sensor-readings  Segment=0  TotalSegments=8  ConsistentRead=false
…
Scan  sensor-readings  Segment=7  TotalSegments=8  ConsistentRead=false

Sekiz worker, sekiz segment, bir tablo okuması kabaca sekiz kat hızlı. Yalnızca yakın okumalar gerekiyorsa, satırlar wire'a düşmeden eski timestamp'leri atan bir FilterExpression ekle — ifadeyi Expression Builder'da kur ve incele:

FilterExpression:  begins_with(SK, :today)

DynamoDB öğeleri segmentlere nasıl atar

DynamoDB her öğeyi partition key'ini hash'leyerek bir segment'e atar — satır sayısına veya bayt sayısına göre değil.

Aynı PK'yi paylaşan her öğe aynı segment'e düşer. sensor-readings'te DEVICE#a83f için tüm okumalar, cihazın kaç timestamp'i olursa olsun veya 'ı ne kadar büyük olursa olsun, bir worker'a gider. (AWS: Paralel scan)

sensor-readings tablosupartition key'i hash'leSegment 0DEVICE#a83fDEVICE#1c20Segment 1DEVICE#9be4Segment 2 (boş)

Segmentler dengesiz çıkar. Bir worker milyonlarca okuması olan üç konuşkan cihazı sahiplenebilir; diğeri boş bir dilim çekebilir. Partition key'lerin kümelenmesi varsa TotalSegments'i yükseltmek yardımcı olmaz — sıcak olanı bekleyen boş worker eklersin. Fan-out'un işe yaramasını sağlayan şey düzgün key dağılımıdır.

Çalıştırmadan önce okuma maliyetini gör

Paralel scan bir throughput olaydır, bedava öğle yemeği değil. Dürüst soru "bu tüm tablonun ne kadarını okumak üzereyim?" — ve DynoTable tam tablo okuması çalıştırmadan önce yaklaşık tablo boyutu ve öğe sayısı artı bir okuma kapasitesi uyarısı gösteren bir onay diyaloğuyla seni kapılar, sonra okuma koşarken canlı taranan-öğe ilerlemesini yayınlar; böylece gece işi seni şaşırtmaz.

Tuzaklar ve ne zaman uğraşma

  • Throughput uçurumu. Yüksek TotalSegments'li bir scan saniyeler içinde tablonun tüm okuma kapasitesini tüketip canlı trafiği aç bırakabilir. Kullanıcı servis eden bir tabloda her worker'ı Limit ile kısıtla veya yoğun saat dışında tara. (AWS: Paralel scan)
  • Hâlâ bir erişim deseni için yanlış araçtır. Paralel scan'ler bilinçli tam tablo işleri içindir — export, backfill, migration. Tekrarlayan bir sorguyu yanıtlamak için birine uzanıyorsan bu bir modelleme sinyalidir: bir GSI ekle ve bunu bir Query yap.
  • PartiQL'de SELECT * aynı scan'in kılığıdır. Sıralı bir Scan'e derlenir. Gerçekten öğeler arası analytics gerektiğinde — bir GROUP BY, JOIN, aggregate — DynoTable'ın SQL Workbench'i tabloyu dövmek yerine bunları sınırlı bir sonuç kümesi üzerinde istemci tarafında çalıştırır.
  • Güçlü tutarlılık faturayı ikiye katlar. Scan varsayılan olarak okur. Export için ConsistentRead=false bırak — her sayfanın en son yazmaları yansıtması gerekmedikçe — ve güçlü tutarlı bir scan'in bile dakikalar sürdüğünü unutma; bu bir anlık görüntü değildir (bunun için PITR/Export kullan).

Sonraki adımlar

Günlük okumaların hiç scan gerektirmemesi için anahtarlarını modelle — single-table design ve Query vs Scan ile başla. Tam tablo işi gerçekten doğru çağrıysa, önceden boyut-ve-maliyet uyarısı ve canlı scan ilerlemesiyle tam tablo okumaları çalıştırmak için DynoTable'ı dene.

Güncellendi