How to use Lucene 3.4 with Mahout 0.5

As you may have been frustrated by, Mahout 0.5 was build with Lucene 3.1 dependencies. How on earth can we use Lucene 3.4 then? My SOLR is 3.4, I want to use its index to play with Mahout.

Fear not. Just download mahout 0.5, both source and binaries. Extract them, it will reside on the same folder i.e: mahout-distribution-0.5. Now, open up that pom.xml. Find lucene and replace 3.1.0 with 3.4.0. I reckon there are only 4 of them. The do mvn install. You may want to skip tests with: mvn -DskipTests=true install.

Once done, do: export MAHOUT_CORE=1

Run mahout from mahout-distribution-0.5/bin folder.

I don’t get index incompatibility anymore. But, I keep getting not enough term vector on document. Even I’ve set the schema.xml dan reindex my docs.

Will write more once I pass it.

Four Tips on Designing SOLR Schema

However similar SOLR to a database, designing schema for each of them has a distinct difference.

  • SOLR is optimized to search purpose, on the other hand, database was commonly design to store (related) data
  • SOLR has a custom behaviour when storing and querying data, ie: indexing behaviour and query behaviour.

So how is it to design schema in SOLR?

  1. Cover all basic data. Make sure to index everything you need to search onto. Indexing more data won’t hurt, storage is cheap.
  2. Cover common search behaviour. Do you search over several fields? Dismax query type sometime does fit your need as it is searching word by word. Store in one field or multifield? Or both? SOLR has copyField feature.You can use it for store concatenated values.
  3. Work on the relevancy and scoring. Setup proper score boosting to your search query. You may found a necessity to ignore score or to use FunctionQuery to tweak scoring or filling a “formula” field, ie: linear, product, sum, etc.
  4. Practise make perfect. Gather feedback from your users, check what search is work and what is not.

FAQ (to be answered soon):

  • Why SOLR, is database not enough?
  • Would it be fair to compare database to Lucene?

Photo by estherase

Lebih jauh dengan (bisnis dan) SOLR

Kenapa harus SOLR, tidak cukupkah google site search/google coop?

Google memang mengindeks dengan handal,akan tetapi Google sepertinya tak akan bisa memberikan banyak interpretasi semantic. Di sinilah implementasi SOLR akan banyak membantu kita. Model searching yang dicontohkan Google adalah evolusi dari search jaman dulu. Walau model ini bekerja dengan baik, kebutuhan search terus berkembang, pada akhirnya pengalaman yang didapat dari aktivitas pencarian lewat Google tidak akan mampu mengakomodasi seluruh permintaan konsumen. Konsumen membutuhkan pengalaman pencarian yang lebih berkesan. Vertical search adalah salah satu jawaban dan harapan. Vertical search hanya bisa dibangun jika semua data dan relasi antar data tersebut tersedia. Dan tentu saja hanya yang pemilik data itu sendiri yang tahu dan mempunyai informasi yang telah disebutkan sebelumnya. Ya, berarti semua orang terkualifikasi untuk mendayagunakan SOLR. Dan sang pemilik data itu sendirilah memang pihak yang paling tepat untuk mengendalikan pengalaman aktivitas pencarian.

Contoh kasus. Mislakan berikut ini adalah data yang kita punyai:

SOLR for Dummies
Pennington, Havoc
7888XXXXX
USD $27

Bisakah google menjawab pertanyaan “Buku apa yang ditulis oleh Havoc Pennington?”, “Buku-buku apa saja yang harganya di bawah $30?”. Google tak akan mampu menjawab satu pun dari pertanyaan tersebut kecuali Google tahu semantik/makna data dalam teks tersebut. Sebaliknya, dengan SOLR kita bisa menjawab pertanyaan di atas. Karena kita tahu bahwa “SOLR for Dummies” adalah judul buku, maka kita bisa mengindeks data ini di bawah field book_title dalam SOLR. Kemudian “Pennington, Havoc” bisa diindeks di bawah “author” dan seterusnya. Maka kita pun bisa mencari data yang kita inginkan dengan lebih akurat.

Siapakah klien potensial kita?

Mengulang kembali apa yang sempat kita singgung sebelumnya. Berikut ini adalah beberapa jenis klien potensial.

  1. Blogs. Data dalam blog bisa dipastikan jauh dari terstruktur. Ini adalah klien potensial yang tersulit. Potensial karena tumpukan datanya sangat banyak dan sepertinya belum ada yang sanggup mengolahnya menjadi data berharga. Hmmm, sebentar, mari kita berimajinasi. Ada tidak kemungkinan: ”cari ulasan tentang SOLR yang ditulis oleh Akhmad Fathonih”. Dengan struktur umum kontent blog berupa title, excerpt, permalink, full-content, category, dan tags ternyata kita sudah bsia memberikan value lebih. Dengan semakin meningkatnya permintaan dan kepercayaan pengguna internet akan peer review dan citizen jurnalism, query yang baru saja saya sebut pasti akan muncul.
  2. e-commerce sites. Segala situs yang bertema amazon, e-bay atau craiglist akan lebih mudah diindeks karena data telah distrukturkan dan mempunyai relasi antar data yang sudah jelas.
  3. Semua pemilik data yang menginginkan datanya lebih discoverable bagi penggunanya

Apa yang harus kita bootstrap lebih dulu?

Selain infrastruktur (cores, storage, bandwidth, etc) di mana kita akan mendeploy SOLR, plugins (untuk CMS dan other data management system) adalah salah satu hal kritikal. Faktor ini akan turut menentukan rendahnya barrier of entry pada konsumen. Semakin mudah konsumer bisa memanfaatkan layanan kita maka besar peluang kita untuk mendapatkan konsumen, data (untuk di-mining is possible) dan peluang-peluang lain.

What do you say?

While I will think and write more on this subject, I’m all free for any discussion; whether you are rushing to execute this plan before anybody else, or you want a simply routine-breaking chit-chat.

Photo:
Source
Flickr
Author
Cayusa
License