Aşağıda pek çok raporda Big Data ve Veri arama (Search) için önerilen ve milyonlarca dolar ciro yapan firmaların search hızları ile ilgili bir fikir oluşturması açısından alınan örnekleri görebilirsiniz. Herhangi biri daha hızlıdır diye bir görüş ortaya atmak bu çalışmanın konusu değildir.

1. Log Arama (Log Search)
Aşağıda pek çok raporda Big Data ve Veri arama (Search) için önerilen ve milyonlarca dolar ciro
yapan firmaların search hızları ile ilgili bir fikir oluşturması açısından alınan örnekleri görebilirsiniz.
Herhangi biri daha hızlıdır diye bir görüş ortaya atmak bu çalışmanın konusu değildir.
Ticari Ürünlerden Örnek Arama Senaryoları ve süreleri
Aşağıdaki örnekler sadece bir fikir oluşturması açısından verilmiştir. Fikir oluşturması açısından
Bir fortinate firewalldan gelen SYSLOG paketleri dosyaya yazılırsa ortalama :
1 000 000 (bir milyon) satır 1 GBlık bir text (ASCII) dosya oluşturmaktadır.
Örnek Arama Hızları:
http://splunk-base.splunk.com/answers/5987/is-there-any-way-to-speed-up-searches
http://splunk-base.splunk.com/answers/50503/reducing-time-taken-for-search-in-splunk-query

2. http://splunk-base.splunk.com/answers/36166/from-forwarder-to-index-to-search-is-taking-too-
long-roughly-10-to-15-minutes
http://splunk-base.splunk.com/answers/54306/reasonable-search-performance

3. http://splunk-base.splunk.com/answers/12559/searches-taking-long
http://splunk-base.splunk.com/answers/13354/slow-search-for-squid-for-a-30-days-report

4. http://www.slideshare.net/aungthurhahein/data-mining-column-stores
http://www.percona.com/docs/wiki/benchmark:ssb:start

5. http://www.mysqlperformanceblog.com/wp-content/uploads/2010/08/Infobright_Phase_1_-
_Report.pdf
900 GB Data

6. http://www.mysqlperformanceblog.com/2010/01/07/star-schema-bechmark-infobright-infinidb-
and-luciddb/
620 GB Data
Log Arama Alternatifleri

7. Pek çok arama alternatifi olan ürün bulunabilir. Bu alternatifler
Logların tamamı anlık arama için aktif veritabanında tutulan ürünler:
o Burada eğer replikasyon ya da sık aralıklarla yedek alınmazsa verinin kaybı ihtimaline
kaşı önlen alınmamış olur
o Ayrıca arama dosyası büyüyeceği için arama hızları artabilir
Loglarınpartionlar halinde canlı veritabanında tutulması:
o Burada eğer replikasyon ya da sık aralıklarla yedek alınmazsa verinin kaybı ihtimaline
kaşı önlen alınmamış olur
o Partition yapısı hızlandırma sağlayabilir
Arşivden logları canlı veritabanına aktardıktan sonra arama
o Canlı veritabanına yükleme süresi overhead olarak eklenecektir.
Yukarıdaki sistemlerin bir yada birkaçını aynı anda destekleyen sitemler.
Proje ihtiyaçlarına göre yukarıdaki alternatiflerin değerlendirilmesi gerekir.
Örnek Bir Arama Kriteri:
EPS : 5000
Dakikada oluşan log: 5000 X60 =300 000 (Üçyüzbin)
Saatte oluşan log=300 000 X60=18 000 000 (Onsekiz milyon)
10 Saatte Oluşan log = 18 000 000 X10= 180 000 000
(Yüzseksen milyon)
Yukarıdaki değerlere bakarak 5000 EPS log akışına sahip bir
sistemde 10 saate 180 milyon log oluştuğu ve dolayısı ile
herhangi bir 10 saatlik aramanın 180 milyon kayıt arasından
olacağı unutulmamalı.
Dolayısı ile son 1 ayda en çok “socialmedia “ da gezen
kullanıcıların listesi ve sıralaması istendiğinde
Eğer 5000 EPS lik bir ağda bu sorgu yapılacaksa

8. 18 000 000 x 24 x 30=12 960 000 000 (yaklaşık 13 milyar)
kayıt içerisinde arama , sayma ve sıralama yapılmak zorunda
olduğu unutulmamalı