Dokumen ini menjelaskan praktik terbaik untuk API Search. Kami menggunakan tanda petik
tunggal ('') untuk memisahkan string kueri. Dengan cara ini, kueri yang berisi
frasa dengan beberapa kata dan dikelilingi oleh tanda petik ganda dapat dipisahkan tanpa membuat Anda kebingungan:
'field:"some text" some-value'
.
Panggilan batch Index.put() dan Index.delete()
Anda dapat meneruskan hingga 200 dokumen sekaligus saat menambahkan atau menghapusnya dari indeks. Ini jauh lebih efisien daripada menanganinya satu per satu.
Menggunakan peringkat dokumen untuk melakukan pra-pengurutan dokumen
Secara default, penelusuran menampilkan hasilnya dengan peringkat menurun. Juga secara default, API Search menetapkan peringkat setiap dokumen ke hitungan detik sejak 1 Januari 2011. Hal ini menyebabkan dokumen terbaru ditampilkan terlebih dahulu. Namun, jika tidak perlu mengurutkan dokumen berdasarkan waktu penambahannya, Anda dapat menggunakan peringkat untuk tujuan lain. Misalkan Anda memiliki aplikasi real estat. Hal yang paling diinginkan pelanggan adalah mengurutkan berdasarkan harga. Untuk pengurutan default yang efisien, Anda dapat menetapkan peringkat ke harga rumah.
Jika memerlukan beberapa tata urutan seperti harga dari rendah ke tinggi dan harga dari tinggi ke rendah, Anda dapat membuat indeks terpisah untuk setiap urutan. Satu indeks akan memiliki peringkat = harga dan peringkat lainnya = MAXINT-price (karena peringkat harus positif).
Menggunakan peringkat sebagai kunci pengurutan akan meningkatkan performa penelusuran. Untuk menentukan kunci pengurutan lainnya, Anda harus menggunakan opsi pengurutan yang membatasi jumlah hasil penelusuran hingga 10.000 dokumen. Dalam hal ini, tata urutan yang ditentukan berdasarkan peringkat akan menentukan dokumen yang akan disertakan dalam pengurutan. Baca opsi pengurutan untuk mempelajari lebih lanjut.
Menggunakan kolom atom untuk data boolean
Menyimpan data boolean di kolom angka sangat tidak efisien. Gunakan kolom atom sebagai gantinya, dan tetapkan konstanta favorit Anda (True/False, yes/no, 0/1).
Mengubah negatif menjadi positif
Misalkan Anda memiliki istilah khusus untuk mengidentifikasi restoran yang hidangannya tidak ditentukan. Jika ingin mengecualikan restoran tersebut, Anda dapat menggunakan 'NOT cuisine:undefined'
sebagai kueri. Namun, cara ini lebih mahal untuk dievaluasi (baik dalam biaya operasi dan waktu komputasi) dibandingkan melakukan hal sebaliknya, yaitu menemukan restoran yang hidangannya sudah diketahui. Daripada menggunakan satu kolom masakan, Anda dapat menggunakan dua kolom, cuisine
dan cuisine_known
, dengan kolom kedua sebagai kolom atom. Untuk restoran yang hidangannya ditentukan, Anda menetapkan kolom pertama ke hidangan sebenarnya dan kolom kedua ke "yes"
. Untuk restoran yang hidangannya tidak diketahui, Anda menetapkan hidangan ke ""
(string kosong) dan cuisine_known
ke "no"
. Sekarang, untuk menemukan restoran yang hidangannya diketahui, Anda mengeluarkan kueri 'cuisine_known:yes'
, yang jauh lebih cepat daripada negasi.
Mengubah disjungsi menjadi konjungsi
Disjungsi "OR" adalah operasi yang mahal dalam beban biaya operasi dan waktu komputasi. Misalnya Anda ingin menelusuri 'cuisine:Japanese OR cuisine:Korean'
. Alternatifnya adalah mengindeks dokumen dengan kategori hidangan yang lebih umum. Dalam hal ini, kueri dapat disederhanakan menjadi 'cuisine:Asian'
.
Menghilangkan tautologi dari kueri Anda
Misalkan Anda ingin mencari semua restoran di Toronto. Dengan asumsi bahwa dokumen Anda hanya memiliki satu kolom bernama "kota", jika menggunakan kueri 'city:toronto AND NOT city:montreal'
, Anda akan mendapatkan hasil yang sama dengan 'city:toronto'
. Ini terjadi karena jika kota ditetapkan ke "toronto"
, kota tidak dapat ditetapkan ke "montreal"
. Kueri kedua berjalan jauh lebih cepat karena hanya melibatkan satu istilah. Kueri pertama melakukan tiga langkah: pertama, menemukan daftar dokumen tempat kota ditetapkan ke “toronto”, lalu menemukan daftar semua kota untuk kota yang tidak ditetapkan ke “montreal”, dan terakhir menghitung persimpangan dari kedua daftar tersebut.
Mempersempit rentang sebelum mengurutkan
Misalnya aplikasi Anda menyimpan informasi tentang restoran di seluruh dunia, dan Anda ingin menampilkan restoran yang terdekat dengan pengguna saat ini. Salah satu cara untuk melakukannya adalah dengan mengurutkan dokumen yang cocok berdasarkan jarak dari lokasi pengguna. Namun, jika Anda memiliki 1.000.000 restoran, menjalankan kueri seperti 'cuisine:japanese'
dengan jarak ekspresi pengurutan (geopoint(x, y), restaurant_loc) akan memakan waktu yang lama. Ada baiknya Anda menambahkan filter ke kueri sehingga Anda memulai dengan kumpulan dokumen pilihan yang lebih penting untuk diurutkan. Salah satu solusinya adalah membuat kategori geografis, seperti negara, negara bagian, dan kota - Anda dapat menyimpulkan kota dan negara bagian dari lokasi pengguna. Kemudian, kueri Anda menjadi 'cuisine:japanese AND city:<user-city>'
. Kemungkinannya sangat bagus karena Anda tidak perlu lagi mengurutkan 1.000.000 dokumen.
Menggunakan kategori yang sempit untuk menghindari atau meminimalkan pengurutan
Jika menggunakan peringkat untuk mengurutkan restoran berdasarkan harga, Anda dapat membuat kolom price_range
yang berisi kategori harga: price_0_10
, price_11_20
, price_21_30
, price_31_40
, price_41_lots
. Kemudian Anda dapat menemukan semua restoran dengan harga antara $21 dan $40 tanpa pengurutan sama sekali menggunakan kueri 'price_range:price_21_30 OR price_range:price_31_40'
. Dalam banyak kasus, kategori yang sesuai tidak terlihat jelas, tetapi dengan teknik ini, Anda dapat menolak dokumen dalam jumlah besar sebelum menyingkirkan penelusuran dengan kueri yang mahal seperti '... AND price>25 AND price<35'
.
Jangan buat skor kecocokan kecuali Anda harus melakukannya
Penskoran digunakan untuk menunjukkan seberapa cocok suatu dokumen dengan kueri tertentu. Namun, kecuali jika Anda ingin mengurutkan berdasarkan skor, jangan minta penskoran. Tindakan ini hanya akan memperlambat penelusuran Anda.