Son zamanların en moda hareketlerinden biri uygulamaların veri saklama kısmında NoSql kullanmak oldu. Yazılım dünyasının “sıcak konuları” vardır. Eğer popüler olmak istiyorsanız bu tür moda hareketleri yapmak zorunda hissedersiniz kendinizi. Scala/Lift kullanmak, JEE’yi karalamak, web arayüzlerini en son js frameworkleri ile gerçekleştirmek, ihtiyacı olmayan uygulamaları bile bulut bilişim üzerinde çalıştırmak şeklinde örnekler çoğaltılabilir. İşte bu örneklerden biri de veritabanı olarak ilişkisel veritabanlarını kötüleyip, NoSql olarak adlandırılan veri saklama yöntemlerine yönelmektir.
İlişkisel veritabanlarını kötülemeden önce, bu veritabanlarının gerçek hayatta nasıl kullanıldığına bir bakmak gerekmektedir. Bu veritabanlarının görevi, adı üzerinde, ilişkisel veriyi tutmak içindir. Peki yazılımlara bir bakarsanız bu veritabanlarında başka hangi veriler bulunmakta?
- uygulama oturum bilgisi (session)
- süreç durum bilgisi (workflow status)
- işletme kurallarının bir kısmı (business rules)
- kullanıcılar ya da uygulama instance’ları arası iletişim için
Siz elinizdeki çekiç ile vida kullanmaya kalkarsanız, ne vidaya ne de çekice suç atmaya hakkınız yoktur. Öncelikli sıkıntılardan biri yazılım mimarisinin yanlış tasarlanmasıdır. Bir veriyi tutmak için elimizde pek çok seçenek var
- cache ya da data grid
- süreç motorları (workflow engine)
- kural motorları (rules engine)
- mesaj kuyrukları (messaging queue)
- farklı NoSql çözümleri
- ilişkisel veritabanları
- dosya sistemleri (file systems)
Bu seçeneklerin bazıları arka tarafta gene ilişkisel veritabanı kullanabilirler, ama bu sizin asıl probleminiz olmamalıdır. Asıl problem, uygulamanızın çözüm sunduğu problem için en uygun mimariyi kullanmaktır. Bu sebeple elinizdeki mysql’i kaldırıp yerine mongodb koyup, sonra da performansın yerlerde nasıl süründüğünü izlemek çok da olağan dışı, rastlamadığımız bir olay değildir.
Öncelikli olarak elinizdeki araçlar hakkında bilgi sahip olmak gerekmektedir. Eğer dedikleri gibi siz bir balığı ağaca tırmanma yeteneğine göre değerlendiriyorsanız, başarısız olması kaçınılmazdır. Hiç bir moda uygulama tek başına her probleme çözüm değildir. Her aracın güçlü ve zayıf yönleri mutlaka vardır. MongoDB’mi iyi, Neo4j mi? Cassandra mı yoksa Oracle mı? Bu soruların aslında cevabı ne aradığınız ile ilgili ve belki de çözümünüz birden fazla araç kullanmanızı gerektirmektedir.
Nasıl mı? Basit bir karma örnek ile açıklayalım
- Redis: Hızlı okuma ve yazma ihtiyacınız var ancak veri kaybı çok da önemli değil, kullanıcı oturum bilgisini tutacaksınız örnek olarak
- MongoDB: Çok fazla okuma var ancak yazım kısmı az, ürün kataloğu ya da blog yazıları gibi
- Cassandra: Pek çok farklı noktada yüksek hacimli yazma işleminiz var, kullanıcı aktivite kayıtları gibi veya rfid takibi
- Neo4j: Nesneler (ya da node’lar) arası ilişkinin çok fazla olduğu durumlar varsa, sosyal medya uygulamaları gibi takip etme, beğenme gibi işlemler yapıyorsanız
- İlişkisel veritabanı: Bir raporlama aracı/framework’u kullanıyorsanız ya da muhasebe/finansal veri gibi ilişkisel veri saklama ihtiyacınız varsa
- Hadoop: Elinizde belli bir zaman kısıtı içerisinde işlenmesi gereken çok büyük (gerçekten çok büyük) veriniz var ve bu işleme işini dağıtacak çok sayıda makinanız var ise kullanabilirsiniz
Esas nokta, yukarıda ismi geçen uygulamaları tek bir yazılımın arkasında kullanabilirsiniz. Yani yazılımınız, yukarıdaki sistemleri en güçlü olduğu alanlarda kullanan bir orkestra şefi gibi çalışıp; veriyi olması gerektiği yerde olması gerektiği şekilde kullanmalıdır. Örnek olarak; Cassandra ile yapılacak bir işi, Neo4j ile yapmaya çalışmak, MongoDB kullandığınız sistemde arada memcache kullanmak gibi seçimlerde performans sorunlarına sebep olacağı için, ve dolayısıyla suçlu asla siz olamayacağınız için, kullandığınız araçların ne kadar başarısız oldukları sonucuna sizi götürecektir.
NoSql çözümleri gerçekten başarılı sonuçlar veren, çok güzel uygulamalar ancak bu ilişkisel veritabanlarını da tamamen beceriksiz yapmaz.
