JPriest: o grafiğin ortasında neden bişey yok? Eğer bişey yoksa orası beyaz olmalıydı dimi CAP teoremine gre bunu ortası yok, dağıtık sistemlerde hep bir tradeoff olmak zorunda yani o üçünden birini feda etmek zorundasın. . . .. . ... .

hocam büyük veri 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 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 ynetim 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 gre 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 , ayrıca sorgu için logic query plan, physical query plan 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 , 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 gzle bakarsın. Çok fazla detaya da girmene gerek yok aslında, bunlar db yneticisinin işleri ama tr de maalesef herkese her iş yaptırılabiliyor :) kolay gelsin Ülkesini Seven Her Türk Vatandasi, Ülkesinin Sessiz Istilasi'na karsi durmak zorunda.

DB yapına gre 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 gre ücretlendiriyor. Mühendis kahveyi projeye dnüştüren bir insan evladıdır.

PostgreSql i tavsiye edebilirim.. Sıralamada MySql in üstünde yeralır... Neye gre dediniz bunu? Hello, i am nothing. I come from Neverland.

DB yapına gre 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 gre ücretlendiriyor. Aslında cloud kullanmak istiyorum ama normal hostinge gre 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:)

Depo/otomasyon sistemi, Aynı anda 100lerce şirketin kullanıp ürünlerini kontrol edebileceğini düşünebiliriz, MySQL biraz snük kalır gibi geldi, gün içinde ürünün gelişi çıkışı faturası vs. bir çok işlem olucak, Belirli bi zaman sonunda kullanıcı sayısı artınca sistemi en başından tekrardan tasarlamak istemiyorum, o yüzden en ktü senaryoya gre bişeyler yapmak istiyorum, Yani max. 2k kullanıcı sorgu yapıcak, 10-15gb'lık bi db'nin içinde aynı anda 100 kullanıcı sorgu yapar diye düşünüyorum gayette mysql bu stresin altından kalkar burdaki kilit nokta mysqlin güzel optimasyonudur ve iyi bir hardware kullanmaktır. @Buremba ya katılıyorum dediklerinde belirli yerlerde nosql kullanabilirsin ama buda sistem memoryisine yük bindircektir. Tabi herşey veritabanı yapısınada bakmıyor adam akıllı optimasyon şekilde programın yazılması ve iyi sqllerin yazılması gerekmektedir. Gereksiz sorgulardan kaçınarak mysql ile harikalar yaratabilirsin.

"snük kalır gibi geldi" dedigin mysql'i su an facebook, youtube, wikipedia, linkedin, twitter gibi devler, database serverlarında kullanıyor hocam :) arkasında oracle'ın oldugu bir veri tabanı ynetim sistemi icin "yeterli olur mu acaba" diye kaygıya düsmeyin. hardware & tuning ikilisinin yapılandırmalarını da gz nünde bulundurarak her türlü transaction yükünün altından kalkabilirsiniz. Andrei tarafından 09/Oca/16 19:28 tarihinde düzenlenmiştir %40 indirimli olarak "Centos Sistem ve Sunucu Ynetimi" adlı kitabımızı satın alarak, Linux üzerine yapılacak olan devam projeleri icin destekte bulunabilirsiniz : http://www.hepsiburada.com/centos-sistem-ve-sunucu-yonetimi-oku-izle-dinle-ogren-p-KKODLAB01579

JPriest: o grafiğin ortasında neden bişey yok? Eğer bişey yoksa orası beyaz olmalıydı dimi Nush ile uslanmayanı etmeli tekdir, Tekdir ile uslanmayanın hakkı ktektir!

JPriest: o grafiğin ortasında neden bişey yok? Eğer bişey yoksa orası beyaz olmalıydı dimi Ortası için hadoop+cassandra veya yeni MsSQL'le gelen hadoop+MsSQL'i yapabilirsin Mühendis kahveyi projeye dnüştüren bir insan evladıdır.

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 grüntülemeleri incelemek istiyorsun kullanıcıların cinsiyetlerine gre 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 gmü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 gre 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 yntemin 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 yntemi bir de sorgulama yntemi 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 yntemi 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 gre tasarlanmıştır ama dağıtık sistemde nce distributed query plan oluşturursun ona gre hangi bilgisayarın hangi veriyi işleyip cevabı nereye gndereceğin belli edersin sonra ayrıca her sunucu kendine gre query plan oluşturup veriyi ona gre 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. . .. . ... .

PostgreSql i tavsiye edebilirim.. Sıralamada MySql in üstünde yeralır... Ondan çocuk olmamıştır . Kendisi de doğmamıştır . İhlas Suresi 3 üncü ayette bunlar yazar.

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.

hocam daha fazla bilgi vermelisin ki cevap verilebilsin sana gre 1m kayıt büyüktür bana gre küçük bir veridir o yüzden daha fazla bilgi lütfen.

ncelikle CAP Theorem'e bakıp, senin projen için hangi ikisinin uygun olacığına karar vermelisin. Sonra da bu ya da buna benzer güncel bir şema bulup, uygun kesişim kümesine düşen seçeneklere bakıp, en uygun sistemle yola devam edebilirsin. Sen hiç kaval çaldın mı?

@Buremba hocam aslında veri girişi de olucak, ama ne kadar boyutta olucağını kestiremiyorum, ama sanırım yine de MySQL ideal olucak gibi @Ccaglayan Tek tablo içinde 100 şirketin bütün ürünlerini saklıcak ve eş zamanlı sorgular olucak sürekli, yüksek ihtimalle bu sorguların hepsi 9.00-18.00 arasında olucak, nası optimize edebilceğim konusunda bi fikrim yok, cache'de tut falan diyolar, ama hiç bi fikrim yok nasıl yapıldığına dair:) @Andrei Cehalet hocam:) ama FB, Twitter gibi devler NoSQL kullanıyo diye biliyodum @SerYolcu Postgre'yi hiç düşünmemiştim, bi gz atayım Hepinize değerli yorumları için teşekkür ederim KuZeTaR tarafından 10/Oca/16 04:32 tarihinde düzenlenmiştir

SerYolcu bunu yazdı PostgreSql i tavsiye edebilirim.. Sıralamada MySql in üstünde yeralır... Neye gre dediniz bunu? Bana gre Veri Tabanı sunucu sistemleri sıralaması... 1 - Oracle 2 - Microsoft Sql Server 3 - PostgreSql Konunun uzmanlarından elde edilmiş bilgiler diyelim... Ondan çocuk olmamıştır . Kendisi de doğmamıştır . İhlas Suresi 3 üncü ayette bunlar yazar.

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:)

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. Hello, i am nothing. I come from Neverland.

ne kadar büyük veri? . . .. . ... .

Depo/otomasyon sistemi, Aynı anda 100lerce şirketin kullanıp ürünlerini kontrol edebileceğini düşünebiliriz, MySQL biraz snük kalır gibi geldi, gün içinde ürünün gelişi çıkışı faturası vs. bir çok işlem olucak, Belirli bi zaman sonunda kullanıcı sayısı artınca sistemi en başından tekrardan tasarlamak istemiyorum, o yüzden en ktü senaryoya gre bişeyler yapmak istiyorum, Yani max. 2k kullanıcı sorgu yapıcak, 10-15gb'lık bi db'nin içinde aynı anda 100 kullanıcı sorgu yapar diye düşünüyorum

hocam büyük veri 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 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 ynetim 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 gre 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 , ayrıca sorgu için logic query plan, physical query plan 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 , 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 gzle bakarsın. Çok fazla detaya da girmene gerek yok aslında, bunlar db yneticisinin işleri ama tr de maalesef herkese her iş yaptırılabiliyor :) kolay gelsin Sylediğ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:)

Ayda yılda bir açıp bakacağın cinsten bi logsa düz txtye depolamanı tavsiye ederim. en az boyut, en düşük kaynak tüketimi sağlar. Dosya adlarını 1GB ı geçmeyecek şekilde güne yada haftaya gre blersen rahat edersin Nush ile uslanmayanı etmeli tekdir, Tekdir ile uslanmayanın hakkı ktektir!

Depo/otomasyon sistemi, Aynı anda 100lerce şirketin kullanıp ürünlerini kontrol edebileceğini düşünebiliriz, MySQL biraz snük kalır gibi geldi, gün içinde ürünün gelişi çıkışı faturası vs. bir çok işlem olucak, Belirli bi zaman sonunda kullanıcı sayısı artınca sistemi en başından tekrardan tasarlamak istemiyorum, o yüzden en ktü senaryoya gre bişeyler yapmak istiyorum, Yani max. 2k kullanıcı sorgu yapıcak, 10-15gb'lık bi db'nin içinde aynı anda 100 kullanıcı sorgu yapar diye düşünüyorum ben mysql'den şaşma derim. eğer verinin başka yerde yedeği varsa mongodb'ye falan atabilirsin alternatif olarak, yoksa çok hızlı olsun sistem memory'de var diyorsan sunucuda elasticsearch'a bakabilirsin. veriyi nasıl sorgulamak istiyorsun bilmiyorum ama basit tek koşullu select sorgularıyla cassandra'ya bakabilirsin. ama bunların hepsini ğrenmen zaman alacak o yüzden hem güvenilir hem de hızlı olan mysql'den gitmen daha mantıklı olur. gerektiğinde daha büyük makina alırsınız, olmadı sharding yapabilirsin. veri zaten büyük değil, anladığım kadarıyla senin için nemli olan veriyi yazmaktan ziyade okumak dolayısıyla büyük veri için tasarlanan veritabanları senin pek işini grmez. . . .. . ... .

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. Ccaglayan tarafından 09/Oca/16 17:30 tarihinde düzenlenmiştir

Selamlar, geliştirmekte olduğum bi uygulamada büyük veriyi nası saklıcağım konusunda tereddütlerim var, En basitinden kullanıcının uygulamada girip çıktığı her sayfayı loglamak istiyorum, Bu ve bunun gibi şeyler için hangi database'i nerirsiniz? Ve azure, amazon gibi cloud platformlarını mı yoksa doğrudan hosting firmalarını mı tercih etmeliyim? Teşekkürler şimdiden

Ya su optimizasyon ile ilgili ufak ornekler verebilir misiniz. Cok iyi olur diye dusunuyorum. Matematikçi ve Yazılımcı. http://www.ontedi.com ve http://www.cizgi.site Siteme beklerim herkesi.