Apakah DynamoDB mendukung pencarian teks lengkap?

Tidak, tidak secara native. DynamoDB tidak punya pencarian teks lengkap: tidak ada pemeringkatan relevansi, tidak ada stemming, dan tidak ada pencocokan fuzzy — alat string bawaannya hanyalah perbandingan persis, begins_with pada sort key, dan filter substring contains. Jawaban AWS adalah integrasi zero-ETL dengan Amazon OpenSearch Service, yang mereplikasi sebuah tabel ke dalam index pencarian untuk pencarian teks lengkap, vektor, dan semantik.

Apa yang bisa Anda lakukan secara native

begins_with pada sort key — pencocokan awalan yang efisien di dalam satu partisi; tulang punggung model sort key hierarkis.
contains di dalam filter expression — pencocokan substring, tetapi filter berjalan setelah pembacaan, jadi pada sebuah Scan Anda tetap membayar untuk membaca setiap item yang diperiksa. Lihat panduan strategi pemfilteran untuk tahu kapan ini bisa diterima.

Tak satu pun dari keduanya memeringkat hasil, menoleransi salah ketik, atau memahami batas kata — mereka adalah predikat string, bukan pencarian.

Query yang sama, empat cara, terukur

Kami memuat 100 item (84 KB) berisi judul produk dan men-scan tabelnya empat kali, hanya mengubah istilah pencariannya:

Filter	`Count`	`ScannedCount`	Unit baca	Cocok
`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	tidak ada

Bacalah baris-baris itu seperti pengguna yang sedang mengetik di sebuah kotak. "run" melewatkan Running shoes dan RUNNING SHORTS, karena perbandingannya case-sensitive. "Run" memulihkan Running shoes, tetap melewatkan RUNNING SHORTS, dan malah menyeret Rungs for a ladder, karena substring sama sekali tidak tahu di mana sebuah kata dimulai. Tidak ada pilihan huruf besar-kecil untuk query itu yang menemukan ketiganya. Hilangkan satu huruf dan Anda tidak dapat apa-apa sama sekali, karena tidak ada fallback fuzzy untuk menurunkannya.

Kolom terakhirlah yang memakan uang. Setiap scan mengonsumsi 11 unit baca, termasuk yang tidak mencocokkan apa pun, karena filternya berjalan setelah pembacaan. AWS mengatakannya terang-terangan: "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." Diagnosis mereka sendiri atas bentuk di atas: "A high ScannedCount value with few, or no, Count results indicates an inefficient Scan operation."

Jadi harga sebuah pencarian mengikuti ukuran katalog, tidak pernah kekhususan query-nya. Sambungkan ini ke kotak search-as-you-type dan "running shoes" menagihkan seluruh tabel tiga belas kali, satu kali per ketukan tombol, untuk mengembalikan satu item.

Jawaban native AWS: zero-ETL ke OpenSearch

Plugin DynamoDB untuk OpenSearch Ingestion menyinkronkan sebuah tabel ke satu atau beberapa index OpenSearch: snapshot awal dimuat lewat ekspor S3 milik DynamoDB (butuh PITR), lalu DynamoDB Streams mereplikasi perubahan mendekati real time. Pipeline-nya tidak mengonsumsi throughput baca atau tulis tabel Anda, jadi aman berdampingan dengan trafik produksi — dan AWS menyatakan integrasi itu memungkinkan pencarian teks lengkap, vektor, dan semantik atas data DynamoDB Anda.

Pelajari lebih lanjut

Kalau "pencarian" Anda sebenarnya adalah pencarian yang sudah diketahui, perbaiki modelnya saja — panduan strategi pemfilteran dan strategi sort key menunjukkan apa yang bisa dilakukan key. Buat prototipe kondisi begins_with/contains di expression builder, dan unduh DynoTable untuk memfilter data tabel live sambil Anda menjelajah.

Referensi

Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas.

Keempat scan itu dijalankan 2026-07-28 terhadap DynamoDB Local 3.3.0 dengan @aws-sdk/client-dynamodb 3.1095.0 pada Node v24.18.0. Count, ScannedCount, dan unit bacanya adalah angka milik engine itu sendiri.