DynamoDB tam metin aramayı destekler mi?

Hayır, yerel olarak desteklemez. DynamoDB'de tam metin arama yoktur: alaka sıralaması yok, gövdeleme yok, bulanık eşleştirme yok — yerleşik dize araçları tam karşılaştırmalar, sıralama anahtarlarında begins_with ve contains alt dize filtreleridir. AWS'nin yanıtı, bir tabloyu tam metin, vektör ve anlamsal arama için bir arama indeksine çoğaltan Amazon OpenSearch Service ile zero-ETL entegrasyonudur.

Yerel olarak neler yapabilirsiniz

Bir sıralama anahtarında begins_with — tek bir bölüm içinde verimli önek eşleştirme; hiyerarşik sıralama anahtarı modellerinin omurgası.
Bir filtre ifadesinde contains — alt dize eşleştirme; ama filtreler okumadan sonra çalışır, dolayısıyla bir Scan'de incelenen her öğeyi okumanın bedelini yine ödersiniz. Bunun ne zaman kabul edilebilir olduğu için filtreleme stratejileri kılavuzuna bakın.

Hiçbiri sonuçları sıralamaz, yazım hatalarına tolerans göstermez ya da sözcük sınırlarını anlamaz — bunlar arama değil, dize yüklemleridir.

Aynı sorgu, dört farklı şekilde, ölçülmüş

Ürün başlıkları taşıyan 100 öğe (84 KB) yükledik ve yalnızca arama terimini değiştirerek tabloyu dört kez taradık:

Filtre	`Count`	`ScannedCount`	Okuma birimi	Eşleşen
`contains(title, "run")`	3	100	11	Shoes for runs · Trail running shoe · Sneaker, runner grade
`contains(title, "Run")`	2	100	11	Running shoes · Rungs for a ladder
`contains(title, "running")`	1	100	11	Trail running shoe
`contains(title, "runing")`	0	100	11	hiçbir şey

Bu satırları, bir kutuya yazan bir kullanıcının okuyacağı gibi okuyun. "run", Running shoes ve RUNNING SHORTS'u ıskalar, çünkü karşılaştırma büyük/küçük harfe duyarlıdır. "Run", Running shoes'u kurtarır, RUNNING SHORTS'u yine ıskalar ve bir de Rungs for a ladder'ı sürükler getirir, çünkü bir alt dizenin bir sözcüğün nerede başladığına dair hiçbir fikri yoktur. O sorgunun hiçbir harf düzeni üçünü birden bulmaz. Bir harf düşürün, hiçbir şey alamazsınız, çünkü düşülecek bulanık bir geri çekilme yoktur.

Son sütun paraya mal olan kısımdır. Her tarama, hiçbir şeyle eşleşmeyen dahil, 11 okuma birimi tüketti, çünkü filtre okumadan sonra çalışır. AWS bunu açıkça söylüyor: "A filter expression is applied after a Scan finishes but before the results are returned. Therefore, a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present." Yukarıdaki biçime dair kendi teşhisleri: "A high ScannedCount value with few, or no, Count results indicates an inefficient Scan operation."

Yani bir aramanın fiyatı, sorgunun özgüllüğünü değil kataloğun boyutunu izler. Bunu yazdıkça-ara kutusuna bağlayın; "running shoes" tek bir öğe döndürmek için tablonun tamamını, her tuş vuruşunda bir kez olmak üzere, on üç kez faturalandırır.

AWS'nin yerel yanıtı: OpenSearch'e zero-ETL

OpenSearch Ingestion için DynamoDB eklentisi, bir tabloyu bir ya da daha fazla OpenSearch indeksiyle eşitler: ilk anlık görüntü DynamoDB'nin S3 dışa aktarımıyla yüklenir (PITR gerekir), sonra DynamoDB Streams değişiklikleri neredeyse gerçek zamanlı olarak çoğaltır. İşlem hattı tablonuzun okuma ya da yazma verimliliğinden hiç tüketmez, dolayısıyla üretim trafiğinin yanında güvenlidir — ve AWS, entegrasyonun DynamoDB verileriniz üzerinde tam metin, vektör ve anlamsal aramayı mümkün kıldığını belirtir.

Daha derine inin

"Aramanız" gerçekte bilinen bir arama ise, bunun yerine modeli düzeltin — filtreleme stratejileri ve sıralama anahtarı stratejileri kılavuzları anahtarların neler yapabileceğini gösteriyor. begins_with/contains koşullarını ifade oluşturucusunda prototipleyin ve keşfederken canlı tablo verilerini filtrelemek için DynoTable'ı indirin.

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.

Dört tarama 2026-07-28 tarihinde @aws-sdk/client-dynamodb 3.1095.0 ile Node v24.18.0 üzerinde DynamoDB Local 3.3.0'a karşı çalıştırıldı. Count, ScannedCount ve okuma birimleri motorun kendi sayılarıdır.