Hoşçakal NoSQL
NoSQL, büyük ölçekli veri toplama ve çoklu veri türlerinin zorluklarını çözmek için ortaya çıktı, ancak şimdi birçok sorunla da karşılaştı.Bu makalenin yazarı Rick Negrin, Microsoft için 12 yıl çalıştı ve zamanının çoğunu SQL Server ekibinde geçirdi. , Dedi, "NoSQL'e veda etme zamanı"!
Yazar | Rick Negrin
Çevirmen | Ay gibi ağlamak
Editör | Tang Xiaoyin
Baş resmi | Oriental IC'den indirilen CSDN
Üretildi | CSDN (ID: CSDNnews)
Aşağıdaki çeviridir:
Zaten bildiğimiz gerçekleri kabul etmenin zamanı geldi: NoSQL modern uygulamalar için uygun değildir, ona veda etmeliyiz.
Veriler, veritabanının kaldırabileceği ölçeği aştıkça, NoSQL teknolojisi ortaya çıktı. Bu yeni veri hizmeti türünün ortaya çıkışı, on yıl önce ortaya çıktığında ağların ve verilerin hızlı büyümesi sorununu çözdü. NoSQL ayrıca petabaytlarca veriye soğuk depolama veya toplu erişim için yeni bir düşük maliyetli yol sağlar. Bununla birlikte, büyük veri ve yüksek eşzamanlılığın zorluklarını çözme isteği nedeniyle, NoSQL, yüksek performanslı ve kullanımı kolay olan veritabanının bazı temel özelliklerini terk etti.
Büyük veri ve yüksek performans ve kullanım kolaylığı ile yüksek eşzamanlılık arasındaki denge, NoSQL'in veritabanı alanına en büyük katkısıdır. Büyük verileri olgun ilişkisel yapı ve esneklikle birleştirmek, bir devrim yaratan ölçeklenebilir bir ilişkisel veritabanıyla sonuçlandı.
İlişkisel veritabanlarının geliştirilmesi, modern uygulamaların ölçeklenebilirlik, güvenilirlik ve kullanılabilirlik gereksinimleri ile hemen hemen tüm görevleri yerine getirebilen yeni bir sistem yarattı. Geleneksel görevlerden (işlem işleme uygulamaları ve iş analizi gibi) daha yeni görevlere (çok kiracılı hizmetler ve operasyonel analiz gibi) geçişle birlikte, Google Spanner, Azure Veri Ambarı ve MemSQL gibi bazı yeni ortaya çıkan veritabanları ortaya çıkmaya başladı. Çoğu durumda ilişkisel veritabanlarının kullanımının daha kolay olduğunu ve genellikle NoSQL'den daha iyi performans gösterdiğini kanıtlıyor.
Yukarıdaki açıklamaların tartışmalara neden olabileceğini biliyorum. Ayrıca görüşlerimin taraflı olduğunu düşündüğünüzü de biliyorum. Ancak lütfen veritabanının tarihçesi, mimarisi ve uygulamayla ilgili bilgilerinden bahsedeyim, kendi kararınızı vermeniz için çok geç değil.
NoSQL'in yükselişi
NoSQL daha erken başlamış olmasına rağmen, 2010'ların ortalarına ve sonlarına kadar tam olarak işlevsel hale gelmedi. Görünüşü, esas olarak mevcut veritabanı sisteminin ölçek problemini çözmektir. Açıktır ki, büyük ölçekli sistemler inşa etmek için yatay olarak genişleyebilmek daha uygun maliyetlidir. Google, Facebook, Microsoft ve Yahoo gibi en büyük e-posta ve arama sistemleri için, genişletmenin tek yolu budur.
2007'de, James Hamilton'ın büyük ölçekli İnternet hizmetlerinin tasarlanması ve kullanılması hakkındaki makalesini okuduğumda, ilk olarak ölçeklendirmenin değerini anladım. Her şeyden önce, durum bilgisiz bir sistemi uygulama katmanında genişletmek daha kolaydır. Depolama katmanını genişletmek farklıdır. Tanım olarak, veritabanları durum bilgisine sahiptir ve dağıtılmış bir sistemde durumu (ACID) sürdürmek çok zordur. Depolama katmanı, dağıtılmış bir depolama sistemi oluşturmak için genellikle mevcut bir veritabanı sistemine (MsSQL, SQL Server vb.) Dayanır.
Microsoft SQL Server ekibinde ürün yöneticisi olduğumda aşağıdaki örneklerle karşılaştım. İlk örnek Microsoft içinde oluşmuştur.Microsoft, Hotmail ve ilgili hizmetler tarafından kullanılan SQL Server'ın üzerinde bir parçalama katmanı olan Web Mağazasını dahili olarak oluşturmuştur. Aslında, Web Mağazası artık Azure SQL Veritabanının öncülüdür. Web Mağazası hantal olmasına ve birçok temel işlevden yoksun olmasına rağmen etkilidir ve Microsoft'a gerekli veri ölçeğine ölçekleme ve yüksek kullanılabilirlik elde etme yeteneği sağlar. Ancak Web Mağazası, oluşturmak ve sürdürmek için eksiksiz bir mühendis ekibine ihtiyaç duyar.
2010'ların ortalarında MySpace, hızla büyüyen verileri yönetmek için çok sayıda SQL Server sunucusu kullandı. Şirketin kullanıcıları çok hızlı büyüdüğü için, şirketin her gün yeni SQL Server makineleri eklemesi gerekiyor. Bu SQL Server sunucularını çalıştırma ve sunucular arası sorguları destekleme işi çok karmaşıktır ve bakımı çok sayıda mühendis gerektirir.
Aynı durum Facebook veya diğer şirketlerde de ortaya çıkıyor, çünkü ortaya çıkan tüm teknoloji devleri sürekli olarak ölçekleri genişliyor, bu yüzden hepsi benzer sorunlarla karşı karşıya.
Açıktır ki, verilerin büyük ölçekli kullanımı ve büyümesiyle, verileri elde etmek, yönetmek ve sorgulamak için yeni veri çözümlerine ihtiyaç duyulmaktadır. İdeal olarak, arayüzler sağlayabilen ve makine ekleyerek genişletilebilen bir araca ihtiyacımız var.
Sonunda, büyük ölçekli bulut hizmetleri (Google, Facebook, Yahoo, Microsoft vb.) Bu veri talebini karşılamak için kendi özelleştirilmiş sistemlerini kurdu. Bu sistemler farklı olmakla birlikte, fikirleri doğrudan veya akademik yollarla dolaylı olarak paylaşılmaktadır. Sonunda, açık kaynaklı sistemler bu fikirlerden öğrenmeye başladı ve NoSQL ortaya çıktı.
Ağ ölçeği sorununu çözmek için NoSQL, bazı temel yönlerden geleneksel veritabanlarından ayrılmaktadır. Sonra bunu neden yaptığını görelim.
Sonunda tutarlı performans ve riskler
ACID, Atomik, Tutarlı, İzolasyon ve Dayanıklı anlamına gelir. Çoğu ilişkisel veritabanının garantilerini kapsar. ACID, yazma işleminin, istemciye başarı getirmeden önce verilerin diske yerleştirilmesini beklemesi gerektiğini garanti eder. Ek olarak, dayanıklılığı önemsiyorsanız (yani veri kaybı yok), veritabanını yazma işlemi ağ üzerinden diğer makinelere iletilene kadar bekleyecek ve karşı tarafın diski yerleştirmesini bekleyecek şekilde yapılandırabilirsiniz. Bu, yazılı verilerin doğruluğunu sağlar ancak yazılı verilerin performansını düşürür.
BASE, NoSQL sistemlerinin tipik bir özelliğidir, yani Temelde Kullanılabilir, Yumuşak Durum ve Sonunda Tutarlı. Programın veri kalıcılığının tamamlandığını onaylaması gerekmediğinden, sonuçta tutarlı yazma performansı daha yüksektir. Veri depolama cihazı bir yazma işlemini aldıktan sonra, uygulamaya devam etmeden veya başka makinelere göndermeden önce yazma işleminin başarılı olduğunu bildirebilir ve uygulama bir sonraki işlemi gerçekleştirebilir. Yazma performansını iyileştirmiş olmanıza rağmen, henüz yazdığınız verileri görememe riskiyle karşı karşıyasınız ve veriler anormal koşullar altında tamamen kaybolabilir.
Nihai tutarlılık, kalıcılık riski ve kullanılabilirlik arasında makul bir değiş tokuştur. İşletmeniz tüketici katılımı ise ve gecikmenin geliriniz üzerinde doğrudan bir etkisi varsa (tüm içerik, topluluklar ve ticari uygulamalar için), daha hızlı yanıt verme peşindesiniz demektir. Aynı anda milyonlarca kullanıcıyı desteklemeniz gerekiyorsa, herhangi bir darboğaza tahammül edemezsiniz. Birinin yayınını veya yorumunu ara sıra kaybetme riski kabul edilebilirse, nihai bir tutarlılık planı uygundur.
Kalıcılık ve risk arasındaki diğer taraf ise finansal uygulamalardır. Bankaların ATM işlemlerinin veya hisse senedi satışlarının sonuçlarını saklamak için nihai tutarlılığı kullanmasını istemezsiniz. Bu gibi durumlarda, kullanıcıların çok az bekleme süresi istemesine veya hiç beklememesine izin verirsiniz, ancak diske yazılmamış işlemleri kabul etmek istemezsiniz.
Nihai tutarlılığın bir yeri vardır, ancak tek çözüm bu değildir. Veri sistemi mimarları ve geliştiricileri, gerçek ihtiyaçlara göre istedikleri tutarlılık düzeyini seçmelidir. Bu seçim, platform düzeyinde değil, kullanım durumu düzeyinde yapılmalıdır.
Modelsiz
NoSQL hareketinde kalıbın neden kaybolduğu belirsizdir. İlk günlerde, bir sütun eklemek gibi, dağıtılmış sistemler arasında çalışacak modelleri korumak için dağıtılmış bir meta veri yöneticisi oluşturmak zordu. Bu nedenle, erken tasarımlarda desenlerin kullanılmaması şaşırtıcı değildir. Ancak, desen eklemek için bir neden bulamadı ve basitçe silindi. Birçok insan modelin o kadar çevik olmadığını düşünüyor. İyi desen tasarımı çok zordur ve dikkatli bir değerlendirme gerektirir. İşler hızla değiştiğinde, kalıplara bağlı kalmak istemezsiniz.
Ancak bu bir yanılgıdır.
Nitekim, kalıpların eksikliği mühendis gelişiminin çevikliğini artırır. Bununla birlikte, bu sorunu, genellikle daha fazla sayıda olan ve verileri yazarken genellikle verilerin durumunu bilmeyen veri okuyucularına iter. Bu kullanıcıların genellikle verilerden değer çıkarması gerekir, bu nedenle mümkün olduğunca az engel oluşturmaları gerekir.
Örneğin, kütüphanenin Dewey Ondalık Kitap Sınıflandırmasını kaldırdıklarını, sadece kitapları yerdeki büyük bir deliğe fırlattıklarını ve kütüphaneciler için daha çok iş olduğu için daha iyi bir sistem olduğunu iddia ettiklerini hayal edin. az. Yarı yapılandırılmış veriler için, zaman ve konum öznitelikleri vardır, çünkü bazen önceden bazı veri yapısını bilmiyorsunuz veya seyrek olup olmadığını bilmiyorsunuz. Ancak gelecek verilerin herhangi bir özelliğini bilmiyorsanız, bunun ne faydası var?
Aslında, kalıplar her zaman vardır. Bu veriler her zaman bazı insanlar için anlamlıdır. Bazı insanlar bilgiyi bir platformda kodlamak için zaman ayırmalıdır, böylece sonraki kişi onu kullanmayı öğrenebilir. Veriler, anlaşılması zor ve hızlı değişen verilerin bir karışımıysa, değiştirilebilir kısmı veritabanının yarı yapılandırılmış sütununa yerleştirebilir ve ardından gelecekte hangi sütunlarla eşlenebileceğini belirleyebilirsiniz. SQL Server ve Oracle, bu özelliği 15 yıl önce XML aracılığıyla uygulayabiliyordu. Diğer modern veritabanları da bu işlevi JSON verileri aracılığıyla gerçekleştirebilir. Belge verilerinin (anahtar / değer çiftleri) depolanması, tek işlev değil, modern veritabanlarının bir özelliğidir.
Sorgu için SQL olmayan sözdizimi
NoSQL veritabanı tasarımındaki bu karar, modelsizlik ilkesini izler. Kalıp yoksa, SQL sözdizimini atmak daha mantıklıdır. Ek olarak, tek bir makine için bir sorgu işlemcisi oluşturmak zordur ve dağıtılmış bir işlemci oluşturmak daha da zordur. En önemlisi, bir geliştiriciyseniz ve yeni bir uygulama kurmak ve çalıştırmak istiyorsanız, NoSQL tabanlı bir sistem oluşturmak daha kolay olacaktır.
MongoDB, kurulum adımlarını ve ilk deneyimi basitleştirmede çok iyi bir iş çıkardı. Ancak ilişkisel modelin çok güçlü olduğu ortaya çıktı. "Nesneyi id 2 ile elde etme" işlevini gerçekleştirmek istiyorsanız, doğrudan get ve koy işlevlerini kullanın. Ancak çoğu uygulama bundan fazlasını gerektirir. MongoDB'yi iki proje için kullanan birinden bir şeyler öğrenmek istiyorsanız bu yazıyı okuyabilirsiniz. Bu makale, belge veritabanının eksikliklerini açıklamaktadır.
Verileri her zaman depolanan verilerden farklı bir şekilde sorgulamak istersiniz. İronik olarak, bu sorunu çözmek için ilişkisel model 1960'larda icat edildi. Veri elde etmenin tek yolu bağlantı işlevine sahip ilişkisel bir veritabanıdır. İlk başta zordur, ancak ilişkiyi kendiniz kurmak için tüm verileri uygulamaya yüklemekten daha iyidir. Ancak bunu NoSQL'de tekrar tekrar yapan müşteriler gördüm ve sonuçlar hayal edilebilir.
Birçok NoSQL sistemi hedeflerine ulaşmıştır. Yüksek kullanılabilirlik elde etmek için birçok makineye genişletilebilen birleşik bir arabirimle veri depolama sağlarlar. Pek çok başarı elde edilmiş olmasına rağmen, NoSQL bazı engellerle karşılaştı.
bir çok neden var. Performans, özellikle herhangi bir tür hizmet düzeyi sözleşmesini (SLA) analiz ederken ve sorgularken temel faktörlerden biridir. Yönetilebilirlik başka bir nedendir, çünkü dağıtılmış sistemlerin yönetilmesi oldukça zordur. Ancak NoSQL'in önündeki en büyük engel, personeli yeniden eğitme ihtiyacıdır. Son 10 yılda, NoSQL dünyayı değiştirmeye çalışıyor, ancak çok az başarı elde etti. NoSQL şirketleri, 50 milyar dolarlık veritabanı pazar payının yalnızca küçük bir bölümünü oluşturuyor.
Yazılım mühendisleri NoSQL'den hoşlanıyor gibi görünse de, veri çalışanları (DBA'lar, veri mimarları ve veri analistleri) bunun tersini yapıyor. Çünkü bu, yeni API'leri, araçları ve ekolojiyi yeniden öğrenmeleri gerektiği anlamına gelir ve bu, yıllar içinde başarılı olan yöntemleri, modelleri ve deneyimleri terk etmeleri gerektiği anlamına gelir. Bir şeyler yapmak için kanıtlanmış modelleri kullanmak isterler, ancak yine de sistem dayanıklılığından, kullanılabilirliğinden ve güvenilirliğinden ödün vermeden ölçeklendirebilirler.
NoSQL'den NewSQL performansına ve ödün vermeden ölçeklendirin
MemSQL'i kullanmayı seçerken, öncelikle kullanıcıların ilişkisel veritabanlarının işlevlerini sevdiklerini, ancak sistemin kullanılabilirliğini ve güvenilirliğini genişletmek istediklerini varsayıyoruz. Hedefimiz her iki dünyanın en iyisi.
MemSQL, işlemleri ve analizi destekleyen ve donanım genişletmeyi destekleyen dağıtılmış bir ilişkisel veritabanıdır. MemSQL'de, tanıdık ilişkisel modeli, SQL sorgu sözdizimini ve devasa araç ekosistemini görebilirsiniz. Ölçeklenebilirlik ve kullanılabilirlik için modern, bulutta yerel sistemleri destekler.
Bunu NoSQL sistemlerinin temel farklılıklarıyla birlikte yeniden inceleyelim.
Tutarlılık ve performans dengesi
MemSQL, tutarlılık ve performans arasında bir değiş tokuş olabilecek bazı "düğmeler" sağlar. Takas kaçınılmazdır, ancak platform düzeyinde tutarlılığı ve performansı tartmanız gerekmez, kullanım durumu düzeyinde ikisi arasında seçim yapabilirsiniz.
Tutarlılık ve performans seçimi felsefi bir konu değil, uygulamanın gerçek durumuna ve ihtiyaçlarına dayalı bir seçimdir. MemSQL'in ayarlayabileceğiniz iki ayarı vardır. Birincisi, diskin kalıcı olmasını bekleyip beklememeye karar vermenize izin vermektir. İşlem diske devam ettirilmeden önce, bellekte bir arabellekte saklanır. Arabelleğe veya diske başarıyla eriştikten hemen sonra verileri iade edebilirsiniz. Arabelleğe ulaşmadan geri dönerse, kalıcılıktan önce makine başarısız olabilir veya yeniden başlayabilir ve veriler kaybolur. Öte yandan, verilerin diskte kalmasını beklemek daha fazla zaman alacaktır.
Buna ek olarak, MemSQL, yüksek kullanılabilirlik sağlamak için eşzamanlı çoğaltma ve eşzamansız çoğaltma olmak üzere iki eşleme modu sağlar. Bir makinedeki verilerin başka bir makinede kopyasının olmasını sağlamak için kopyalayarak. Çoğaltma eşzamanlı moda ayarlanmışsa, istemciye başarı getirmeden önce işlemin yedekleme sunucusunda alınmasını beklemeniz gerekir. Eşzamansız çoğaltma modu etkinleştirilirse, veriler yedekleme sunucusuna kopyalanmadan önce işlem başarılı olur. Bu size tutarlılık ve performans arasında bir denge kurma fırsatı verir.
Şekil: MemSQL 7.0 hızlı eşzamanlı çoğaltma ve eşzamanlı kalıcılık
Dağıtılmış sistemlerde mod bakımı
MemSQL modeli, meta verileri küçük bir dahili veritabanında depolayarak ve tüm düğümler değiştiğinde meta verileri eşzamanlı olarak çoğaltarak uygular. DDL değişikliklerinin, sorgu engellemesine neden olmayacak şekilde kümede doğru şekilde yayılmasını sağlamak için iki aşamalı kesinleştirme kullanır.
MemSQL, ilişkisel modellerden daha fazlasını destekler. Bir JSON sütunu girebilir ve bunu bir JSON belgesinde saklayabilirsiniz. Daha sonra bir sütunu sorgulamak isterseniz, özniteliği bir sütuna eşleyebilir ve dizine ekleyebilirsiniz. MemSQL ayrıca uzamsal türleri ve tam metin dizinlerini de destekler. Müşterilerin bilindik bir sistemde çeşitli veri türlerini karıştırması gerekir ve her tür veri doğal olarak bir arada bulunabilir.
SQL "ortak dilini" koruyun
Dağıtık veritabanlarında büyük ölçekli SQL sözdizimi kullanımı sorunu çözüldü. Dağıtılmış sorgu işlemcisi, sorguları ifade etmek için standart SQL sözdizimini kullanmanıza olanak tanır.Sistem, kümedeki her düğüme sorgu görevlerini atamaktan ve sonuçları özetlemenize yardımcı olmaktan sorumludur. MemSQL, tüm yaygın ANSI SQL operatörlerini ve işlevlerini destekler.
MemSQL, bu işlevi sistemdeki iki tür düğüm aracılığıyla gerçekleştirir: toplayıcı ve yaprak düğüm. Toplayıcı, dağıtılmış sistemin meta verilerini, yönlendirme sorgularını ve toplama sonuçlarını işler. Yapraklar verileri depolar ve bölümler üzerinde yoğun sorgular gerçekleştirir. Mümkünse, MemSQL bağlantıyı yerel olarak yürütür ve bu da şema tasarımının önemini gösterir. Değilse, MemSQL verileri gerektiği gibi yeniden düzenleyecektir. Bu nedenle müşteriler, verilerin nasıl bölümlendiğini bilmeden SQL dilini kullanabilir.
Şekil: MemSQL, verileri toplayıcılarda ve yaprak düğümlerde dağıtır
Bu, MemSQL'i şirketinizin zaten sahip olduğu beceriler, yatırımlar ve araçlarla kullanabileceğiniz anlamına gelir. İnsanlar, ek eğitime ihtiyaç duymadan diğer ilişkisel veritabanları gibi MemSQL'i kullanabilir. Ek olarak, MemSQL MySQL kablo protokolünü desteklediğinden, mevcut büyük ölçekli iş zekası (BI), ETL (veri çıkarma, dönüştürme ve yükleme) ve diğer ara yazılım araçlarının tümü MemSQL ile çalışabilir. Yeni çalışanlar işe almanıza, bir dizi yeni araç öğrenmenize veya yeni bir yazılım sunmanıza gerek yok. Sadece kullan.
NoSQL'e veda edin!
NoSQL'in ortaya çıkışı, Web uygulamalarının ve çok kiracılı hizmetlerin ölçek ihtiyaçlarını karşılamaktır. Bu sorunları çözmenin zorluğunu düşündüğünüzde, ilk günlerde depolama katmanında genişlediklerinde kullanıcıları neden zor takas yapmaya zorladıklarını anlayabilirsiniz.
Ancak ilişkisel veri tabanı da önemli ilerleme kaydetti. Neredeyse tüm iş yüklerinin üstesinden gelebilirler ve modern uygulamaların ölçeklenebilirlik, güvenilirlik ve kullanılabilirlik gereksinimlerini karşılayabilirler.
İş yükü, operasyonel analizi içerir. Tüm şirketler veriye dayalı olmanın değerini anladığında, tüm çalışanların en son verilere erişmesini isterler. Bunu yapmak için, yüzlerce eşzamanlı sorguya ölçeklenebilen, ön toplama olmadan hızlı sorgular sağlayabilen ve oluşturulduğunda verileri çıkarabilen yeni bir tür analiz sistemine ihtiyaç vardır. En önemli şey, müşterilere ve ortaklara verileri ifşa etmek istemeleridir; bu, bir operasyonel hizmet seviyesi anlaşması (SLA), güvenlik performansı, performans ve ölçek gerektirir ve mevcut veri depolaması imkansızdır. Bu, eski veritabanlarının ve NoSQL sistemlerinin sağlayamayacağı yeni işlevlerin gereksinimlerini karşılayan özelliklerden yalnızca biridir.
İlişkisel model zaman testine dayanmıştır ve MemSQL SingleStore gibi hala yenilikçidir. Ayrıca, yeni veri türlerini (arama, uzay, yarı yapılandırılmış vb.) Ve tutarlılık modellerini bir sistemde bir arada bulunabilmeleri için özümser. İlişkisel modellerde veya SQL sorgu sözdiziminde doğal ölçeklenebilirlik zorlukları yoktur. Ölçeklendirme mimarisinden yararlanmak için yalnızca farklı bir depolama uygulamasına ihtiyaç duyar.
MemSQL gibi yeni veritabanları, çoğu kullanım durumu için ilişkisel veritabanlarının kullanımının daha kolay olduğunu ve genellikle NoSQL sistemlerinden daha iyi performans gösterdiğini kanıtlamıştır.
Teşekkürler NoSQL, bulut ölçekli bir dünyanın zorluklarını çözmek için veritabanı topluluğuna baskı uyguladınız. Bu numara çok iyi çalışıyor. Ancak ilişkisel veritabanları bu ihtiyaçları karşılayabilecek kadar gelişti, öyleyse bir sonraki aşamaya geçelim.
https://www.usenix.org/legacy/event/lisa07/tech/full_papers/hamilton/hamilton_html/index.html
Türkçe: Yardımınız için Teşekkür Ederiz NoSQL, Ama Onu Buradan Aldık
Bağlantı: https://www.memsql.com/blog/why-nosql-databases-wrong-tool-for-modern-application/
Yazar hakkında: Rick Negrin. Rick, MemSQL'in ürün yönetimi ekibinden sorumludur ve 12 yıldır Microsoft'ta, çoğu zaman SQL Server ekibinde çalışmaktadır.
Çevirmen: Mingmingruyue, tanınmış bir İnternet şirketi Java kıdemli geliştirme mühendisi, CSDN blog uzmanı.
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
