Arama Sunucuları

Merhaba arkadaşlar, kısa süre önce naçizane sosyal medya üzerinden duyurduğum Solr hakkında yazı dizisi hazırlama haberini hayata geçiriyorum.

Zamanım oldukça Solr hakkında öğrendiğim/uyguladığım birçok bilgi/yöntemi buradan paylaşmaya çalışacağım. Basit kurulumundan başlayıp (bu yazı hazır, önümüzdeki hafta yayında olacak), replica kurulum, cloud kurulum gibi adımlarla devam edip, daha sonra detaylı konfigürasyon yazıları (solr.xml, solrconfig.xml, schema.xml, zoo.cfg vd.) yayınlayıp örnek senaryolar üzerinden Solr optimizasyon konularını içeren yazıları da paylaşıp yazı dizisini tamamlamayı düşünüyorum.

Neden Arama Sunucusu* (otomatik tamamlama – auto complete)

Bu yazı tabi ki arama sunucusu kullanmayı düşünenler için ama yine de -tam cevabı olamasa da- kendi tecrübelerime dayanarak ifade etmeye çalışayım. Genellikle kullanıcı arama sorgularını veritabanı üzerinde LIKE kullanarak işleriz, text alanlarda da MATCH() AGAINST ile fulltext search yaparız. Hatta bazen SOUNDEX de kullandığımız olmuştur ve bunu basit bir eşleme işi için kullandığımı da söylemeden geçemeyeceğim.

Özellikle gelişmiş e-ticaret sistem ve/veya sitelerini teknik açıdan incelerseniz (Magento iyi bir örnek) sadece arama yapmak değil kullanıcı anlamaya ve yardımcı olmaya yönelik birçok optimizasyon yapıldığını rahatlıkla görebilirsiniz. Mesela arama kelimeleri için eşanlamlı sözcük listesi kullanılır. Kullanıcı sorgusu öncelikle bu kelimelerin olduğu tabloda taranır ve değiştirilerek yukarıdaki arama yöntemi ile devam edilir. Mesela kullanıcı Karnıbahar araması yaptığında biz bunu Karnabahar olarak değiştirip (düzeltme) aramayı bu şekilde sürdürürüz. Kullanıcı TV araması yaptığında Televizyon olarak yine bu tablo yardımıyla değiştiririz (eşanlamlı sözcük).

Bunun yanı sıra yine Magento üzerinde bir örneğini görebileceğiniz bazı performans ve optimizasyonlar görebiliriz. Buna en iyi örnek Magento catalogsearch_fulltext tablosudur. Bu tabloda ürün özelliklerinden aranmasını istediğiniz özellik değerleri yatay halde tek satırda tutulur. Çünkü özellikle biraz gelişmiş sistemler bile yönetim panelinde esneklik sağlamak için verilerin önemli bir kısmı düşey olarak tutulur. Hâl böyle olunca bunları tek bir tabloya alıp otomatik tamamlama (auto complete) sorgularını hızlandırmamız gerekir. Bu tablonun bir nedeni de (en azından MySQL ‘de) InnoDB arama motoru kullanan tabloda fulltext search index kullanamıyor olmanızdır.

Ayrıca arama kelimelerini dil işleyen bir sınıf/sistem üzerinden geçirip çekim ve yapım eklerini atarak aramaya devam etmek istiyor da olabiliriz.

Neden Arama Sunucusu (filtreleme/faceted search-navigation**)

İnternet üzerinde portallarda ve e-ticaret sitelerinde sıklıkla karşılaştığımız bir özellik olan filtreleme artık vazgeçilmez hale geldi. Ve IT olarak bu isteğe çözüm üretmek gibi bir yükümlülüğümüz var. Bu cümleden sonra iç içe yazılmış AND / OR sorguları gözümüzün önünde hemen canlandı sanki. Hele bir de çoklu seçim özelliği ile ürün sayıları eklenince kafalarımız biraz daha karışmaya başlıyor.

Kullanıcı A markalı ürünleri görmek istediğinde ekranda sadece A markalı ürünleri gösteriyorken bir başka marka da seçebilmesi için (seçimi/filtreyi genişletme, çoklu seçim) diğer markaları da göstermemiz gerekir. Bunun üzerine bir başka özelllik ile de (renk, fiyat vd) filtre yapmak istediğinde -bir çok projede- ürün listesindeki ürünleri ayrı, filtreleri ayrı sorgularla çekmek zorunda kalırız.

Bir başka en iyi örnek ise; kullanıcı Android Telefon araması yapıp ucuzdan pahalıya doğru sıraladığında önce direkt eşleşenleri kendi içlerinde sıralamak sonrasında tek tek eşleşenleri kendi içlerinde sıralamak gerekir. Bu arama da Telefon kelimesiyle eşleşen ama ucuz olan bir telefonun Android Telefon ile direkt eşleşen telefonlardan önce çıkmaması gerekir. ORDER BY FUNC(x) DESC, ORDER BY FUNC(x) DESC .. sorgusundan bahsediyoruz aslında. Bu, arama sunucularının sıralamadaki en basit özelliğidir, bunun için bile MySQL sunucumuzu filesort ‘a zorlamış oluyoruz (yanılmıyorsam).

Hangi Arama Sunucusu

Piyasada yaygın olarak kullanılan Apache Solr ve ElasticSearch var. İkisi de lucene tabanlı olup bazı özellik farkları bulunmakta. Biz Apache Solr ile devam edeceğiz. Özellik karşılaştırması için güzel bir site de mevcut. Solr vs ElasticSearch adresinden ulaşabilirsiniz.

Adresini şu an hatırlamadığım bir başka sitede okuma işlemlerinde Solr, yazma işlemlerinde ise ElasticSearch ‘ün hızlı olduğunu okumuştum. Karar vermeden önce kendi testlerinizi yapmanızı öneririm.

Kaynak ve Ekstra Bilgi

Search Engine Indexing
Faceted Search
Inverted Index
N-gram
Apache Lucene
Apache Solr
Elasticsearch
—————————————————————–
* Arama moturu olarak da adlandırılmasıyla birlikte hem Google, Yahoo, Bing gibi sitelerle karıştırılmaması hem de arama algoritması, indexleme yazılımı gibi isimleri olması nedeniyle “Arama Sunucusu” olarak anıyoruz
** Türkçe karşılığını bulamadığım için kusura bakmayın, ayrıca Magento bunu layered navigation adıyla anıyor