pengindeksan dokumen ringan untuk menangani kurang dari 250 ribu catatan potensial

Baru-baru ini saya mendapati diri saya kesal pada keterbatasan mesin pengindeksan dokumen. Saya sedang mengembangkan sebuah situs web kecil yang membutuhkan beberapa kemampuan pencarian yang cukup kuat tetapi karena kendala perangkat kerasnya, saya tidak dapat menggunakan solusi Lucene-ish (seperti Solr atau ElasticSearch, seperti yang biasanya saya lakukan) untuk menangani kebutuhan ini.

Dan bahkan saat itu, ketika saya perlu menyajikan beberapa data dan perhitungan yang kompleks yang padat-basis data, saya tidak perlu menangani lebih dari 250 ribu catatan potensial. Menyebarkan seluruh contoh Solr atau ES hanya untuk menangani ini sepertinya sia-sia.

Setelah saya memikirkannya, sepertinya masalah yang cukup besar. Kebanyakan orang menangani persyaratan pencarian hanya dengan SQL. Mereka hanya menjalankan query SQL untuk data mereka dan hanya itu. Kemampuan pencarian mereka juga berakhir mengerikan.

• Melakukan pencarian wildcard full-text blanket bisa sangat lambat pada beberapa sistem (host bersama khususnya) dan menghambat database Anda, terutama jika Anda memiliki pertanyaan yang rumit dan banyak bergabung.

• Anda akhirnya melakukan beberapa kueri atas satu permintaan dari pengguna. Anda mungkin bisa menyelesaikan ini dengan pertanyaan yang semakin rumit, tetapi lihat poin sebelumnya.

• Kurangnya fitur biasanya hadir dalam mesin teks lengkap.

Basis data memiliki masalah yang sama yaitu perlu digunakan sebagai server dan kemudian SQLite datang dan tiba-tiba kita bisa menggunakan database yang lengkap dalam satu file. Googling saya tidak menghasilkan apa-apa - bertanya-tanya apakah ada sesuatu seperti ini untuk pengindeksan / pencarian teks lengkap.

Faktor-faktor apa yang harus dipertimbangkan ketika memutuskan apakah akan menerapkan pengindeksan dokumen ringan (misalnya seperti yang dijelaskan dalam jawaban atas pertanyaan lain ) atau tetap menggunakan SQL untuk situasi ini?

Anda tahu, saya harus mengatakan pertimbangkan untuk menggunakan redis.

• Gunakan ide konteks . Akan sulit untuk masuk tanpa tahu lebih banyak tentang dokumen. Seringkali Anda dapat membedakan banyak hal dari judul dokumen. Membuat profil setiap dokumen adalah langkah dasar dasar, seperti halnya perayapan web.

• Lakukan penghitungan pada setiap dokumen kata dalam kamus kata kunci. Melacak jumlah popularitas setiap kata untuk total proyek. Tambahkan bobot lebih ke iterator untuk hitungan ini jika Anda dapat mendeteksi relevansi tinggi dalam dokumen atau set.
  
  Hal pertama yang dilakukan adalah memberi Anda daftar kata yang mencakup semua dalam seluruh rangkaian Anda. Apa pun yang TIDAK ditemukan dalam daftar itu, secara otomatis mengembalikan 'tidak ada hasil'. Saya sarankan hasil peringkat yang lebih rendah dari 5-20% bawah popularitas (ketika menjalankan permintaan pencarian pada indeks) juga hanya mengatakan tidak ada hasil '.

• Jika Anda tidak pergi dengan sesuatu seperti Redis, atau bahkan hanya membuat struktur memori Anda sendiri, Anda dapat memasangkan dokumen dengan file descriptor atau berkas mini-db dan benda-benda halaman yang menggambarkan setiap kembali dokumen spesifik-balik ke memori. Simpan pencarian umum di memori dengan mungkin mereka bersaing untuk slot atau memberi mereka waktu untuk hidup yang tumbuh pada setiap pencarian.

• Untuk melangkah lebih jauh, mulailah menyimpan data referensi yang mengelompokkan tautan / ref / pointer / indeks / apa pun dari dua atau lebih dokumen dan kumpulan kata kunci atau frasa. Pada dasarnya Anda mendapatkan cloud tag yang dipompa.

• Lebih jauh lagi, lakukan pendeteksian frase dengan melacak ketika sebuah kata dalam kamus Anda diikuti atau didahului oleh string yang tepat, biasanya dalam dokumen dengan metadata / judul yang sama. Ini intensif tetapi hanya membutuhkan satu pass untuk merender data.

• Semakin banyak cara Anda dapat memisahkan data Anda dan menjaga grup terkait satu sama lain dalam penggunaan aktual, semakin baik.

• Hubungkan kemungkinan kebenaran dengan melacak setiap kali pengguna mengklik hasil yang bukan tiga besar. Dapatkan peningkatan deteksi frase dengan menonton pencarian pengguna yang tidak memberikan hasil sempurna. Paksa permintaan Anda untuk menjadi relatif terhadap pencarian klien.

• Apakah Anda harus memperhatikan pembaruan dokumen? Chronjobs / skrip shell atau tugas terjadwal / skrip batch dapat membantu. Ada berbagai opsi untuk penjadwalan dan scripting meskipun jelas.

• Limbah disk, menambah kecepatan, kehilangan kompleksitas. Simpan beberapa pohon dokumen Anda dan / atau pohon tautan ke dokumen. Hanya mencari di pohon yang kriteria telah dipenuhi, atau setidaknya lebih suka untuk mendapatkan hasil lebih cepat dalam banyak kasus.

• Buat mesin permutasi ringan Anda sendiri atau temukan yang menggunakan deteksi karakter cepat dan tanpa regex. Atau cukup buat satu menggunakan regex dalam beberapa jam tetapi perbedaan kinerja akan terlihat di sini untuk pencarian yang memadai.

• Begitu banyak hal.

Ini dimaksudkan sebagai solusi yang mungkin untuk menerapkan pengindeksan dan pencarian dokumen yang kuat. Itu tidak termasuk semua. Dan pada saat itu Anda mungkin akan melakukan yang lebih baik untuk mengambil kotak cadangan, melemparkan jaring saraf di atasnya dan menghabiskan beberapa hari membuat antarmuka web yang bagus ke jaring saraf itu.