DynamoDB Vektör Araması

DynamoDB, 5 Ağustos 2026'da yerel vektör arama kazandı. Embedding'leri öğelerinin üzerinde düz bir Number değerleri List'i olarak saklarsın, bir vektör index'i eklersin ve yeni SearchVectors API'siyle yaklaşık en yakın komşu sorguları çalıştırırsın.

Şimdiye dek benzerlik araması, tablonu OpenSearch'e ya da ayrı bir vektör veritabanına replike etmek ve ikisini senkron tutmak demekti. O pipeline artık yok. Yerine gelen faturalandırma modeli ise DynamoDB'deki başka hiçbir şeye benzemiyor.

DynamoDB vektör aramayı destekliyor mu?

Evet — 5 Ağustos 2026'dan beri, yerel olarak. Embedding'leri düz bir Number değerleri List'i olarak saklarsın, bir vektör index'i eklersin ve SearchVectors API'siyle yaklaşık en yakın komşu sorguları çalıştırırsın — OpenSearch replikası yok, ayrı vektör veritabanı yok. Yalnızca on-demand tablolarda, 4.096 boyuta kadar çalışır ve yazılan, aranan ve saklanan bayt başına faturalandırılır.

• Üçüncü bir index ailesi: vektör index'leri GSI'lar ve LSI'ların yanında durur. Tek bir yeni okuma API'si (SearchVectors), yalnızca ANN, yalnızca on-demand tablolar, 4.096 boyuta kadar.
• Hızlı, ölçülmüş: us-east-1'deki canlı 1024 boyutlu index'imize karşı SearchVectors, aynı istemciden GetItem kadar hızlı yanıt verdi (p50 39 ms vs 44 ms) ve taze bir yazma ~136 ms içinde aranabilir hale geldi.
• Ölçüm bayt başınadır: vektör yazmalarının GB'ı başına $0.52, bir aramanın incelediği vektör verisinin GB'ı başına $0.002, depolamanın GB-ay'ı başına $0.25 (us-east-1). Bir embedding'i index'lemek, temel tablo kopyasını boyut başına tam 4 bayttan faturalandırır; aynı liste index'siz ~1.9× faturalandırır.
• S3 Vectors hâlâ toplu depodur: beklemede kabaca 8× daha ucuz ve toplu yüklemesi çok daha ucuz. DynamoDB, milisaniyelik okumalarda, akış halinde yazmalarda ve vektörlerin tanımladıkları öğenin yanında yaşamasında kazanır.

Bir vektör index'i nasıl çalışır

Yeni bir attribute türü yok. Bir embedding, öğenin üzerinde sıradan bir sayı listesidir — telde {"L": [{"N": "0.0132"}, {"N": "-0.0475"}, …]} — ve zaten kullandığın aynı PutItem ve UpdateItem ile yazılır.

Index ayrı bir yapıdır. DynamoDB, vektörü ona 32-bit float hassasiyetinde, projekte ettiğin ya da üzerinde filtrelediğin tüm özniteliklerle birlikte asenkron replike eder. Arama sonuçları, bir GSI okuması gibi nihai tutarlıdır.

Gecikme pratikte küçüktür. Canlı test index'imize karşı, taze yazılmış bir vektör, PutItem döndükten yaklaşık 136 ms sonra arama sonuçlarında belirdi. Yine de üzerine asla bir kendi-yazdığını-oku akışı kurma.

Bildiğin index türlerinin yanında nerede durduğu:

Her index, boyut sayısını (4.096'ya kadar) ve üç mesafe fonksiyonundan birini oluşturma anında sabitler. COSINE ve EUCLIDEAN düşük-skor-daha-benzer puanlar; DOT_PRODUCT yüksek-skor-daha-benzer puanlar ve negatife düşebilir. Hiçbiri sonradan değiştirilemez.

Herhangi bir şeyi benchmark etmeden önce bir hassasiyet notu. Index, vektörleri f32 olarak tutar; daha yüksek hassasiyetli değerler kabul edilir ama girişte hassasiyet kaybeder. Float64 embedding'lerle geliyorsan her mesafe f32 kopyaya karşı hesaplanır; bu yüzden recall'u orijinallerine değil f32'ye karşı ölç.

Bir tane oluştur ve içinde ara

Diyelim ki destek biletleri üzerinde semantik arama çalıştırıyorsun; böylece bir temsilci, anahtar kelime eşleştirmeden "bununla daha önce karşılaşan müşterileri" bulabilsin. Her bilet öğesi, konusunun ve gövdesinin istediğin herhangi bir modelle üretilmiş bir embedding'ini taşır (Titan Text Embeddings V2, Bedrock'ta milyon girdi token'ı başına $0.02'ye mal olur).

Index'i mevcut tabloya ekle. HASH öğesi her aramayı tek bir product değerine kapsamlar; INLINE_FILTER öznitelikleri (18'e kadar) arama anında eşitlik filtrelerine izin verir:

aws dynamodb update-table \
  --table-name SupportTickets \
  --attribute-definitions AttributeName=product,AttributeType=S \
                          AttributeName=severity,AttributeType=S \
  --vector-index-updates '[{"Create": {
    "IndexName": "TicketEmbeddings",
    "VectorAttribute": {"AttributeName": "embedding"},
    "SearchSchema": [
      {"AttributeName": "product", "SearchSchemaElementType": "HASH"},
      {"AttributeName": "severity", "SearchSchemaElementType": "INLINE_FILTER"}
    ],
    "Projection": {"ProjectionType": "KEYS_ONLY"},
    "Dimensions": 1024,
    "DistanceFunction": "COSINE"
  }}]'

Oluşturma süreci, daha keskin kenarlı bir GSI backfill'i gibi davranır. SearchVectors, oluşturmanın tamamı boyunca ValidationException döndürür — kısmi sonuç yok.

AWS, DescribeTable ACTIVE dedikten sonra bile arama endpoint'inin bir süre reddetmeye devam edebileceği konusunda uyarır. Waiter yok; bir retry döngüsünde gerçek bir aramayla yokla. Index'i boş bir tabloyla birlikte oluşturduğumuzda 26 saniyede ACTIVE oldu ve 0.6 s sonra aramaları kabul etti.

Arama, sorgu embedding'ini {"N": …} değerlerinden oluşan çıplak bir JSON dizisi olarak alır. Onu bir DynamoDB L'sine sarma. Saklanan öznitelik liste türünü kullanır, istek parametresi kullanmaz ve ikisini karıştırmak kolay bir ilk hatadır:

aws dynamodb search-vectors \
  --table-name SupportTickets \
  --index-name TicketEmbeddings \
  --search-vector file://query-embedding.json \
  --top-k 5 \
  --search-condition-expression "product = :p AND severity = :sev" \
  --expression-attribute-values '{":p": {"S": "checkout"}, ":sev": {"S": "high"}}'

Geri, en-benzer-önce sıralı, her biri bir Score taşıyan TopK kadar öğe alırsın; istersen ConsumedCapacity de gelir. TopK 100'de tavanlanır, sayfalama yoktur ve yanıt 16 MB'de tavanlanır.

Embedding'in kendisi, onu projekte edip açıkça istemedikçe sonuçların dışında tutulur. Bu varsayılan bilinçlidir; vektörleri döndürmek hem yanıtı hem de arama faturasını şişirir.

Filtre ifadeleri yalnızca eşitlik kabul eder; BETWEEN, IN ya da begins_with yoktur. Index bir HASH özniteliği tanımladığında, her arama onun için tam olarak bir değer sabitlemek zorundadır. AWS'nin aralık operatörleri hakkındaki ifadesi "not yet available", yani bu gevşeyebilir.

İlk deploy'dan önce bilinmeye değer iki operasyonel sürpriz var. SearchVectors, mevcut okuma politikalarının hiçbirinde bulunmayan yeni dynamodb:SearchVectors IAM eylemine ihtiyaç duyar.

Ayrıca ayrı bir endpoint ile konuşur: search-dynamodb.{region}.amazonaws.com. Yalnızca dynamodb.{region}'ı kapsayan egress allowlist'leri ve VPC endpoint yapılandırmaları, nedenini asla söylemeyen bir bağlantı hatasıyla yalnızca vektör aramayı bozar.

Bir vektör index'i neyi faturalandırır

Normal tablo ücretlerinin üstünde, hepsi yazma başına ve arama isteği başına 1 KB minimumlu, bayt başına üç yeni sayaç (us-east-1, AWS fiyatlandırma API'sinden, 2026-08-15):

Dokümanlar, bir List içinde ondalık string'ler olarak saklanan bir embedding'in temel tablo kopyasının, index'teki f32 kopyadan "considerably larger" olabileceği konusunda uyarır. Yazma birimi faturalandırmasını us-east-1'deki canlı tablolara karşı ölçtük ve gerçek daha tuhaf.

Üzerinde hiç vektör index'i olmayan bir öznitelikteki embedding, belgelenmiş ondalık kurala göre, f32 boyutunun kabaca 1.9× katında faturalandırır. Aynı özniteliğe bir vektör index'i doğrult ve temel tablo faturası boyut başına tam 4 bayta düşer:

Yazma birimi sınırını bir dolgu özniteliğiyle ikiye böle böle arayarak, her yazmada taze bir öğe anahtarıyla, bayta kadar kalibre ederek ölçtük. Tam 1024 boyutlu bilet öğemiz 5 yazma birimi faturalandırdı; embedding üzerinde index olmayan birebir aynı öğe 8 faturalandırır.

Vektör yazma sayacı, aynı koşularda f32 boyutunu yakından izledi. VectorWriteRequestBytes, çıplak bir index'te boyut başına 4 bayt artı 11 B anahtar ek yükü, iki öznitelikli arama şemamızla ise artı 65 B olarak geldi.

Arama faturası, önceden hesaplayamayacağın sayaçtır. VectorSearchRequestBytes, ANN geçişinin ne kadar vektör verisi incelediğini izler ve AWS'nin kendi rehberliği, boyut sayısından tahmin etmek yerine bunu ReturnConsumedCapacity ile ölçmektir.

İlk veri noktalarını bizim yoklamamız veriyor. 50 vektörlük bir partition üzerinde TopK=10, arama başına 22.2-22.4 KB inceledi; aynı arama 1 vektörlük bir partition üzerinde yine 21.4 KB inceledi, yani küçük ölçekte sorgu başına kabaca 21 KB'lık (yaklaşık $0.00000004) bir taban var. AWS'nin eğitimi, kendi 50 vektörlük örneği için 31.449 bayt raporlar.

Tablo tarafı maliyetleri fiyatlandırma hesaplayıcısında modelle; vektör sayaçları, onun zaten hesapladığı yazma birimlerinin üstüne eklenir.

DynamoDB vektör araması vs S3 Vectors

AWS artık iki sunucusuz vektör deposu satıyor ve bunlar zıt erişim desenleri için inşa edilmiş. S3 Vectors (GA Aralık 2025), index başına 2 milyara kadar vektörü GB-ay başına $0.06'ya tutar, 100 ms ile 1 s aralığında yanıtlar ve her sorguyu tüm index'in boyutuna karşı faturalandırır.

DynamoDB milisaniyelerde yanıtlar ve index'in tuttuğuna değil, aramanın incelediğine karşı faturalandırır.

Akış senaryosunu yazma minimumları belirler ve bunlar depolama oranlarının tam tersini işaret eder. 1024 boyutlu vektörleri teker teker yazarken, milyon yazma başına (doğrulanmış oranlardan ve ölçtüğümüz öğe başına 5 yazma birimi + 4.161 vektör yazma baytından):

S3'ün PUT başına 128 KB minimumu, onu tam da insanların ucuz sandığı iş yükü için pahalı seçenek yapar. Vektörleri S3 Vectors'a teker teker akıtırsan DynamoDB'nin oranının neredeyse 5× katını ödersin; toplu yüklersen kabaca 7× daha az ödersin.

1024 boyutlu bir korpus için ayda 1M sorguda aylık depolama ve sorgu toplamları, doğrulanmış oranlardan hesaplanmıştır (yazma maliyetleri yukarıdaki milyon-başına tablodur). S3 Vectors'ın sorgu ücreti yayımlanmış formülünü izler: tüm index boyutu çarpı kademeli bir oran.

DynamoDB'nin sorgu ücreti incelenen baytlara bağlıdır, bu yüzden geçişini biliyormuş gibi yapmak yerine bir duyarlılık aralığı gösteriyoruz:

O tablodan iki şey çıkar. DynamoDB'nin sorgu başına maliyeti korpus boyutuyla büyümez — bir ANN araması index'i değil bir komşuluğu inceler ve partition key kapsamı onu daha da küçültür.

S3 Vectors'ın depolama avantajı (~8×, çünkü DynamoDB 4× oranda iki f32 kopya saklar) ise kimse sorgulasa da sorgulamasa da sonsuza dek birikir.

Hangisini ne zaman kullanmalı

• Vektörler zaten DynamoDB'de tuttuğun canlı öğeleri tanımlıyorsa (biletler, ürünler, kullanıcı oturumları, ajan hafızası): vektör index'ini kullan. Tek yazma yolu, tek öğe, kayacak bir senkron pipeline yok.
• Milyonlarca embedding, ara sıra sorgulanıyorsa (dokümanlar üzerinde RAG, arşivler, gece işleri): S3 Vectors'ı kullan. Ucuza toplu yükle, beklemede $0.06/GB öde, birkaç yüz ms'yi tolere et.
• Hibrit sıralamalı yüksek QPS (metin ilgililiği + vektörler, faceting, agregasyonlar): klasik bir serverless koleksiyon için kabaca ayda $350'lik bir altyapı tabanıyla, yanıt hâlâ OpenSearch.
• İlişkisel veriye join'lenen vektörler: pgvector'lü Aurora PostgreSQL — sıfıra ölçeklenir ve küçük RAG iş yükleri için ayda ~$50'nin altında kalır.

Bir DynamoDB dükkânı için dürüst varsayılan ikisidir. Sıcak, filtrelenebilir vektörleri, yazmaların öğeyle atomik olduğu tabloda tut ve uzun kuyruğu, güçlü tutarlı toplu yazmaları onu temiz bir havuz yapan S3 Vectors'a arşivle.

Tuzaklar

• Sessiz index dışı kalma: index'in HASH özniteliği eksik olan bir öğe tabloya sorunsuz yazılır ve vektör index'ine asla girmez. Bunu canlı olarak yeniden ürettik: PutItem başarılı oldu ve vektör 15 saniye sonra hiçbir partition'da yoktu. Hata yok, sonuç yok, yanıtta sana bunu söyleyecek hiçbir şey yok.
• Yanlış boyutlu yazmalar reddedilir: embedding modellerini migrate etmeden değiştir ve her yazma, özniteliği ve her iki boyutu adlandıran bir ValidationException ile başarısız olur (Invalid size for parameter, kendi sayfasında birebir yakalanmıştır), çünkü index boyut sayısını sonsuza dek sabitler.
• Bayat embedding'ler: DynamoDB vektörleri asla yeniden hesaplamaz. Bir biletin metnini embedding'i yeniden yazmadan düzenle ve aramalar sessizce eski içeriği eşleştirir. Standart çözüm, Streams artı bir yeniden üretim consumer'ıdır.
• TopK her zaman K öğe döndürür: üç iyi eşleşme ve --top-k 10 ile yine 10 alırsın. İlgililiği sonuç sayısıyla değil Score ile yargıla ve skor yönünün mesafe fonksiyonları arasında ters döndüğünü hatırla.
• 1 KB minimumları: düşük boyutlu vektörler, yazmalarda da aramalarda da orantılı olarak daha ucuza ölçülmez.
• Her şey değiştirilemezdir: boyutlar, mesafe fonksiyonu ve bir INCLUDE projeksiyonunun öznitelik kümesi — hepsini değiştirmek sil-ve-yeniden-oluştur gerektirir. Index depolaması, sorgulansın ya da sorgulanmasın, index'in tüm ömrü boyunca faturalandırır.

Kendi tablolarında dene

Vektör arama, DynamoDB'nin geri kalanının sana öğrettiği maliyet disiplinini devralır. Embedding'in boyutunu ona bağlanmadan önce ölç, çünkü öğe boyutu sınırları hâlâ geçerlidir ve 3072 boyutlu bir embedding, her öğe yazmasına iki sayaçta birden 12 KB ekler.

GSI'ların nasıl asenkron replike olduğunu ve ne zaman LSI yerine GSI seçileceğini biliyorsan index mekaniği tanıdık gelecek. Aynı veri üzerinde sözcüksel arama içinse DynamoDB'nin hâlâ bir tam metin motoru yok; vektör arama yazımı değil anlamı eşleştirir.

Bir embedding'in gerçek bayt maliyetini öğe boyutu hesaplayıcısında kontrol et, sonra vektör index'inin arkasındaki öğelere göz atmak için DynoTable'ı dene — embedding'ler, üzerinde filtrelediğin alanların hemen yanında sıradan liste öznitelikleri olarak görüntülenir.