En çok kullanılan NoSQL veri saklama ve erişme yöntemleri aşağıdaki gibi gösterilebilir :
NoSQL çözümleri kritik işlemlerde ve veri tutarlılığın çok önemli olduğu yerlerde tercih edilmemelidir. Bankacılık, sayın alma işlemleri vb.. örnek verilebilir
Üstelik SQL daha önceki alternatifleri doğrudan veritabanının her alanında rekabet etmiyorlar, başka bir konuda uzmanlaştıkları için sadece belli alanlarda kullanım alanı buluyorlardı. Ancak şu anda SQL'e gelen tehdit doğrudan SQL'i hedef alıyor ve oldukça düşmanca bir isme sahip : NoSQL. Yani SQL Yok!
SQL veritabanları verileri çabuk yazmak ve gerektiğinde sorgulamayla bulma mantığında çalışırlar. İndeksleme gibi çeşitli yöntemlerde sorgulama türü erişimlerin hızlandırılmaya çalışılır. Bir başka konu da verilerin tablolar halinde saklanmasıdır ve tablo demek her kayıtta aynı türde ve sayıda sütunlar olması demektir. Bazı sütunların boş bırakılması bu düz yapıyı değiştirmiyor. Bir tabloya bir alan eklenmesi oldukça sorunlu olabiliyor, çoğu kez veritabanın çevrimdışı bırakma zorunluluğu getiriyor.
LDAP (Lightweight Directory Access Protocol - Hafif Dizin Erişim Protokolü) verileri ağaç biçiminde tutuyor. Gerektiğinde ağacın yolu göstererek verilere ulaşılabiliyor. Bir şirket içinde bölümler, bölüm içinde çalışanlar, çalışanlar içinde adres bilgisi gibi bir veri gerçekten de bu sırada birbiri içerisinde bulunuyor. LDAP'ın en temel özelliği yazarken yazarken kolay erişilebilecek biçimde yazmak için yavaş çalışması ancak okurken tek seferde aramadan erişim yapması nedeniyle hızlı çalışması. LDAP doğrulama (authentication) ve yetkilendirme (authorization) alanında yaygın olarak kullanılıyor. Çünkü bir kişi bir alanda bir kere oluşturulur (yani bir kere yazılır), ancak şifresini değiştirmediği sürecek sadece o kişi için okuma yapılır. Bu da yazmada yavaş ama okumada hızlı olmasının bir yararı olarak erişimleri kolaylaştırır. Bir çok LDAP sunucu ön tarafta LDAP'la çalışırken verileri arka tarafta SQL ile tutabilmektedir. Ancak kullanıcı için görünen şey yine LDAP'tır. LDAP'ın bir özelliğinin de çalışma zamanında nesneler alanlar eklenebilmesi ve bunların tablolarda olduğu gibi her kayıt için geçerli olmayabilmesi. Bir çalışanda "arabasının plaka numarası" gibi bir bilgi eklendiğinde diğer çalışanlarda öyle bir sütun olmak durumunda değil. Bu da daha esnek bir şema yapısı oluşturuyor ve çalışma zamanında bir nitelik (bir sütun) eklemek çok kolay oluyor. Çünkü eski kayıtlar bundan etkilenmiyor.
SQL'in tablo yapısı belli tipte verileri yan yana tutulması anlamına geliyor. Örneğin çalışanlar bir tabloda adresler bir başka tabloda tutuluyor. Oysa önceleri web sayfaların içeriğini tutmak için düşünülmüş XML, birbiriyle ilişkili verileri bir arada tutuyor. Bunun anlamı verileri çeşitli tabloları birleştirmekle uğraşılmaması. Ancak bu yaklaşım veri erişiminde mantıklı olarak görülse de veri saklamakta pek başarılı olamadılar. O yüzden XML veri saklamaktan çok veri iletişiminde kullanılıyor. Bir SQL veritabanında bir konuyla ilgili veriler çeşitli tablolardan toplanarak bir belge oluşturuluyor ve gönderiliyor. Alıcı da aldığı belgeyi ayrıştırıyor ve gerekiyorsa yine SQL veritabanında çeşitli tablolara yerleştiriyor. SQL veritabanlarının hemen hepsi XML sorgularını destekliyor. Dolayısıyla XML SQL'e bir alternatif olmaktan çok onu tamamlayıcı bir teknoloji olarak ortaya çıkıyor. Elbette veritabanı dışında alanlarda XML kullanımının SQL'de hiç bir karışılığı yok. SQL ve XML kesişim kümesi olan iki ayrı bir küme gibi ortaya çıkıyor.
SQL'in tablo yapısının iki boyutlu olması nesneye yönelik programlamanın sınıf veya nesne denilen yapısını doğrudan uymuyor. C++, Java, C#, PHP gibi dillerde nesnelerle çalışan insanlar üç boyutu iki boyuta indirerek SQL veritabanına yazıyor. Gerektiğinde de iki boyutlu verileri toplayarak tekrar nesneler oluşturuyorlar. Nesneye yönelik programlama ciddi ve büyük projelerin neredeyse olmazsa olmaz durumunda olduğu için, bu 2B-3B yansıtma işlemi geliştirici tarafında fazladan geliştirme anlamına geliyor. Bunu önlemek için ORM (Object-Relation Mapping / Nesne-İlişkisel Eşleşme) adı verilen teknikler kullanılıyor. Java'da JPA veya C#.NET'te Entity Framework adı verilen bu teknikler geliştiriciyi bu zahmetten kurtarıyorlar. Hiç SQL yazmadan (sorgulamada bazen SQL'e benzeyen bazı diller yapmak durumunda kalsalar da) geliştirme yapılıyor. Ancak bu tür çözümlerde geliştirici SQL yazmasa da kullanılan çatı bunu yaptığı için SQL'e alternatif sayılmıyorlar.
Nesneleri doğrudan veritabanına yazıp okuyan sistemler de bulunmakta. Nesne Veritabanı (Object Database) adı verilen bu yapılar temel okuma ve yazma işlemelerini doğrudan yapıyorlar. Dahası iç içe verilerde kullanıcının yazarken ayrıştırması ve okurken birleştirmesi gibi işleme gerek duyulmuyor. Basit veri yapılarında daha yavaş olmalarına rağmen karmaşık verilerde nesne veritabanları çok hızlı çalışıyor. Belli alanlardaki açık üstünlüklerine rağmen nesne veritabanları çok fazla yaygın değil. Bunun bir kaç nedeni var. En önemlisi yapılarının karmaşık olması ve nesneye yönelik programlama yapmayanlar tarafından pek fazla anlaşılmaması. Ancak en önemli nedenin bilinmemesi nedeniyle çok fazla destek bulunmaması. SQL herkes tarafından bilinirken ODB'yi duymuş olanların sayısı bile oldukça az.
SQL'in on yıllar süren tahtının sallanmasının elbette belli nedenleri var. Bunlardan en önemlilerinden Büyük Veri (Big Data). Eskiyle karşılaştırılamayacak oranda veritabanları büyümektedir. Bir başka etmen, bazılarının "Büyük Kullanıcılar" (Big Data) da dediği kullanıcı sayısının artışı. NoSQL'i gerekli kılan nedenlerden biri de son zamanların en vızıltı sözcüğü "Bulut Bilişim" (Cloud Computing).
Daha önce veritabanları bir çeşit defter olarak düşünülüyordu. Dolayısıyla bilgisayarlara yazılan kayıtlar daha önce defterlere yazılan verilerden ibaretti. Raporlama gereksinimi de sadece defterde bir kayıt aramaktan ibaretti. "Yaz kızım kereviz" denince bir yazma, "Bilmem ne şirketinin dosyasını getir kızım" denince bir okuma yapmaktan ibaretti. Kurumsal yazılımlar ERP, HCM ve CRM gibi yazılımlarla yapılan her işin neredeyse kaydını tutar oldular. Ancak çalışan sayısı ne kadar büyük olursa olsun, işletmede yapılan işlem sayısı ne kadar çok olursa olsun bir kaç sunucu ile karşılanabilecek düzeydeydi. Kurumsal dünyada "ciddi" kayıtlar tutulurken şimdi bir kedi videosunun tekrar gönderim ve yorumlar nedeniyle milyonlarca kayıt üretebiliyor. Üstelik eskiden bir kere yaz gerekirse okursun gibi bir durum da yok. Her şey anında cereyan ediyor. Bir gecede bir uygulama milyonlar tarafından kullanılır hale gelebiliyor ve korkunç miktarda veri üretebiliyor.
Verideki büyüme kadar önemli bir konu da kullanıcı sayısındaki büyüme. İnternet'in kullanımının sürekli artışı ile ile artık veritabanına yazanlar "çalışanlar" değil "ziyaretçiler" oldular ve en basit bir site bile en büyük firmalardan daha fazla kullanıcıya sahip oldu. Yapılan araştırmalar küresel çevrim içi kullanıcı sayısını 2 milyara ulaştığını gösteriyor. Akıllı telefon kullanıcıların sayısı 1 milyar olarak kestiriliyor.
Uygulamaların hem kullanıcılardan hem de firmalardan uzakta, "bulutların arasında" olduğu uygulama modeline "Bulut Bilişim" (Cloud Computing) adı veriliyor. Daha önce her firma için ayrı uygulamalar, sunucular ve veritabanları varken bulut bilişim, bir çok firmanın verisini aynı veritabanında tutuyor. Firmaların gereksinimlerine göre veritabanlarını kullanıldırıyor ve ona göre onlara fatura kesiyor. Bu biçimde, önce bir kaç kullanıcı için çalışan bir uygulama binlerce kullanıcıya çok kolay ölçeklenebiliyor. Bir çok firmanın verilerinin aynı veritabanında tutulması, her firmanın verisinin birbirinden farklı olması SQL veritabanlarıyla çalışmayı biraz daha zorlaştırıyor.
SQL veritabanları, tasarım mantıkları gereği yapılı verilerle çalışıyorlar. Bir kayıt için hangi veriler tutulacaksa önceden belirleniyor ve veriler buna uygun toplanıyor. Bazı kayıtlarda bazı verilerin olmaması durumunda o sütün boş bırakılıyor. Çalışma zamanında bir sütun daha eklenmesi işlem başarımı açısından çeşitli sorunlara yol açabiliyor. Oysa İnternet'teki bir çok uygulamanın katı bir veri modeline ihtiyacı yok. Bir kayıtta olan alanlar diğerinde olmayabilir. SQL veritabanlarının bir başka özelliği de aynı türde verileri bir arada tutması, aynı konudaki verileri ayırması. Örneğin bir kişinin kendisi bir tabloda adresi başka tabloda olmak zorunda. Binlerce kez erişilse dahi SQL bunları iki ayrı tabloyu birleştirerek sorguluyor. Elbette gelişmiş veritabanı sunucular sık kullanılan veriler için başarım artırıcı önlemler alıyorlar. Ancak İnternet ortamında çok veri var ve bunlar aynı sıklıkta erişilmiyor. Çoğu bir kullanıcıya, bir belgeye veya bir hizmete ait belli bir ögeye ait özel veriler. Dolayısıyla bir öğeye ait verileri, ayrı türlerde dahi olsa bir arada tutulması önemli bir başarım sorunu oluşturuyor.
SQL veritabanları verinin büyüklüğünde veya erişimimdeki artışları yukarı ölçekleyerek yani donanımın gücünü artırarak çözüyorlar. Birden çok sunucuyla salkımlı (clustered) bir yapı olsa bile aynı veri sunuculara kopyalanıyor. Bunun nedeni bir verilerin birbiriyle çok "ilişkili" olması nedeniyle her sunucudaki veriye erişme ihtiyacının doğabilmesi. Internet'teki veri ne kadar güçlü olursa, çok çekirdekli işlemciler, katı durumlu diskler kullanılsa da bir sunucuya veya bir kaç sunucuya sığmıyor. Binlerce sunucuya dağıtılmış birbiriyle çok fazla ilişkili olmayan verilerde SQL sunucuların yaklaşımı yeterli veya gerekli olmuyor.
SQL veritabanlarının en büyük özellikleri yönetim zorluğudur. Veritabanı kullanan hemen her firmada bir veritabanı yöneticisi (DBA - Database Administrator) bulunmaktadır. Zira SQL sunucular karmaşık ve gelişmiş özellikleri bırakın sıradan bir bilgisayar uzmanını, veritabanı geliştiriciler için bile oldukça çetin bir iş. Çok sayıda ve karmaşık veriyi bir yere koymak, oldukça hantal bir yapının uzman kişilerce bakımını gerekli kılıyor.
SQL'in, daha doğrusu SQL diliyle çalışan İVTYS (RDBMS) yazılımlarının ortaya çıkartığı sıkıntıları giderdiğini iddia eden bir çok veritabanı ürünü var. Bunlar SQL'e alternatif olma iddiasındalar ve çok keskin bir ifadeyle Yok SQL (No SQL!) diyorlar. Peki nedir bu NoSQL? Aslında NoSQL bir ürün olmadığı gibi bir ürün türü de değil. SQL veritabanları az çok birbirine benzer özellikler sunarken NoSQL aslında SQL veritabanları dışında kalan her tür veritabanın ortak adı. NoSQL tanımına uyan ürünler arasında ortak bir yaklaşım yok.
NoSQL kendi arasında aşağıdaki öbeklere ayrılıyor :
Belge Veritabanlarını
Anahtar-Değer Depoları
Çizge Depoları
Geniş Sütun Depoları
Nesne Veritabanı
Bu tip veritabanları büyük ve karmaşık verilere bir anahtar atanması temeliyle çalışır. Bir belge veritabanına belli bir anahtarla konulur ve gerektiğinde bu anahtar verilerek veriye ulaşılır. Belge olarak XML ve JSON gibi biçimler gibi doğrudan ofis belgeleri de saklanabilmektedir.
Verileri bir anahtarla saklandığı ve gerektiğinde yine o anahtarla erişildiği veritabanlarına Anahtar-Değer (KV / Key-Value) deposu adı verilmektedir. Bu tür veritabanları içerdikleri bilginin yapısını, yani şemayı tutmazlar. Girilen verinin doğruluğu ve geçerliliği veritabanı değil onu kullanan uygulamaca sağlanır.
Ağ türü veriler için çizge (graph) türü veritabanları kullanılır. Bunlar nesneleri bir düğüm olarak tanımlar ve her düğüm arasında bir veya daha çok çizgi (yani ilişki) kurulur. Toplum Ağları (Sosyal Network) sitelerindeki veriler için birebir olan bu veritabanı türü, sıradan SQL sunucularda çok zor kurulabilecek bir ağ yapısının çok kolay gerçekleştirilmesine olanak tanıyor.
Verileri satır satır tutmak yerine büyük sütunlar halinde tutan veritabanı türlerine Sütun Veritabanı veya Geniş Sütun Veritabanı adı verilmektedir. Bu tür veritabanları, bir kayıttaki bir çok sütuna erişmek yerine bir sütundaki bütün değerlere erişilmesi durumunda çok yüksek başarımlar veri erişimi sağlayabilmektedirler.
Aslında NoSQL olarak ilk akla gelen veritabanı türü olmasa da Nesne Veritabanı (ODB - Object Database) da SQL kullanmadığı için NoSQL grubuna dahil edilmektedir. Bu tür veritabanları nesneyi tablolara parçalamadan, yani içindeki nesnelerler birlikte doğrudan depolama birimlerinde saklar ve gerektiğinde bir bütün olarak geri verir.
NoSQL ifadesi SQL yok anlamına geldiği halde bir çok NoSQL veritabanı SQL veya SQL benzeri bir diller sorgulama yapılmasında izin vermektedir. O yüzden de NoSQL'i 'No SQL' (SQL Yok) değil 'Not Only SQL' (Sadece SQL Değil') anlamına geldiğini belirtenler bulunmaktadır.