• 10-09-2012, 15:55:09
    #10
    Ajax Push ile bu işlem yapılabilir. Ancak bilmediğiniz için o kısmı geçerek, yapabileceğiniz bir mantık yürütelim.

    Üye login olduğunda, onun için bir json oluşturur ve üye id ile bir yerlere yazdırabilirsiniz. Üyenin işlemleri sırasında dilerseniz bu dosyayı upgrade edersiniz. Örneğin üye bir mesaj gönderdi, mesajın gönderilme aşamasına bir kod yazarak buradaki değeri 1 artırabilirsiniz. Aradan biraz zaman geçer (Örn:10 gün), var olan dosyalar eskiden başlayarak silen bir tetikleyici yazarsınız. Her 10 günde 1 veriler silinir. Böylece disk sorunu yaşamazsınız.

    Bu size hangi aşamada bir avantaj kazandırır, Sadece dolaşmak için giren üyelerin bilgileri dosyadan okunacağı için sql sorgu sayısı bu noktada azalır. Aktif üyelerin sabit bilgileri de dosyadan çekileceği için yine sorgu sayısında bir azalma olur. Yeni eklenen mesajlar için de dosyaya +1 şeklinde bir artırım yapacağınızdan, sql server ile bu noktada yine işiniz olmaz taa ki 10 gün sonraya kadar.

    10 gün semboliktir. Dilerseniz ilgili dosyaları her gün oluşturur-silersiniz.

    Not: mysql sunucusunu rahatlatacağım diye, web sunucusuna da fazla yüklenmeyin hani
  • 10-09-2012, 18:06:20
    #11
    bayGaReZ hocam dediğiniz şeyi araştırdım. ajax push, long data polling, reverse ajax, comet gibi bazı tanımlarla da izah ediliyor.

    işleyiş şeklinde farklı yöntemler var ama mantık kabaca şu şekilde, istek, tetikleme ve sonuç. açarsak ajax ile sunucuya bir istek yollanıyor ve sunucu bu isteği belli aralıklarla kontrol etmeye başlıyor. browser ile bağlantıyı koparmamak için arada bir ufak dataları geri yolluyor. istenen işlemin sonucunda bir güncelleme varsa ajax'a yeni verileri çekmesini tetikleyen bir uyarı geliyor ve ajax da ikinci mekanizma devreye giriyor ve güncel veriyi çekip ekrana basıyor sonra olay yeni güncelleme numarası ile tekrardan başa dönüyor.

    bu durum işime yarar ama asıl sorduğum şeyin cevabı değil.
    meseleyi anlatırken üye mesaj sayısına göre örnek vermiştim bunu 100 tane ürün olarak da düşünebilirsiniz.
    şu anki çözüme göre 100 tane ürün için 100 tane ayrı json dosyası oluşturmak ve fiyat güncellemesi olduğundan sadece o ürünün json dosyasını update etmek sorunu çözüyor.
    bu işlemi tek dosya üzerinden her seferinde sıfırdan dosyayı inşaa etmeden yapmanın yolu varmıdır acaba? diğer türlü dosyalar baya bi dallanıp budaklanacak
  • 10-09-2012, 19:36:52
    #12
    Javascript ile mysql sunucusuna bağlantı kurmayı biliyor musunuz? public dizinin bir üstünde mysql sunucusu ile bağlantı kurma yeteneğine sahip bi' js dosyası ve comet server bu işi çözecektir. Server için 80 ya da 8080 portları dışında başka bir port dinleyerek, hem yükü comet üzerine yıkar ve mysql ile web sunucularını rahatlatırsınız, hem de bu teknik ile diğerine göre çok çok büyük oranda verilerde bile harika performans alırsınız.

    Dediğinize gelince, iyi bir dizinleme ile oldukça çok dosya sıkıntı çıkarmayacaktır. Yani her ürün, her üye ya da her neyse onun için bir dosya bile oluştursanız sorun yaşamazsınız. Bu tekniği kullanan bir yer biliyorum. Bir saat içerisinde binlerce dosya oluşturup, binlerce dosya silen ve performanstan ödün vermeyen..
  • 11-09-2012, 10:54:38
    #13
    olaya biraz daha tuz biber ekersek ben projede bu durumu aşağıda izah ettiğim sebeplerden dolayı şu şekilde kullanmayı planlıyorum uygun bir çözüm önerisine de açığım.

    konunun çıkış mantığı ve hikayesi şu şekilde. organize eden bir ana site ve buna bağlı onlarca site düşünün. benim sorunun organize eden sitenin dar boğaza girmesiyle tüm yapının durması.

    hali hazırda işleyen projede durum şu şekilde, çoğumuz sitelerimizde merkez bankasındaki bir xml servisinden döviz bilgilerini çekip kullanmışızdır. işte benim sıkıntılarımın kaynağı bu merkez bankasının döviz kuru servisi gibi hizmet veren organize edici sitemin gelen taleplere cevap veremez hale gelmesidir. cpu ve ram kullanımına bağlı olarak anlık belli bir online işlem kapasitemiz var bu kapasite dolduğunda tüm sistem duruyor. cpu ve ram takviyesi ile bu durumu çözebiliyorum ama bu geçici bir çözüm çünkü bu çözümün de bir sınırı var ve site sayısı arttığında oluşacak durum gözümü korkutuyor.

    benim şu anki arayışımın hedefi cpu ve ram'e bağlı olan kapasite bağımlılığının eşiğini olabildiğince arttırmak.

    herhangi bir sitede her sayfa görüntülenmesinde ana sitede anlık değişiklik olmuşmu diye kontrol etme ihtiyacımdan dolayı organize eden siteye sürekli talep gidiyor ve bu talep mysql üzerinden karşılanıyor bazen de karşılanamıyor. şimdi bende tüm sistemi baştan aşağı yeniden dizayn edicem.
    ilk olarak tek bir sunucuyu hosting sunucusu, veri tabanı sunucusu ve bu cache işlemleri için file server olarak üç parçaya bölmeyi planlıyorum. ihtiyaca göre bunlar ayrı ayrı üç sunucu da olabilir ama ilk etapdaki düşüncem bu.

    bu saydece veri güvenliği ve bu verilerin tutarlılığının kontrolunu sağlamayı planlıyorum.
    sitelerin tüm işleyişini file server üzerindeki json file ile ayalayıp en son aşamada kayıt güncellemesi gerekiyorsa db deki veri ile json'u karşılaştırıp tutarlılık varsa json ve mysql de güncellemeleri yapıcam.

    bu sistemin bana en büyük katkısı şu noktada olucak olur ya aksi bir durumda birisi veritabanını üzerinde manipülasyon yapsa ayrı sunucudaki jason dataları ile tutarlılık olmayacağından işlemleri yasaklayabilicem. yada tam tersi json kurcalansa bile veri tabanı bana ek güvenlik saylayacak.

    yapı bu şekilde olunca dallanıp budaklanmaması için üye işlemlerini tek bir json dosyası üzerinde tutup gerektiğinde sadece ilgili üyenin verisini değiştirebilirmiyim diye sordum çünkü ortak olan dosyayı 5 numaralı üye için gincellerken aynı anda 10 numaralı üyeninki de güncellenmesi gerekirse datada bozukluk olacağından korkuyorum.

    son tahlilde veri tabanını ve json data file sunucularını ayırıcam.
    her kategori için ayrı, üye için ayrı json file üzerinden siteleri işleticem.
    yorum, oylama vs. gibi data değişikliği gerektiren durumlarda json datası ile myswl datasındaki revize numarasından tutarlılığı kontrol edip sorun yoksa ilgili dataları güncelleyecem. bu şekilde cache file ile gene sunucunun anasını ağlatırmıyım acaba

    json datalarının güvenliği için bu verileri kendi algoritmam ile şifreliyorum. birisi dosyayı indirse bile içeriğinden bişey anlamaz. ek olarak klasör güvenliğini nasıl sağlarız.

    böyle bir yapı için başka nasıl bir çözüm düşünülebilir?
  • 11-09-2012, 16:38:15
    #14
    Kimlik doğrulama veya yönetimden onay bekliyor.
    tüm üye bilgilerinin tek dosyada olması çok yanlış. mesela senle ben aynı anda üye bilgilerimizi değiştirmeye çalıştık. bu durumda ne olacak? kaos. birimizin güncellemesi diğeri yüzünden geçersiz olacak.
  • 11-09-2012, 17:44:19
    #15
    hocam zaten o yüzden ilk başta json dosyasındaki belli bir alanı güncellemenin yolu varmı diye sordum.
    1000 kişilik json datasının içinden sadece 10 numaralı olanın datasını editleme imkanımız yok sanırım. aksi halde sizin dediğiniz durumun oluşması kuvvetle muhtemel bende bu yüzden arayiş içindeyim.
    her üye için tek tek json file yaparsam sorun çıkmayacak gibi görünüyor.

    üye kısmı tamam ama ürünler kısmında benzer sorun halen var. aynı yapıyı her ürün için de tek tek json data file oluşturarak kullanmayı düşünüyordum fakat bu seferde şöyle bir sorun var sayfalarda atıyorum "grafik tasarım" kategorisindeki ürünleri fiyatları ile ekrana basmam gerek diyelim. kategoriye bağlı 200 ürün/ilan olduğunu varsaysak scriptin tek tek 200 json dosyasına bağlanıp ürün - fiyat verilerini çekmesi gerekicek. bu da zamandan ve işlem gücünden büyük ödün vermek manasına gelir diye düşünüyorum. bu noktada aklıma bir çözüm gelmediğinden ürünler için cache kullanamayacam. bu da en baştaki can sıkan mysql sorgusu problemime geri dönmem manasına geliyor

    duruma göre json file yada mysql sorgusu şeklinde hibrit bir yapı kurmam gerekicek sanırım.
  • 12-09-2012, 01:34:20
    #16
    Hocam şu sistemin hangi sitede olduğunu, nasıl bir iş yaptığını vs. somut bir şekilde gösterebilir misiniz bana? Özelse pm ile de gönderebilirsiniz. İhtimal o ki farklı teknolojilerle bu sorun çözülebilir, ancak size doğru bir tavsiyede bulunabilmem için sistemin tam olarak ne olduğunu bilmem daha iyi olur..
  • 12-09-2012, 16:08:05
    #17
    Üyeliği durduruldu
    Hocam No-SQL çözümleri senin işini görür gibi duruyor

    Düzeltme: hatta CouchDB ye bir bak