DynamoDB'de Query ve Scan

Query, partition key ile tek bir item koleksiyonunu okur (isteğe bağlı olarak sort key'i daraltarak); Scan ise tüm tabloyu okur ve sonradan filtreler. API'de benzer görünürler, ancak tamamen farklı faturalandırılır — ve ölçeklenir.

DynamoDB'de Query mi yoksa Scan mi kullanmalıyım?

İhtiyacınız olan partition'ı adlandırabildiğiniz her durumda Query kullanın — tek bir item koleksiyonunu okur ve yalnızca eşleşen item'lar için faturalandırılır. Scan'e yalnızca tek seferlik dışa aktarımlar veya küçük tablolar için başvurun; her item'ı okur ve herhangi bir FilterExpression çalışmadan önce tüm tabloyu faturalandırır. Gerçek verilerde Query kazanır.

• Query hedeflidir: eşleşen partition'daki item'lar için ödeme yaparsınız.
• Scan kapsamlıdır: her item'ı okumak için ödeme yaparsınız, ardından çoğunu okuma ölçüldükten sonra çalışan bir FilterExpression ile atarsınız.

Gerçek boyutta herhangi bir tabloda, filtreli bir Scan, klasik "faturam neden bu kadar yüksek ve gecikmem RDS'den daha kötü" tuzağıdır.

Yan yana

Ana tuzak: bir FilterExpression, her iki işlemde de, DynamoDB okumayı ölçtükten sonra çalışır. "10 satır döndüren" bir Scan, bir milyon okumak için faturalandırabilir — filtreleme bir kolaylıktır, asla bir maliyet kontrolü değil.

Query kullanın

Query  PK = "USER#42"  AND  SK begins_with "ORDER#"

Yaygın bir erişim modelini yanıtlamak için kendinizi Scan'e başvururken buluyorsanız, bu bir modelleme sinyalidir: modelin bir Query haline gelmesi için bir Global Secondary Index ekleyin.

Seçim tek bir soruya iner — ihtiyacınız olan partition'ı adlandırabiliyor musunuz?

Anahtar biliniyorsa Query yaparsınız; bilinmiyorsa onu bir Query yapmak için bir GSI ekleyin ve yalnızca hiçbir anahtar uymadığında Scan'e geri dönün.

Scan ne zaman uygundur

Tek seferlik dışa aktarımlar, küçük yapılandırma tabloları ve tüm tablo arasında bilerek sayfalama yapan arka plan işleri. Gerçekten her şeyi okumanız gerektiğinde, bir Scan'i çalışanlar arasında bölmek (bir parallel scan) için Segment/TotalSegments kullanın.

DynamoDB üzerinde refleksif bir SELECT * FROM table, PartiQL kılığında aynı anti-modeldir — bir Scan'e derlenir. Gerçekten item'lar arası analitik (bir GROUP BY, bir JOIN, bir toplama) gerektiğinde, DynoTable'ın SQL Workbench'i bunları tabloyu zorlamak yerine sınırlı bir sonuç kümesi üzerinde istemci tarafında çalıştırır.

Her iki modelin de maliyetini kapasite hesaplayıcısı ile tahmin edin ve bu sorguları kendi tablolarınıza karşı çalıştırmak ve incelemek için DynoTable'ı deneyin.