NoSQL nedir? Bulut ölçeğinde bir gelecek için veritabanları

Bir uygulama geliştirirken yapılacak en temel seçimlerden biri, verileri depolamak için SQL veya NoSQL veritabanı kullanılıp kullanılmayacağıdır. Geleneksel SQL (yani ilişkisel) veritabanları, onlarca yıllık teknoloji evriminin, iyi uygulamanın ve gerçek dünya stres testinin ürünüdür. İş alanı uygulamalarının temelini oluşturan güvenilir işlemler ve geçici sorgular için tasarlanmıştır. Ancak, diğer türden uygulamalar için onları daha az uygun hale getiren katı şema gibi kısıtlamalarla da yüklenirler.

NoSQL veritabanları bu sınırlamalara yanıt olarak ortaya çıktı. NoSQL sistemleri, geliştiriciler tarafında yüksek operasyonel hız ve büyük esneklik sağlayan şekillerde verileri depolar ve yönetir. Birçoğu, büyük web siteleri için içerik depolamanın veya verileri işlemenin daha iyi yollarını arayan Google, Amazon, Yahoo ve Facebook gibi şirketler tarafından geliştirildi. SQL veritabanlarından farklı olarak, birçok NoSQL veritabanı, yüzlerce veya binlerce sunucuda yatay olarak ölçeklenebilir.

Yine de NoSQL'in avantajlarının bir bedeli yoktur. NoSQL sistemleri genellikle SQL veritabanları ile aynı düzeyde veri tutarlılığı sağlamaz. Aslında, SQL veritabanları güvenilir işlemlerin arkasındaki ACID özellikleri için geleneksel olarak performans ve ölçeklenebilirlikten ödün verirken, NoSQL veritabanları hız ve ölçeklenebilirlik için bu ACID garantilerinden büyük ölçüde vazgeçmiştir.

Kısacası, SQL ve NoSQL veritabanları farklı ödünleşimler sunar. Belirli bir proje bağlamında rekabet edebilirler - bu uygulama veya o uygulama için hangisini seçecekleri gibi - daha büyük resimde tamamlayıcıdırlar. Her biri farklı kullanım durumlarına uygundur. Karar, ya / ya da iş için hangi aracın doğru olduğu sorusuyla ilgili bir durum değildir.

NoSQL ve SQL

SQL ve NoSQL arasındaki temel fark o kadar da karmaşık değil. Her birinin, verilerin nasıl depolanması ve geri alınması gerektiği konusunda farklı bir felsefesi vardır.

SQL veritabanları ile tüm veriler doğal bir yapıya sahiptir. Microsoft SQL Server, MySQL veya Oracle Database gibi geleneksel bir veritabanı bir şema kullanır - veritabanına eklenen verilerin nasıl oluşturulacağına dair resmi bir tanım. Örneğin, bir tablodaki belirli bir sütun yalnızca tamsayılarla sınırlı olabilir. Sonuç olarak, sütuna kaydedilen veriler yüksek derecede normalleşmeye sahip olacaktır. Bir SQL veritabanının katı şeması, örneğin JOIN'ler yoluyla veriler üzerinde toplamaların gerçekleştirilmesini nispeten kolaylaştırır.

NoSQL ile veriler, şemasız veya serbest formda depolanabilir. Herhangi bir veri herhangi bir kayıtta saklanabilir. NoSQL veritabanları arasında, verileri depolamak için dört yaygın NoSQL sistemi türüne yol açan dört ortak model bulacaksınız:

  1. Belge veritabanları (örneğin CouchDB, MongoDB). Eklenen veriler, verilerin tam sayılardan dizelere ve serbest biçimli metne kadar her şey olabileceği serbest biçimli JSON yapıları veya "belgeler" biçiminde depolanır. Varsa, bir belgenin hangi alanları içereceğini belirtmeye doğal olarak gerek yoktur.
  2. Anahtar-değer depoları (ör. Redis, Riak). Basit tam sayılardan veya dizelerden karmaşık JSON belgelerine kadar serbest biçimli değerlere, veritabanında anahtarlar aracılığıyla erişilir.
  3. Geniş sütun depoları (örn. HBase, Cassandra). Veriler, geleneksel bir SQL sisteminde olduğu gibi satırlar yerine sütunlarda saklanır. Herhangi bir sayıda sütun (ve dolayısıyla birçok farklı veri türü), sorgular veya veri görünümleri için gerektiği şekilde gruplandırılabilir veya toplanabilir.
  4. Grafik veritabanları (örneğin Neo4j). Veriler, bir ağ veya varlık grafiği ve grafikteki her düğümle serbest biçimli bir veri parçası olarak temsil edilir.

Şemasız veri depolama, aşağıdaki senaryolarda kullanışlıdır:

  1. Verilere hızlı erişim istiyorsunuz ve güvenilir işlemler veya tutarlılıktan çok erişimin hızı ve basitliği ile ilgileniyorsunuz.
  2. Büyük miktarda veri depoluyorsunuz ve kendinizi bir şemaya kilitlemek istemezsiniz çünkü daha sonra şemayı değiştirmek yavaş ve zahmetli olabilir.
  3. Yapılandırılmamış verileri, onu üreten bir veya daha fazla kaynaktan alıyorsunuz ve maksimum esneklik için verileri orijinal biçiminde tutmak istiyorsunuz.
  4. Verileri hiyerarşik bir yapıda depolamak istiyorsunuz, ancak bu hiyerarşilerin harici bir şema tarafından değil, verilerin kendisi tarafından tanımlanmasını istiyorsunuz. NoSQL, SQL veritabanlarının taklit etmesi için daha karmaşık yollarla verilerin gelişigüzel kendi kendine referans vermesine izin verir.

NoSQL veritabanlarını sorgulama

Geleneksel veritabanları tarafından kullanılan Yapılandırılmış Sorgu Dili, verileri depolarken ve alırken sunucu ile iletişim için tek tip bir yol sağlar. SQL sözdizimi yüksek oranda standartlaştırılmıştır, bu nedenle bireysel veritabanları belirli işlemleri farklı şekilde gerçekleştirebilir (örneğin, pencere işlevleri), temel bilgiler aynı kalır.

Buna karşılık, her NoSQL veritabanı, verileri sorgulamak ve yönetmek için kendi sözdizimine sahip olma eğilimindedir. Örneğin CouchDB, veritabanından belge oluşturmak veya almak için HTTP aracılığıyla gönderilen JSON biçimindeki istekleri kullanır. MongoDB, JSON nesnelerini bir komut satırı arabirimi veya bir dil kitaplığı yoluyla ikili protokol üzerinden gönderir.

Bazı NoSQL ürünleri , verilerle çalışmak için SQL benzeri sözdizimini kullanabilir, ancak yalnızca sınırlı ölçüde. Örneğin, bir sütun deposu veritabanı olan Apache Cassandra'nın kendi SQL benzeri dili, Cassandra Sorgu Dili veya CQL'i vardır. CQL sözdiziminin bir kısmı, SELECT veya INSERT anahtar sözcükleri gibi, doğrudan SQL oyun kitabından çıkarılmıştır. Ancak Cassandra'da bir JOIN veya alt sorgu gerçekleştirmenin bir yolu yoktur ve bu nedenle ilgili anahtar kelimeler CQL'de mevcut değildir.

Hiçbir şey paylaşılmayan mimari

NoSQL sistemlerinde ortak olan bir tasarım seçeneği "paylaşılmayan" bir mimaridir. Hiçbir şey paylaşılmayan tasarımda, kümedeki her sunucu düğümü diğer tüm düğümlerden bağımsız olarak çalışır. Sistemin, bir veri parçasını istemciye döndürmek için her bir düğümden fikir birliği alması gerekmez. Sorgular hızlıdır çünkü en yakın veya en uygun olan düğümden döndürülebilirler.

Hiçbir şeyin paylaşılmamasının bir başka avantajı da esneklik ve ölçeklendirmedir. Kümenin ölçeğini genişletmek, kümedeki yeni düğümleri döndürmek ve diğerleriyle senkronize olmalarını beklemek kadar kolaydır. Bir NoSQL düğümü arızalanırsa, kümedeki diğer sunucular birlikte chug yapmaya devam edecektir. İsteklere hizmet etmek için daha az düğüm bulunsa bile tüm veriler kullanılabilir durumda kalır.

Hiçbir şey paylaşılmayan tasarımın NoSQL veritabanlarına özel olmadığını unutmayın . Birçok geleneksel SQL sistemi, hiçbir şey paylaşılmadan kurulabilir, ancak bu genellikle performans için küme genelinde tutarlılıktan ödün verilmesini içerir.

NoSQL sınırlamaları

NoSQL bu kadar çok özgürlük ve esneklik sağlıyorsa, neden SQL'i tamamen terk etmiyorsunuz? Basit cevap: Birçok uygulama hala SQL veritabanlarının sağladığı kısıtlama, tutarlılık ve koruma türlerini gerektirir. Bu durumlarda, NoSQL'in bazı "avantajları" dezavantajlara dönüşebilir. Diğer sınırlamalar, NoSQL sistemlerinin nispeten yeni olmasından kaynaklanmaktadır. 

Şema yok

Serbest biçimli verileri alıyor olsanız bile, onu kullanışlı hale getirmek için neredeyse her zaman kısıtlamalar getirmeniz gerekir. NoSQL ile kısıtlamalar getirmek, sorumluluğu veritabanından uygulama geliştiricisine kaydırmayı içerir. Örneğin, geliştirici bir nesne ilişkisel haritalama sistemi veya ORM aracılığıyla yapıyı empoze edebilir. Ancak şemanın verilerin kendisiyle yaşamasını istiyorsanız , NoSQL genellikle bunu yapmaz.

Bazı NoSQL çözümleri, veriler için isteğe bağlı veri tipleme ve doğrulama mekanizmaları sağlar. Örneğin Apache Cassandra, geleneksel SQL'de bulunanları hatırlatan çok sayıda yerel veri türüne sahiptir.

Nihai tutarlılık

NoSQL sistemleri, daha iyi kullanılabilirlik ve performans için güçlü veya anında tutarlılık sağlar. Geleneksel veritabanları, işlemlerin atomik (bir işlemin tüm bölümleri başarılı olur veya hiçbiri yapmaz), tutarlı (tüm kullanıcılar aynı veri görüşüne sahiptir), izole (işlemler rekabet etmez) ve dayanıklı (tamamlandıktan sonra hayatta kalacaktır bir sunucu hatası).

Toplu olarak ACID olarak adlandırılan bu dört özellik, çoğu NoSQL sisteminde farklı şekilde ele alınır. Küme genelinde anında tutarlılık yerine, güncellemeleri kümedeki diğer düğümlere kopyalamak için gereken süre nedeniyle nihai tutarlılığa sahip olursunuz . Kümeye eklenen veriler nihayetinde her yerde bulunur, ancak ne zaman olacağını garanti edemezsiniz.

Bir SQL sisteminde bir işlemdeki tüm adımların (örneğin, bir satışın yürütülmesi ve envanterin azaltılması) tamamlandığını veya geri alındığını garanti eden işlem semantiği, genellikle NoSQL'de mevcut değildir. Banka gibi "tek bir doğruluk kaynağı" olması gereken herhangi bir sistem için, NoSQL yaklaşımı iyi çalışmayacaktır. Gittiğiniz ATM'ye bağlı olarak banka bakiyenizin farklı olmasını istemezsiniz; her yerde aynı şekilde raporlanmasını istiyorsunuz.

Bazı NoSQL veritabanları, bunun etrafında çalışmak için kısmi mekanizmalara sahiptir. Örneğin, MongoDB, tek tek işlemler için tutarlılık garantilerine sahiptir, ancak bir bütün olarak veritabanı için değildir. Microsoft Azure CosmosDB, kullanım durumunuza uygun davranışı seçebilmeniz için istek başına bir tutarlılık düzeyi seçmenize olanak tanır. Ancak NoSQL ile, varsayılan davranış olarak nihai tutarlılığı bekleyin.

NoSQL kilidi

Çoğu NoSQL sistemi kavramsal olarak benzerdir, ancak çok farklı şekilde uygulanır . Her biri, verilerin nasıl sorgulandığı ve yönetildiğine ilişkin kendi metaforlarına ve mekanizmalarına sahip olma eğilimindedir.

Bunun bir yan etkisi, uygulama mantığı ve veritabanı arasında potansiyel olarak yüksek derecede bir bağlantıdır. Bir NoSQL sistemi seçip ona bağlı kalırsanız bu o kadar da kötü değil, ancak sistemleri yolda değiştirirseniz tökezleyen bir engel olabilir.

Örneğin MongoDB'den CouchDB'ye (veya tam tersi) geçiş yapıyorsanız, verileri taşımaktan daha fazlasını yapmalısınız. Ayrıca veri erişimi ve programlı metaforlardaki farklılıklarda da gezinmelisiniz - başka bir deyişle, uygulamanızın veritabanına erişen bölümlerini yeniden yazmalısınız.

NoSQL becerileri

NoSQL'in bir başka dezavantajı, göreceli uzmanlık eksikliğidir. Geleneksel SQL yeteneği pazarının hala oldukça büyük olduğu yerlerde, NoSQL becerileri için pazar yeni doğmaktadır.

Referans olarak Indeed.com, 2017 sonu itibariyle geleneksel SQL veritabanları (MySQL, Microsoft SQL Server, Oracle Veritabanı vb.) İçin iş listelerinin hacminin son üç yılda iş hacminden daha yüksek olduğunu bildirdi. MongoDB, Couchbase ve Cassandra için. NoSQL uzmanlığına olan talep artıyor, ancak yine de geleneksel SQL için pazarın bir parçası.

SQL ve NoSQL'i Birleştirme

SQL ve NoSQL sistemleri arasındaki bazı farklılıkların zamanla ortadan kalkmasını bekleyebiliriz. Zaten birçok SQL veritabanı artık JSON belgelerini yerel bir veri türü olarak kabul ediyor ve bu verilerle ilgili sorgular gerçekleştirebilir. Hatta bazılarının JSON verilerine kısıtlamalar getirmenin yerel yolları vardır, böylece bunlar geleneksel satır ve sütun verileriyle aynı titizlikle işlenir.

Diğer taraftan, NoSQL veritabanları yalnızca SQL benzeri sorgu dilleri değil, geleneksel SQL veritabanlarının diğer yeteneklerini de eklemektedir. Örneğin, en az iki belge veritabanı - MarkLogic ve RavenDB - ACID uyumlu olmayı vaat ediyor.

Burada ve gelecek nesil veri tabanlarının paradigmaları aşacağına ve hem NoSQL hem de SQL işlevselliği sunacağına dair işaretler var. Örneğin Microsoft'un Azure Cosmos DB'si, her iki sistem türünün davranışlarını birbirinin yerine yeniden üretmek için kaputun altında bir dizi ilkel kullanır. Google Cloud Spanner, güçlü tutarlılığı NoSQL sistemlerinin yatay ölçeklenebilirliğiyle birleştiren bir SQL veritabanıdır.

Yine de, saf SQL ve saf NoSQL sistemleri yıllarca yerini alacak. Serbest biçimli verilere hızlı, yüksek düzeyde ölçeklenebilir erişim için NoSQL'e bakın. Bu, okumaların tutarlılığı ve SQL veritabanlarında ortak olan diğer güvenlik önlemleri gibi birkaç maliyetle birlikte gelir. Ancak birçok uygulama için, bu güvenlik önlemleri NoSQL'in sunduğu şeyler için ticarete değer olabilir.