Nosql DBMS için büyük artılardan biri, daha kolay kümelenebilmeleridir. Sözde NoSQL ile farklı veri parçalarını depolayan ve hepsini bir seferde sorgulayan yüzlerce ucuz makine yaratabilirsiniz.

Sorum şu: neden ilişkisel DBMS bunu mysql veya sql sunucusu gibi yapamıyor? Satıcılar bunu mevcut ürünleri ile yapmanın teknik bir yolunu bulamadılar mı, yoksa bunun uygulanabilir olmasını engelleyen ilişkisel modelle ilgili bir sorun mu var? NoSQL'in kümelemeyi kolaylaştıran verinin (anahtar / değer, belgeler, vb.) Saklanması ve erişilmesinin bu kadar önemli olması ne işe yarar ki?

Dağıtılmış Veri Tabanı Sistemleri 101

Veya, Dağıtılmış Veritabanları - FK ' web ölçeği ' aslında ne anlama geliyor?

Dağıtılmış veritabanı sistemleri karmaşık yaratıklardır ve birçok farklı tada sahiptir. Eğer üniversitede bu konuda hatırladığım hatırlamamın derinliklerine kadar kazarsam, dağıtılmış bir veritabanı sistemi oluşturmak için bazı temel mühendislik problemlerini açıklamaya çalışacağım.

İlk olarak, bazı terminoloji

ACID (Atomisite, Tutarlılık, İzolasyon ve Dayanıklılık) özellikleri: Bunlar, istenmeyen yan etkilere neden olmadan bir işlemin güvenilir bir şekilde uygulanması için uygulanması gereken kilit değişmezlerdir.

Atomiklik , işlemin tamamen tamamlanmasını veya geri alınmasını gerektirir. Kısmen tamamlanmış işlemler hiçbir zaman görünür olmamalı ve sistemin bunun olmasını önleyecek şekilde inşa edilmesi gerekir.

Tutarlılık , bir işlemin hiçbir zaman veritabanı şeması tarafından garanti edilen değişmezleri (bildirimsel referans bütünlüğü gibi) ihlal etmemesini gerektirir. Örneğin, eğer bir yabancı anahtar varsa, varolmayan bir ebeveyne saygı göstererek bir çocuk kaydı eklemek imkansız olmalıdır.

Yalıtım , işlemlerin birbirine karışmamasını gerektirir. İşlemler paralel veya ardışık olarak yapılırsa sistem aynı sonuçları garanti etmelidir. Uygulamada çoğu RDBMS ürünü, performansa karşı yalıtımı bozan modlara izin verir.

Dayanıklılık , bir kez taahhüt edildiğinde, işlemin donanım veya yazılım arızasına karşı dayanıklı bir şekilde kalıcı depolamada kalmasını gerektirir.

Aşağıda belirtilen dağıtılmış sistemlerde bu gereksinimlerin bazı teknik engellerini açıklayacağım.

Paylaşılan Disk Mimarisi: Bir kümedeki tüm işleme düğümlerinin tüm depolamaya erişebildiği bir mimari. Bu veri erişimi için merkezi bir tıkanıklık sunabilir. Paylaşılan disk sistemine bir örnek Oracle RAC veya Exadata'dır .

Paylaşılan Hiçbir Şey Mimarisi: Bir kümedeki işlem düğümlerinin diğer küme düğümleri tarafından görülmeyen yerel depolamaya sahip olduğu bir mimari. Paylaşılan sistemlerin örnekleri Teradata ve Netezza'dır .

Paylaşılan Bellek Mimarisi: Birden CPU'lar (veya düğümler) bellek ortak havuz erişebilir hangi bir mimari. Çoğu modern sunucu paylaşılan bellek türündedir. Paylaşılan hafıza, dağıtılmış sistemlerde yapılması daha zor olan önbellek veya atomik senkronizasyon ilkelleri gibi bazı işlemleri kolaylaştırır.

Senkronizasyon: Birden fazla işlem veya iş parçacığı tarafından paylaşılan bir kaynağa tutarlı erişim sağlamak için çeşitli yöntemleri tanımlayan genel bir terim. Bazı ağ mimarilerinde (örneğin Teradata'nın BYNET) ağ protokolünde senkronizasyon ilkelleri olmasına rağmen, dağıtılmış sistemlerde, paylaşılan bellek sistemlerinden daha zordur. Senkronizasyon ayrıca önemli miktarda ek yük ile de gelebilir.

Yarı Birleştirme: Dağıtılmış bir sistemin iki farklı düğümünde tutulan verinin birleştirilmesinde kullanılan ilkel. Temel olarak, birleşmeyi çözmek için bir düğüm tarafından diğerine geçirilen ve birleştirilen satırlar hakkında yeterli bilgiden oluşur. Büyük bir sorguda bu, önemli bir ağ trafiğini içerebilir.

Nihaî Tutarlılık: Yazmalarda performans (ve dolayısıyla daha yüksek işlem hacmi) için dağıtılmış bir sistemin tüm düğümlerinde derhal güncellemeyi (okumalardaki tutarlılık) bozan işlem anlamını tanımlamak için kullanılan bir terimdir. Nihai tutarlılık,birden fazla veri kopyasının ayrı düğümlerde tutulduğu dağıtık veritabanlarında işlem taahhütlerini hızlandırmak için bir performans optimizasyonu olarak Çekirdek Çoğaltmanın kullanılmasının bir yan etkisidir.

Lamport Algoritması: Paylaşılan hafızası olmayan sistemler arasında karşılıklı dışlama (senkronizasyon) uygulamak için bir algoritma. Normalde bir sistem içindeki karşılıklı dışlama, normalde yalnızca paylaşılan bir hafıza sisteminde pratik olan bir atomik okuma-karşılaştır-yaz ya da benzer bir talimatı gerektirir. Diğer dağıtılmış senkronizasyon algoritmaları mevcuttur, ancak Lamport's ilklerden biriydi ve en iyi bilinenleri. Dağıtılmış senkronizasyon mekanizmalarının çoğu gibi, Lamport algoritması da büyük ölçüde doğru zamanlamaya ve saat senkronizasyonu küme düğümlerine bağlıdır.

İki Aşama Taahhüdü (2PC): Birden fazla fiziksel sistemi içeren veritabanı güncellemelerinin tutarlı bir şekilde yapılmasını veya geri alınmasını sağlayan bir protokol ailesi. 2PC'nin bir sistemde mi yoksa birden fazla sistemde bir işlem yöneticisi aracılığıyla mı kullanıldığı önemli bir ek yükü taşır.

İki aşamalı bir işlem protokolünde işlem yöneticisi, katılımcı düğümlerden işlemi gerçekleştireceğini garanti edecek şekilde devam ettirmelerini ve ardından bu durumu bildirmelerini ister. Tüm düğümler 'mutlu' statüsünü döndürdüğünde, bu durumda düğümleri işlemek için işaret eder. Tüm düğümler, işlemin tamamlandığını belirten bir yanıt gönderene kadar işlem hala açık olarak kabul edilir. Eğer bir sinyal tamamlama işlemi tamamlanmadan önce düşerse, işlem yöneticisi geri döndüğünde düğümü tekrar sorgulayacak ve işlemin gerçekleştirildiğini belirten olumlu bir cevap alacaktır.

Çok Versiyonlu Eşzamanlılık Kontrolü (MVCC): Verilerin yeni versiyonlarını farklı bir yere yazarak ve yeni işlemin yapılmasına kadar başka işlemlerin verinin eski versiyonunu görmesine izin vererek çekişmeyi yönetin . Bu, yeni sürümü yazmak ve ardından eski sürümü eski olarak işaretlemek için bazı ek yazma trafiği pahasına veritabanı çekişmesini azaltır.

Seçim Algoritması: Birden fazla düğümü içeren dağıtılmış sistemler, daha fazla hata modu olduğundan, doğal olarak tek bir sistemden daha az güvenilirdir. Çoğu durumda, kümelenmiş sistemlerin bir düğümün başarısızlığı ile başa çıkması için bazı mekanizmalara ihtiyaç vardır. Seçim algoritmaları, 'lider' düğümün% 100 belirlenemediği veya güvenilir olmadığı durumlarda dağıtılmış bir hesaplamayı koordine edecek bir lider seçmek için kullanılan bir algoritma sınıfıdır.

Yatay Bölümleme: Bir tablo, anahtarına göre birden fazla düğüme veya depolama birimine bölünebilir. Bu, büyük bir veri hacminin daha küçük parçalara bölünmesine ve depolama düğümleri arasında dağıtılmasına izin verir.

Paylaşma: Bir veri kümesi paylaşılan-hiç bir mimarideki birden fazla fiziksel düğümde yatay olarak bölümlenebilir. Bu bölümlemenin şeffaf olmadığı durumlarda (yani müşteri, bölüm planının farkında olmalı ve hangi düğümü açıkça sorgulayacağına karar vermelidir), bu, paylaşım olarak bilinir. Bazı sistemler (örneğin Teradata) verileri düğümlere böler ancak konum müşteri için şeffaftır; Bu terim normalde bu tür bir sistemle birlikte kullanılmaz.

Tutarlı Hashing: Verileri, anahtara göre bölümlere ayırmak için kullanılan bir algoritma. Karma anahtarların eşit şekilde dağıtılması ve kepçe sayısını verimli bir şekilde elastik olarak genişletme veya azaltma yeteneği ile karakterize edilir. Bu nitelikler, verileri bölümlere ayırmayı veya boyutların düğümlerin eklenerek veya kümeden düşmesiyle (belki de başarısızlık nedeniyle) dinamik olarak değişebileceği bir düğümler kümesinde yüklenmesini sağlar.

Çok-Master Çoğaltma: Bir kümedeki birden fazla düğüm üzerindeki yazma işleminin diğer düğümlere çoğaltılmasını sağlayan teknik. Bu teknik, bazı tabloların sunucular arasında ve bazılarının küme boyunca senkronize edilmesine bölünmesine veya paylaşılmasına izin vererek ölçeklendirmeyi kolaylaştırır. Yazmaların bir çekirdek yerine tüm düğümlere çoğaltılması gerekir; bu nedenle işlem taahhütleri çok ana kopyalanmış bir mimaride çekirdek çoğaltılmış bir sistemden daha pahalıdır.

Engellenmeyen Anahtar: Dahili tıkanıklığı olmayan bağlantı noktalarının sayısıyla orantılı olarak verim elde etmek için iç donanım paralelliğini kullanan bir ağ anahtarı. Naif bir uygulama bir çapraz çubuk mekanizması kullanabilir, ancak bunun N portları için O (N ^ 2) karmaşıklığı vardır, bu onu daha küçük anahtarlarla sınırlar. Daha büyük anahtarlar, O (N ^ 2) donanıma ihtiyaç duymadan doğrusal verim ölçeklemesi elde etmek için engelleme yapmayan bir minimum yayılma anahtarı adı verilen daha karmaşık bir iç topoloji kullanabilir.

Dağıtılmış bir DBMS yapma - ne kadar zor olabilir?

Bazı teknik zorluklar pratikte bunu yapmayı oldukça zorlaştırmaktadır. Dağıtılmış bir sistem inşa etmenin karmaşıklığının yanı sıra, dağıtılmış bir DBMS'nin mimarı bazı zorlu mühendislik problemlerinin üstesinden gelmek zorundadır.

Dağıtılmış sistemlerdeki atomiklik: Bir işlem tarafından güncellenen veriler birden fazla düğüme yayılmışsa, düğümlerin kesinleşmesi / geri çevrilmesi koordine edilmelidir. Bu, paylaşılan hiçbir sistemde önemli bir ek yük sağlar. Paylaşılan disk sistemlerinde bu, daha az sorun yaratır, çünkü depolamanın tümü tüm düğümler tarafından görülebilir, böylece tek bir düğüm, görevi koordine edebilir.

Dağıtılmış sistemlerdeki tutarlılık: Yukarıda belirtilen yabancı anahtarı ele almak için sistemin tutarlı bir durumu değerlendirebilmesi gerekir. Örneğin, bir yabancı anahtar ilişkisinin ebeveyni ve çocuğu farklı düğümlerde bulunabilirse, işlemin doğrulanması için eski bilgilerin kullanılmadığından emin olmak için bir çeşit dağıtılmış kilitleme mekanizması gerekir. Bu zorlanmazsa (örneğin), çocuğun eklenmesine izin vermeden önce, varlığı onaylandıktan sonra ebeveynin silindiği bir yarış koşuluna sahip olabilirsiniz.

Gecikmeli kısıtlamaların uygulanması (yani, DRI’yi doğrulamak için karar verene kadar beklemek) işlem süresince kilit tutulmasını gerektirir. Bu tür dağıtılmış kilitleme önemli bir ek yük ile birlikte gelir.

Birden fazla veri kopyası tutulursa (bu, yarı birleşmelerden gereksiz ağ trafiğini önlemek için hiçbir şey paylaşılmamış sistemlerde gerekli olabilir), verilerin tüm kopyalarının güncellenmesi gerekir.

Dağıtılmış sistemlerde yalıtım: Bir işlemden etkilenen verilerin birden fazla sistem düğümünde bulunduğu yerlerde kilitler ve sürüm (MVCC kullanılıyorsa) düğümler arasında senkronize edilmelidir. Operasyonların seri hale getirilebilirliğini garanti etmek, özellikle de verilerin yedek kopyalarının saklanabildiği paylaşılan hiçbir şeyde olmayan mimarilerde, ağ trafiğinde de önemli bir yükü olan Lamport Algoritması gibi dağıtılmış bir senkronizasyon mekanizması gerektirir.

Dağıtılmış sistemlerde dayanıklılık: Paylaşılan bir disk sisteminde dayanıklılık sorunu, düğümler arasında hala dağıtılmış senkronizasyon protokollerinin gerekli olması dışında, esasen paylaşılan bellek sistemiyle aynıdır. DBMS'nin günlüklere yazması ve verileri tutarlı bir şekilde yazması gerekir. Paylaşılan hiçbir şey sisteminde, verilerin veya farklı düğümlerde depolanan verilerin bölümlerinin birden fazla kopyası olabilir. İşlemin düğümler arasında doğru şekilde gerçekleşmesini sağlamak için iki aşamalı bir işlem protokolü gerekir. Bu aynı zamanda önemli ek yükü de beraberinde getirir.

Paylaşılan hiçbir sistemde bir düğümün kaybı, verilerin sistemde mevcut olmadığı anlamına gelebilir. Bu veriyi azaltmak için birden fazla düğümde çoğaltılabilir. Bu durumdaki tutarlılık, verilerin normalde bulunduğu tüm düğümlere çoğaltılması gerektiği anlamına gelir. Bu yazılarda önemli bir ek yüke neden olabilir.

NoSQL sistemlerinde yapılan yaygın bir optimizasyon, işlemin taahhüt edildiği gibi rapor etmeden önce bir çekirdeğe yazılarak verinin belirli bir esneklik seviyesini garanti ederken, nispi olarak çoğaltılmasına izin vermek için çekirdek çoğaltmanın ve nihai tutarlılığın kullanılmasıdır. Veriler daha sonra tembel olarak verinin kopyalarının bulunduğu diğer düğümlere kopyalanır.

'Nihai tutarlılığın', işlemin yapılmasından hemen sonra verilerin tutarlı bir şekilde görüntülenmesi gerektiğinde kabul edilemeyecek tutarlılık üzerine yapılan büyük bir denge olduğuna dikkat edin. Örneğin, bir finansal başvuruda güncellenmiş bir bakiye hemen kullanılabilir olmalıdır.

Paylaşılan Disk sistemleri

Paylaşılan disk sistemi, tüm düğümlerin tüm depolamaya erişimi olan sistemdir. Dolayısıyla, hesaplama konumdan bağımsızdır. Birçok DBMS platformu da bu modda çalışabilir - Oracle RAC böyle bir mimarinin bir örneğidir.

Paylaşılan disk sistemleri, depolama düğümleri ve işleme düğümleri arasındaki M: M ilişkisini destekleyebildiklerinden büyük ölçüde ölçeklenebilir. Bir SAN birden çok denetleyiciye sahip olabilir ve birden çok sunucu veritabanını çalıştırabilir. Bu mimarilerin merkezi bir darboğazı olan bir şalteri var, ancak çapraz çubuklar bu anahtara çok fazla bant genişliğine sahip oluyor. Depolama bant genişliğindeki trafiği azaltabilecek bazı işlemler (Oracle Exadata'da olduğu gibi) depolama düğümlerine yüklenebilir.

Anahtar teorik olarak bir darboğaz olmasına rağmen, mevcut bant genişliği, paylaşılan disk mimarilerinin büyük işlem hacimlerine oldukça etkili bir şekilde ölçekleneceği anlamına gelir. Çoğu ana DBMS mimarisi bu yaklaşımı benimsemektedir, çünkü 'yeterince iyi' ölçeklenebilirlik ve yüksek güvenilirlik sağlar. Fiber kanal gibi yedekli bir depolama mimarisi ile herhangi bir işlem düğümü ile herhangi bir depolama düğümü arasında en az iki yol olduğundan tek bir hata noktası yoktur.

Paylaşılan hiçbir şey sistemleri

Paylaşılan hiçbir şey sistemi, verilerin en azından bir kısmının yerel olarak bir düğüme tutulduğu ve doğrudan diğer düğümlere görünmeyen sistemlerdir. Bu, merkezi bir anahtarın tıkanıklığını giderir ve veritabanının düğüm sayısıyla (en azından teoride) ölçeklenmesini sağlar. Yatay bölümleme, verilerin düğümler arasında bölünmesine izin verir; bu müşteri için şeffaf olabilir veya olmayabilir (yukarıdaki Sharding'e bakınız).

Veriler doğal olarak dağıtıldığından, bir sorgu birden fazla düğümden veri gerektirebilir. Bir birleştirme farklı düğümlerden veri gerektiriyorsa, bir düğümü bir düğümden diğerine desteklemek için yeterli veriyi aktarmak için yarı birleştirme işlemi kullanılır. Bu, büyük miktarda ağ trafiğine neden olabilir, bu nedenle verilerin dağıtımını optimize etmek, sorgu performansında büyük bir fark yaratabilir.

Çoğunlukla, veriler yarı birleşmelerin gerekliliğini azaltmak için paylaşılan hiçbir sistemin düğümleri arasında çoğaltılır. Bu, boyutlar tipik olarak olgu tablolarından daha küçük büyüklükteki siparişler olduğundan ve düğümler arasında kolayca çoğaltılabildiğinden, veri ambarındaki cihazlarda oldukça iyi çalışır. Ayrıca, genellikle gruplar halinde yüklenir, böylece çoğaltma ek yükü işlemsel bir uygulamada olduğundan daha az sorun olur.

Paylaşılan hiç bir mimarinin doğal paralelliği, onları bir veri ambarının karakteristik tablo tarama / toplama sorguları türüne uygun hale getirir. Bu tür bir işlem, işlem düğümlerinin sayısı ile neredeyse doğrusal olarak ölçeklenebilir. Yarı birleştirme işlemleri çok sayıda ağ trafiği oluşturabildiğinden, düğümler arasındaki büyük birleşmeler daha fazla ek yüke neden olma eğilimindedir.

Büyük veri hacimlerini taşımak, birden fazla güncellemenin ek yükünün bu tür mimariyi paylaşılan bir diskten daha az çekici hale getirdiği işlem işleme uygulamaları için daha az kullanışlıdır. Dolayısıyla, bu tür bir mimarlık, veri ambarı uygulamalarından geniş ölçüde kullanılma eğilimindedir.

Keskinleştirme, Çekirdek Çoğaltma ve Nihai Tutarlılık

Çekirdek Çoğaltma, bir DBMS'nin yüksek kullanılabilirlik için verileri çoğalttığı bir tesistir. Bu, SAN gibi yerleşik yüksek kullanılabilirlik özelliklerine sahip olmayan daha ucuz emtia donanımlarında çalışmayı amaçlayan sistemler için kullanışlıdır. Bu tip bir sistemde, veriyi, sistemin bir düğümün donanım arızasına karşı dayanıklı kılması için okuma performansı ve yedek depolama için çoklu depolama düğümleri arasında çoğaltılır.

Ancak, tüm düğümlere yazmaların çoğaltılması, M düğümleri ve N yazarları için O (M x N) 'dir. Bir işlem yapmasına izin verilmeden önce, yazma işleminin tüm düğümlere çoğaltılması gerekiyorsa bu, yazma işlemlerini pahalı hale getirir. Çekirdek çoğaltması, yazarların hemen düğümlerin bir alt kümesine çoğaltılmasını ve ardından arka plan görevi tarafından diğer düğümlere tembel olarak yazılmasını sağlayan bir uzlaşmadır. İşlem, müşteriye taahhüt edildiği bildirilmeden önce, asgari düzeyde bir düğüm alt kümesine çoğaltılmalarını sağlayarak belirli bir fazlalık derecesi sağlarken, daha hızlı bir şekilde yazılabilir.

Bu, nisanın dışındaki düğümleri okuyan, arka plan işleminin geri kalan düğümlere veri yazmayı bitirinceye kadar verilerin eski sürümlerini görebileceği anlamına gelir. Anlambilim 'Nihai Tutarlılık' olarak bilinir ve başvurunuzun gerekliliklerine bağlı olarak kabul edilebilir veya olmayabilir, ancak işlem taahhütlerinin kaynak kullanımında O (n) 'den O (1)' e daha yakın olduğu anlamına gelir.

Paylaşma, müşterinin veritabanlarında verilerin bölümlere ayrılmasının farkında olmasını gerektirir; genellikle 'tutarlı karma' olarak bilinen bir algoritma kullanılır. Bölünmüş bir veritabanında, istemci, sorgunun yayınlanacağı kümede hangi sunucuyu belirleyeceğine ilişkin anahtarı kullanır. İstekler kümedeki düğümler arasında dağıtıldığı için, tek bir sorgu koordinatörü düğümü ile hiçbir tıkanıklık yoktur.

Bu teknikler, kümeye düğümler ekleyerek bir veritabanının doğrusal bir hızda ölçeklenmesini sağlar. Teorik olarak, çekirdek çoğaltması, yalnızca temel alınan depolama ortamının güvenilmez olarak kabul edilmesi durumunda gereklidir. Bu, eğer emtia sunucularının kullanılması gerekiyorsa faydalıdır, ancak altta yatan depolama mekanizması kendi yüksek kullanılabilirlik şemasına sahipse (örneğin, yansıtılmış denetleyicilere sahip bir SAN ve ana makinelere çok yollu bağlantı), daha az değerlidir.

Örneğin, Google’ın BigTable’ı, çekirdek çoğaltmayı kullanan kümelenmiş bir dosya sistemi olan GFS’de oturmasına rağmen, Çekirdek Çoğaltmayı kendi başına uygulamaz. BigTable (veya paylaşılan hiçbir sistem), birden fazla denetleyiciye sahip güvenilir bir depolama sistemi kullanabilir ve verileri denetleyiciler arasında bölümlendirebilir. Paralel erişim daha sonra verilerin bölümlendirilmesiyle sağlanacaktır.

RDBMS platformlarına geri dön

Bu tekniklerin RDBMS ile birlikte kullanılamamasının doğal bir nedeni yoktur. Ancak, kilitleme ve sürüm yönetimi böyle bir sistemde oldukça karmaşık olacaktır ve böyle bir sistem için herhangi bir pazarın oldukça uzmanlaşmış olması muhtemeldir. Ana RDBMS platformlarının hiçbiri çekirdek çoğaltması kullanmaz ve bunun herhangi bir RDBMS ürününden (en azından önemli bir alımına sahip olmayan) biri olduğunun farkında değilim.

Paylaşılan disk ve paylaşılan hiçbir sistem çok büyük iş yüklerine kadar ölçeklenebilir. Örneğin, Oracle RAC, 63 işlem düğümünü (kendi başlarına büyük SMP makineleri olabilir) ve SAN üzerindeki isteğe bağlı sayıda depolama denetleyicisini destekleyebilir. Bir IBM Sysplex (bir zSeries anabilgisayar kümesi), birden fazla anabilgisayarı (her biri önemli işlem gücü ve kendi I / O bant genişliğine sahip) ve birden çok SAN denetleyicisini destekleyebilir. Bu mimariler, güvenilir depolamayı üstlenmelerine rağmen, ACID anlambilimiyle çok büyük işlem hacimlerini destekleyebilir. Teradata, Netezza ve diğer satıcılar, son derece büyük veri hacimlerine ölçeklenen hiçbir şey paylaşmayan tasarımlara dayanan yüksek performanslı analitik platformlar oluşturur.

Şimdiye kadar, ucuz ancak ultra yüksek hacimli tamamen ACID RDBMS platformları pazarına, sharing ve multi-master replikasyonunu destekleyen MySQL hakimdir. MySQL yazma verimini optimize etmek için çekirdek çoğaltma kullanmaz, bu nedenle işlem taahhütleri NoSQL sisteminden daha pahalıdır. Paylaşma, çok yüksek okuma verimine izin verir (örneğin Facebook, MySQL'i yoğun olarak kullanır), bu nedenle bu tür mimari, okuma yoğun iş yüklerinde iyi ölçeklenir.

İlginç bir tartışma

BigTable , aşağıdaki Michael Hausenblas'ın işaret ettiği gibi paylaşılan hiçbir şey içermeyen bir mimaridir (temel olarak dağıtılmış bir anahtar-değer çifti) . Orijinal değerlendirmem, BigTable'ın bir parçası olmayan ancak normalde en yaygın uygulamalarında (örneğin Hadoop / HBase ve Google'ın MapReduce çerçevesi gibi) kullanılacak olan MapReduce motorunu içeriyordu.

Bu mimariyi, depolama ve işleme arasında fiziksel bir afiniteye sahip olan Teradata ile karşılaştırmak (yani, düğümler paylaşılan bir SAN yerine yerel depolamaya sahiptir), BigTable / MapReduce'un, küresel olarak görülebilen paralel depolama sistemi aracılığıyla paylaşılan bir disk mimarisi olduğunu iddia edebilirsiniz.

Hadoop gibi bir MapReduce tarzı sistemin işleme çıkışı, engelleyici olmayan bir ağ anahtarının bant genişliği ile sınırlandırılmıştır. ¹ Sigara engelleme anahtarları, ancak dolayı tasarımda doğasında paralellik büyük bant genişliği agrega işleyebilir, bu yüzden nadiren performansı üzerinde önemli bir pratik sınırlama vardır. Bu, paylaşılan bir disk mimarisinin (belki de daha iyi paylaşılan depolama sistemi olarak adlandırılır), ağ anahtarı teorik olarak merkezi bir darboğaz olmasına rağmen, büyük iş yüklerine ölçeklenebilir anlamına gelir.

Orijinal nokta, bu merkezi darboğazın paylaşılan disk sistemlerinde mevcut olmasına rağmen, birden fazla depolama düğümüne sahip (örneğin BigTable tablet sunucuları veya SAN denetleyicileri) bölümlenmiş bir depolama alt sisteminin hala büyük iş yüklerine kadar ölçeklenebileceğini not etmekti. Bloke edici olmayan bir anahtar mimarisi (teoride) portlara sahip olduğu kadar çok sayıda mevcut bağlantıyla başa çıkabilir.

¹ Tabii ki, mevcut işleme ve G / Ç verimi de performansta bir sınır oluşturuyor, ancak ağ anahtarı tüm trafiğin geçtiği merkezi bir nokta.

İlişkisel veritabanları olabilir NoSQL çözümleri gibi yığılır. ACID özelliklerinin korunması, bunu daha karmaşık hale getirebilir ve bu özelliklerin korunması için yapılan tradeoffların bilinmesi gerekir. Maalesef, tam olarak değişimin ne olduğu iş yüküne ve elbette veritabanı yazılımı tasarlanırken alınan kararlara bağlıdır.

Örneğin, birincil olarak OLTP iş yükü, kümenin verimliliği iyi ölçeklendiğinde bile ek tek sorgu gecikme süresi olabilir. Bu gecikme süresi farkedilmeyebilir veya uygulamaya bağlı olarak gerçek bir anlaşma olabilir. Genel olarak, kümelenme verimliliği artırır ve gecikmeyi incitir, ancak bu kural bile bir uygulamanın sorgularının paralel işleme için özellikle uygun olup olmadığından şüphelenir.

Çalıştığım şirket olan Clustrix , göreceli olarak yüksek hızlı bir ağa bağlı bir dizi homojen hesaplama ve depolama düğümü sunuyor. İlişkisel veriler düğümlere, 'dilimler' dediğimiz topaklarda her bir endeks bazında dağıtılmıştır. Her dilim, düğüm veya disk arızası durumunda dayanıklılık için küme boyunca yayılmış iki veya daha fazla kopyaya sahip olacaktır. İstemciler, MySQL tel protokolünü kullanarak sorgular yayınlamak için kümedeki herhangi bir düğüme bağlanabilir.

Bir ACID veri tabanının bileşenlerini bağımsız olarak düşünmek biraz doğaldır, çünkü çoğu zaman birlikte çalışır, ancak işte bu:

Atomiklik - Clustrix, atomikliği sağlamak için iki fazlı taahhüt kullanır. GÜNCELLEME ve SİLME işlemleri aynı zamanda dağıtılmış kilit yöneticimiz aracılığıyla satırları da kilitleyecektir, çünkü bu işlemleri dahili olarak SELECT ve ardından tam UPDATE / DELETE işlemleri olarak çeviririz.

Atomisite, bir işleme katılan düğümler arasındaki mesajlaşma miktarını açıkça arttırır ve bu protokolün işleme konması için bu düğümler üzerindeki yükü artırır. Bu, dağıtılmış bir sisteme sahip olmanın ek yükünün bir parçasıdır ve her düğüm her işleme katılırsa ölçeklenebilirliği sınırlar, ancak düğümler yalnızca bir kopyaya yazılan kopyalara sahipse bir işleme katılır.

Tutarlılık - Yabancı anahtarlar, işlem sırasında değerlendirilen tetikleyiciler olarak uygulanır. GÜNCELLEME GÜNCELLEME ve SİLME işlemleri kilitleme nedeniyle performansımızı zedeleyebilir, ancak neyse ki hepsini bu kadar sık ​​görmüyoruz. Bir işlem görmek veya birkaç satır silmek ve daha sonra kabul etmek çok daha yaygındır.

Tutarlılığın diğer bir kısmı da, yalnızca bilinen düğümlerin çoğunluğuna sahip kümelerin yazabilmelerini sağlayan PAXOS konsensüs protokolü ile bir nisabı korumaktır . Elbette bir kümenin çekirdeğe sahip olması ancak yine de (eksik bir dilimin tüm kopyaları) veri eksik olması, bu dilimlerden birine erişen işlemlerin başarısız olmasına neden olabilir.

İzolasyon - Clustrix, konteyner seviyesinde MVCC izolasyonu sağlar. Atomikliğimiz, taahhüt edilen işlemi rapor etmeden önce tüm geçerli kopyaların belirli bir yazı aldığını garanti eder, çoğunlukla kümelenmemiş durumda sahip olacağınız yalıtım sorununu azaltır.

Dayanıklılık - Her bir ilişkisel veri dilimi, düğüm veya disk arızası durumunda esneklik sağlamak için iki veya daha fazla düğüme depolanır. Burada ayrıca, ürünümüzün cihaz versiyonunun performans nedenleriyle WAL'ın depolandığı bir NVRAM kartına sahip olduğunu da belirtmekte fayda var. Birçok tek örnekli veritabanları, her bir taahhüt yerine belirli aralıklarla kontrol ederek WAL'lerin performansını artıracaktır. Bu yaklaşım dağınık bir sistemde problemlidir çünkü “nerede? karmaşık bir soru. Sert bir dayanıklılık garantisi vererek bunu cihazdan kaldırıyoruz.

Temel cevap, tutarlılık modelinin farklı olmasıdır. Bunu, bunun için referans noktası olması gereken ConcernedOfTunbridge'in yanıtını genişletmek için yazıyorum.

ACID tutarlılık modelinin temel noktası, küresel olarak sistemin içindeki verilerin durumuna ilişkin bir dizi temel garanti vermesidir. Bu garantiler, temelde, onları işlemesi için bir işlem gerçekleştirdiğinizi bildirmeden önce aynı sayfada tüm yetkili kaynaklara sahip olmanız gerektiği anlamına gelen CAP teoremi sınırlamalarına tabidir. Çok ana çoğaltmanın bu kısıtlamalara girmeden yapılması çok zordur. Kesinlikle bir çok ana ortamda senkronize olmayan çoğaltma yapmaya başladığınızda, bu garantiler pencereden dışarı çıkar. ACID tutarlılık modeli, önemli veya kritik bilgiler için tasarlanmış güçlü bir tutarlılık modelidir.

BASE tutarlılık modeli, kritik olmayan bilgiler için amaçlanan zayıf bir tutarlılık modelidir. Garantiler oldukça zayıf olduğu için, çok ana sistemlerde bu kadar zayıf garantiler sunma kabiliyeti daha kolay elde edilebilir çünkü garantiler çok zayıf.

RDBMS'ler NoSQL çözümlerinin yanı sıra ölçeklenebilirler ve yapabilirler!

Ancak, RDBMS'lerin NoSQL'in bile eşleşemeyeceği bir düzeye kadar ölçeklenebileceği ve ölçeklenebileceği durumlar vardır. Sadece çok farklı. Postgres-XC'ye güçlü tutarlılık garantilerinden ödün vermeden ölçeklendirmenin nasıl mümkün olduğunun bir örneği olarak bakacağım.

Bu belirli RDBMS'lerin yaptığı gibi, bir proxy ve benzeri bir paylaşılan disk mimarisine sahip, ancak her ikisinden de çok daha karmaşık olan bir tür netleştirme çözümü kullanmaktır. Bunlar NoSQL çözümleriyle aynı şekilde ölçeklenmiyor ve bu yüzden farklılıklar farklı.

Postgres-XC modelinin Teradata'dan ilham aldığını biliyorum. Depolama düğümleri veya koordinatörleri olarak iki farklı roldeki düğümlerden oluşur. Koordinatörler çoklu-ana sistemdir (gerçek bir çoğaltma söz konusu değildir) ve gerçek veri işlemeyi işlemek için depolama düğümlerine bağlanırlar. Depolama düğümleri bir master-slave kurulumunda çoğaltılır. Her bir depolama düğümü özünde veritabanının bir parçası olanı içerir, ancak koordinatörler verilerin tutarlı bir resmini korur.

Sorumlulukların önemli bir ayrımı burada yer almaktadır. Depolama düğümleri verileri yönetir, kısıtlamaları kontrol eder, yerel olarak uygulanabilir yabancı anahtar kısıtlamalarını kontrol eder ve en azından bazı verilerin toplanmasını işler. Koordinatörler, yerel olarak uygulanamayan yabancı anahtarların yanı sıra, birden fazla veri düğümünden çekebilecek pencereleme ve diğer veri hususlarını ele alır. Temel olarak koordinatörler, kullanıcının işlemlerin dağıtıldığını bile bilmediği çok ana bir kurulumda dağıtılmış işlemlerde ACID'yi mümkün kılar.

Bu bağlamda, Postgres-XC, NoSQL ölçeklendirme seçeneklerine benzer bir şey sunar ancak ek tutarlılık garantileri nedeniyle bazı karmaşıklıklar da vardır. Bununla birlikte, bu tür bir ölçeklenebilirlik sunan ticari RDBMS'lerin olduğunu biliyorum. Teradata bunu yapar. Ayrıca paylaşılan disk sistemleri de benzer şekilde ölçeklenebilir ve DB2 ve Oracle bu tür çözümler sunar. Bu yüzden RDBMS’lerin bunu yapamayacağını söylemek haksızlık. Yapabilirler. Bununla birlikte, ihtiyaç, geçmişte o kadar küçüktü ki, ölçek ekonomileri, özel çözümleri çoğu oyuncu için çok uygun hale getirmek için yetersizdi.

Sonunda VoltDB üzerine bir not. NoSQL çözümleri gibi VoltDB'yi de çok özel bir araç olarak görüyorum. Çok hızlı, ancak çok yönlü işlem masrafları ve diskteki dayanıklılık pahasına. Bu, çok farklı bir endişelerinizin olduğu anlamına gelir. VoltDB, RDBMS öncüleri bir NoSQL çözümü oluştururken elde ettikleridir ;-). VoltDB kısmen hızlıdır çünkü denklemin eşzamanlılığını ve dayanıklılığını tanımlar. Dayanıklılık, bir ana bilgisayar içi özellik değil bir ağ özelliği olur ve eşzamanlılık, sırayla, sırayla sırayla sırayla iç paralelleştirilmiş sorgular çalıştırılarak yönetilir. Bu geleneksel bir RDBMS değildir (ve geleneksel RDBMS'nin yapamayacağı yerlere gidebileceği için btw için iyi bir şeydir, ancak sohbet de çok doğrudur).

Düzenle: Birleşmelerin anlamını dikkate almak da önemlidir. Kümelenmiş sistemlerde, birleşimler çok farklı bir performans sorunu haline gelir. Her şey aynı düğümde ise performansı artırabilirler, ancak farklı bir düğüme gidiş dönüş yapmanız gerekiyorsa, bu çok yüksek bir maliyet getirir. Dolayısıyla veri modelleri farklılık yaratır ve kümelenme yaklaşımının performans etkileri vardır. Postgres-XC ve Postgres-XL gibi yaklaşımlar, bir şeyleri düşünerek oldukça fazla zaman harcayabileceğinizi ve böylece verilerinizi uygun şekilde parçalayabileceğinizi ve birleştirilmiş verileri bir arada tutabileceğinizi varsayar. Ancak bu, genel olarak tasarım yükler. Öte yandan, bu, birçok NoSQL çözümünden çok daha iyi ölçeklenir ve uygun şekilde ayarlanabilir. Örneğin, (Adjust olarak) PostgreSQL'deki temelde log analizi olan 3.5PB verilerimiz için NoSQL benzeri bir kümeleme stratejisi kullanıyoruz. Ve tasarımımızın çoğu, NoSQL kümeleme stratejilerinden derinden ilham alıyor. Bu yüzden bazen veri modeli kümelenme modelini de kısıtlar.

Cevabım öncekiyle iyi yazılmış olmayacak, ama işte.

Ingres'in şöhretli Michael Stonebraker, bir kümedeki farklı düğümler arasında veri dağıtan ve ACID'yi koruyan bir MPP paylaşılan bir sütun deposu (Vertica) ve bir MPP paylaşılan hiçbir şey Yeni SQL veritabanı (VoltDB) yarattı. Vertica o zamandan beri HP tarafından satın alındı.

Diğer Yeni SQL veritabanlarının da ACID'yi koruduğuna inanıyorum, ancak kaçının satırlarını küme üzerine dağıttığından emin değilim.

İşte Stonebraker'ın New SQL'de NoSQL ve "Old SQL" e göre verdiği bir konuşma. http://www.youtube.com/watch?v=uhDM4fcI2aI

MySQL kümelemesi, küme genelinde çoklu mastering çoğaltması ve karma kırıkları kullanarak engel olabilir.