Üye Girişi
Bağlan Google+ ile Bağlan Facebook ile Bağlan
Yeni Kayıt
Tüm Forumlar
  • Tüm Forumlar
  • Web Tasarım - Programlama
  • Yazılım Geliştirme
  • Delphi / C++ /Vb
  • Bu Konuda
Şimdi Ara

C++ ile Web Sitesi Yayını

Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla
Bu Konudaki Kullanıcılar: Daha Az
3 Misafir - 3 Masaüstü
5 sn
21
Cevap
0
Favori
5.074
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
Konuya Özel
0 oy
Öne Çıkar
Cevapla
Sayfa: 12
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  • Selam ahali.
    Bildiğiniz üzere halihazırdaki database'ler oldukça verimsiz ve ben web yayınlarımda kullanacağım database'leri kendim programlamak istiyorum.Zanledersem web sitesi yayınlamaya yarıyan programlar da pek verimli değil.En temizi hepsini baştan programlamak diye düşünüyorum.Bu konuda aşmam gereken platformsal kısıtlamalardan kaynaklanan temel engeller var.
    1.Birkaç web sitesi yapmak ve server tarafını C++ ile kodlamak istiyorum.Web sayfalarının network üzerinden gönderimini yazacağım program üzerinden yapmak ve web sayfasındaki formlar doldurulunca formlardaki bilgileri gene yazacağım programdaki değişkenlere iletmek istiyorum.Bunu hangi yollardan yapabilirim?Sonrasında Python'u kendi programıma entegre bir Python yorumlayıcısı üzerinde çalıştırmayı ve C++'a aktardığım form bilgilerini de Python'a aktarmayı düşünüyorum.
    2.Halihazırda bilgisayarımda çalışan HTML ve PHP ile kodlanmış bir web sayfasındaki MySQL sorguların MySQL yerine C++'da yazacağım bir database üzerinde çalışmasını nasıl sağlayabilirim?
    --------05.11.2013
    Yüksek performanslı web sitesi yayını yapmak ve web uygulamaları geliştirmek için kullanılan C++ tabanlı sistemler varmış.Bunlar ilk maddede bahsettiğim şeye benziyorlar:
    http://www.webtoolkit.eu/wt/?wtd=7s8mlsQmBKVrLShRtNrkn0ptvVjUt5pY
    http://cppcms.com/wikipp/en/page/main
    MySQL'in saklama motorundan daha iyisini yapabileceğine inanan bilimadamları ve mühendisler yeni bir database yapmak yerine MySQL'in ve başka veritabanlarının saklama motoruyla yer değiştiren çok daha hızlı bir motor yazmışlar.Bu da algoritmalarını kullanmak isteyenlerin kullandıkları veri tabanını değiştirmek yerine sadece basit bir kurulum yaparak halihazırdaki veritabanlarında bu algoritmaları kullanmabilmelerini sağlamış.Bu da ikinci yapmak istediğime çok benziyor ama ondan daha iyi:
    http://www.tokutek.com/products/tokudb-for-mysql/

    Sonuç olarak yeni bir database yazmak yerine TokuDB gibi bir motor yazsam daha verimli olurum ve sadece kendim kullanmak yerine başka insanlara da ulaşabilirim.SSD'yi ikinci dereceden ram olarak da kullanabilen ve gerektiğinde yardımcı işlemci olarak ekran kartını kullanabilen,üzerinde çalıştığı bilgisayarın nimetlerinden sonuna kadar istifade eden bir sistem kurmak ve bundan web yayını yapmak istiyorum.Hedefim 3 yıl içerisinde metro eternet çektiğim tek bir güçlü bilgisayardan çok kişiye ucuz hosting imkanı sağlayabilmek.



    < Bu mesaj bu kişi tarafından değiştirildi tatankalahari -- 5 Kasım 2013; 13:08:26 >







  • c++ php gibi bir dil olarak düşünmelisin database yazamazsın. Belki veriyi hafızada tutturabilirsin ama verimsiz olur sunucu kapandığında gider açılırken sıfırlanır.

    Ama dosya olarak diskte tutmak istiyorum ve web sunucunun yaptığı işlemi benim yazıcağım uygulama yapsın diyorsan burada seni uyarmak isterim yanlış bir yol ama yapılabilir. Öncelikle sqlite gibi diskte database tutan bir kütüphane ile uygulamanın içinde verileri işleyebilirsin. Sonrada boost::asio ile port 80 den gelen bağlantıları programa kabul edip işleyebilirsin. Amerikayı yeniden keşfetmeye gerek yok; apache php mysql üçlüsü işini rahat görmesi lazım bütün bu bahsettiklerim gereksiz aslında. html 5 yardımını unutmamak lazım.
  • quote:

    Orijinalden alıntı: uozgu

    c++ php gibi bir dil olarak düşünmelisin database yazamazsın. Belki veriyi hafızada tutturabilirsin ama verimsiz olur sunucu kapandığında gider açılırken sıfırlanır.

    Ama dosya olarak diskte tutmak istiyorum ve web sunucunun yaptığı işlemi benim yazıcağım uygulama yapsın diyorsan burada seni uyarmak isterim yanlış bir yol ama yapılabilir. Öncelikle sqlite gibi diskte database tutan bir kütüphane ile uygulamanın içinde verileri işleyebilirsin. Sonrada boost::asio ile port 80 den gelen bağlantıları programa kabul edip işleyebilirsin. Amerikayı yeniden keşfetmeye gerek yok; apache php mysql üçlüsü işini rahat görmesi lazım bütün bu bahsettiklerim gereksiz aslında. html 5 yardımını unutmamak lazım.
    db nedir abi, sırf insert update select midir yani sana göre normal aklı başında bir insan mevcut db çözümleri verimsiz ben yenisini yazacağım gibi bir cümleyi nasıl kurabilir insan hayret ediyor cidden

    ayrıca bu işin bir sürü bilmen gereken temeli var, thread ve row lock muhabbetleri bir yana, yerleştirme ve sonuç döndürmek için kullanılan bir çok teknik var basit bir stack üzerine doldurmuyor sonuçta verileri, beğenmediğin mysql bile bir schema üzerinde 3 milyon küsür kayda kadar sıkıntı çıkarmıyor, çakıldığı zaman kendini toparlayabiliyor vs. daha iyisini nasıl yapmayı düşündüğünü çok merak ettim şu an




  • tatankalahari T kullanıcısına yanıt
    Veritabanlarını hangi açılardan ve ney ile kıyaslayarak verimsiz bulduğunu sorabilir miyim?

    Kurguladığın veritabanını ne tarz veri yapıları üzerine oturtmayı düşünüyorsun? B+ Tree mi? Bucket mı? Yoksa daha iyi bir önerin mi var?

    Query'leri işlemek için hangi yapıyı kullanacaksın? Indexed Structure mı? Parse Tree mi? Neden?

    "Trade-off"un ney olacak? Eklemeyi mi ön planda tutacaksın yoksa aramayı mı?

    Herbir işlem için "complexity" değerin kaç olacak?

    ...

    Server kısmına girmiyorum bile..
  • quote:

    Orijinalden alıntı: uozgu

    c++ php gibi bir dil olarak düşünmelisin database yazamazsın. Belki veriyi hafızada tutturabilirsin ama verimsiz olur sunucu kapandığında gider açılırken sıfırlanır.

    Ama dosya olarak diskte tutmak istiyorum ve web sunucunun yaptığı işlemi benim yazıcağım uygulama yapsın diyorsan burada seni uyarmak isterim yanlış bir yol ama yapılabilir. Öncelikle sqlite gibi diskte database tutan bir kütüphane ile uygulamanın içinde verileri işleyebilirsin. Sonrada boost::asio ile port 80 den gelen bağlantıları programa kabul edip işleyebilirsin. Amerikayı yeniden keşfetmeye gerek yok; apache php mysql üçlüsü işini rahat görmesi lazım bütün bu bahsettiklerim gereksiz aslında. html 5 yardımını unutmamak lazım.

    Sıfırdan database yazmak çok zaman alabilir.SQLite'ın kodlarını değiştirerek yapmak daha mantıklı.Verinin bir kısmını ram'da tutcak.Gerektiğinde harddiske yedeklicek.Sunucu kapanırken de bilgiler hafızaya yedeklenirse sorun olmaz.Sorun bunlar değil.Sorun serverımdaki sitelerin MySQL sorgularını benim yazdığım programa yönlendirememek ve web sayfasından gelen bilgileri C++'a aktaramamak.
    Port80'den gelen verileri zanledersem UDP socket programlamayla kabul edebilirim.Sonrasında nasıl işlemem gerektiğini nereden öğrenebilirim?




  • quote:

    Orijinalden alıntı: Dracos

    db nedir abi, sırf insert update select midir yani sana göre normal aklı başında bir insan mevcut db çözümleri verimsiz ben yenisini yazacağım gibi bir cümleyi nasıl kurabilir insan hayret ediyor cidden

    ayrıca bu işin bir sürü bilmen gereken temeli var, thread ve row lock muhabbetleri bir yana, yerleştirme ve sonuç döndürmek için kullanılan bir çok teknik var basit bir stack üzerine doldurmuyor sonuçta verileri, beğenmediğin mysql bile bir schema üzerinde 3 milyon küsür kayda kadar sıkıntı çıkarmıyor, çakıldığı zaman kendini toparlayabiliyor vs. daha iyisini nasıl yapmayı düşündüğünü çok merak ettim şu an

    SQLite'ın kodlarını değiştirerek başlıyacağım için elimde halihazırda çalışan bir database olcak.Çok threadli kendi yöntemler kullanmak ve aynı anda birden fazla query işlemek istediğimden lock olaylarıyla uğraşmam gerekebikir ama diğer ayrıntılarla başlangıçta uğraşmam gerekmeyecektir.Sadece zamanla yerleştirme ve sonuç döndürme tekniklerini geliştirip hızlandırmayı düşünüyorum.Aşağıdaki mesajımda ayrıntılara da yer verdim.



    < Bu mesaj bu kişi tarafından değiştirildi tatankalahari -- 1 Kasım 2013; 11:38:22 >




  • quote:

    Orijinalden alıntı: qamyoncu

    Veritabanlarını hangi açılardan ve ney ile kıyaslayarak verimsiz bulduğunu sorabilir miyim?

    Kurguladığın veritabanını ne tarz veri yapıları üzerine oturtmayı düşünüyorsun? B+ Tree mi? Bucket mı? Yoksa daha iyi bir önerin mi var?

    Query'leri işlemek için hangi yapıyı kullanacaksın? Indexed Structure mı? Parse Tree mi? Neden?

    "Trade-off"un ney olacak? Eklemeyi mi ön planda tutacaksın yoksa aramayı mı?

    Herbir işlem için "complexity" değerin kaç olacak?

    ...

    Server kısmına girmiyorum bile..


    Mevcut yaygın veritabanları büyük ihtimalle mimariye özel geliştirilmiyor ya da kendini üzerinde çalıştığı bilgisayara özel yeteri kadar optimize edemiyor.En iyi verimi almak için ihtiyaca özel bir bilgisayar toplayıp veri tabanını ona özel programlayıp optimize etmek lazım.
    Tek anahtarlı tablolar için ikili ağacın özelleştirilmiş bir çeşidini kullanmayı planlıyorum.Bu veri yapısı bilgileri bütün bellek seviyeleri için yeterince verimli bir şekilde saklayabiliyor.B Tree'ye de benzeyen bu yapı hem B+Tree'den daha az yer kaplıyor hem de bilgilere erişim konusunda daha hızlı.Çok anahtarlı tablolar için de bu yöntemi R-Tree KDTree gibi yöntemlerle birleştirmeyi planlıyorum.
    Veri tabanını programlamaya SQLite'ın kodlarını değiştirerek başlıyacağım için başlangıçta bununla pek uğraşmam gerekmeyecek.İleride yeni veri tabanı kodları eklemem ya da giriş yöntemini değiştirmem gerekirse o zaman düşünürüm.
    Başlangıçta aramayı ön planda tutmayı planlıyorum.Bu durumda bile 60milyon elemanlı bir tabloyu yeniden inşa etmek bile 0.1 saniyeden kısa sürecebilir.Tabiki yeni eleman eklemek için bütün tabloyu yeniden inşa etmek zorunda değilim.Daha hızlı yöntemler kullanabilirim ama bazı tablolarda anahtarların uzun olması bu süreyi arttırabilir.
    Zaman karmaşıklığı şimdilerde kullanılan yöntemlerden pek de farklı olmayacak.Gizli sabit daha iyi olabilir ama en önemli nokta veri yapıları donanımdan en en yüksek verimi almak üzere ona özel geliştirilcek,kodlancak ve derlencek.
    Önerilerin var mı?

    Güzel sorular geldi,güzel noktalara değinildi şimdiye kadar.Bu işlerle ilgilenenleri görmek güzel.Yorumlarınızın devamını bekliyorum.




  • quote:

    Orijinalden alıntı: tatankalahari

    quote:

    Orijinalden alıntı: qamyoncu

    Veritabanlarını hangi açılardan ve ney ile kıyaslayarak verimsiz bulduğunu sorabilir miyim?

    Kurguladığın veritabanını ne tarz veri yapıları üzerine oturtmayı düşünüyorsun? B+ Tree mi? Bucket mı? Yoksa daha iyi bir önerin mi var?

    Query'leri işlemek için hangi yapıyı kullanacaksın? Indexed Structure mı? Parse Tree mi? Neden?

    "Trade-off"un ney olacak? Eklemeyi mi ön planda tutacaksın yoksa aramayı mı?

    Herbir işlem için "complexity" değerin kaç olacak?

    ...

    Server kısmına girmiyorum bile..


    Mevcut yaygın veritabanları büyük ihtimalle mimariye özel geliştirilmiyor ya da kendini üzerinde çalıştığı bilgisayara özel yeteri kadar optimize edemiyor.En iyi verimi almak için ihtiyaca özel bir bilgisayar toplayıp veri tabanını ona özel programlayıp optimize etmek lazım.
    Tek anahtarlı tablolar için ikili ağacın özelleştirilmiş bir çeşidini kullanmayı planlıyorum.Bu veri yapısı bilgileri bütün bellek seviyeleri için yeterince verimli bir şekilde saklayabiliyor.B Tree'ye de benzeyen bu yapı hem B+Tree'den daha az yer kaplıyor hem de bilgilere erişim konusunda daha hızlı.Çok anahtarlı tablolar için de bu yöntemi R-Tree KDTree gibi yöntemlerle birleştirmeyi planlıyorum.
    Veri tabanını programlamaya SQLite'ın kodlarını değiştirerek başlıyacağım için başlangıçta bununla pek uğraşmam gerekmeyecek.İleride yeni veri tabanı kodları eklemem ya da giriş yöntemini değiştirmem gerekirse o zaman düşünürüm.
    Başlangıçta aramayı ön planda tutmayı planlıyorum.Bu durumda bile 60milyon elemanlı bir tabloyu yeniden inşa etmek bile 0.1 saniyeden kısa sürecebilir.Tabiki yeni eleman eklemek için bütün tabloyu yeniden inşa etmek zorunda değilim.Daha hızlı yöntemler kullanabilirim ama bazı tablolarda anahtarların uzun olması bu süreyi arttırabilir.
    Zaman karmaşıklığı şimdilerde kullanılan yöntemlerden pek de farklı olmayacak.Gizli sabit daha iyi olabilir ama en önemli nokta veri yapıları donanımdan en en yüksek verimi almak üzere ona özel geliştirilcek,kodlancak ve derlencek.
    Önerilerin var mı?

    Güzel sorular geldi,güzel noktalara değinildi şimdiye kadar.Bu işlerle ilgilenenleri görmek güzel.Yorumlarınızın devamını bekliyorum.

    Alıntıları Göster
    Verimlilik mi ariyorsun:

    http://research.google.com/archive/bigtable.html

    http://en.wikipedia.org/wiki/BigTable

    http://en.wikipedia.org/wiki/Apache_HBase

    http://en.wikipedia.org/wiki/Apache_Cassandra

    http://en.wikipedia.org/wiki/Apache_Accumulo




  • quote:

    Orijinalden alıntı: ThisisaNightmare

    Verimlilik mi ariyorsun:

    http://research.google.com/archive/bigtable.html

    http://en.wikipedia.org/wiki/BigTable

    http://en.wikipedia.org/wiki/Apache_HBase

    http://en.wikipedia.org/wiki/Apache_Cassandra

    http://en.wikipedia.org/wiki/Apache_Accumulo

    Alıntıları Göster
    sqliteın hiçbişeyini değiştirme verim hesabını neyle yaptığını anlamıyorum bilgisayarların fiziksel sınırları var zaten ve şu an kullanılan db çözümleri gayet verimli.

    bir sitenin tcp 80 portu üzerinden (http protokolünde) yayın yaptığını bilmememen eksik bilgin olduğunu gösteriyor. daha başlangıçta böyle bir eksik varken önerim böyle bir işe kalkışma.

    Amacın sitedeki verileri sunucu üzerinde yada dünyanın herhangi bir yerinde c++ ile yazılmış uygulamaya almak ise mysql sunucusuna bağlanarak bunu çok rahat yapabilirsin. mysqlpp kütüphanesi yönün.



    < Bu mesaj bu kişi tarafından değiştirildi uozgu -- 3 Kasım 2013; 19:50:45 >




  • ThisisaNightmare T kullanıcısına yanıt
    Bunlardan haberim yoktu.Çok ilgimi çekti.Bunları da araştırmaya başladım.
    Benim dediğim BigTable ya da Hadoop gibi dağıtık bir database değil.Tam tersine çalıştığı tek bilgisayar üzerine optimize edilmiş bir DB.Ancak bunu daha sonra diğer sistemlere de kendini otomatik optimize edecek şekilde programlamak ve hatta dağıtık sistemlerde çalışabilecek şekilde optimize etmek istiyorum.
  • uozgu U kullanıcısına yanıt
    Bilgisayarların fiziksel sınırlarını kullanma konusunda geleneksel yöntemler çok da iyi değil.Son yıllarda işlemcilerin hızları çok geliştiyse de ram-cpu arasındaki bant genişliği o ölçüde gelişemediğinden genelde işlemci yeterli veriyle beslenemediğinden işlem gücünün tamamını kullanamıyor.Bu sorunu çözen algoritmalar var.Ekran kartı,XeonPhi,FPGA gibi yardımcı işlemcileri kullanan veri tabanlarına ayrıca ihtiyaç var.Birçok veri saklama yönteminin SSD'ler için yeniden optimize edilmesi lazım.
    Daha önce arkadaşım SQLite'ın kodlarını değiştirerek hızlandırmıştı.Ben de benzer şekilde bir donanıma optimize etmek istiyorum.
    Alanımla ilgiligi olmadığından bilmem gerekmemesine rağmen 80. portu kullandığını biliyorum.Gelen verileri nasıl işleyebileceğimi bilmiyorum.Sorularımdan birisi buydu zaten.Şimdiye kadar sadece algoritma kısmıyla ilgilendim.
    İstediğim bu değildi,MySql sorgularını kendi yazdığım veritabanına yönlendirmekti.




  • quote:

    Orijinalden alıntı: tatankalahari

    Bilgisayarların fiziksel sınırlarını kullanma konusunda geleneksel yöntemler çok da iyi değil.Son yıllarda işlemcilerin hızları çok geliştiyse de ram-cpu arasındaki bant genişliği o ölçüde gelişemediğinden genelde işlemci yeterli veriyle beslenemediğinden işlem gücünün tamamını kullanamıyor.Bu sorunu çözen algoritmalar var.Ekran kartı,XeonPhi,FPGA gibi yardımcı işlemcileri kullanan veri tabanlarına ayrıca ihtiyaç var.Birçok veri saklama yönteminin SSD'ler için yeniden optimize edilmesi lazım.
    Daha önce arkadaşım SQLite'ın kodlarını değiştirerek hızlandırmıştı.Ben de benzer şekilde bir donanıma optimize etmek istiyorum.
    Alanımla ilgiligi olmadığından bilmem gerekmemesine rağmen 80. portu kullandığını biliyorum.Gelen verileri nasıl işleyebileceğimi bilmiyorum.Sorularımdan birisi buydu zaten.Şimdiye kadar sadece algoritma kısmıyla ilgilendim.
    İstediğim bu değildi,MySql sorgularını kendi yazdığım veritabanına yönlendirmekti.
    Kendi veritabani sisteminizi yazma isi baya zor bi is.

    Yaklasik 5 aydir D dili ile yazdigim bir sistem var. Tabii surekli vaktimi ayiramadim bu yuzden yavas ilerliyor ama hala interpreter'daki bug'lari duzenliyorum. D dili C++ gibi bir dildir. Compiled dil. Compiled dil'den bir interpreter olusturdum. Binlerce satir da kod oldu yani. Lexical vs. analiz kodlarinin dosyalari islem, optimizasyon dosyalari binlerce satir. Daha algoritmasini olusturdugum fiziksel saklama bicimini hala projeye ekleyemedim.

    Bu o kadar kolay bi is degil.

    C++ ile web frameworkleri var. gelelim bu mantikli mi sorusuna. kim neden kullanir ki? govde gosterisi yapmak isteyenler harici kimse kullanmaz.

    Eger gercekten fayda saglayacagini dusunulseydi buyuk sistemler kullanirdi. Belki C++ ile karistirilmis diller kullanilir ama yine bunlar compiled degil.

    C++ ile sunucu islemlerini halledebilirsin. Yani performans saglayici kismi ama server tarafi daima yorumlanan bicimde olacaktir.

    Kolay gelsin.




  • X-1 kullanıcısına yanıt
    Yaptığınız çalışma gerçekten ilgimi çekti.Bundan bahsettiğiniz bir konu ya da blog var mı?
    Dediklerinize bakılırsa sadece veri tabanı kısmını yeniden programlamam en mantıklısı gibi.Yeterince hız vaadederse ve kullanımı kolay olursa belki kullanıcı bulabilir.Öte yandan web frameworku yazarsam pek kullanıcı bulamam gibi.Yine de bunu da yapmak istiyorum,en azından kendi sistemimde kullanırım.
    Önceliği veri tabanı yazmaya verdim.Bunu yapmak için yaklaşık 2 yıl vaktim var gibi.Aslında tamamen yeni bir veri tabanı yazmama gerek yok.Mevcut veri tabanlarının benim saklama ve arama yöntemlerimi kullanmasını sağlamak yetebilir.Benzerini gayet başarılı bir şekilde yapmışlar:
    http://www.tokutek.com/products/tokudb-for-mysql/




  • quote:

    Orijinalden alıntı: tatankalahari
    Birçok veri saklama yönteminin SSD'ler için yeniden optimize edilmesi lazım.

    SSD ler fiyat/kapasite olarak hala HDD lerden ucuz degil.
    Acikcasi gunumuzdeki "Big Data" icin yazilmis sistemler, HDD ye depolar ve kullanilcagi yeri onceden tespit ederek ram e aktarir. Boylelikle diskten olusacak yavaslama gorulmez.
  • ThisisaNightmare T kullanıcısına yanıt
    SSD ucuz olduğu için değil hızlı olduğu için kullanılır.Yüksek hıza ihtiyaç olduğu bazı durumlarda insanlar çok yüksek paralar ödeyebiliyor.Normal SSD'leri geçtim PCI-e kullanan SSD'ler var.Çok pahalı ama çok hızlılar:
    http://www.amazon.com/OCZ-Z-Drive-Series-Maximum-ZD4CM84-HH-1-2T/dp/B005HU0LJ8
    Bu da veri tabanları için özel üretilmiş:
    http://ocz.com/enterprise/zd-xl-sql-accelerator-pcie-ssd




  • tatankalahari T kullanıcısına yanıt
    Hocam gelişme oldukça burada paylaşırsanız sevinirim. Kolay gelsin
  • unforgiven1127 kullanıcısına yanıt
    Öneriniz üzerine ilk mesaja ilk güncellemeyi yaptım.
  • quote:

    Orijinalden alıntı: tatankalahari

    SSD ucuz olduğu için değil hızlı olduğu için kullanılır.Yüksek hıza ihtiyaç olduğu bazı durumlarda insanlar çok yüksek paralar ödeyebiliyor.Normal SSD'leri geçtim PCI-e kullanan SSD'ler var.Çok pahalı ama çok hızlılar:
    http://www.amazon.com/OCZ-Z-Drive-Series-Maximum-ZD4CM84-HH-1-2T/dp/B005HU0LJ8
    Bu da veri tabanları için özel üretilmiş:
    http://ocz.com/enterprise/zd-xl-sql-accelerator-pcie-ssd

    8 bin dolar

    Benim anlatmak istedigim. Az bir data icin degilde petabytelik cozumler vs icin Google in yaptigi gibi concurrent diske yaz, ordan gerektikce kullan tarzi bir sistem daha uygun geldi.




  • quote:

    Orijinalden alıntı: ThisisaNightmare

    quote:

    Orijinalden alıntı: tatankalahari

    SSD ucuz olduğu için değil hızlı olduğu için kullanılır.Yüksek hıza ihtiyaç olduğu bazı durumlarda insanlar çok yüksek paralar ödeyebiliyor.Normal SSD'leri geçtim PCI-e kullanan SSD'ler var.Çok pahalı ama çok hızlılar:
    http://www.amazon.com/OCZ-Z-Drive-Series-Maximum-ZD4CM84-HH-1-2T/dp/B005HU0LJ8
    Bu da veri tabanları için özel üretilmiş:
    http://ocz.com/enterprise/zd-xl-sql-accelerator-pcie-ssd

    8 bin dolar

    Benim anlatmak istedigim. Az bir data icin degilde petabytelik cozumler vs icin Google in yaptigi gibi concurrent diske yaz, ordan gerektikce kullan tarzi bir sistem daha uygun geldi.

    Alıntıları Göster
    "Hedefim 3 yıl içerisinde metro eternet çektiğim tek bir güçlü bilgisayardan çok kişiye ucuz hosting imkanı sağlayabilmek."

    Bahsettiğiniz iyileştirme çalışmaları ve kullanıcağınız donanımın yanında eğer sunucu Türkiye sınırları içinde olacaksa veri aktarımına da oldukça yüksek paralar vericeğinizi tahmin ediyorum tüm bunları göz önünde bulundurunca "ucuz" tanımı değişiyor. Yaptığınız yatırımın geri dönmesi gerekecek.

    Bugün halihazrdaki teknolojilerle oldukça yüksek kişiye ucuz hosting sağlanabilir tek bir sunucudan. Hepsi de bu konuda bahsedildiği gibi halihazıdaki kendini ispatlamış özellikleri kullanarak.

    mysql postrsql apache php asp ftp smtp pop3 ve pek çok diğer servisi tek bir sunucu üzerinde atıyorum 50 TB disk alanı üzerinden( tabiki değişik kombinasyolarda raidlerle) yine atıyorum uçuk miktarlarda ram ve intel xeon işlemcilerle belki 100 binlerce kişiye hosting sağlanabilir. Tabiki biraz uç bir tahmin. oldukça fazla optimizasyon yapmak gerekecektir her bir servis için. Detaylı ayarlarının tek tek uygulanarak stres testlerinin yapılması lazım. Hatta direk olarak vps dediğimiz sanal sunuculardan yüzlercesini sunmak mümkün. Sonuçta kısıtlayıcı etmenin veri bağlantısı olacağını düşünüyorum bu durumda. Bu nedenle cloud olarak tabir ettiğimiz sistemlere ihtiyaç duyuldu. Bu kadar yüksek özelliklerde bir sunucu yerine onlarca sunucuda görevlerin parçalara ayrılarak yaptırılması oldukça mantıklı. cdn de buna benzer bir durum.

    Yapmak istedikleriniz gerçekten çok güzel ancak bunları 3 sene gibi bir süre içerisinde kendi başınıza başarmanız oldukça zor görünüyor. Amacınıza ulaşmanızı sağlayacak zaten kullanılan ispatlanmış o kadar çok method varki. Ayrıca db motorlarından bahsetmişsiniz eğer belirli bir ihtiyaca yönelk olarak kullanılacaksa hazırda bulunanlar ince ayarları yapılarak oldukça verimli hale gelecektir.




  • uozgu U kullanıcısına yanıt
    Uzun süren araştırmalarımdan sonra ben de sizinle aynı sonuçlara vardım.Web yayını işindeki en büyük maliyet internet erişimi gibi.Bense özellikle veritabanı yoğunluklu web uygulamalarında donanım ve elektrik maliyetlerini düşürmeyi amaçlıyordum.Buna harcadığım emeği başka şeylere harcasam daha verimli olur gibi duruyor.Web scrapping'e yönelmeye karar verdim son zamanlarda.Veri tabanı motorlarıyla uğraşmaya ise işim gereği devam edeceğim.Olur da ileride internet fiyatları düşüp, web yayını maliyetleri donanım ve elektrik fiyatlarına bağlı hale gelirse ve veri tabanı ağırlıklı uygulamalar artarsa o zaman MySQL için bir hızlandırıcı yazarmayı düşünebilirim.

    Türkiye'de normal internet gerçekten çok kaliteli ve ucuz.Şu meşhur her evde 100Mb internet olan Kore'de yaşıyorum.Kore içinde bağlantı süper hızlı ama Avrupa'ya,Türkiye'ye,Amerika'ya bağlanmaya çalıştığımda 1Mb'in altına bile düşebiliyor.En bariz sonucu olarak Youtube videolarının dolmasını beklemem gerekebiliyor.Fiyat bugünlerde 50 lira gibi.İş Türkiye'deki upload hızına geldiğinde işler değişiyor.5Mb upload için bile binlerce lira ödemek gerekiyor.Korede upload hızı download hızına eşit ya da yarısı olsa gerek.Yani 50-100Mb/s ile site yayınlamak için de aynı 50 liralık internet yetiyor.Upload hızı sağlamanın ve download hızı sağlamanın maliyetinin yaklaşık aynı olduğu varsayılırsa ülkemizde bu konuda büyük bir sorun var.Görünen o ki fiyatları yüksek tutabilmelerinin nedeni insanların elinin mahkum olması ve durumun normal görünmesi,ses çıkaran olmaması.Bu konuda ilgili insanlar toplanıp çalışmalar yapsa(araştırma,bilgilendirme,imza kampanyası,boykot vs.) şirketler indirime gider diye düşünüyorum.




    • 
Sayfa: 12
Sayfaya Git
Git
sonraki

Benzer içerikler

- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.
Hizmet kalitesi için çerezleri kullanabiliriz. DH’ye girerek kullanım izni vermiş sayılırsınız.
Anladım Veri Politikamız