Forum
Aktif konular
Üyeler
Kurallar
Arama
Büyük Veriyi Saklama Büyük Veriyi Saklama
-
DB yapına göre değişir senin büyük veri dediğin şey aslında gayet küçük :)
MySQL veya Postgresql kullanabilirsin eğer yok uğraşmam dersen AWS ve Azure'un direk DBaaS hizmetleri var sorgulama sayına göre ücretlendiriyor.
-
sandman bunu yazdı
DB yapına göre değişir senin büyük veri dediğin şey aslında gayet küçük :)
MySQL veya Postgresql kullanabilirsin eğer yok uğraşmam dersen AWS ve Azure'un direk DBaaS hizmetleri var sorgulama sayına göre ücretlendiriyor.
Aslında cloud kullanmak istiyorum ama normal hostinge göre 2 3 kat daha pahalı, DBaaS hiç kullanmadım, azure'un 610 liralık deneme sürümünü aldım, bi bakıcam, teşekkürler:)
-
Tüm veriler için tek bir sql tipi düşünme. birbirinden bağımsız veriler varsa her biri için ihtiyacı karşılayacak sql tipi düşün.
Mesela ziyaret edilen web sayfalarını log lama ile ürün sipariş giriş-çıkışı için gereken sql farklı olsun.
Bu kadar yoğun çalışmada klasik mekanik harddisler yerine ssd kullanman performans da çok fark eder. Mesela saat başı yedek alarak mekanik harddislerde yedeğin olsun ama aktif çalışma ssd de olsun.
-
SerYolcu bunu yazdı
PostgreSql i tavsiye edebilirim.. Sıralamada MySql in üstünde yeralır...
Neye göre dediniz bunu ?
-
hocam büyük veri (big data) denilen şey senin sorduğun şey değildir :) sağlayacağın veri çok küçük aslında o yüzden öyle kompleks çözümler aramana gerek yok..
mesela kullanıcıların her girip çıktığı sayfayı loglayacaksan iki tane int türünden field yeterli (kullanıcı_id, sayfa_id)
hatta işi daha basitleştirmek için o sayfaya kaç kere girip çıktığını da aynı yerde tutabilirsin kullanici_id,sayfa_id, erisim_sayisi)
milyonlarca üyen yoksa bu tarz bir yapı ile kolaylıkla yönetim yapabilirsin.
hız açısından v.s. de sorun olmaz.
öncelikle indexleme nin nasıl yapıldığını ve doğru dürüst indexlemenin nasıl yapıldığını öğrenmen lazım.Veritabanını oluştururken düzgün indexleyebilirsen her şey daha performanslı olur.
Sorgulardaki costları da ona göre hesap edersen tertemiz bir sistem ortaya çıkar.
Bu işler biraz ileri seviye veritabanı işlemlerine giriyor, ancak öğrenmek istersen bu yolda ilerlemeni tavsiye ederim.
bakman gereken kavramlar:
clustured/unclustured indexing
primary/secondy index
hash-based index, tree-based index (b+ trees,r tree),
ayrıca sorgu için logic query plan, physical query plan (bunlarla birlikte cost ve cost parametreleri)
big data olayına gelirsek, bildiğim kadarıyla google big table dışardaki kullanıcılara açık bir sistem değil, o yüzden cassandra, google big table dan esinlenerek tasarlanmıştır. Ancak bu iş öyle çok veri saklayayım mantığından ziyade, no single point of failure olayı vardır. Sanırım sen de bunu kastetmek istememişsindir ama bazı arkadaşlar bunla ilgili bir şeyler yazınca açıklama ihtiyacı hissettim.
velhasıl kelam, herhangi bir db kullanabilirsin (mysql olabilir), bunun yanında tablo yapılarını düzgün oluştur, üstte yazdığım araştırman gereken şeylerden bir şeyler öğrenebilirsen ufkunu genişletir ve db ye daha farklı bir gözle bakarsın. Çok fazla detaya da girmene gerek yok aslında, bunlar db yöneticisinin işleri ama tr de maalesef herkese her iş yaptırılabiliyor :)
kolay gelsin
-
unbalanced bunu yazdı
hocam büyük veri (big data) denilen şey senin sorduğun şey değildir :) sağlayacağın veri çok küçük aslında o yüzden öyle kompleks çözümler aramana gerek yok..
mesela kullanıcıların her girip çıktığı sayfayı loglayacaksan iki tane int türünden field yeterli (kullanıcı_id, sayfa_id)
hatta işi daha basitleştirmek için o sayfaya kaç kere girip çıktığını da aynı yerde tutabilirsin kullanici_id,sayfa_id, erisim_sayisi)
milyonlarca üyen yoksa bu tarz bir yapı ile kolaylıkla yönetim yapabilirsin.
hız açısından v.s. de sorun olmaz.
öncelikle indexleme nin nasıl yapıldığını ve doğru dürüst indexlemenin nasıl yapıldığını öğrenmen lazım.Veritabanını oluştururken düzgün indexleyebilirsen her şey daha performanslı olur.
Sorgulardaki costları da ona göre hesap edersen tertemiz bir sistem ortaya çıkar.
Bu işler biraz ileri seviye veritabanı işlemlerine giriyor, ancak öğrenmek istersen bu yolda ilerlemeni tavsiye ederim.
bakman gereken kavramlar:
clustured/unclustured indexing
primary/secondy index
hash-based index, tree-based index (b+ trees,r tree),
ayrıca sorgu için logic query plan, physical query plan (bunlarla birlikte cost ve cost parametreleri)
big data olayına gelirsek, bildiğim kadarıyla google big table dışardaki kullanıcılara açık bir sistem değil, o yüzden cassandra, google big table dan esinlenerek tasarlanmıştır. Ancak bu iş öyle çok veri saklayayım mantığından ziyade, no single point of failure olayı vardır. Sanırım sen de bunu kastetmek istememişsindir ama bazı arkadaşlar bunla ilgili bir şeyler yazınca açıklama ihtiyacı hissettim.
velhasıl kelam, herhangi bir db kullanabilirsin (mysql olabilir), bunun yanında tablo yapılarını düzgün oluştur, üstte yazdığım araştırman gereken şeylerden bir şeyler öğrenebilirsen ufkunu genişletir ve db ye daha farklı bir gözle bakarsın. Çok fazla detaya da girmene gerek yok aslında, bunlar db yöneticisinin işleri ama tr de maalesef herkese her iş yaptırılabiliyor :)
kolay gelsin
Söylediğin terimlerin hiç birisini bilmiyorum :D bi proje yapıcaz diye altından üstünden her yerine giricez sanırım :D çok teşekkür ederim, teker teker bakmaya başlayayım, çok teşekkür ederim:)
-
Olgunisik bunu yazdı
Tüm veriler için tek bir sql tipi düşünme. birbirinden bağımsız veriler varsa her biri için ihtiyacı karşılayacak sql tipi düşün.
Mesela ziyaret edilen web sayfalarını log lama ile ürün sipariş giriş-çıkışı için gereken sql farklı olsun.
Bu kadar yoğun çalışmada klasik mekanik harddisler yerine ssd kullanman performans da çok fark eder. Mesela saat başı yedek alarak mekanik harddislerde yedeğin olsun ama aktif çalışma ssd de olsun.
Evet çok mantıklı, yedekleme işini falan hiç düşünmemiştim, ama dediğin şekilde yapmak çok mantıklı, bi bilene sormakta her zaman fayda varmış, teşekkürler:)
-
ozgunlu bunu yazdıSerYolcu bunu yazdı
PostgreSql i tavsiye edebilirim.. Sıralamada MySql in üstünde yeralır...
Neye göre dediniz bunu ?
Bana göre Veri Tabanı sunucu sistemleri sıralaması...
1 - Oracle (Ücretli)
2 - Microsoft Sql Server (Ücretli)
3 - PostgreSql (Ücretsiz)
Konunun uzmanlarından elde edilmiş bilgiler diyelim...
-
aynen öyle big data'da verinin saklanma şeklinden tut işlenme şekline kadar herşey farklı. saklanma şekli genel olarak join işlemi pahalı olmasından dolayı çok sütunlu büyük tablolar kullanılıyor. yani atıyorum ürünlerin var ve ziyaretçilerin var sayfa görüntülemeleri incelemek istiyorsun kullanıcıların cinsiyetlerine göre ama 100m üzerinde eşsiz ziyaretçin var, normal şartlar altında join yaparsan sorgulama motoru 100m id içeren bi hash table oluşturup her ziyaret aksiyonu için buna map etmeye çalışır ki çok fazla memory gerektiriyor bu işlem. dolasıyla cinsiyet bilgisini de ziyaret aksiyonunun içine gömüyorsun ve join yapmaktan kurtuluyorsun lakin 20 30 sütunlu tabloların olmuş oluyor.
şimdi sql bilgisiyle hareket edersen çok mantıksız geliyor çünkü içinde bir sürü null olacak çok fazla veri dolacak sisteme ama saklama şekli de ona göre değişiyor. normal rdbms'lerde row-oriented yapı var yani her satır ardarda serialize ediliyor, bir sütuna ulaşmak için bütün satırı deserialize etmen lazım ki 30 sütunlu tabloda sıkıntı olacaktır bu. big data için de columnar-oriented yapı var, bunda sütunlar ardarda serialize ediliyor, run-length encoding tarzı algoritmalar uygulanıyor raw veri üzerinde ve sıkıştırılıp saklanıyor bir sütunun verisi.
sen 30 sütunluk tabloda 2 sütun çekip birin group by yapınca veritabanı gidip diskten 2 farklı lokasyondan veriyi memory'ye map edip decompress işleminden geçiriyor ve group by'ını güzel güzel yapıyor. ama bu yöntemin dezavantajı da "select * from bilmemne" tarzı sorgular sıkıntı, delete update gibi işlemler de aynı şekilde çok pahalı, insert işleminde de teker teker yapmak yerine 10k satır birden yapmak gerekiyor yoksa öbür türlü de pahalı oluyor.
bu işin veriyi saklama yöntemi bir de sorgulama yöntemi var. rdbms'ler genelde dikey ölçeklenir yani sistemin performansını geliştirmek için gidip daha büyük makina alırsın ama daha iyi makinanın da bir sınırı var tabi. big data'da da yatay ölçekleme yöntemi var yani gidip yeni makina koyarsın sisteme veriyi de aralarında paylaştırırsın. postgresql mssql gibi veritabanlarının sorgulama motorları veriye ulaşmak için diskten bloklar okur ve ona göre tasarlanmıştır ama dağıtık sistemde önce distributed query plan oluşturursun ona göre hangi bilgisayarın hangi veriyi işleyip cevabı nereye göndereceğin belli edersin sonra ayrıca her sunucu kendine göre query plan oluşturup veriyi ona göre işler.
gene rdbms'lerdeki gibi single point of failure olayından kaçınmak için veriyi birden fazla bilgisayarda tutarsın. partitioning, sharding vs gibi teknikler kullanırsın belli verilere daha hızlı ulaşabilmek için onda pek değişiklik yok. big data'da hadoop'u duymuşsundur, spark gibi in-memory sistemler geliştirildi son zamanlarda ama bunlar veriyi işlemek için kullanılan motorlar. veritabanı olarak impala, prestodb, cassandra falan var ben prestodb ile uğraşıyorum bu sıralar.
bu konularla ilgili olan/kendini geliştirmek isteyen varsa ben de bu alanla uğraşıyorum açık kaynak bi proje geliştiriyorum ve bu aralar şirketleşme çalışmaları vs. falan var. açık kaynak projeye burdan bakabilirsiniz: https://github.com/buremba/rakam
-
Ccaglayan bunu yazdı
öncelikle nerde değil hangi platfromda diye sorman daha doğru olur. Logları NoSQL bir yapıda tutabilirsin verileri hızlı işlemek için. Geri kalanlar için MySQL kullanabilirsin şuan 4-5gb lık verilerde ve güzel bir ayarla sorun çıkarmadan kullanabilmekteyiz tabi amazonda ayrı bir instance açarak sadece mysql olarak ayarladığımız makinada. Burda çoğu şirketin satış ve giren çıkan bilgisi tutulmakta.
artı olarak arama bazlı işler yapıcaksanda hadoop veya solr ı öneririm 300gb lık text veri içinden verileri getirmesi gayet hızlıdır sanki 1-2 mb lık veritabanında sorgu yaparcasına hızlı tepki vermektedir.
hadoop ya da solr' dan hangisine alışmak daha kolaydır ? Hiç nosql yapı kullanmadım.
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla