NoSQL ile ilişkisel veritabanları arasındaki farkları anlama

  • Makale
  • Okumak için 6 dakika

Uygulama hedefı: MongoDB için SQL API Cassandra API gremlin API tablo API'si Azure Cosmos DB API 'si

Bu makalede NoSQL veritabanlarının ilişkisel veritabanlarına göre bazı temel avantajları numaralanmıştır. NoSQL ile çalışırken karşılaştığınız zorluklardan bazıları da ele aacağız. Var olan farklı veri depolarına ayrıntılı bir bakış için doğru veri depolarını seçme makalemize göz atabilirsiniz.

Yüksek aktarım hızı

İlişkisel veritabanı sisteminin bakımının en belirgin zorluklarından biri, çoğu ilişkisel altyapının katı ACID semantiği uygulamak için kilitler ve kilitler uygulamasıdır. Bu yaklaşımın, veritabanında tutarlı bir veri durumu sağlama açısından avantajları vardır. Ancak eşzamanlılık, gecikme süresi ve kullanılabilirlik ile ilgili önemli bir sorun vardır. Bu temel mimari kısıtlamalar nedeniyle, yüksek işlem hacimleri verileri el ile parçalama ihtiyacıyla sonuçlandırılabilir. El ile parçalama uygulamak zaman alan ve zor bir alıştırma olabilir.

Bu senaryolarda, dağıtılmış veritabanları daha ölçeklenebilir bir çözüm sunabilirsiniz. Ancak bakım yine de maliyetli ve zaman alan bir alıştırma olabilir. Sistemin dağıtılmış doğasının saydam olduğundan emin olmak için yöneticilerin ek çalışmalar yapmaları gerekir. Ayrıca veritabanının "bağlantısı kesilmiş" yapısına da sahip olması gerekir.

Azure Cosmos DB, tüm Azure bölgelerine dağıtarak bu zorlukları basitleştiriyor. Bölüm aralıkları, aynı anda yüksek kullanılabilirliği korurken veritabanını uygulamayla uyumlu bir şekilde sorunsuz bir şekilde büyütecek şekilde dinamik olarak alt bölümlere ayrılmış olabilir. Çok katmanlı ve sıkı denetimli, buluta yerel kaynak idaresi, şaşırtıcı gecikme süresi garantileri ve tahmin edilebilir performans sağlar. Bölümleme tam olarak yönetilir, bu nedenle yöneticilerin kod yazması veya bölümleri yönetmesi gerek değildir.

İşlem birimleriniz saniye başına binlerce işlem gibi aşırı düzeylere ulaşıyorsa, dağıtılmış bir NoSQL veritabanını göz önünde bulundurabilirsiniz. Maksimum verimlilik Cosmos bakım kolaylığı ve daha az toplam sahip olma maliyeti için Azure veritabanı veritabanı'nın kullanımına göz önünde bulundurabilirsiniz.

Backend

Hiyerarşik veriler

Veritabanındaki işlemlerin çok sayıda üst-alt ilişkisi içerenin önemli sayıda kullanım örnekleri vardır. Bu ilişkiler zaman içinde önemli ölçüde artabilir ve yönetimi zor olabilir. Hiyerarşik veritabanlarının formları 1980'lerde ortaya çıktı, ancak depolama verimsellik nedeniyle popüler değildi. Ayrıca Ted Codd'un ilişkisel modeli neredeyse tüm temel veritabanı yönetim sistemleri tarafından kullanılan gerçek standart haline geldi.

Ancak, günümüzde belge stili veritabanlarının popülerliği önemli ölçüde artmıştır. Bu veritabanları, artık verileri diskte depolamanın maliyetiyle ilgili endişeler nedeniyle onaylanmamış hiyerarşik veritabanı paradigmasını yeniden oluşturmak olarak düşünülebilir. Sonuç olarak, ilişkisel veritabanında birçok karmaşık üst-alt varlık ilişkisinin korunması artık modern belge odaklı yaklaşımlara kıyasla bir anti-desen olarak kabul edilir.

Nesne odaklı tasarımınortaya çıkması ve onu ilişkisel modellerle birleştirerek ortaya çıkan empedans yanlışlığı, belirli kullanım örnekleri için ilişkisel veritabanlarında bir anti-desen vurgular. Bunun sonucunda gizli ancak genellikle önemli bakım maliyetleri ortaya çıkabilir. ORM yaklaşımları bunu kısmen azaltmak için gelişmiş olsa da, belge odaklı veritabanları nesne odaklı yaklaşımlarla çok daha iyi bir şekilde birleşti. Bu yaklaşımda geliştiriciler, ORM sürücülerine veya dile özgü OO Veritabanı altyapılarını taahhüt etmek zorunda değildir. Verileriniz birçok üst-alt ilişki ve hiyerarşinin derin düzeyleri içeriyorsa, Azure Cosmos DB veritabanı veritabanı api'si gibi bir NoSQL belge veritabanı SQL düşünebilirsiniz.

Orderdetails

Karmaşık ağlar ve ilişkiler

İroni olarak, adlarıyla ilişkisel veritabanları derin ve karmaşık ilişkileri modellemek için en uygun çözümü sunar. Bunun nedeni varlıklar arasındaki ilişkilerin ilişkisel bir veritabanında mevcut olmadığını gösterir. Sorguları kullanarak eşlemeye izin vermek için kartesyen birleşimleri gerektiren karmaşık ilişkilerle bunların çalışma zamanında hesaplaması gerekir. Sonuç olarak, ilişkiler artarak işlemler hesaplama açısından üstel olarak daha pahalı hale gelir. Bazı durumlarda bu tür varlıkları yönetmeye çalışan ilişkisel bir veritabanı kullanılamaz hale gelecektir.

İlişkisel veritabanlarının ortaya çıkması sırasında "Ağ" veritabanlarının çeşitli biçimleri ortaya çıkmıştır, ancak hiyerarşik veritabanlarında olduğu gibi bu sistemler de popülerliği kazanmakta zorlandı. Yavaş benimsemenin nedeni o anda kullanım örnekleri olmaması ve depolama verimsizlikleridir. Günümüzde graf veritabanı altyapıları, ağ veritabanı paradigmasını yeniden ortaya çıkması olarak değerlendirebilir. Bu sistemlerin en önemli avantajı, ilişkilerin veritabanında "birinci sınıf vatandaşlar" olarak depolanmış olduğudur. Bu nedenle, her yeni birleşim veya çapraz ürünle zaman karmaşıklığını artırmak yerine, ilişkiler arasında geçiş sabit zamanda yapılabilir.

Veritabanınız içinde karmaşık bir ilişki ağı yönetiyorsanız, bu verileri yönetmek için Azure Cosmos DB Gremlin API'si gibi bir grafik veritabanı düşünebilirsiniz.

Veritabanı diyagramı, birkaç çalışan ve departmanların birbirine bağlı olduğunu gösterir.

Azure Cosmos DB, tüm önemli NoSQL model türleri için API projeksiyonu sunan çok modelli bir veritabanı hizmetidir; Sütun ailesi, Belge, Graph ve Anahtar-Değer. Gremlin (grafik) ve SQL (Çekirdek) Belge API'si katmanları tamamen birlikte çalışabilir. Bunun programlanabilirlik düzeyinde farklı modeller arasında geçiş yapmak için avantajları vardır. Graph, hem karmaşık ağ geçişleri hem de aynı depoda belge kayıtları olarak modellenmiş işlemler açısından sorgu olabilir.

Fluid şeması

İlişkisel veritabanlarının bir diğer özelliği de şemaların tasarım zamanında tanımlanmalıdır. Bunun, bilgi tutarlılığı ve veri uyumluluğu açısından avantajları vardır. Ancak uygulama büyüdükçe kısıtlayıcı da olabilir. Aynı tabloyu veya veritabanı tanımını paylaşan mantıksal olarak ayrı modellerde şemadaki değişikliklere yanıt verme zaman içinde karmaşık hale geldi. Bu tür kullanım örnekleri genellikle şemanın kayıt başına yönetecek şekilde uygulamaya kadar çözülmemiş olmasından yarar sağlar. Bunun için veritabanının "şemadan bağımsız" olması ve kayıtların içinde yer alan veriler açısından "kendi kendini açıklayan" olmasına izin vermesi gerekir.

Yapıları sürekli yüksek oranda değişen verileri yönetiyorsanız, özellikle de işlemler veritabanı genelinde uyumluluk sağlamakta zorlanan dış kaynaklardan geliyorsa, Azure Cosmos DB gibi yönetilen bir NoSQL veritabanı hizmeti kullanarak daha şemadan bağımsız bir yaklaşım kullanmayı düşünebilirsiniz.

Mikro hizmetler

Mikro hizmet düzeni son yıllarda önemli ölçüde artmıştır. Bu düzenin kökleri Hizmet Odaklı Mimariye sahiptir. Bu modern mikro hizmet mimarilerinin veri iletimi için standart olan JSON,belge odaklı NoSQL Veritabanlarının büyük çoğunluğu için de depolama ortamıdır. Bu, NoSQL belgesinin karmaşık Mikro Hizmet uygulamaları genelinde hem kalıcılık hem de eşitleme (olay kaynak oluşturma düzenlerini kullanarak)için çok daha sorunsuz bir uyum sağlar. Daha geleneksel ilişkisel veritabanlarının bu mimarilerde korunması çok daha karmaşık olabilir. Bunun nedeni, api'ler arasında hem durum hem de eşitleme için gereken dönüşüm miktarının daha fazla olmasıdır. Azure Cosmos DB'nin özellikle çok sayıda NoSQL veritabanından daha çok JSON tabanlı Mikro Hizmet Mimarileri için daha sorunsuz bir uyum sağlayan bir dizi özelliği vardır:

  • saf JSON veri türleri seçimi
  • veritabanında yerleşik bir JavaScript altyapısı ve sorgu API'si.
  • bir kapsayıcıda yapılan değişikliklerden haberdar olmak için istemcilerin abone olduğu son teknoloji bir değişiklik akışı.

NoSQL veritabanlarıyla ilgili bazı zorluklar

NoSQL veritabanlarını uygulamanın bazı net avantajları olsa da, göz önünde bulundurulması gereken bazı zorluklar da vardır. İlişkisel modelle çalışırken bunlar aynı dereceye kadar mevcut değildir:

  • aynı varlığa işaret etmek için birçok ilişki olan işlemler.
  • tüm veri kümesi genelinde güçlü tutarlılık gerektiren işlemler.

İlk zora bakarak, NoSQL veritabanlarında başparmak kuralı genellikle normalleştirmeden çıkarmaktır ve daha önce belirtildiği gibi dağıtılmış bir sistemde daha verimli okumalar üretir. Ancak, bu yaklaşımda bazı tasarım zorlukları vardır. Bir kategori ve birden çok etiketle ilgili bir ürün örneği alalım:

Birleştirmeler

NoSQL belge veritabanındaki en iyi yöntem, kategori adını ve etiket adlarını doğrudan bir "ürün belgesinde" normalleştirmeden çıkarmaktır. Öte yandan kategorileri, etiketleri ve ürünleri eşit tutmak için, bunu kolaylaştıran tasarım seçenekleri bakım karmaşıklığını da eklemişti çünkü veriler "bire çok" ilişkisinde basit bir güncelleştirme ve verileri almak için birleştirme yerine üründe birden çok kayıt arasında çoğaltıldı.

Burada önemli olan okumaların normalleştirilmiş olmayan kayıtta daha verimli olması ve kavramsal olarak birleştirilmiş varlıkların sayısı arttıkça daha verimli hale olmasıdır. Ancak okuma verimliliği arttıkça, bir normalleştirme kaydında bir araya katılmış varlıkların sayısı arttıkça, varlıkları eşit tutmanın bakım karmaşıklığı da artar. Bu takası azaltmanın bir yolu, karma bir veri modeli oluşturmaktır.

NoSQL veritabanlarında bu takaslarla başa çıkarılacak daha fazla esneklik mevcutken, artan esneklik daha fazla tasarım kararı da üretebilir. Normalleştirilmiş olmayan kullanıcı verilerini yalnızca farklı bölümlere değil farklı kapsayıcılara da yer alan eşitlenmiş durumda tutmaya yönelik bir yaklaşım içeren gerçek dünya örneğini kullanarak Azure Cosmos DB'deverileri modelleme ve bölümleme makalemize bakın.

Güçlü tutarlılıkla ilgili olarak, bunun veri kümesi genelinde gerekli olması nadirdir. Ancak bunun gerekli olduğu durumlarda, dağıtılmış veritabanlarında bu bir zorluk olabilir. Güçlü tutarlılık sağlamak için, istemcilerin okumasına izin vermeden önce verilerin tüm çoğaltmalar ve bölgeler arasında eşitlenmesi gerekir. Bu, okumaların gecikme süresini artırabilir.

Yine Azure Cosmos DB, burada uygun olan çeşitli takaslar için ilişkisel veritabanlarından daha fazla esneklik sunar, ancak küçük ölçekli uygulamalar için bu yaklaşım tasarım konusunda daha fazla dikkat edilmesi gereken noktalara neden olabilir. Bu konu hakkında daha fazla ayrıntı için Tutarlılık, kullanılabilirlik ve performanstan elde edilen getiriler makalemize bakın.

Sonraki adımlar

Azure hesap ve diğer Cosmos yönetmeyi öğrenin: