Commits dan NRT Search di SolrCloud

1. Ikhtisar

Solr adalah salah satu solusi pencarian berbasis Lucene yang paling populer. Ini cepat, terdistribusi, kuat, fleksibel dan memiliki komunitas pengembang aktif di belakangnya. SolrCloud adalah Solr versi baru yang didistribusikan .

Salah satu fitur utamanya di sini adalah pencarian near real-time (NRT) , yaitu dokumen tersedia untuk pencarian segera setelah diindeks.

2. Mengindeks di SolrCloud

Koleksi di Solr terdiri dari beberapa pecahan, dan setiap pecahan memiliki replika yang berbeda. Salah satu replika pecahan dipilih sebagai pemimpin pecahan tersebut saat koleksi dibuat:

  • Saat klien mencoba mengindeks dokumen, dokumen tersebut pertama kali diberi pecahan berdasarkan hash dari id dokumen
  • Klien mendapatkan URL pemimpin beling itu dari penjaga kebun binatang, dan akhirnya, permintaan indeks dibuat ke URL itu
  • Pemimpin shard mengindeks dokumen secara lokal sebelum mengirimnya ke replika
  • Setelah pemimpin menerima pengakuan dari semua replika yang aktif dan pulih, ia mengembalikan konfirmasi ke aplikasi klien pengindeksan

Saat kami mengindeks dokumen di Solr, itu tidak langsung ke indeks. Itu tertulis dalam apa yang disebut tlog (log transaksi). Solr menggunakan log transaksi untuk memastikan bahwa dokumen tidak hilang sebelum dibuat, jika terjadi crash sistem.

Jika sistem macet sebelum dokumen dalam log transaksi dilakukan, yaitu, disimpan ke disk, log transaksi diputar ulang saat sistem muncul kembali, yang mengarah ke nol kehilangan dokumen.

Setiap permintaan indeks / pembaruan dicatat ke log transaksi yang terus berkembang sampai kami mengeluarkan komit.

3. Berkomitmen di SolrCloud

Sebuah komit operasi sarana menyelesaikan perubahan dan bertahan bahwa perubahan pada disk. SolrCloud menyediakan dua jenis operasi komit yaitu. komit dan komit lembut.

3.1. Commit (Hard Commit)

Komit atau komit keras adalah salah satu di mana Solr membersihkan semua dokumen yang tidak terikat dalam log transaksi ke disk. Log transaksi aktif diproses, dan kemudian file log transaksi baru dibuka.

Ini juga menyegarkan komponen yang disebut pencari sehingga dokumen yang baru dikomit menjadi tersedia untuk pencarian. Seorang pencari dapat dianggap sebagai tampilan hanya-baca dari semua dokumen yang dikomit dalam indeks.

Operasi komit bisa dilakukan secara eksklusif oleh klien dengan memanggil API komit :

String zkHostString = "zkServer1:2181,zkServer2:2181,zkServer3:2181/solr"; SolrClient solr = new CloudSolrClient.Builder() .withZkHost(zkHostString) .build(); SolrInputDocument doc1 = new SolrInputDocument(); doc1.addField("id", "123abc"); doc1.addField("date", "14/10/2017"); doc1.addField("book", "To kill a mockingbird"); doc1.addField("author", "Harper Lee"); solr.add(doc1); solr.commit();

Dengan kata lain, ini bisa diotomatiskan sebagai autoCommit dengan menetapkannya di file solrconfig.xml , lihat bagian 3.4.

3.2. SoftCommit

Softcommit telah ditambahkan dari Solr 4 dan seterusnya, terutama untuk mendukung fitur NRT dari SolrCloud. Ini adalah mekanisme untuk membuat dokumen dapat dicari hampir secara real-time dengan melewatkan aspek mahal dari komitmen sulit.

Selama softcommit, log transaksi tidak terpotong, ia terus bertambah. Namun, pencari baru terbuka , yang membuat dokumen sejak softcommit terakhir terlihat untuk pencarian. Juga, beberapa cache tingkat atas di Solr tidak valid, jadi ini bukan operasi yang sepenuhnya gratis.

Saat kami menetapkan maxTime untuk softcommit sebagai 1000, itu berarti bahwa dokumen akan tersedia dalam kueri selambat-lambatnya 1 detik sejak diindeks.

Fitur ini memberi SolrCloud kekuatan pencarian hampir real-time, karena dokumen baru dapat dibuat dapat dicari bahkan tanpa perlu melakukannya. Softcommit dapat dipicu hanya sebagai autoSoftCommit dengan menetapkannya di file s olrconfig.xml , lihat bagian 3.4.

3.3. Autocommit dan Autosoftcommit

File solrconfig.xml adalah salah satu file konfigurasi terpenting di SolrCloud. Itu dibuat pada saat pembuatan koleksi. Untuk mengaktifkan autoCommit atau autoSoftCommit , kita perlu memperbarui bagian berikut di file:

 10000 30000 true   6000 1000 

maxTime: Jumlah milidetik sejak update uncommitted paling awal setelah commit / softcommit berikutnya harus dilakukan.

maxDocs: Jumlah pembaruan yang telah terjadi sejak komit terakhir dan setelah komit / softcommit berikutnya harus dilakukan.

openSearcher: Properti ini memberi tahu Solr apakah akan membuka pencari baru setelah operasi komit atau tidak. Jika benar , setelah komit, pencari lama ditutup, dan pencari baru dibuka, membuat dokumen yang dikomit terlihat untuk pencarian , Jika salah , dokumen tidak akan tersedia untuk pencarian setelah komit.

4. Pencarian Dekat Real-Time

Pencarian Near Real-Time dicapai di Solr menggunakan kombinasi komit dan softcommit. Seperti yang disebutkan sebelumnya, ketika dokumen ditambahkan ke Solr, itu tidak akan terlihat dalam hasil pencarian sampai itu dimasukkan ke indeks.

Komitmen normal itu mahal, itulah mengapa komitmen lunak berguna. Tetapi, karena softcommit tidak mempertahankan dokumen, kita perlu menyetel interval maxTime autocommit (atau maxDocs ) ke nilai yang wajar, tergantung pada beban yang kita harapkan.

4.1. G et s. Waktu Nyata

Ada fitur lain yang disediakan oleh Solr yang sebenarnya real-time - get API. The get API dapat kembali kami dokumen yang tidak bahkan lembut berkomitmen belum.

Ia mencari langsung di log transaksi jika dokumen tidak ditemukan di indeks. Jadi kita bisa mengaktifkan panggilan get API, segera setelah panggilan indeks kembali dan kita masih bisa mengambil dokumen.

Namun, seperti semua hal yang terlalu bagus, ada batasan di sini. Kita perlu meneruskan id dokumen dalam panggilan get API. Tentu saja, kami dapat menyediakan kueri filter lain bersama dengan id , tetapi tanpa id , panggilan tidak berfungsi:

//localhost:8985/solr/myCollection/get?id=1234&fq=name:baeldung

5. Kesimpulan

Solr memberikan sedikit fleksibilitas kepada kami terkait mengutak-atik kapabilitas NRT. Untuk mendapatkan kinerja terbaik dari server, kita perlu bereksperimen dengan nilai-nilai komit dan komitmen lunak, berdasarkan kasus penggunaan dan beban yang diharapkan.

Kita tidak boleh membiarkan interval komit terlalu lama, atau log transaksi kita akan bertambah besar. Kami tidak boleh terlalu sering mengeksekusi softcommit kami.

Juga disarankan untuk melakukan pengujian kinerja yang tepat dari sistem kami sebelum kami pergi ke produksi. Kami harus memeriksa apakah dokumen dapat dicari dalam interval waktu yang kami inginkan.