Forum
Aktif konular
Üyeler
Kurallar
Arama
Tahribat.com Forumları 
Webmaster ve Yazılım Geliştiriciler 
Büyük Dataları Yönetebilmek. (Performans) ( SQL - Server - Cache) Büyük Dataları Yönetebilmek. (Performans) ( SQL - Server - Cache)
-
Sharding işlemi olarak bilinir. Databaseler kendi içinde senkronize olur. Ancak yazarken a veritabanına yazarsın okurken b veri tabanından okursun. Bu veri tabanlarını da master/slave olarak ayarlarsın. Böylelikle okumayla meşgul olan veri tabanını bir de yazmayla meşgul etmezsin. Mssql de nasıl yapılır bir bilgim yok ama mysql postgresql ve mongodb de yardımcı olabilirim. Kullandığın dile göre ayrı bağlantılar açarsın. Açtığın bağlantıları da hemen sonlandırmaz polling kullanırsan yani elindeki bağlantıları yedekleyip lazım olduğunda tekrar kullanırsan yine tasarruf etmiş olursun. Ben bu sistemi amazon ec2 makinelerde kullanıyorum. 2 master 6 slave ile postgresql database kullanıyordum. Aynı sistemi postgresqlden mongodbye geçirdim. Anlık çok yüksek qpslerde bile gözle görülür bir yavaşlama olmadı bu güne kadar.
-
doganaydin bunu yazdı:
-----------------------------Sharding işlemi olarak bilinir. Databaseler kendi içinde senkronize olur. Ancak yazarken a veritabanına yazarsın okurken b veri tabanından okursun. Bu veri tabanlarını da master/slave olarak ayarlarsın. Böylelikle okumayla meşgul olan veri tabanını bir de yazmayla meşgul etmezsin. Mssql de nasıl yapılır bir bilgim yok ama mysql postgresql ve mongodb de yardımcı olabilirim. Kullandığın dile göre ayrı bağlantılar açarsın. Açtığın bağlantıları da hemen sonlandırmaz polling kullanırsan yani elindeki bağlantıları yedekleyip lazım olduğunda tekrar kullanırsan yine tasarruf etmiş olursun. Ben bu sistemi amazon ec2 makinelerde kullanıyorum. 2 master 6 slave ile postgresql database kullanıyordum. Aynı sistemi postgresqlden mongodbye geçirdim. Anlık çok yüksek qpslerde bile gözle görülür bir yavaşlama olmadı bu güne kadar.
-----------------------------mssql ile keşke yapmış olsaydın hocam valla söylediğin şeyler tam benlik gibi :)
Sql optimize şart. Ben biraz bütçe ayarlatayımda 2. serverda denemelere başlayım. İstanbuldaysan seni davet edeyim hocam gel mssqlde kastıralım :)
Onun dışında asp.net cache kullanıyorum sistem. 20.000 data olan tabloyu attım cache'e çok iyi çalışıyor. Ancak daha da büyüdüğü zaman direk cache server diye bişey var sanırım ona atmak gerekli?
Ayrıca plesk panelde de olan output cache'i kullanan var mı?
-
cemnet bunu yazdı:
-----------------------------mssql ile keşke yapmış olsaydın hocam valla söylediğin şeyler tam benlik gibi :)
Sql optimize şart. Ben biraz bütçe ayarlatayımda 2. serverda denemelere başlayım. İstanbuldaysan seni davet edeyim hocam gel mssqlde kastıralım :)
Onun dışında asp.net cache kullanıyorum sistem. 20.000 data olan tabloyu attım cache'e çok iyi çalışıyor. Ancak daha da büyüdüğü zaman direk cache server diye bişey var sanırım ona atmak gerekli?
Ayrıca plesk panelde de olan output cache'i kullanan var mı?
-----------------------------Onunla da çok zor bir problem değildir. Biraz uğraşırsan halledersin. Zaten dökümanlar mutlaka vardır. Anlattığın olayın dökümanını atıyım bulursam. Çeşitli cache yöntemleri var in-memory: verileri ramde tutan ve in-disc: verileri diske yazan gerektiğinde oradan okuyan. In-memory çözümleri denersen daha rahat edersin. Mesela windowsta çalışıyor mu bilmiyorum ama memcached deneyebilirsin. Senin verdiğin sayılarla en kötü ihtimalle master/slave 2 serverla çözersin olayı. Malesef İstanbul'da değilim. :)
-
Büyük verilerle çalışmak için bir kaç yöntem var bir tanesini arkadaş yukarıda söylemiş sharding ek olarak biz günlük 1 milyondan fazla kullanıcısı olan bir firmaya şöyle bir sistem kurduk.
Mysql loglama ve kullanıcı verileri için kullanıyorduk burda sharding ve m-querry vardı ama yinede veritabanını yeteri kadar hızlı büyütemiyor ve en büyük sorunumuz mysql'in yüksek sorgularda çökmesini enğelliyemiyorduk.Bunun için hibrit bir çözümde karar kıldık.
NoSQL ve Mysql'i beraber kullanmaya başladık. NoSQL olarak coachdb kullanıyor ve anlık yapılan işlemler ve applicationın tuttugu bazı geçici verileri burada tutarken loglama(NoSQL sistemlerinde transaction log yoktur) ve kullanıcı verilerini Mysql'de tuttuk sorunumuz en azından scability adına çözüldü.
-
bulut sunucuları kullanabilirsin sanırım bu alanda kayda değer gelişmeler var.
-
index olayı mükemmel bişey dakikalarca süren select sorgusunu ms mertebesine indirdim postgresqlde.12 milyon satır :D
-
- veritabanı tablonda en çok where koşulu kullandığın alanı (mesela kategori alanı olabilir bu, çünkü en çok o kullanılır gibi senin sistemde) belirle ve clustered index uygula (eğer bu tabloya hiç kayıt yapılmıyorsa (readonly) fill factor u %100 e çek) (clustered index senin datanı indexlediğin sütuna göre sıralar, bu şekilde aradığın datayı hash yaparak çok hızlı bulur)
- where koşuluna bağlı olarak non-clustered index uygula (eğer tablonda clustered index yoksa non-clustered uyguladığında sql server tempdb ye yüklenir onun için mutlaka clustered oluştur)
- eğer sql server enterprise kullanacaksan mutlaka partition özelliğini kullan. mesela ürünleri CategoryId ye göre partititon yapıp farklı data dosyalarında tutabilirsin. "select * from Products where CategoryId=5 and Price between 200 and 500" gibi bir sorguda sql server tüm db yi taramak yerine gidip CategoryId=5 olan data dosyasını tarayacak. Price üzerinden de non-cluster index in olduğunu varsayarsak sorgu ms sürer. Partition ları ayırmak için birden fazla fiziksel hdd kullan.
- Memory limitin yoksa, cacheleye bildiğin kadar cachle. AppFabric e bak.
- Sql Server Loglarını kapat, simple da tut (Recovery yapamazsın)
- NoSql çözümlere bakabilirsin (örnek: RavenDB)
-
Tecrübelerini aktaran herkese teşekkürler. Bunlar oldukca değerli bilgiler sonuçda. Şuan hepsini uygulayamıyorum ama bu konuda altında yapılacakları toplayıp adım adım gideceğim.
Sql alanında 3 aşşa 5 yukarı neler yapılması gerektiğini anladım. Gerisi ar-ge yapmaya bakar. DB yapısını elimden geldiğince sade ve temiz kurmaya çalışıyorum. Tek korkum şu ki; şimdi gözden kaçırarak yaptığım bir hata ilerde düzeltme adına büyük problemlere neden olmasın bana. (Artık olmuşsada uykusuz geceler bizi bekler :)
-------------------------------------------------
Diğer dert resimler.
Sizce resimleride ayrı bir serverda mı tutmak gerek? Örneğin sahibinden tüm resimleri subdomain altında tutmuş.
/images/ altında ürünleri düşündüğümüzde 200.000 adet resim olacak. Bunları diske yazarken KategoriID ile bir klasör açıp onun içine attım. Yani ürünün son kıvrılımdaki kategoriID değeri ne ise onun klasörünü açıp resmide içine attım. Bu ne derece doğrudur?
/images/resim5785/asd.jpg
/images/resim5785/asd2.jpg/images/resim5744/asd.jpg
/images/resim5744/asd2.jpg -
Resimler sunucu tarafında pek sorun çıkarmaz. Ancak browserlar aynı anda aynı urlden sadece 2 veri okuyabilirler. Yani x1 ve x2 resmini aynı anda çekerken x3 resmini çekemez. Veya bir css bir js render ederken bir diğer nesneyi çekemez. Bunun için subdomaine atabilirsin. Cookiesiz bir domain kullanırsan hız bakımından yararına olur. Aşırı miktarda resmin varsa amazon s3 de kullanabilirsin. Ücretlendirmesi çok uygun.
-
doganaydin bunu yazdı:
-----------------------------Resimler sunucu tarafında pek sorun çıkarmaz. Ancak browserlar aynı anda aynı urlden sadece 2 veri okuyabilirler. Yani x1 ve x2 resmini aynı anda çekerken x3 resmini çekemez. Veya bir css bir js render ederken bir diğer nesneyi çekemez. Bunun için subdomaine atabilirsin. Cookiesiz bir domain kullanırsan hız bakımından yararına olur. Aşırı miktarda resmin varsa amazon s3 de kullanabilirsin. Ücretlendirmesi çok uygun.
-----------------------------hocam dediğini anlayamadım nasıl 2 veri okuyabilir az daha basitleştirerek anlatabilir misin bu cahil için?
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla