Sistem penyerapan dokumen yang sangat fleksibel, terukur, dan toleran terhadap kesalahan yang dirancang untuk pencarian.
Pembangunan dijalankan pada infrastruktur yang disumbangkan oleh
Seringkali, proyek pencarian dimulai dengan memasukkan beberapa dokumen secara manual ke mesin pencari, sering kali melalui fitur pemrosesan bawaan Solr "hanya untuk pengujian" seperti SolrCell atau post.jar. Fitur-fitur ini didokumentasikan dan disertakan untuk membantu pengguna merasakan apa yang dapat mereka lakukan dengan Solr dengan pengaturan minimal yang sulit.
Ini bagus dan begitulah seharusnya dalam eksplorasi pertama. Sayangnya hal ini juga berpotensi menjadi jebakan.
Terlalu sering, pengguna yang tidak tahu apa-apa, dan mungkin disesatkan oleh fakta bahwa antarmuka ini didokumentasikan dalam manual referensi (dan menganggap apa pun yang didokumentasikan pasti merupakan "cara yang benar" untuk melakukannya) terus mengembangkan sistem pencarian mereka dengan mengotomatiskan penggunaan antarmuka yang sama. Agar adil bagi para pengguna tersebut, beberapa versi lama dari panduan Solr Ref gagal mengidentifikasi sifat antarmuka yang "hanya untuk pengujian", terkadang karena komunitas memerlukan waktu beberapa saat untuk menyadari kendala yang terkait dengannya.
Sayangnya, penyerapan dokumen dalam skala besar untuk pencarian bukanlah hal yang sepele dan antarmuka pengindeksan tersebut tidak dimaksudkan untuk penggunaan produksi. Hasil yang biasa terjadi adalah ia berfungsi "baik" untuk korpus pengujian kecil dan kemudian menjadi tidak stabil pada korpus produksi yang lebih besar. Kode yang ditulis untuk dimasukkan ke dalam antarmuka seperti itu sering kali perlu diulang untuk beberapa jenis dokumen atau untuk berbagai format dokumen, dan dapat dengan mudah menyebabkan duplikasi dan penyalinan potong dan tempel dari fungsi umum. Selain itu, setelah menginvestasikan banyak rekayasa agar solusi tersebut berfungsi pada korpus besar, hal berikutnya yang mereka temukan adalah bahwa mereka tidak memiliki cara untuk memulihkan jika pengindeksan gagal di tengah jalan. Dalam kasus terburuk, kegagalan terkait dengan ukuran korpus dan kegagalan menjadi semakin umum seiring dengan pertumbuhan korpus hingga peluang untuk menyelesaikan dan menjalankan pengindeksan menjadi kecil dan sistem pada akhirnya tidak dapat diindeks atau ditingkatkan sama sekali jika masalah dibiarkan. membusuk. Hasilnya adalah serangkaian rasa sakit pertumbuhan yang mengerikan, menyakitkan, dan berpotensi mahal.
JesterJ berupaya untuk mempermudah memulai dengan infrastruktur pengindeksan berfitur lengkap yang kuat, sehingga Anda tidak perlu memikirkan kembali hal tersebut. JesterJ dimaksudkan sebagai sistem yang tidak perlu Anda tinggalkan sampai Anda bekerja dengan dokumen dalam jumlah yang sangat besar (dan mudah-mudahan pada saat itu Anda sudah menghasilkan keuntungan besar yang dapat membayar solusi khusus yang besar!). Berbagai komponen pemrosesan yang dapat digunakan kembali disediakan dan menulis prosesor khusus Anda sendiri semudah menerapkan antarmuka 4 metode dengan mengikuti beberapa panduan sederhana.
Seringkali versi pertama dari sistem untuk mengindeks dokumen ke Solr atau mesin pencari lainnya cukup linier dan lurus ke depan, namun seiring berjalannya waktu, fitur dan penyempurnaan sering kali menambah kompleksitas. Di lain waktu, sistem ini rumit sejak awal, mungkin karena penelusuran ditambahkan ke sistem yang sudah ada. JesterJ dirancang untuk menangani skenario pengindeksan yang kompleks. Pertimbangkan alur kerja pengindeksan hipotetis berikut:
JesterJ menangani skenario seperti itu dengan satu rencana pemrosesan terpusat, dan akan memastikan bahwa jika sistem dicabut, Anda tidak akan mendapatkan pesan kedua tentang pesanan yang diterima. Mode default untuk JesterJ adalah memastikan pengiriman paling banyak satu kali untuk langkah-langkah yang tidak ditandai aman atau idempoten. Langkah-langkah aman tidak memiliki efek eksternal, dan langkah-langkah idempoten dapat diulangi dalam perjalanan ke titik akhir pemrosesan akhir.
Lihat situs web dan dokumentasi untuk info lebih lanjut
Silakan lihat dokumentasi di wiki
Rilis saat ini : 1.0-Beta3. Ini adalah versi terbaik untuk digunakan, dan sebagian besar berfungsi. (masalah umum: #189)
Rilis Berikutnya: 1.0-Beta4 akan segera diterbitkan jika tidak ditemukan masalah serius dalam waktu dua minggu 1.0 akan dirilis.
CATATAN: Kode saat ini dan rilis 1.0 mendatang menargetkan desain dan beban apa pun yang dapat dilayani oleh satu mesin. JesterJ secara eksplisit dirancang untuk memanfaatkan mesin dengan banyak prosesor. Anda dapat merancang rencana Anda dengan duplikat langkah paling lambat untuk mengurangi kemacetan. Setiap duplikat menyiratkan thread tambahan yang mengerjakan langkah itu. Penskalaan thread otomatis direncanakan untuk versi 1.1 dan Penskalaan di banyak mesin merupakan prioritas utama untuk rilis 2.x. Seperti biasa, jika Anda menginginkan fitur ini lebih cepat, silakan mulai diskusi dan sumbangkan PR jika Anda mampu!
Saat ini hanya JDK 11 yang telah diuji secara rutin. Distribusi JDK 11 apa pun harus berfungsi. Dukungan untuk Java 17 dan versi LTS mendatang direncanakan untuk rilis mendatang.
Diskusikan fitur, ajukan pertanyaan, dll di Discord: https://discord.gg/RmdTYvpXr9
Dalam rilis ini kami memiliki beberapa fitur berikut
~/.jj/cassandra
Rilis 1.0 dimaksudkan agar dapat digunakan untuk sistem node tunggal, dan oleh karena itu cocok untuk digunakan pada proyek skala kecil hingga menengah (puluhan juta atau mungkin ratusan juta dokumen).
Tebakan terbaik kapan pun tentang apa yang akan terjadi pada rilis mendatang diberikan oleh filter pencapaian di halaman terbitan kami