• sanirim mega holdings'in destekledigi, genellikle network marketing ile buyuyen database.
    insanlar mongodb icin library'ler yazar, tutoriallar yazar, birbirine tavsiye eder, olm cok efsane diye blog postlar yazar, seminerler verir, kelimeler kifayesiz falan kalir.
    ancak bu database'i basarili sekilde kullanan insanlarin sayisi azdir.
    yine de insanlar birbirlerine tavsiye ederler bunu, baskalari da kullansin isterler.
    ancak aksam yataklarina yattiklarinda bu belanin icinden nasil minimum zararla cikabileceklerini hesaplarlar.
    ve bunu asla baskalarinin yaninda dile getirmezler.
    bilmeyenin, yazmadan once okuyup ogrenmeye parasi/zamani veya hevesi olmayanin uzak durmasini tavsiye edecegim database.
    (bkz: yatirim tavsiyesi degildir)

    edit: penceresi cam cama muallim ne oldu bu kadar sinirlenicek diye sordu. pek atla deve bisey olmadi, abarttim biraz goz korkutmak icin. ama ona yazdigim seylere bakinca farkettim, sinirlenmisim mongo komunutesine.
    gercekten dikkat cekmek istedigim sey bilginin onemi. bu sadece mongodb icin degil, butun database uygulamalari icin gecerli. eger kullandiginiz database uygulamasiyla iyi gecinemiyorsaniz, nazlarindan cikolataya ihtiyaci oldugunu anlayamiyorsaniz, gunun sonunda bu da kulagima kupe olsun dediginiz problemler gotunuze giren kalin bir fitil seklinde oluyor.

    hikaye: mysql cocuguyuz o zamanlar, kol gibi bir tavsiye servisi gelistirmisiz, ekibimiz baska bir projeye heves edince unutulmus. unutuldugu 6 ay boyunca slow query logu bile basmadan calismis, milyonlarca tavsiye servis etmis bunlarin on kati kadar event process etmis falan. 6 ay sonunda durumu farkeden biz de scale bizden sorulur diye gotumuz tavan olmus dolasiyoruz. ve bir outsourcing macerasina atiliyoruz ayni ekiple.
    (simdi bahsettigim olaylar 2012 ortasi ile 2014 basi arasi gerceklesiyor) bu network marketingci dayilara kanmis outsource calistigimiz ekip, her yerde mongo cigirtkanligi yapiyorlar. mongodb gunlerine gidiyorlar, aaa tasaklarim cok guzel serinliyor mongo kullanirken diyerek havuz kenarinda margarita iciyolar, bosalirken mongo diye inliyorlar falan. biz de hehe guzel bisey galiba diyoruz tabi bilmiyoruz nasil bir illet oldugunu.
    uygulama da enteresandir, kitap yayincilarindan birkac terabaytlik xml dosyalari geliyor, bu data uzerinde zibillah islem yapip hangi publisherdan hangi kitap geldi hangi kitaptan birden cok var, hangi yazar hangi kitaplari yazmis lan bu iki yazarin ismi ayni ama galiba bunlar baska adamlar, lan bu kitaplar ayni da isbn'leri farkli aa bak burda bir index var, bu kitapta da var bu sanirim bunlar ayni tadinda calisan bir uygulama. kitaplari eslestirdikten ve standart bir formata cevirdikten sonra site datasini komple bastan generate ediyoruz. uzerine tavsiye/arama datasi falan olusturuyoruz. devamli yeni data geliyor tabi, bizim gelistirdigimiz uygulama da devamli daha akilli bir hale evriliyor. ama butun bunlar private beta'da oluyor.
    sonra private beta'dan cikalim karari geliyor ve maceramiz enteresan bir hal aliyor.
    bir gece ansizin yukarida yazdigim operasyonlarin bir kismi daha yavas calismaya basliyor. exponansiyel bir yavaslamadan bahsediyoruz ama
    2-3 kat degil 1 saatte calisan import isli 1 saatte isin 10'da birini falan yapamiyor. enteresandir ki tam da bizim yeni bir feature release'imize denk geliyor bu ve yazdigimiz seyin yavas olmasi ihtimali uzerinden 3 muhendis aval aval hintlisinden mitlisine 20 kisinin gelistirdigi projedeki butun degisiklikleri kontrol ediyoruz. abi nasil ya diye birbirimize bakiyoruz. 6 saat sonrasinda lan olm yoksa bu mongo gibi sacma bir cumle kuruyor ve mongonun map/reduce'un map kisminda yavas calistigini farkediyoruz. yani uygulamamiz diyor ki, bana "3 milyondan sonra 200bin kayit getir" mongo peki deyip arkasini donuyor. ve 10 threadin anlamsizca bekledigini farkediyoruz. bugun oturdugum yerden io waitlere baksaymisiz gorucekmisiz problemi diyebiliyorum. ama zor bir gunun sonrasinda, amerikada gun aydinlanmis, ceo chatte beyler ne zaman up olucak diye soruyor, o gerginlikle dogru yerkere bakamiyor.

    bu tabii bir ornek, bunun gibi uykusuz gecelerimiz problemli donemlerimiz cok oldu her seferinde devops ekibi olarak okudukca/arastirdikca insanlarin nasil benzer problemler yasadigini ve nasil workaroundlarla cozdugunu ogrenmistik, sonra bu workaroundlar da best practice olmustu. ama asla zamanla problemlerimiz azalmadi.

    isin can alici kismi, hangi database uygulamasi boyle degil ki? ama mongonun bizim canimizi sikan tarafi (sozum meclisten disari) herkesin mongodan bahsederken gotune badem takip konusmasi. sonra bir de mongo experlerinin capslock acip "ama buyuk updateler yaparken indexleri kaldirmazsan patlar bu dokumantasyonda var rtfm!1" veya "evet belli araliklarda optimize etmezsen tablolarini tabii ki zamanla patlar" demesi sinir bozucu.

    yani kimsenin ne kadar uber oldugunu soylemesine inanmayin, cok affedersiniz mongodb, cok daha yasli ve olgun onlarca alternatifinden daha problemli bir database uygulamasi. ayrica asla kimsenin bir documented bug'i bilmemek sizin hatanizmis gibi davranmasina izin vermeyin.

    tekrar edit: io waitlere bakinca cozemezmisiz bahsettigim problemi, muhtemelen baktik da. yaslaniyor muyum lan?
  • san francisco 14 konferansi sen sakrak gecmis no-sql veritabani. yaklasik 1000 kadar developer, architect, cto vs. ile duzenlenen konferansin ana basliklari wiredtiger and mms gelistirmeleri oldu. wiredtiger, 2.8 ile birlikte gelecek olan, write performansini cok ciddi sekilde arttiracak yeni bir pluggable storage engine. mongodb'nin "director of performance'inin gosterdigi benchmark'a bakilirsa, multi-thread uygulamalarda thread sayisi arttikca write performansi da neredeyse 2 katina cikiyor. wiredtiger, 2.8 ile default olarak gelmiyor ve dogrudan production sistemlerinde kullanilmasi onerilmiyor, lakin dusuk seviyeli bir node'da denenmesi de fena olmaz. dokuman bazinda locking onemli bir ozellik ve performans artisi getirmesi suphesiz.

    mms'e gelince, tek tusla tum cluster'i upgrade etmek icin can alici yenilikler gelecek.

    cok beklenen ozelliklerden bir tanesi olan c# async ve java async driver'lari da 3.0 ile birlikte gelecek. resmi aciklama olmasa da, dogrudan mongodb engineer'larindan gelen bilgi boyle. bu arada, scala icin hali hazirda bir async driver var. java developer iseniz, async driver ayricaligi, scala'yi da ogrenmek icin guzel bir neden olabilir. :)

    bu arada, mongodb'ye bebek muamelesi yapmaktan ve ozelliklerini bir rdbms ile karsilastirmaktan vazgecmekte fayda var. inner join desteklememesini handikap olarak gormek, mongodb'yi yanlis yerde kullandiginiza isarettir, haliyle sisteminizi yeniden gozden gecirmeniz gerekir. mongodb (veya diger onemli no-sql veritabanlari), inanilmaz yuksek hizlarda veri sunabilir ve terabyte'larca veri saklayabilir, bir sistemin performansi ve handikaplari, neyi, nerede ve nasil kullanacaginizi bilmenize bagli olarak gorecelidir.

    yeni baslayanlara birkac nacizane oneride bulunayim.

    1- 'schemaless' demek, allah ne verdiyse bir 'collection'a o veriyi yazmak demek degil. 'schemaless schema' diye bir tabir var, yani 'data structure'ina gore 'schema' nin belirlenmesinde fayda var. (embedded documents vs references etc..)

    2- sirf, sharding icin sharding'e bulasmayin. eger, veriniz memory'e sigiyorsa ellemeyin. sharding, performansi ciddi anlamda etkileyen bir yapilandirma.
    - sharding key icin dogru alanlari secin. _id alanini sharding icin kullanmayin (hotspot), kullanacaksaniz da hashed olarak kullanin.
    - sharding key icin bol kombinasyonlu bir alan kullanin.
    - sunu okuyun, iyice kavrayin: http://docs.mongodb.org/…torial/choose-a-shard-key/

    3- index'lerinizi dogru yapilandirin. write/read agirliklarinizi hesaplayarak, verinizin tipine gore dogru indeksleri secin. gordugum kadariyla, yeni baslayanlarin en buyuk sikintisi, dogru index stratejisini secememek. biraz okuyup arastirmakta fayda var.

    gerekli okuma: http://docs.mongodb.org/…core/indexes-introduction/

    4- capped collection'lari dikkatli kullanin.

    5- cogu zaman, 'embedded documents'tan uzak durun. mongodb'nin veriyi diske nasil yazdigi ve dokumani genisletmek icin neler yaptigini bilmek cok onemli. 'padding' problemine takildiginizda, uygulamanizin performansi yerlerde surunuyor olacaktir. mongodb'nin yeni surumleri, 'powerof2sizes' algoritmasini kullaniyor, yani veriniz bir sonraki 'powerof2' kadar yer kapliyor. buradaki amac, olasi dokuman genislemeleri icin ekstra padding birakmak lakin bu yaklasim bahsettigim soruna ancak bir yara bandi olabilir. embedded dokumanlari, log sistemleri, activity tracking sistemleri icin kullanmayin.

    6- transactional islemleriniz icin mongodb kullanmayin. mongodb, dokuman bazinda atomic islemleri desteklemesine ragmen, birden fazla dokuman soz konusu oldugunda acid compliant degil.

    7- https://www.mongodb.com/presentations adresindeki dokumanlara bir goz atin.

    not: ingilizce-turkce karisimi bir entry oldu, anlam karmasasi olmasin diye terimleri ingilizce biraktim. mongodb ile ilgili yardima ihtiyaciniz olursa da mesaj atin, cekinmeyin.
  • yaklaşık 2 yıldır çatır çatır production ortamında mesai saatleri içerisinde saniyede 500+ update/insert 200 read ile kullandığımız ve veri kaybı yaşamadığımız nosql veritabanı.
    dökümantasyonlarında, sunumlarında 50 puntoluk neon ışıkları ile transaction ve relation desteklemediğini ve performans kriterleri yüzünden desteklemeyeceğini belirtmesine rağmen hala bu konuda dırdır eden developerlar mevcuttur.

    replication çocuk oyuncağıdır fakat primary node'un seçilmesi için majority mantığı kullandığı için genelde 3, 5, 7 gibi tek sayıda replication setler oluşturmak daha uygundur. alternatifi için arbiter gibi çözümleri vardır.
    4 çeşitwrite concern seçeneği vardır. performans/veri güvenliği ihtiyacı doğrultusunda uygun olanı seçilmeli daha sonra vay efendim replicalardan birisi gitti veri kaybım oldu, yok efendim bu işler neden bu kadar yavaş diye şikayet edilmemelidir.
    primary node göçse bile journal tuttuğu için tekrar açıldığında auto recovery özelliği çalışır ve veri kaybı yaşanmaz bu senaryolarda. kendi eğitim sitesi üzerinden verilen sertifikasyon kurslarında bu senaryolar işlenir hatta.

    5 çeşit read preference modu vardır ki aslında 3 tane gibidir bunlar. hatta replica set üzerindeki nodelara tag tanımlayıp okuma işlemi bu tag ile özelleştirilebilir. örneğin bir operatörün cdrları 3 node üzerine senkron olarak yazılıyorken operasyon, marketing, mediation gibi ekiplere asenkron yazan node lar tanımlanabilir. bu sayede yazma performansında gecikme olmazken her ekip kendi için taglenmiş olan replica set elemanı üzerinden near time sonuçlarla çalışabilir.

    geleneksel rdbms veritabanlarından nosql veritabanlarına geçerken yaşanan en büyük sıkıntı ne transactionlar ne de veri kaybıdır. en büyük sıkıntı verinin nasıl tutulacağının belirlenmesidir. rdms paradigmasında veri yapısı nasıl saklanacağı düşünülerek tasarlanır*, nosql de ise nasıl kullanılacağı düşünülerek. bu yüzden rdms deki her satır için ayrı bir döküman yaratıp bir collection içerisinde 500 milyon+ document de oluşturabilirsiniz, array ve map kullanarak 700 bin document de yaratabilirsiniz. null, date, number, string, array ve map olmak üzere 6 çeşit veri tipi vardır.

    indexleri sadece b-tree olarak tutması ile çok fazla eleştiri almaktadır. bir diğer eleştirildiği nokta da memory üzerinde önce indexleri sonra verileri tutup bu yapıya kullanıcı tarafından müdahaleyi engellemesidir, bu senaryo için sharding çözümü önerilir ki split key düzgün belirlenmezse skıntı yaratabilir.

    diğer nosql veritabanlarına göre en büyük avantajı müthiş bir community desteği olmasıdır. dökümantasyonları güncel ve temiz yazılmıştır. evanjelistleri sürekli olarak dolaşır sunumlara katılır, insanları kullanması için cesaretlendirir ve destek veriri. türkiyede finans sektörüne girebilirlerse ofis açmak gibi niyetleri olduğunu belirtirler.
  • c++ ile geliştirilmiştir. storage olarak bson objelerini kullandığı için scalable'dır. uzun yıllar rdbms'lerle çalışmış biri olarak datanın kendisini array olarak atayabilince mutluluktan havalara uçtum desem yeridir. o kadar alışmışız ki sql'e, tuhaf geliyor böyle şeyler.
  • mongodb eğitimi için örneklerle hazırlanmış türkçe kaynak: https://oentegrasyon.github.io/trainingmongodb/
  • hsbc 60 ulkeye yayilmis, 65 farkli veritabani sisteminde calisan daginik sistemlerini, tek bir global mongodb altinda birlestirmeye karar vermis.

    https://diginomica-com.cdn.ampproject.org/…database
  • 1998'den beri oracle ile calisan ve uc sene once tum uygulamalari mongodb'ye geciren [> 100tb] bir sirkette calisiyorum.

    su ana dek hicbir problem yasamadik. siz ne yapiyor da yasiyorsunuz bilemiyorum.
  • replication'i tum slave'lerde degisiklik yapilmasini garanti edecek sekilde ayarlamak mumkundur. hatta, replication yapilmis slave sayisini [ornegin en az 3 slave'de replicate olsun, yeterli] seklinde ayarlamak da mumkundur. lakin bu islem yazma hizini dusurur [bu yuzden by default acik degildir, zira islemi bloklar]

    mongodb the definitive guide adli guzide eserimizden ilgili bolum soyle:

    "mongodb’s getlasterror command allows developers to enforce guarantees about how up-to-date replication is by using the optional "w" parameter. here we run a getlasterror that will block until at least n servers have replicated the last write operation:

    > db.runcommand({getlasterror: 1, w: n});

    if n is not present or is less than two, the command will return immediately. if n is two, the master won’t respond to the command until at least one slave has replicated the last operation. (the master itself is included toward n.) the master uses the "syncedto" information stored in local.slaves to track how up-to-date each slave is.

    when specifying "w", getlasterror takes an additional parameter, "wtimeout", which is a timeout in milliseconds. this allows the getlasterror to time out and return an error before the last operation has replicated to n servers. (by default the command has no timeout.)

    blocking for replication will cause write operations to slow down significantly, partic- ularly for large values of "w". in practice, setting "w" to two or three for important operations will yield a good combination of efficiency and safety."
  • uzun alan isimleri yerine kısaltma kullanılması kayıtların kapladığı yeri azaltmakla beraber yazılımcılar için kötü bir çözümdür.

    bazı kitaplar bunu önerse de birçok anlam kargaşasının sebebidir.
    yazılımcıya zalimliktir. proje büyüdükçe yazılımcılar içinden çıkılmaz kısaltmalar arasında bunalırlar.

    böyle bir tasarım yerine daha fazla shard kullanıp adam yük paylaştırılması. isimlerin uzun uzun yazılması daha şukela oluyor fikrinde/deneyimindeyim.

    halihazırda mongodb scale edilmek için yaratılmış bir sistemdir. workgroup büyümesin aman scale etmek durumunda kalmayalım fikri kötü bir fikirdir.

    ortaya çıkan json un okunabilir olması çok önemli.

    edit: iş bu entry uykusuzken yazılmış, daha sonra düzeltilecektir.
  • saniyorum ki hayatimda boyle bir database gormedim.* resmen dogru use case'de ihtiyaci tam karsilayacak bir urun, indexinden replication'una, her yonuyle for dummies tarzi scale eden bir sistem. yonetmek icin de system admin olmaniza falan gerek yok.

    mesela foursquare falan diyoruz hani nasil cat diye etrafinizdaki mekanlari getiriyor,

    db.venues.ensureindex({"location": "2d"}) // iste burda index'i yarattim
    sonra db.venues.find({"location": {"$near": {lat: 41, lon:29}}}) // iste burda da sorguyu yaptim.

    pat diye size spatial index yarativeriyor. ha tabi bu oracle'da, sql server'da yok mu; var, ama burda daha guzel gorunuyor. mapreduce syntaxi, group by syntaxi ilk basta biraz zor gelse de alisinca bal gibi.
hesabın var mı? giriş yap