Sayfalar

MongoDB etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
MongoDB etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

20 Şubat 2013 Çarşamba

MongoDB Embed Doküman İşlemleri

MongoDB ile uzunlu soluklu online oyun projemizin alt yapısını oluşturmaya çalışıyorum. MongoDB nin veritabanı tasarım mantığını ısınmaya başladım. Ancak bazen sorgulama işlemleri için çeşitli araştırmalar yapmam gerekiyor. SQL diline yatkın olan biri olarak bu yeni sorgulama işlemleri ilk başta açıkçası zor geliyor. Ayrıca her ne kadar MongoDb nin kendi sitesinde detaylı döküman olsa da tam olarak istediğinizi bulmak için yabancı forumlarda araştırma yapmak gerekiyor. Temel collection yapılarını oluşturmak ve bu collectionlarda yapılan temel sorgular ekle,güncelle,bul,sil işlemlerini oluşturmak çok zor olmasa da dokümanda ağaçlanma başladığı zaman işlemler biraz daha zorlaşıyor.


{
_id:"5432af324432eaf43243"
name:"murat",
password:"12345"
mail:"muratsalweb@gmail.com"
}

Yukarıdaki yapıdaki basit döküman yapısında işlem yapmak kolay bir iş.

{_id: '4eb79ee1e60fc603788e7259',
Name: 'name', 
Subsidiaries: [
  { _id: '4eb79eeae60fc603788e7271',
   Location: 'location1'},
  { _id: 'subid2',
   Location: 'location2'},
]}

Yukarıdaki bir yapıda ise bir döküman içinde array döküman bulunmakta işte burda işler biraz karıştırıyor. Gerçi  mantığını öğrendikten sonra çokta zor değil açıkçası. Bunun gibi embed döküman yapısındaki collectionlarda veri işlemleri nasıl yapılabildiği hakkında diğer bloğumda yazı yazmak istiyorum zamanım olursa.

2 Şubat 2013 Cumartesi

Server Taraflı Programlama

Bu aralar küçük multiplayer oyunlar üzerine denemeler yapmak istiyorum. Ama kullanacağım teknolojiler hakkında biraz kararsızım. Önümde iki seçenek var aslında biri servis bazlı ikincisi realtime socket kullanımı.
Önümdeki engeller ise servis bazlı bir oyunda performansta sıkıntı yaşayabilirim. Veritabanı üzerinden diğer kullanıcılar ile haberleşme yapmak gerçekten performans kaybı demek. Ama iyi tarafı kolay şekilde bir php veya asp.net ile yazılabilir ve herhangi bir share hostingte kullanılabilir. Realtime soket tarafında ise performans çok daha iyi ama kodlama için iyi bir tecrübe gerekebilir. Ayrıca bunu denemek için en azından bir vps sunucusuna ihtiyacım olacak. Onun için çokta riske girmek istemiyorum. Sadece deneme  yapmak için hem para hemde zaman kaybetmek istemiyorum. Onun için muhtemelen böyle bir şeye girişirsem servis tabanlı bir server teknolojisi kullanacağım galiba.

 Bu işi daha performanslı hale getirmek için NoSQL veritabanıda kullanabilirim aslında. MongoDB rami çok kullanan bir veritabanı. Öyleki bir veriyi insert edip eklediğinizde ve bu veriye tekrardan ulaştığınızda bu veri hala sadece ram üzerinde tutuluyor olabilir. Aslında bunun ayarlamasını biz yapabiliyormuyuz bilmiyorum. Ama hangi collection veya dokümanın ramde cachelenebileceğini ayarlayabiliyorsak bu performans için çok yaralı olabilir. Aslında bu şekilde çalışan Memcached gibi teknolojilerde mevcut. Ama yine kendinize ait bir sunucu ihtiyacı doğuyor bu şekilde.

Bir ara bu iş için web socket teknolojiside kullanmayı düşünsem de . Bunun için hosting firmasının bazı kütüphaneleri aktif etmesi ve socket açmanıza izin vermesi gerekiyor. Bunu sağlayan bir hosting bulmakta biraz zor gibi.

16 Ocak 2013 Çarşamba

MongoDB Tecrübesi

Bir yıldan fazla MongoDB kullanan kiip servisi kullandıkları bu teknojinin artı ve eksileri  yazmışlar. Aslında pek de memnun olduklarını söyleyemem ki zaten yeni teknoloji arayışlarına girişmişler. Sonuç olarak verilerinin %90 nından fazlasını  Riak ve PostgreSQL üzerine taşımışlar.
Kiip servisinin veri istatistikleri

  • Veri Boyutu: 240 GB
  • Toplam Döküman Sayısı: 85,000,000
  • Saniyedeki İşlem Sayısı: 520 ( okuma, yazma, gibi.)
Yazıya bu linkten ulaşabilirsiniz.

8 Ocak 2013 Salı

MongoDB Sayfalama problemi

Bu aralar MongoDB ile bir çok problemle karşılaşıyorum. Test etmek için veritabanına 17 milyondan fazla kayıt eklemiştim. Kullandığım MongoVue GUI programı ilk olarak fark ettiğim olay verilerin sayfalama ile gösterilirken son sayfaların  çok yavaş getiriliyor olması idi. 100 000lere kadar çok bir kasma yaşamasam da
milyonluk verilerin içinden son sayfalara ulaşmak çok kasıcı bir işlem olduğunu gördüm.
17 milyondan fazla kayıt bulunan bu collectionda ilk sayfalardaki veriyi mili saniyeler içinde çekebiliyorum.

Sol tarafta bulunan resim 14 milyon ile 14 milyon 9. kayıtların arasındaki kayıtları gösteriyor. Bu veriyi çekmek için aşağıdaki resimdeki gibi 32 saniye işlem yapıldı.

Bu işlemi birde konsol ekranından denedim.

db.urls.find().skip(14000000).limit(10);

Fakat bir değişiklik göremedim. Bununla ilgi internetten araştırmalarım sonucu bir çok kişinin aynı sorunla karşılaşmış olduğunu gördüm.
Herhangi bir veriyi aslında çok hızlı bir şekilde sorgulaya biliyorum. Özellikle de indexlenmiş alanlarda ama sayfalama gibi basit bir sorguda böyle bir sonuçla karşılaşmayı hiç ummazdım.

5 Ocak 2013 Cumartesi

MongoDB hakkında

MongoDB , NoSQL veritabanları arasında en popüler olanlardan. MongoDB ölçeklenebilirlik açısından güzel bir çözüm sunsa da bu sistemi yönetmek biraz zor olabilir. Veritabanın read/write performansını artırmak için shard özelliği ile yatay ölçekleyebilirsiniz. Ancak bu özelliği kullanmanız için önerilen sistemde 1 mongos proxy server, 3 config server, 2 shard(replica set herbiri  mongod server) toplam 10 server kurulumu yapmak gerekiyor. Veriler shardlar üzerinne config serverlarda bulunan ayarlara göre dağıtılır. Yani her hangi bir shard çöktüğünde verilen bütününe ulaşılamaz. Bu nedenle replica set kullanımı önerilir. Replica set 3 mongod instancedan oluşur. 1 primary, 2 secondary mongod belirlenir. Primaryde çıkan bir sorunda secondary devreye otomatik geçebilir. Başangıç projeleri için bu nedenle , shard kullanımı çok gerekli değilse   pek kullanışlı olmayabilir. Bu özellikler zaten yüksek trafiiğe sahip servisler için düşünülmüş bir yapıdır. Ayriyeten böyle bir alt yapı için çokça masraf ortaya çıkar.MongoDB'de diğer NoSQL veritabanları gibi ACID özelliklerini pek sağlamıyor. Bir server çökmesi sonucu veri kaybı yaşayabilirsiniz.Veriler diske yazılmadan hafızan bile çekilebilmesi performans açısından iyi olsa da kritik veriler için kötü sonuçlara sebep olabilir. Foursquare 2 yıl önce böyle bir durumla karşılaşmış ve 11 saat boyunca servis sağlayamamıştı.

4 Ocak 2013 Cuma

Crawler Sonuçlarım

Php ve MongoDB ikilisini denemek için yazdığım crawler uygulamasını deniyorum. Muhtemelen 4-5 saat sürekli çalıştı  ve çalışmaya devam ediyor. App Store için yazmıştım  bu uygulamayı. App Store için derken onu crawl etmek için yani. İçindeki linkleri ve uygulama bilgilerini parse ediyor ve MongoDB'ye kaydediyor.
Şuanda MongoDB yönetimi için MongoVue GUI yazılımını kullanıyorum ve çektiğim ürün bilgisi sayısını paylaşıyorum.

Şuandaki toplam ürün bilgisi 9221 olarak görülüyor. Bunun dışında ürün bilgisi çekilmeyenler le birlikte toplam 33000 den fazla kayıt bulunmakta. Ve artmaya devam ediyor. Ürün ile ilgili uygulama adı,üretici,resim  adresi,ücreti ve boyutu gibi özelliklerini de çekiyorum. Burda bu işlemi hızlı çalışmasını kısıtlayan faktör ne php parsing işlemleri nede veritabanına yazma ve kontrol işlemleri. Tamamen internet bağlantısı ve Appstore sistesinin yanıt hızıyla lakalı. İşlemci kullanımım%1-2 civarında olması bunu gösteriyor.

App Storeda toplam 700 000 den fazla uygulama varmış. Ben bütün veriyi çekmek istemiyorum aslında . 100 000 uygulama verisi çeksem yeter bana. Bu kadar uygulama verisi çeksem muhtemelen 200 000 den fazla ürün linkide çekmiş olurum. Eğer bir yerden sonra yeni uygulama linki bulma sıkıntısı yaşanmazsa.

Bende bu arada bu verilerle MongoDb de değişik denemeler yapmayı planlıyorum. Sorgulama diline daha hakim olmam gerekiyor. Map Reduce işlemleri nasıl işliyor tam olarak anlamam gerekiyor. Ayrıca çeşitli performance testleride yapabilirim. Ürünlerin bilgisini kullanarak belki ististiksel bilgiyede ulaşabilirim.

Crawler hakkında daha detaylı bilgi için http://www.murat-cakal.com/2013/01/03/php-crawler-programlama/ bakabilirsiniz.