FireBird Ne Kadar Yeterli

[name]

Merhaba

Hakan Bey tavsiyeleriniz için teşekkürler. Benimde aklımda verileri sizin tavsiye ettiğiniz şekilde ve farklı şekillerde gruplandırma düşünceleri var. Bunları karma bir şekilde uygulayıp testler yapıcam. Ama öncelikle SQLite ile bazı denemeler yapıyorum.

Recep Bey database yapısını tasarlarken en uygun yapıyı oluşturduğumu düşünüyorum. Bu engeli farklı yöntemler ile yada farklı bir database sistemi ile çözmeye çalışacağım.

Bu kadar veri ile başa çıkmak ne kadar zahmetli imiş .

[mussimsek]

Merhaba,

Şu adreste hiç bir fts motoru kullanmadan firebird ile yapılan bir uygulama var. İlk aramada 30-40 sn sürse de, 2. aramadan sonra aramalar ms. sürelerine düşüyormuş.

http://www.ibphoenix.com/downloads/Fire ... Z303-R.zip

Hatta elemanlar iyice abartmış, yabancı dil gibi birçok şey eklemişler. Bunları da temizlersen daha da hızlanabilir.

Ayrıca birkaç tane çok tavsiye edilen fts motoru tavsiye ediyorlar, inceleyebilirsin :

- Rubicon : http://www.fulltextsearch.com/
- IB Objects : http://www.ibobjects.com/ibofts.html
- Mutis : http://sourceforge.net/projects/mutis/ -> Bu proje .net dünyasında baya bir meşhur olan dotlucene isimli bir projenin delphi eşiymiş.

Bence hiç bir fts motorunu kullanmadan ilk projeyi kendine uyarla...

Kolay gelsin.

[name]

Merhaba

İlginiz için teşekkürler Mustafa bey. Zamanım olmadığı için yeni cevap yazabiliyorum.

SQLite ile bir türlü başarılı denemeler yapamadım. Firebird içersinde ki metinleri SQLite'a sağlıklı bir şekilde aktaramadım. Bu proje için de Firebird'den vazgeçemedim yani. :)

Karşılaştığım zorlukları, verilerin olduğu tabloları gruplayarak çözdüm. 20 milyonluk tablodan 10 kadar alt tablo oluşturdum. Arama hızı şu anda değişkenlik göstersede ortalama olarak iyi sayılır. Bazı müdahaleler daha yaparak hız konusunda bazı iyileştirmeler yapmayı düşünüyorum.

Merhaba,
Şu adreste hiç bir fts motoru kullanmadan firebird ile yapılan bir uygulama var. İlk aramada 30-40 sn sürse de, 2. aramadan sonra aramalar ms. sürelerine düşüyormuş.

http://www.ibphoenix.com/downloads/Fire ... Z303-R.zip

Hatta elemanlar iyice abartmış, yabancı dil gibi birçok şey eklemişler. Bunları da temizlersen daha da hızlanabilir.

Bu projeyi siz link'ini verdikten sonra inceleme fırsatı buldum. Kodlarda işime yarayacak şeyler bulamadım. Bunların sebepleri şunlar;

1. Metinler varchar alanda saklanıyor ve en fazla 32.000 karekter saklayabiliyorlar. Benim metinler ise 2 MB'ı bulabiliyor. Blob alanda olmaları gerekli.
2. Indexleme işini arama sırasında yapıyor. Kullanıcının girdiği her arama kelimesini önce index tablolarında arıyor index tablosunda yok ise aranan kelime metinler içersinde aranıyor. Kelime metinler içersinde bulunduğunda da önce index tablosunu yeniliyor sonra sonuçları ekrana getiriyor.
3. Matıksal arama yapmıyor.

Bu işlemleri Stored Procedure'ler kullanarak database tarafında yapmışlar.

Verdiğiniz diğer üç projeyi daha önceden incelemiştim. Bunlardan da işime yarayacak bir şeyler edinemedim.

Zaten kelime indexleme için kullanılan mantık her projede hemen hemen aynı. Sadece Rubicon'da biraz farklı yapmışlar. Bağ tablosu ile kelime tablosunu birleştirmişler. Rubicon'un bu yapısında 20 milyon ve daha fazla kayıt olduğunu düşünemiyorum. Her nekadar rubicon'un bu yapısını anlayamasam da 14gb'lık veriyi index'lediklerini ve çok hızlı bir şekilde kullandıklarını biliyorum (http://www.tamaracka.com/). 14gb'lık veritabanını hangi konfigürasyonda ki makinada barındıklarını da merak etmiyo değilim.

[Kuri_YJ]

Selamlar,

Aramalarınız bu kadar zaman kritik ise ve yukarıdaki tavsiyeler de bir fayda etmiyorsa, iş donanıma kaldı demektir.

Donanımınızı güçlendirin. Manuel de olsa FTS'yi oluşturtun. Ondan sonra denemelerinizi yapın. FB'nin firebird.conf dosyasınında cached page sayısını bellek sınırına getirin ve DB run olduktan sonra işlemleri bellekte yapacağından yeterince bir hız elde edersiniz diye düşünüyorum.

Zira kayıt sayısı ve veri büyüklüklerini düşünürseniz cached page sayısını buna göre yüksek tutmalısınız diye düşünüyorum.

Ayrıca serverınızın disk hızları ve serverınızdaki Memory miktarını da abartabildiğinizce abartın ki beklemeler minimuma insin.

Aksi halda hangi veritabanını kullanırsanız kullanın, 20 Milyon kayıt ve her kayıt ortalama 2 MB boyunda olduğu sürece kaçarınız yok.

Bu verileri Pentium 3.2 Ghz. 512 MB bir makinada sorgulamak var,

bir de 4 CPU'lu, 32 GB RAM'li, 15K RPM SCSI Disklerden oluşan bir SAN üzerinde sorgulamak farklı

Kolay Gelsin