• Twitter
  • Facebook
  • RSS

Archive for category: NoSQL

Fehmi Can Sağlam‘ın blog‘unda bahsettiği gibi Ankara’da NoSQL ile ilgilenenleri buluşturabileceğimiz ve tecrübelerimizi paylaşabileceğimiz bir ortam yaratmak için uğraşmaktaydık.  Ve sonunda gerçekleştirme imkanı bulduk.  Bu toplantılar için en çok kafa yoran Fehmi’ye çok teşekkür ediyorum.

4primes‘ın geliştirdiği 4biryanda uygulamasında Ankara NoSQL buluşmaları ile ilgili bilgi bulabilir ve kayıt olabilirsiniz :)
Herkesi bekliyoruz…

SPP42′nin desteklediği eventler içinse events duyurularımıza bakabilirsiniz…

 

SPP42′nin 10Gen ile yaptığı ortaklıktan sonra Türkiye’ye olan ilgisi oldukça arttı.  Kendilerine yaptığımız daveti de kırmayıp bizi ziyaret etmek için Türkiye’ye geliyorlar.   Bu sebeple 20 Kasım 2012 Salı günü Cyberplaza B Blok 1. Kat Dr. Fikret Yücel Konferans Salonu‘nda 1 günlük bir aktivitemiz olacak.

10Gen’den Tim Marston (Director, EMEA Channels),  Alvin Richards (EMEA Technical Director) ve Noberto Leite (Senior Solutions Architect for EMEA) bizimle beraber olacaklar.

Saat: 10:00 – 10:45 – Tim Marston 10Gen – MongoDB: Veri devrimini sürüklemek

MongoDB lider bir NoSQL teknolojisidir, ancak NoSQL neden sizi ilgilendirir?  Pek çok firma ve kurum için “Büyük Veri” problemi, verinin ne kadar büyük olduğu değil o veri ile ile ne yapmak istediğidir ve MongoDB ile bu potansiyelin nasıl açığa çıktığını görün. Bu sunumda MongoDB’nin anahtar özellikleri, müşteri örnekleri ve yeni iş modellerinin nasıl kolayca ve hızlıca geliştirilebileceği anlatılacaktır.

Saat 11:00 – 11:45 – Noberto Leite  10Gen – MongoDB’ye Giriş

Bu sunum veri tabanları ve NoSQL teknolojilerinin panoramayı nasıl değiştirdiği ile ilgili olacaktır.  MongoDB temelleri ve kullanım durumları anlatılacaktır.

Saat 13:30 – 14:15 – M. Emrah Özçelebi SPP42 – Dünyayı Yakalamak – NoSQL rüzgarı

Dünya’da kullanılan NoSQL uygulamaları ve Türkiye’deki fırsatlar

Saat 14:45 – 15:15 – Bülent Öztürk Nokta.com – Nokta.com’da MongoDB kullanımı

Nokta.com servislerinde MongoDB kullanımı

Katılım ücretsiz olup yerimiz sınırlı olduğu için lütfen sitemizden kayıt yaptırınız.

Gelin tanışalım…

5. yaşımızda SPP42 olarak NoSQL alanından pek çok atılımda bulunduk.  Önce 10Gen ile MongoDB partnerliği daha sonra da NeoTehnology ile Neo4j çözüm ortaklığı.  İki ürün de alanlarında lider ürünler olmakla beraber en önemli özellikleri kurumsal destek sunmalarıdır.  Ancak öyle bir ürün var ki, onu da yelpazemize katmadan NoSQL alanında komple bir çözüm sunuyoruz dememiz mümkün değildi.  Apache Hadoop kuşkusuz NoSQL ailesinin en meşhurlarından.  Biz de Hadoop için kurumsal destek veren ve de ürünler geliştiren Cloudera ile olan temaslarımız sonucunda Türkiye’deki çözüm ortağı olmaya karar verdik.

Artık Cloudera ürünlerine ve desteğine SPP42 üzerinden ulaşmak mümkün hale geldi.  Bu ortaklığın belki de en önemli sonuçlarından biri, artık NoSQL kullanımında doğru ürünü doğru şekilde konumlandırılmasında rehberlik edecek bilginin SPP42‘de olmasıdır.  MongoDB‘nin esnekliği, Neo4j‘in ilişkisel gücü ve Hadoop‘un dağıtık yapısı sayesinde en doğru çözümleri müşterilerimiz ile buluşturabileceğimize inanıyoruz.

Tekrar hatırlatalım :)

  • Büyük-veri ile çalışmaya başlamak için hayal gücüne sahip olmalısınız,
  • İyi sonuçlar almak için doğru araçları kullanmalısınız. *

Neo4J‘in üreticisi NeoTechnology ile bir süredir bazı ortak projeleri yürütmekteyiz.  Bu projeler sonucunda gelişen iletişim sayesinde Neo Technology, SPP42‘yi Türkiye’deki partneri olarak duyurmaya karar verdi.

Neo4J, NoSQL ailesindeki en ilginç veri tabanı tiplerinden biri olan Graph Database uygulamalarının en önde gelenlerindendir.  Veriye yaklaşımı ve modelleme şekli sebebi ile alışık olduğumuz veri tabanı yapısından çok farklı olmakla beraber, bu getirdiği yeni yaklaşım pek çok avantajı da yanında taşır.  Bu sayede veri tabanına çok daha değişik sorular sorulabilir.

SPP42 olarak Neo4J’i kullanıyoruz. Neo Technology’nin bilgi ve birikimi, SPP42′nin de yerel müşteri iletişimi sayesinde güzel projeler gerçekleştirebileceğimizi düşünüyoruz.  Bu partnerlik ile beraber SPP42 olarak Neo Technology eğitimlerini, lisanslarını ve danışmanlığını artık Türkiye içerisinde de Neo4J kullanan teknoloji severlere iletebileceğiz

Biz, SPP42 olarak, önerdiğimiz, eğitimini ve danışmanlığını verdiğimiz tüm ürünleri aynı zamanda da kendimiz için de kullanmaktayız. Bu sebeple Neo4J’in ne kadar özel bir ürün olduğunu çok rahatlıkla söyleyebiliriz.

Mutlaka deneyin :)

19 Ekim’de Özgür Web Günleri‘nde sizleri MongoDB ile Web Uygulamaları sunumumuza bekliyoruz.  Cuma günü saat 14′de 1. Salonda “MongoDB ve Web Uygulamaları” konusunu ben, “Graylog ile Web Uygulama Hata Kayıtlarının İzlenmesi” konusunu da Özgür Yazılım A.Ş.’den Doruk anlatacak.  İlgilenenleri bekleriz.

Cumartesi günü’de konferans alanında olacağım.  Sohbet ve kahve/çay için her zaman beklerim.  Bu arada MongoDB ile ilgilenenlerin Cumartesi günü “Countly Mobil Analiz Platformu” sunumunu da kaçırmamasını tavsiye ederim.

MongoDB‘de query performansından bahsederken, index kullanmanın ne kadar önemli olduğundan bahsetmiştim.  Geliştirme sürecinde bu indexlerin doğru tanımlanması, ileride çıkabilecek problemleri çok basit bir şekilde önceden önlenmesini sağlayacaktır.  Bu sepeble MongoDB‘nin aslında bize sunduğu güzel bir opsiyon bulunmakta.

Eğer bir sorgu, her hangi bir index tarafından karşılanmazsa, bütün veri baştan sona taranır.  Bu işleme tablescan adı verilmektedir.  Tablescan ise en yavaş veri tarama şeklidir.  Ancak sorgularınızın da tablescan yapıp yapmayacağını her zaman kontrol etmek mümkün olamayabilir.  Bu sebeple geliştirme ortamınızda kullanılan mongod instance‘sına parametre olarak “notablescan” verirseniz (./mongod –notablescan), bütün tablescan yapan sorgularınız hata verecektir.  Bu şekilde daha geliştirme esnasında hangi field‘lar üzerinde index olması gerektiğini rahatlıkla görebilirsiniz.

Dikkat edilmesi gereken nokta ise notablescan opsiyonu production sunucularında kesinlikle kullanılmamalıdır.  Production ortamında veritabanıza ulaşıp, bazı sorguları manuel çalıştırmak isteyebilirsiniz, ya da zaman kısıtı olmayan raporlama işlemlerini gerçekleştirmeniz gerekebilir veya bazı sorgularınızda indexler performansa zarar veriyor da olabilir.  notablescan” opsiyonu ile çalışan mongod instance’ları daha hızlı çalışır diye bir kural yoktur.  Burdaki amaç geliştirme esnasında, real time işlemlerde optimum performansı elde etmek için kullanılan sorguların mümkün olan en doğru indekslere yönlendirilmesini sağlamaktır.  Hatırlanması gereken bir nokta da, yanlış index kullanımı performansı negatif etkiler.

 

MongoDB’nin popüler olmasında beraberinde getirdiği query (sorgu) yetenekleri göz ardı edilemez kesinlikle.  Sadece map/reduce algoritmasına bağlı kalmayıp kendi sorgulama yönetmini uygulayan ve bu sorgulama sistemini SQL’e yaklaştıran MongoDB’nin popülerliğinin artması kaçınılmazdı.  Bir de buna ek olarak aggregate fonksiyonlarının yeni versiyona eklenmiş olması bu avantajı daha da ileri götürmek niyetinde olduklarının açık bir göstergesi. Peki MongoDB’de query yazmak bu kadar popüler ise, performansı nasıldır? Eğer bazı basit noktalara dikkat ederseniz oldukça hızlıdır.

  1. Index kullanın: Tıpkı ilişkisel veritabanlarında (rdbsm) olduğu gibi, MongoDB’de size collectionlar üzerinde indeks kullanmanıza izin verir ve bu indeksler tıpkı rdbms’lerde olduğu gibi sorgu performansını ciddi bir şekilde arttırır.  Bütün tabloyu taramak (tablescan) yerine BTree indeksleri çok çok hızlı olacaktır.
  2. Index kullanmayın: Bir önceki madde ile çelişen bir önerme oldu ama, aşırı index kullanımı da mongodb performansınızı negatif etkileyecektir.  Verilerinizi çoğaltmaktan ya da farklı yapılara tekrar yerleştirmekten çekinmemek gerekmekte.  Genel kural olarak bir indeks,collection içerisindeki verilerin yarısından fazlasının gelmesine sebep oluyorsa o indeksi kullanmanın pek de bir faydası yoktur.  Bir collection içerisindeki kullanıcıların cinsiyetini indekslemek size oldukça maliyetli olacaktır.  Uygulamanızın gerekliliklerini kontrol edip ona göre indeks kullanmakta fayda var.  Özellikle böyle geniş veriyi kapsayan bir indeks yaratmak yerine birden fazla alanı bileşik indekslemek çok daha faydalı ve verimli olacaktır.
  3. Doğru indeksleri kullanın: Bir önceki madde ile alakalı olarak, örneğin bütün alanlarınızı indekslemek performansı oldukça kötü etkileyecektir.  Bu sebeple sorgularınıza bakıp, gerekli indeksleri kullanmakta fayda vardır.
  4. Mantıksal operatörlerin sırasına dikkat edin: Özellikle dikkat edilmesi gereken kısım “and” operatörü ile bağlarken büyük setten, “or” ile bağlarken de küçük setten başlamaktır. Burdaki amaç “workingset” denilen üzerinde çalıştığımız veriyi minimumda tutmaktır.

Yukarıda bahsettiklerim tabi en genel performans konularıdır.  Daha dikkat edilmesi gereken pek çok parametre ve konu var performans arttırımı için.  Bu sebeple hem sorgularınızı, hem de MongoDB kurulumlarınızı önceden düzgün bir şekilde tasarlayıp, çalışma anında da izlemek çok önemlidir.

MongoDB kurulumlarında rastladığım bazı hataları burada paylaşmak istedim.  Lütfen bunları yapmayın:

  1. Paket yöneticisi üzerinden MongoDB kurmayın: Genelde paket yöneticisi ile gelen MongoDB sunucularının versiyonları oldukça eski.  En son çıkan MongoDB 2.2 versiyonu sitesinden indirip rahatlıkla kurabilirsiniz.  Özellikle 2.x serisi bir mongod kullanmaya özen gösterin.
  2.  Windows makina üzerine MongoDB kurmayın:  Her ne kadar 2.2 versiyonunda Windows Sunucular için pek çok özellik desteklese de siz yine de MongoDB’nizi paşa paşa Linux’unuza kurun.
  3. 32Bit makinaya kesinlikle gerçek uygulama MongoDB’si kurmayın.
  4. Tek instance MongoDB kurmayın:  MongoDB’nin gücü replicaset’lerden ve sharding’den gelmektedir.  Bu gücü kullanın.
  5. Ram’i düşük makinalara MongoDB kurmayın: İşlem yaptığınız veriniz (workingset) kadar makinanızda ram olmasına özen gösterin.

MongoDB, nosql fırtınasının yıldız çocuklarından biri olduğu aşikar. MongoDB’nin bu popülerliliğinin arkasında oldukça haklı sebepler bulunmaktadır. Ancak unutulmamalıdır ki, MongoDB de bir araçtır ve her araçta olduğu gibi, doğru yerde kullanılmalıdır.

Nedir?

Web sayfasından alıntı yapmak gerekirse

ölçeklenebilir, yüksek performanslı, açık kaynak NoSQL veritabanıdır.

Özellikleri arasında:

  • döküman tipi veri saklama
  • indeks kullanımı
  • yedekli çalışma ve yüksek erişilebilirlik
  • otomatik sharding
  • sorgulama
  • map/reduce
  • gridFS
  • ticari destek

MongoDB Temel Tasarımı

MongoDB’de, ilişkisel veritabanı yönetim sistemlerindeki (rdbsm) gibi “database” yaklaşımı vardır.  Yani, bir MongoDB kurulumunda sıfır ya da daha fazla database olabilir.  Bu database’ler içerisinde “collection” denilen ve bizim rdbsm’lerde kullandığımız tablo benzeri yapılar vardır.  Bu collection’lar ise içlerinde sıfır ya da daha fazla “document” barındırırlar. Bunları veritabanı tablomuzdaki satırlara benzetebiliriz.  Bu document’larda sıfır ya da daha fazla “field” bulundururlar.  “Field” ise veritabanındaki kolon tanımına benzetebiliriz.  Yani her “database” içerisinde “document” barındıran sıfır ya da daha fazla “collection” içerir.

Peki madem bizim bildiğimiz rdbsm’e bu kadar benziyor, neden yeni isimler icat edilmiş? Aslında tasarıma tekrar bakarsak çok ciddi bir farklılık göze çarpacaktır.  İlişkisel veritabanlarından kolon bilgisi tabloya ait iken MongDB’de ise “field” bilgisi “document” içerisindedir.  Bu sebeple “document” veritabanındaki satıra göre çok daha fazla bilgi tutabilir ve en önemlisi bir “collection” içerisindeki her “document” farklı “field” bilgilerine sahip olabilir.

{isim:”Emrah”, soyisim “Özçelebi}

{isim:”SPP42, ticariUnvan:”SPP42 Yazılım Geliştirme ve Danışmanlık Ltd. Şti”, url:”spp42.com”}

Yukarıdaki örneğe bakarsak, iki “document” da farklı “field” tanımlamalarına sahipler.  Bu, bir ilişkisel veritabanında bulamayacağımız bir esnekliktir.

MongoDB’yi Kimler Kullanır?

10Gen’in sayfasına bakacak olursak pek çok dev firma MongoDB’ye güvenmekte. Pek çok alanda başarılarını kanıtlamıştır.

  • yüksek hacim/içerikli problemler
  • analiz için veri saklanması
  • caching sistemleri
  • web içerik yönetim sistemleri
  • e-ticaret siteleri
  • web yorum/etiket saklama ve yönetme
  • MMORPG uygulamaları

Ancak önemli olan nokta, MongoDB’nin getirdiği özellikleri ve tasarım yaklaşımını kullanmak olmalıdır.  Bire bir şekilde rdbms üzerindeki veriyi taşımak doğru olan yol değildir.  Doğru kurgulanmış MongoDB çözümleri en optimum performansı almanızı sağlayacaktır.  Veriniz ister megabyte’lar boyunda olsun ister petabyte, MongoDB başarı ile hizmet verecektir.

10genmongoDBde de bu aralar ciddi bir yoğunluk bulunmakta. Hem Londra hem de New York ofislerine aldıkları yeni personelleri ve bizler gibi yeni iş ortakları sebebi ile ciddi yük altındalar. Yeni iş ortaklarının da bulunduğu sayfa ile bizimle ilgili sayfada güncellemeler oldu.  Artık 10gen’in resmi iş ortağı olduğumuz bilgisi kendi sayfalarından da duyurulmakta.

MongoDB, eğitim ve danışmanlık hizmetlerimiz ile ilgili bilgileri ise bizim sayfalarımızda bulabilirsiniz.