My story began with SOLR DIH. It was way too slow. So, I ended up building another tool to replace DIH. Something friendly to CPU and memory. I did it. Not.

After indexing I realized that my text was full of ???????. WTF. Yeah, it’s encoding problem. So I’ve spent a day trying to solve this thing. What works for me was this advice from 2005:

PHP can input and output Unicode, but a little different from what Microsoft means: when Microsoft says “Unicode”, it unexplicitly means little-endian UTF-16 with BOM(FF FE = chr(255).chr(254)), whereas PHP’s “UTF-16″ means big-endian with BOM. For this reason, PHP does not seem to be able to output Unicode CSV file for Microsoft Excel. Solving this problem is quite simple: just put BOM infront of UTF-16LE string.

Example:

$unicode_str_for_Excel = chr(255).chr(254).mb_convert_encoding( $utf8_str, ‘UTF-16LE’, ‘UTF-8′);

I get no ??? char anymore. I don’t know if it is the proper way to do it. And I still get occasional htmlspecialchars invalid multibyte sequence. I think I’ll classify this solution as “miracle”.

When’s PHP 6 finally come?

Update:

CRAP. DOES NOT WORK!.

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.

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

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

To tell you the truth, SOLR is great. SOLR sebenarnya mirip dengan flat database yang teroptimasi untuk keperluan searching. Sama seperti halnya database, dalam SOLR juga dikenal apa yang disebut field. Jika dalam common DBMS bisa terdapat banyak tabel, dalam SOLR hanya bisa dibuat satu “tabel”. Lalu apa bedanya dengan database pada umumnya?

Seperti pada database pada umumnya, field dalam SOLR juga bisa diindex. yang membedakan SOLR dengan ordinary database adalah bahwa cara mengindex dengan algoritma yang kita definisikan sendiri. Misal, kita bisa mengindex dengna menghilangkan whitespace sehingga suatu record bisa dimatchkan dengan keyword: “PowerShot”, “Power-shot”, ataupun “power shot”, atau “power/shot”. Jika memakai database pada umumnya, anda memang bisa mensimulasikan hal yang sama. Akan tetapi anda pasti harus memproses keyword sebelum diforward ke database sebagai query. You won’t need such activity when dealing with SOLR. Dalam dunia SOLR, keyword akan dianalisa oleh SOLR sendiri. Bisa jadi prosesnya sama persis seperti saat hendak melakukan peng-indeks-an atau sama sekali berbeda. Kita bisa mendefinisikan tata caranya sesuai kebutuhan kita. Misalnya, kita ambil dari definisi yang ada di file skema SOLR:

A text field that uses WordDelimiterFilter to enable splitting and matching of  words on case-change, alpha numeric boundaries, and non-alphanumeric chars, so that a query of “wifi” or “wi fi” could match a document containing “Wi-Fi”.

Synonyms and stopwords are customized by external files, and stemming is enabled. Duplicate tokens at the same position (which may result from Stemmed Synonyms or WordDelim parts) are removed.

I guess above quote explains to you how interesting SOLR field is. Hehehe. Versi complete contoh schema bisa dilihat di sini. Jika dicuplik, terkait quote di atas, akan tampak seperti ini:

<!-- A text field that uses WordDelimiterFilter to enable splitting and matching of
        words on case-change, alpha numeric boundaries, and non-alphanumeric chars,
        so that a query of "wifi" or "wi fi" could match a document containing "Wi-Fi".
        Synonyms and stopwords are customized by external files, and stemming is enabled.
        Duplicate tokens at the same position (which may result from Stemmed Synonyms or
        WordDelim parts) are removed.
        -->
    <fieldType name="text" class="solr.TextField" positionIncrementGap="100">
      <analyzer type="index">
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <!-- in this example, we will only use synonyms at query time
        <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
        -->
        <!-- Case insensitive stop word removal.
             enablePositionIncrements=true ensures that a 'gap' is left to
             allow for accurate phrase queries.
        -->
        <filter class="solr.StopFilterFactory"
                ignoreCase="true"
                words="stopwords.txt"
                enablePositionIncrements="true"
                />
        <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt"/>
        <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
      </analyzer>
      <analyzer type="query">
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/>
        <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt"/>
        <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
      </analyzer>
    </fieldType>

See, ada bagian tersendiri untuk melakukan proses analisa dalam rangka pengindeksan dan ada definisi tata cara tersendiri untuk pemrosesan query yang dimasukkan oleh pengguna.

Lalu apa keunggulannya? Jelas unggul karena proses ini sudah “di-refactor”, tidak perlu lagi anda tangani sendiri jika anda memakai solusi database biasanya. Ini berarti anda bisa menyediakan pengalaman berbeda dan lebih unggul. tentun saja ini bisa berarti konten anda akan menjadi lebih discoverable dan lebih memiliki banyak value daripada sekedar teks biasa.

Vertical search, itulah yang terdekat bisa kita pikir. Tidak lagi seperti Google yang saat ini (ya, Google mungkin juga punya data untuk melakukan vertical search), akan tetapi mungkin bisa jadi seperti AOL yang saya contohkan kemarin.

Sumber foto:

Source

Flickr

Author

jurvetson

License

So, will it work? What do we sell?

• Sell grid power. This is no-brainer. But shouldn;t be the first in the priority list. For most site, search is a non-dominant action. So, they may already have the computing power needed to run their site (includes search activity)
• Tuneable search experience. User will no longer depending on what their CMS provide, instead they can create their own search experience using their defined field and search weigthing.
• Leverage content discoverability. Some site may have a big bulk of data inside their server. Indexing this data (on SOLR) may give them added value. Eg: faceted data can be displayed to attract visitors. It’s like “simple” data mining.
• Targetted ad . We can push ad onto the search page

Then, who are our potential customers?

• e-commerce site. There are many e-commerce site in Indonesia. many of then is simply built from scratch of using off-the-shelf FOSS CMS such as osCommerce which is lacking good search feature. yes, MySQL Fultext search just won’t cut it.
• document intensive site. Eg: library (OMG, there are lots of library out there), .go.id site
• any rich content site

Ok, so how are we going to execute it, technically?

• provide REST API, or
• simply expose the SOLR endpoint for integration and searching purposes

Former option would enable us to push our ad. And the later seems fit premium service, where user can process raw SOLR data.

So, anyone interested? Or desperately wanting one for your own site? Or, you suddenly want to start your own web crawler? That’s an interesting idea … Going vertical, anyone?

Photo source: swisscan