blixt php
1.0.0
Mewakili berbagai jenis dalam indeks, seperti pengguna, produk dll.
Mewakili batang kata, unik untuk seluruh indeks. (misalnya lari adalah batang dari kata -kata yang berjalan, pelari, berlari dll.). Frekuensi dokumen terbalik dihitung dan disimpan terhadap kata tersebut untuk memberikan IDF selebar indeks yang dapat digunakan untuk melakukan pencarian tanpa skema terhadap indeks.
Suatu istilah mewakili keberadaan kata dalam skema tertentu. Artinya, jika kata yang dibendung "jalankan" muncul dalam skema pengguna dan juga muncul dalam skema produk, maka akan ada dua catatan istilah untuk kata itu, dalam skema itu. Frekuensi dokumen terbalik juga disimpan di samping istilah untuk memberikan IDF spesifik skema yang memungkinkan pencarian terhadap skema tertentu (pencarian ini tidak akan dipengaruhi oleh nilai IDF selebar indeks untuk kata-kata).
Kolom adalah bidang yang tersedia dalam skema. Kolom menyimpan aturan tentang apakah data yang diwakilinya disimpan, apakah itu diindeks dan bobotnya yang dapat digunakan untuk memprioritaskan kolom dalam kueri (misalnya judul produk mungkin memiliki bobot lebih dari deskripsi)
Sebuah dokumen mewakili entitas aktual dalam indeks, ini adalah item yang sebenarnya diindeks dan akan membentuk dasar hasil untuk kueri.
Bidang adalah atribut dari dokumen yang cocok dengan kolom. Kolom, dokumen, dan bidang bertindak seperti database yang khas. Kolom seperti kolom tabel, dokumen seperti baris atau catatan dan bidang adalah sel atau entri.
Suatu kejadian mewakili keberadaan istilah (kata spesifik skema) dalam bidang dalam dokumen. Kejadian adalah representasi unik dari suatu istilah dan bidang. Di samping suatu kejadian, kami juga menyimpan frekuensi, yang mewakili berapa kali istilah muncul di dalam bidang (yang digunakan untuk menghitung skor nanti saat mencari).
Posisi mewakili posisi sebenarnya dari istilah dalam bidang. Jika kata "run" (atau batangnya) muncul 3 kali di bidang, akan ada 3 catatan posisi, masing -masing menandai posisi kejadian itu dalam bidang yang sesuai.
Bayangkan kami memiliki skema "pengguna" dalam indeks kami. Skema itu mendefinisikan 2 kolom untuk setiap instance pengguna, "nama" dan "tentang". Setiap kolom disimpan dan diindeks dan mereka berdua memiliki bobot 1. Kami memiliki 2 pengguna untuk ditambahkan ke indeks, [kunci: 1, nama: "Joe Bloggs", "tentang": "Joe suka Jane"] dan [Key: 2, nama: "Jane Doe", tentang: "Jane suka berpesta"]. Kami akan berakhir dengan struktur berikut:
| pengenal | nama |
|---|---|
| 1 | pengguna |
| pengenal | nama | tersimpan | diindeks | berat |
|---|---|---|---|---|
| 1 | nama | 1 | 1 | 1 |
| 2 | tentang | 1 | 1 | 1 |
| pengenal | kata |
|---|---|
| 1 | Joe |
| 2 | Blogg |
| 3 | menyukai |
| 4 | Jane |
| 5 | kelinci betina |
| 6 | Cinta |
| 7 | ke |
| 8 | berpesta |
| pengenal | schema_id | word_id | Document_count |
|---|---|---|---|
| 1 | 1 | 1 | 2 |
| 2 | 1 | 2 | 1 |
| 3 | 1 | 3 | 2 |
| 4 | 1 | 4 | 3 |
| 5 | 1 | 5 | 1 |
| 6 | 1 | 6 | 1 |
| 7 | 1 | 7 | 1 |
| 8 | 1 | 8 | 1 |
| pengenal | schema_id | kunci |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| pengenal | Document_id | kolom_id | nilai |
|---|---|---|---|
| 1 | 1 | 1 | Joe Bloggs |
| 2 | 1 | 2 | Joe menyukai Jane |
| 3 | 2 | 1 | Jane Doe |
| 4 | 2 | 2 | Jane suka berpesta |
| pengenal | field_id | Term_id | frekuensi |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 1 | 2 | 1 |
| 3 | 2 | 1 | 1 |
| 4 | 2 | 3 | 1 |
| 5 | 2 | 4 | 1 |
| 6 | 3 | 4 | 1 |
| 7 | 3 | 5 | 1 |
| 8 | 4 | 4 | 1 |
| 9 | 4 | 3 | 1 |
| 10 | 4 | 7 | 1 |
| 11 | 4 | 8 | 1 |
| pengenal | kejadian_id | posisi |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | 1 |
| 4 | 4 | 2 |
| 5 | 5 | 3 |
| 6 | 6 | 1 |
| 7 | 7 | 2 |
| 8 | 8 | 1 |
| 9 | 9 | 2 |
| 10 | 10 | 3 |
| 11 | 11 | 4 |
Ketika objek blixt dibuat, awalnya memuat semua skema yang tersimpan dan objek kolom ke dalam memori, jika ada. Hal ini memungkinkan Blixt dengan cepat mencari skema dan kolom yang terkait untuk memvalidasi permintaan indeks dan untuk dengan cepat mengumpulkan kendala is_indexed dan is_stored pada setiap kolom.
Sebelum pengindeksan dokumen dapat terjadi, skema harus ditentukan dengan satu set kolom, masing -masing dengan properti mereka sendiri yang menentukan apakah bidang yang mereka wakili harus disimpan dan atau diindeks. Jika skema sudah ada, bagian ini dapat dilewati. Jika definisi skema tidak disediakan dan tidak ada skema seperti itu, pengecualian dilemparkan.
Dokumen disediakan dalam bentuk dokumen yang dapat diindeks, menentukan kunci yang dapat digunakan oleh sistem klien untuk mengidentifikasinya nanti. Dokumen yang dapat diindeks berisi satu set bidang. Skema (atau jenis) disediakan bersama dengan dokumen sehingga Blixt dapat menempatkan dokumen dalam skema yang benar dalam indeks.
Blixt mulai memproses dokumen dengan pertama -tama memeriksa untuk memastikannya belum ada dalam indeks di bawah skema itu. Jika ada, pengecualian dilemparkan.
Blixt kemudian akan menambahkan catatan dokumen dan mulai memproses bidang dokumen. Setiap bidang dibagi menjadi token (dalam banyak kasus token adalah sebuah kata), dan kemudian masing -masing token berasal (yaitu menemukan akar kata, misalnya dengan bahasa Inggris/Porter Stemmer kata "run" adalah batang dari kata "running", "runner", "run" dll))
Catatan kata kemudian ditambahkan untuk masing -masing token jika belum ada catatan yang sesuai, dan kemudian catatan istilah dibuat berdasarkan skema yang sesuai. Total jumlah dokumen untuk Catatan Istilah diperbarui untuk mencerminkan penambahan dokumen baru.
Catatan kejadian dibuat untuk setiap istilah unik dan kombinasi lapangan, menunjukkan bahwa istilah yang ditentukan terjadi dalam bidang spesifik. Frekuensi (berapa kali istilah itu terjadi di dalam lapangan) disimpan di sepanjang sisi catatan kejadian. Data posisi juga disimpan terhadap setiap catatan kejadian yang mewakili setiap posisi dalam bidang yang terjadi istilah.
Jenis -jenis pertanyaan berikut didukung:
+ yang membuat istilah diperlukan (dan) atau ~ yang membuat istilah menghapus dokumen dari pertimbangan (bukan). Jenis kueri ini membentuk dasar dari semua kueri lainnya. Pencarian dimulai dengan membagi frasa pencarian menjadi kata -kata terpisah (tokenisasi) dan kemudian mengubah setiap kata menjadi bentuk akarnya (Stemming). Indeks kemudian ditanyai untuk menemukan catatan kata yang cocok dengan istilah. Menggunakan catatan kata dan skema yang kami interogasi, catatan istilah kemudian diekstraksi. Jika salah satu istilah pencarian yang memiliki operator + terpasang padanya tidak ada dalam catatan istilah, maka set hasil kosong dikembalikan.
Kueri kemudian dilakukan untuk menemukan bidang yang berisi ketentuan kueri (terlepas dari operator) dan dokumen -dokumen yang terkait dengan bidang -bidang tersebut dikembalikan (dengan bidang, kejadian dan posisi mereka yang semuanya dimuat sesuai). Setiap dokumen kemudian dianalisis dan diterima atau ditolak, jika dokumen tidak berisi istilah yang diperlukan ( + ) atau memuat istilah yang dihapus ( ~ ) ditolak, semua dokumen lain diterima. Set dokumen yang diterima kemudian dikembalikan sebagai hasil.
Jenis -jenis kueri berikut akan didukung nanti:
Kueri istilah tunggal: Mirip dengan kueri multi-jangka, dokumen dinilai terhadap satu istilah.
Permintaan frasa penuh: Mirip dengan kueri multi-jangka, tetapi hanya dokumen yang berisi setiap istilah dalam urutan yang benar diizinkan.
Ini juga dimaksudkan untuk menerapkan parsing kueri sehingga string pencarian input dapat dikonversi ke jenis kueri yang benar sebelum pencarian dilakukan.
Ini adalah perbaikan yang dimaksudkan untuk masa depan.
Menerapkan cache agnostik penyimpanan (redis, memcached, sistem file dll.) Yang dapat kita gunakan untuk meningkatkan kinerja pencarian. Ada sejumlah kasus penggunaan untuk cache dalam proyek ini:
Catatan: Untuk mengimplementasikan beberapa fitur di atas, kami berpotensi perlu menggunakan pengidentifikasi sesi yang unik untuk dilewati dan menerima dari pengguna untuk memastikan bahwa pencarian yang di -cache hanya berlaku untuk pengguna tersebut dan untuk menghentikan objek yang di -cache yang dibersihkan. Ini jelas terjadi ketika caching serangkaian hasil pencarian lengkap untuk memungkinkan pengguna paginat. Ini juga bisa menjadi versi caching yang layak yang tidak dianggap khusus sesi untuk memungkinkan banyak pengguna mencari hal yang sama untuk melihat hasil pencarian yang sama dengan cepat.
Selama proses pengindeksan kami dapat menggunakan tabel tambahan untuk menyimpan pemetaan istilah ke dokumen, yang akan memberi tahu kami dokumen mana yang muncul dalam istilah yang diberikan. Ini akan memungkinkan kami untuk melewatkan banyak proses mencoba menentukan ID dokumen kandidat hanya dengan meraih daftar dokumen bahwa suatu istilah muncul untuk memungkinkan kami menghasilkan dengan cepat (atau dalam kasus yang dikurangi, mengurangi jumlah dokumen.
