On Aug 21 05:53, Emre Sevinc wrote:
> Zemberek gelistiricilerine ilettim buradaki düsünceleri. Veritabanina
> bu tür görevlerin bindirilmesi konusunda biraz cekimser görünüyor
> gelistiricilerden Ahmet A. Akin:
>
> https://zemberek.dev.java.net/servlets/ReadMsg?list=dev&msgNo=563
>
> Ben ise tam olarak buna katilmiyorum, yani atiyorum PostgreSQL veritabanim
> varsa ve buna da 50.000 makale, belge, vs. icerigi yükledi isem
> bunlarin üzerinden detayli tam metin arama varyeteleri yapmak icin
> bir de kalkip Lucene filan kurmak zorunda kalmak istemem eger
> veritabani bana bu özelligi sunuyorsa. Ama tabii pek cok karmasik
> teknik konuda oldugu gibi burada tek bir mutlak dogru yok.
Ahmet Bey'in sanırım PostgreSQL hakkında çok yanlış bir görüş açısı var.
Şu şekilde olayı basit bir şekilde özetleyeyim:
tsearch2 (PostgreSQL için FTS motoru) geliştirilmeden önce, adamlar
stem'lerin imzalarını integer array'ler içinde tutmak istediler. Yani
metinler düz metin olarak kaydedilmiyor, ayrı bir alanda ayrı bir
biçimde tutuluyor?
Peki integer array'lerin normal array'lerden farkı ne? Son derece
FTS'ye özel durumlar için optimize edilmiş algoritmalar barındırıyor.
Peki bu algoritmalar veritabanının programcıya sağladığı arayüz ile mi
sunucuya tutturuluyor? Hayır! tsearch2'yi yazan amcalarım (Oleg
Bartunov, Teodor Sigaev) tsearch2'yi yazmadan önce intarray modülünü
yazdılar. intarray modülünü yazmadan önce de PostgreSQL veritabanına
GiST (Generalized Search Trees) index yapısını eklediler.
GiST'in ne olup ne olmadığı hakkında burada bahsetmeyeceğim, ama konu
hakkında azıcık bir bigilisi olanlar bunun ne kadar fonksiyonel, esnek
ve bir o kadar da önemli bir eklenti olduğunun farkına varmışlardır.
Yani tsearch2, 3-5 satırdan oluşan C+Perl kodundan ibaret değildir.
tsearch2 geliştirilmeden önce evvelde binlerdce satır kod
PostgreSQL'in içine gömülmüştür. (8.2 sürümü ile gelecek olan GIN,
Generalized Inverted Index, mevzuusuna hiç girmek istemiyorum.)
Yani demek istediğim şu ki, Ahmet Bey'in "Duz yazi iceren veri tabani
alanlarinin indekslenmesi ve derin analizinin veri tabaninin kendisinden
cok bir arama motoru tarafindan yapilmasini daha makul buluyorum."
sözünü gayet haksız buluyorum. Bu MySQL ya da MS SQL'de böyle olabilir,
ama PostgreSQL kesinlikle çok çok farklı.
Bir de mesajın içinde Lucene bahsi geçmiş. Lucene kullanarak verinin
aranmasına bir şey demiyorum da... verinin Lucene'in erişebileceği
şekilde konumlandırılması sorun teşkil ediyor. Ayrıca farzedin ki,
veriyi veritabanında tutuyorsunuz ve Lucene index'leri ile
veritabanındaki verinin bir şekilde senkronize olmasını sağladınız. Bu
ne derece güvenilir, dayanıklı ve yeniliklere açık bir yapı sunacak
size?
Mesajda şöyle bir tümce de geçiyor: "Java Performansinin son derece iyi
oldugunu soyleyebilirim." Rakamlar ile buna bir örnek verilebilir mi?
Örneğin ne büyüklükte bir veri (esasen sistem belleğine sığmayacak
büyüklükte bir veri) ne koşullar altında sorgulandı? Sorgu kriterleri ne
derece karmaşıktı? Platform ve sistem özellikleri neydi? (Hatta
kullanılan diskin önbellek boyutu ve DMA'sının açılı olup olmadığı bile
çok öenmli bir ayrıntı. Gerçi veri belleğe sığdığı sürece bunların
hiçbirinin en ufak bir anlamı olmaz.)
Mesaja ilk göz attığımda, veritabanının verinin sadece depolanması için
kullanılması gerektiği ve tsearch2'den ise düz metin alanları şeklinde
bahsedildiğini görünce son derece irkildim. Eğer veritabanları bu
çerçeve içinde kalsaydı, Sleepycat'in Berkeley DB'sinden başka hiçbir
şeye ihtiyacımız olmazdı. Hatta zannetmiyorum ki SQL diline herhangi bir
yerde gerek kalsın.
> Bu asamada, arz-talep meselesi gibi görünmekle beraber biraz
> da söyle bir sey var, insanlara belli bir islevselligi dogru dürüst
> gerceklestiren bir ürün sunmadiginiz ve bununla gerceklestirilecek
> calismalara örnek vermediginiz takdirde genellikle akillara pek
> bir "talep" gelmiyor. Yani bazi durumlarda durduk yerde bir seyleri
> arz etmek talebi körükleyebilir diye düsünüyorum.
Yukarıdaki düşüncelerin hepsine sonuna kadar katılıyorum.
> Türkce dogal dil isleme konusunda Ingilizce, Almanca gibi diller icin
> hazirlanmis teknolojileri ve yazilimlari 30 sene kadar geriden takip
> ettigimiz icin genellikle teknolojiyi is güc yapmak icin kullanan
> insanlarin da gözünün önünde pek bir teknolojik imkan olmuyor,
> dolayisi ile akillara düsmüyor sanki(?).
Benim asıl burada üzerinde durmak istediğim diğer bir nokta ise,
tsearch2'ye Türkçe bir stemmer kazandırdığımız taktirde şunu elde
ederiz: Tam anlamıyla Türkçe dil desteğine sahip BSD lisanslı bir
veritabanı. Bence bu bir çok şirket için maliyeti çok büyük oranda
kıstığı gibi, imkansızlıktan tercih edemedikleri bir çok yeniliğin de
kapısını açmış olur.
> Dolayisi ile, belki de bir seylerin implementasyonuna girismeden
> önce asagidaki sorulari cevaplamak lazim:
>
> - Burada somut olarak bahsedilen fikir (ve bunun acilimlari, daha
> uc örnekleri) uygulansa, bir ürün olarak hemen kurulup calistirilabilir
> olsa, bu kimin ne isine yarar? Kime nasil bir cözüm sunar? Para
> kazandirir, vs.?
Biraz felsefi bir yaklaşım olacak ama, eğer bir şirkete kafamda bu tarz
bir proje kurulumu önerisi ile gidecek olsaydım, onlara şu soruyu
yöneltirdim: Şirkete ağına giren tüm verilerin (belgeler, e-posta'lar,
makbuzlar, telefon faturaları, ihale katılımları... vs.) Google benzeri
bir yapı ile aranabiliyor olmasını istemez miydiniz?
> - Zemberek listesine yazilmis yukarida baglantisini verdigim iletide
> cok daha gelismis "string" benzerlik metriklerinin kullanimi ile ilgili
> enteresan örnekler verilmis. Türkce icin bu kimin ne isine yarardi?
Geçen gün elime şöyle bir problem geçti: Bir firmanın bilmemne hede
hödösü için tutulan yaklaşık 30,000 kayıtlık bir MS Access (gülmeyin)
veritabanında aynı isimlerin çoğu yanlış yazılmıştı: Ayhan Onar yerine,
Ayan Onar, Ayhan Onur, Ayan Onur... gibi. Sorun bu tür, aslında aynı
olup birden fazla satırda girdisi olan kayıtların belirlenmesiydi.
Sanırım tam da sizin yukarı yönettiğiniz sorun için bir use-case
oluşturuyor bu. (Ben problemi nasıl mı çözdüm? Bunu MS Access'te
kaydetme akıllığını gösterip, tüm veriyi eliyle giren arkadaşı bir de
benim için geçmiş olsun deyip alnından öpün dedim.)
İyi çalışmalar.
P.S. Listenin "Bay Offtopic"i olarak tanınmak istemiyorum. O yüzden
tartışmayı pgsql-tr-genel listesine taşıyorum.
_______________________________________________
cs-lisp mailing list
cs-lisp@cs.bilgi.edu.tr
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
