çok fazla data ve j2ee

[senko]

arkadaşlar şöyle bir durumu nasıl handle edebilirim;

şimdi düşünün her gün için bir csv dosyası var ve bu csv dosyasının içinde ortalama 200.000 adet satır var, db'den csv'ye günlük olarak aktarılan veriler bunlar. kolon adeti de 10 civarlarında, 10-15 arası.

şimdi ben max 2ay'lık, csv'leri alıp arama ve analiz işlemleri yapmak istesem ki bu da 2x30x200.000'den bayağı bir data yapıyor.

hepiniz db kullan diyeceksiniz ama öyle bir imkanın olmadığını, cluster'ların neredeyse full kapasitede çalıştığını düşünün, yani ama bir taraftan da min. zahmeti yapmak cpu'ya.

daha önce hiç bu kadar veri ile uğraşmadığım için ne yapabilirm bilmiyorum, kullanılacak teknoloji muhtemelen arkada enterprise ve managed beanler ön tarafta jsf olur.

[Mirage]

Yapilacak analiz belliyse CSV'leri ek olarak yapilacak analize uygun bir formata cevirip kaydedebilirsin.

Onun disinda 12 milyon satir cok da ciddi bir miktar degil.

[di]

Ben olsam datalari dizip her biri icin index dosyalari olusturup, sonra arama tarama islerini o index dosyalarini kullanarak yapardim.

[riglous]

dosyaların hepsini bir seferde okumak yerine tek tek oku ve satır satır oku.

[senko]

bende dosyaları tek tek okuma taraftarıyım da yine de nasıl tutacağıma karar veremedim.
analiz için en iyi yöntem aslında, kolonların attribute olduğu bi class yaratıp, her row okunuşunda o class'tan insatance yaratıp bi listeye atmak.

ama tek dosyada 20.000e yakın row var, haliyle her dosya okumak bana 20.000 instance yaratılması demek.
hadi her dosya okuma bittiğinde list hedesini temizlerim de acaba java'nın arraylist'leri 20.000 instance'ı handle edebilecek mi?

di index oluştur demişsin de dosyalar ve içindeki bilgiler tarihe göre sıralılar.

[di]

Sorgulayamadigin dosya istedigi kadar dizili olsun bir isine yaramaz. Kaldi ki daha buyuk dosyayi taramak daha fazla kaynak demektir her zaman icin.

Nokta atisi yapabilecegin bir konuma ulasirsan, mesela aradigin verinin hangi dosyada oldugunu ve hangi hangi byte'da basladigi bilsen file seek ile halledebilirsin cok rahat.

Dosya sistemi uzerinde veritabani gibi sorgulama da yapabilirsin bu arada. Performansi nasil olur bilmiyorum ama incelemek istersen bkz: sqlite.

[riglous]

senko said:

bende dosyaları tek tek okuma taraftarıyım da yine de nasıl tutacağıma karar veremedim.
analiz için en iyi yöntem aslında, kolonların attribute olduğu bi class yaratıp, her row okunuşunda o class'tan insatance yaratıp bi listeye atmak.

ama tek dosyada 20.000e yakın row var, haliyle her dosya okumak bana 20.000 instance yaratılması demek.
hadi her dosya okuma bittiğinde list hedesini temizlerim de acaba java'nın arraylist'leri 20.000 instance'ı handle edebilecek mi?

di index oluştur demişsin de dosyalar ve içindeki bilgiler tarihe göre sıralılar.

Liste oluşturamazsın. Bu zaten dosyayı okumakla eşdeğer.
Analiz için istediğin şeyi tek seferde yaparak ilerle.
Mesela ortalama alacaksan bir değişkende toplamları, diğer değişkende dosya adedini tut; tüm okumalar bittiğinde senin 2 değişkenin olur ve ortalamayı hesaplayabilirsin.

Ne yapmak istediğini daha açık anlatırsan belki daha fazla yardımcı olabiliriz. Öteyandan amacın CDR işlemek falansa, infobright üzerinde çalış; hiç öyle java'yla falan uğraşma. DB'lerin ortaya çıkmasının da bir sebebi var ;)

[sharky]

6-7, max 10 milyon rowluk bir tablo olacak. DB Clusterlar overloadedsa kendine bir DB sunucusu kur. DB olmadan gereksiz efor sarfedeceksin.

MySQL falan kur hatta. 10m row nedir allaskina. Hic bisi.

[aquila]

bu devirde 10 m row...