Sql veya NoSql, bu makaleyi okuduktan sonra anlayacaksınız
Önsöz
Sistemin veritabanının büyük bir trafik akışında neredeyse CPU ile dolu olduğu gerçeğinden mi endişeleniyorsunuz? Çeşitli NoSql'lere karıştınız mı, hangisi en iyisi? Bugünün dünün benim, bu da bu makaleyi yazmanın asıl amacı.
Bu makale birkaç aydır yazmak istediğim bir makale ve her zaman öğrenmek istediğim bir şeydi.İnternet uygulayıcıları olarak ilişkisel veritabanlarının (MySql, Oracle) tüm depolama gereksinimlerimizi karşılayamayacağını bilmeliyiz. Bu nedenle, temel depolamanın seçimi, her bir depolama motorunun anlaşılması çok önemlidir. Aynı zamanda geçmiş dönemdeki iş tecrübemden dolayı bu alanla ilgili biraz daha düşüncelerim var ve bunu kendi özetimle yazmak ve herkesle paylaşmak istiyorum.
Yapılandırılmış veriler, yapılandırılmamış veriler ve yarı yapılandırılmış veriler
Yazının başında yapılandırılmış veriler, yapılandırılmamış veriler ve yarı yapılandırılmış verilerden bahsedelim, veri özelliklerindeki farklılıklar nedeniyle depolama motoru teknolojisi seçimini doğrudan etkileyecektir.
İlki, tanım gereği yapılandırılmış verilerdir Yapılandırılmış veriler, mantıksal olarak ifade edilen ve iki boyutlu bir tablo yapısı tarafından gerçekleştirilen, veri formatını ve uzunluk spesifikasyonunu kesinlikle takip eden, aynı zamanda satır verileri olarak da bilinen verileri ifade eder. Özellikler şunlardır: veriler davranış birimlerindedir, bir veri satırı bir varlığın bilgilerini temsil eder ve her veri satırının öznitelikleri aynıdır. Örneğin:
Bu nedenle ilişkisel veritabanları, yapılandırılmış verilerin özelliklerine mükemmel bir şekilde uyar ve ilişkisel veritabanları da ilişkisel veriler için ana depolama ve yönetim motorudur.
Yapılandırılmamış veriler, Düzensiz veya eksik veri yapısı, önceden tanımlanmış herhangi bir veri modeli olmadan, verileri temsil etmek için iki boyutlu mantık tablosu kullanmak uygun değildir Ofis belgeleri (Word), metin, resimler, HTML, çeşitli raporlar, video ve ses vb.
Yapılandırılmış ve yapılandırılmamış veriler arasındaki veriler yarı yapılandırılmış verilerdir, yapılandırılmış bir veri biçimidir, ancak İki boyutlu mantığın veri modeli yapısına uymaz, ancak anlamsal öğeleri ve katman kayıtlarını ve alanlarını segmentlere ayırmak için ilgili etiketleri içerir . Yaygın yarı yapılandırılmış veriler XML ve JSON'dur, örneğin:
< kişi > < isim > Zhang San < / isim > < yaş > 18 < /yaş > < telefon > 12345 < /telefon > < /kişi >Bu yapıya kendi kendini tanımlayan yapı da denir.
İlişkisel bir veritabanında depolama mimarisinin evrimi
İlk olarak, ilişkisel veritabanlarını kullanma yöntemine ve bir kuruluştaki bir sistemin geliştirilmesindeki çeşitli aşamaların mimarisinin evrimine bir göz atalım (çünkü bu makale Sql ve NoSql ile ilgilidir, bu nedenle giriş noktası olarak yalnızca depolama yöntemi kullanılır ve MQ ve ZK diye bir şey yoktur. Ara yazılım içeriği):
Aşama 1: Kuruluşun henüz geliştirdiği en basit aşama Bir uygulama sunucusu ilişkisel bir veritabanı ile donatılmıştır ve veritabanı her seferinde okunur ve yazılır.
Aşama 2: İster MySQL ister Oracle veya diğer ilişkisel veritabanları kullanıyor olun, veritabanı genellikle ilk olarak bir performans darboğazı haline gelmez. Genellikle, kuruluş ölçeği genişledikçe, bir uygulama sunucusu yukarı akış trafiğini işleyemez ve bir uygulama sunucusu Tek bir hata noktası sorunu vardır, bu nedenle bir uygulama sunucusu ekleyin ve trafiğin uygulama sunucusuna eşit olarak dağıtılmasını sağlamak için bir yük dengeleme katmanı yapmak için trafik girişinde Nginx kullanın.
Aşama 3: İşletmenin ölçeği genişlemeye devam ettikçe, şu anda, okuma ve yazma işlemlerinin tümü aynı veri tabanında olduğu için, veri tabanı performansında belirli bir darboğaz vardır. Şu anda, bir okuma ve yazma ayrımı katmanı basitçe gerçekleştirilir ve her defasında ana veri tabanı yazılır ve yedek veri tabanı okunur Ana ve yedek veritabanları arasında binlog aracılığıyla veri senkronizasyonu, bu aşamadaki veritabanı performans sorunlarını büyük ölçüde çözebilir
Aşama 4: İş geliştirme gittikçe daha iyi hale geliyor, iş büyüyor ve büyüyor, veri tabanının baskısı, ayrımı okuduktan ve yazdıktan sonra hala artıyor, şu anda ne yapmalıyız, bir veri tabanı onu tutamaz, sonra onu birkaç taneye böleriz Veritabanını ve tabloyu ayıralım, tabloyu dikey olarak ayıralım ve kitaplığı yatay olarak bölelim. Veritabanının genişletilmesi örnek olarak ele alındığında, belirli bir sipariş numarası (işlem bilet numarası gibi) ve belirli bir kural (modulo gibi) ile iki veritabanı genişletilir İşlem bilet numarası modulo 2, veritabanı 1'e bırakılır. İşlem bilet numarası modulo 2, veri tabanına 2 atılır. Bu şekilde, veri tabanı yazma trafiği iki veri tabanı arasında eşit olarak bölünür. Genel olarak, alt veritabanı ve alt tablo, bağlantı yönetimi, veri izleme için uygun olan ve müşterinin veritabanı ipini algılaması gerekmeyen bir ara katman yazılımı aracılığıyla Shard yöntemini kullanacaktır.
İlişkisel veritabanlarının avantajları
Yukarıdaki yöntem problemi çözebilir gibi görünmektedir (aslında birçok problemi çözebilir) Normalde ilişkisel veritabanı için normal bir okuma-yazma ayrımı + alt veritabanı alt tablosu yapmak ve 1W + okuma ve yazma QPS'yi desteklemek büyük bir problem değildir. Bununla birlikte, ilişkisel veritabanının kendisi ile sınırlı olan bu mimari çözümün hala bariz eksiklikleri vardır.Aşağıda, ilişkisel veritabanı yöntemini kullanarak depolama çözümünün avantajlarını analiz edecek ve daha sonra ikinci kısımdaki dezavantajları analiz edeceğiz. Avantaj ve dezavantajların tam olarak anlaşılması, teknoloji seçimi için bir ön koşuldur.
- Anlaması kolay
- Satır + sütun iki boyutlu tablo mantığı mantıksal dünyaya çok yakın bir kavram olduğundan, ilişkisel modelin anlaşılması ağ ve hiyerarşi gibi diğer modellere göre daha kolaydır.
- Çalıştırması kolay
- Genel SQL dili, ilişkisel veritabanlarını çalıştırmayı çok kolaylaştırır ve birleştirme gibi karmaşık sorguları destekler
- Veri tutarlılığı
- ACID özelliklerini destekler ve veriler arasındaki tutarlılığı koruyabilir.Bu, veritabanını kullanmanın en önemli nedenlerinden biridir.Örneğin, aynı bankaya para aktarırken Zhang San, Li Si'ye 100 yuan aktarır, Zhang San 100 yuan kesinti yapar ve Li Si, 100 yuan ekler. Ve aynı anda başarılı veya başarısız olmalıdır, aksi takdirde kullanıcının sermaye kaybına neden olur
- Veri kararlı
- Veriler diske saklanır, veri kaybı riski yoktur ve büyük miktarda veri depolama desteklenir
- Kararlı hizmet
- En yaygın kullanılan ilişkisel veritabanı ürünleri olan MySql ve Oracle sunucuları mükemmel performansa ve istikrarlı hizmetlere sahiptir ve genellikle birkaç anormal kesinti süresi vardır.
İlişkisel veritabanlarının dezavantajları
Daha sonra, ilişkisel veri tabanlarının daha belirgin olan eksikliklerine bakıyoruz.
- Yüksek eşzamanlılık altında yüksek IO basıncı
- Veriler satırlar halinde saklanır, sütunlardan yalnızca biri hesaplansa bile, tüm veri satırı depolama cihazından belleğe okunur ve bu da yüksek GÇ ile sonuçlanır.
- Dizini korumanın maliyeti yüksektir
- Zengin sorgu yetenekleri sağlamak için, sıcak tablolar genellikle birden çok ikincil dizine sahiptir. İkincil dizinler olduğunda, verilerin eklenmesi zorunlu olarak tüm ikincil dizinlerin eklenmesine eşlik edecek ve verilerin güncellenmesi kaçınılmaz olarak tüm ikincil dizinlere eşlik edecektir. İlişkisel veritabanlarının okuma ve yazma yeteneğini kaçınılmaz olarak azaltan ve indeksler ne kadar fazlaysa, okuma ve yazma becerisi de o kadar kötü olur. Fırsatınız varsa, şirketinizin veritabanına bir göz atabilirsiniz.Veri dosyalarının kaçınılmaz olarak yer kaplamasına ek olarak, dizin aslında çok fazla yer kaplar.
- Veri tutarlılığını korumanın maliyeti yüksektir
- Veri tutarlılığı, ilişkisel veritabanlarının özüdür, ancak veri tutarlılığını sürdürmenin maliyeti de çok yüksektir. Hepimiz SQL standardının işlemler için farklı izolasyon seviyeleri tanımladığını biliyoruz. Düşükten yükseğe, bunlar taahhüt edilmemiş, okunmuş, tekrarlanabilirlik ve serileştirme olarak okunur. İşlem izolasyon seviyesinin sonunda, daha fazla eşzamanlı istisnalar meydana gelebilir, ancak Genel olarak konuşursak, daha fazla eşzamanlılık sağlanabilir. İşlem tutarlılığını sağlamak için, veritabanının iki teknoloji sağlaması gerekir: eşzamanlılık kontrolü ve hata kurtarma. İlki, eşzamanlılık istisnalarını azaltmak için kullanılır ve ikincisi, sistem anormal olduğunda işlem ve veritabanı durumunun yok edilmemesini sağlayabilir. Eşzamanlılık kontrolü için temel fikir, ister iyimser bir kilit ister kötümser bir kilit olsun, sağlanan izolasyon seviyesi ne kadar yüksekse, okuma ve yazma performansı o kadar kötü olacaktır.
- Yatay genişlemeden sonra her türlü problemin üstesinden gelmek zor
- Yukarıda belirtildiği gibi, işletmenin ölçeği genişledikçe, bir yol veri tabanını bölmektir.Ayrılma yapıldıktan sonra veri geçişi (bir veri tabanından veri belirli kurallara göre iki veri tabanına aktarılır), veri tabanları arası birleştirme (sipariş Verilerde kullanıcı verileri vardır ve iki veri parçası aynı veri tabanında değildir), dağıtılmış işlem işleme, dikkate alınması gereken konulardır, özellikle dağıtılmış işlem işleme, sektörün şu anda özellikle iyi bir çözümü yoktur
- Tablo yapısı genişletmesi uygun değil
- Veritabanı yapılandırılmış verileri depoladığından, tablo yapısı şeması sabittir ve genişletilmesi uygun değildir. Tablo yapısını değiştirmeniz gerekirse, DDL (veri tanımlama dili) deyim değişikliği yapmanız gerekir.Değişiklik sırasında tablo kilitlenecek ve bazı hizmetler kullanılamayacaktır.
- Tam metin arama işlevi zayıf
- Örneğin, "% Çin gerçekten harika%" gibi, yalnızca "2019 Çin gerçekten harika, ana vatanı seviyor" şeklinde arama yapabilirsiniz, ancak "Çin gerçekten harika" gibi metinleri arayamazsınız, yani kelimeleri segmentlere ayırma yeteneği yoktur ve benzer sorgu içerisindedir. "% Çin harika" gibi arama koşullarında, dizine ulaşılamaz ve bu da sorgu verimliliğini büyük ölçüde azaltır
Bu kadar çok yazdıktan sonra, anlayışımın özü ilk üç nokta Yüksek eşzamanlılık altında ilişkisel veri tabanlarının yeteneğinin, özellikle sık yazma / güncelleme durumunda darboğaz olması bir sorunu yansıtıyor. Yani, veritabanı CPU'su yüksek, Sql yürütmesi yavaş ve müşteri, yetersiz veritabanı bağlantı havuzu gibi hataları bildiriyor.Bu nedenle, örneğin 10.000 spike senaryosunda, veritabanı üzerinden doğrudan envanter çıkarmamız kesinlikle imkansız.
Bazı arkadaşlar yüksek eşzamanlılık altında veri tabanının kabiliyetinde bir darboğaz olduğunu söyleyebilir.Firmamızın parası var.İşlemci eklemek, katı hal sürücülere geçmek, alt veri tabanları için sunucu ve veri tabanı almaya devam etmek daha iyidir.Sorun, bunun çok düşük maliyetli bir performans olmasıdır. 10 milyon harcama ile elde edilen etki yöntemi, 1 milyonluk başka bir yöntemle sağlanabilir.Personel ve sunucuların girdi-çıktı oranını dikkate almayan bir lider, niteliksiz bir liderdir ve ilişkisel veri tabanı yöntemi kendisiyle sınırlıdır. Özellikler, para harcadıktan sonra bile istenen etkiyi elde edemeyebilir. 1 milyon harcayarak 10 milyon harcamanın yolu nedir? Aşağıya bakmaya devam edebilirsiniz, bu bahsettiğimiz NoSql.
NoSql ile birleştirilmiş depolama mimarisinin evrimi
Yukarıda analiz edildiği gibi, ilişkisel bir veri depolama motoru olarak, veritabanı ilişkisel verileri depolar.Açık dezavantajların yanı sıra avantajları da vardır.Bu nedenle, genellikle kurumsal ölçeğin sürekli genişlemesi durumunda, körü körüne geçmeyi beklemeyecektir. Veritabanının veri depolama sorununu çözme yeteneğini geliştirin, ancak NoSql olarak adlandırdığımız diğer depolamayı tanıtacaktır.
NoSql'in tam adı, genellikle ilişkisel olmayan veritabanlarına atıfta bulunan Yalnızca SQL Değildir.İlişkisel veritabanlarına bir tamamlayıcıdır.Bu iki kelimeyi tamamlamaya özellikle dikkat edin.Bu, NoSql ve ilişkisel veritabanlarının birbirine zıt olmadığı anlamına gelir. Artıları ve eksileri, birbirlerinin güçlü yönlerinden öğrenmek ve doğru senaryoda doğru depolama motorunu seçmek doğru yaklaşımdır.
Daha basit NoSql önbelleğe almaktır:
Yazılandan daha fazla okunan veriler için bir önbellek katmanı eklenir.Her okuma önbellekten okunur.Önbellekten okunamıyorsa veritabanından alınır.Aldıktan sonra önbelleğe yazılır. Başarısızlık mekanizması genellikle büyük bir sorun değildir. Genel olarak konuşursak, önbelleğe alma, performans optimizasyonu için ilk tercihtir ve en etkili çözümdür.
Bununla birlikte, önbellekler genellikle KV tipi depolamadır ve tüm sorunları çözemeyen sınırlı kapasiteye (belleğe dayalı) sahiptir, bu nedenle daha fazla optimizasyon, diğer NoSql'leri sunmaya devam ediyoruz:
Veritabanı ve önbellek, diğer NoSql ile paralel olarak çalışır ve her bir NoSql'in özelliklerini tam olarak oynar. Tabii ki, NoSql performans açısından ilişkisel veritabanından çok daha iyidir, ancak çoğu zaman bazı özelliklerin eksikliği ile birlikte gelir.En yaygın olanı işlem fonksiyonlarının olmamasıdır.
Yaygın olarak kullanılan NoSql ve bunların temsili ürünlerine bir göz atalım ve her bir NoSql'nin özelliklerine aşina olmak ve teknik seçimi kolaylaştırmak için her NoSql'nin avantajlarını ve dezavantajlarını ve uygulanabilir senaryolarını analiz edelim.
KV NoSql (Temsilci ---- Redis)
KV NoSql, adından da anlaşılacağı gibi, anahtar-değer çiftleri şeklinde depolanan ilişkisel olmayan bir veritabanıdır.En basit, anlaşılması en kolay ve en tanıdık NoSql'dir, bu nedenle hızlı bir şekilde tanıtılacaktır. Redis ve MemCache temsilcilerdir. Redis, KV tipi NoSql arasında en yaygın kullanılan NoSql'dir. KV tipi veritabanı, örnek olarak Redis'i kullanır. En büyük avantajlar iki nokta:
- Veriler, yüksek okuma ve yazma verimliliğiyle belleğe dayalıdır
- KV verileri, zaman karmaşıklığı O (1) ve sorgu hızı hızlı
Bu nedenle, KV tipi NoSql'in en büyük avantajı yüksek performanstır.Karşılaştırma testi için Redis ile birlikte gelen BenchMark'ı kullanarak, TPS 100.000 seviyesine ulaşabilir ve performans çok güçlüdür. Aynı Redis'in, tüm KV tipi NoSql'in sahip olduğu bariz eksiklikleri de vardır:
- Yalnızca V'yi K'ye göre kontrol edebilir, ancak V'ye göre K'yi kontrol edemez
- Sorgu yöntemi tektir, yalnızca KV yöntemidir ve koşullu sorguları desteklemez. Çok koşullu sorgular için tek yol veri yedekliliğidir, ancak bu, depolama alanını büyük ölçüde boşa harcayacaktır.
- Bellek sınırlıdır, büyük miktarda veri depolamayı destekleyemez
- Benzer şekilde, KV NoSql'in depolanması belleğe dayalı olduğundan, veri kaybı riski vardır.
Özetle, KV NoSql için en uygun senaryo önbelleğe alınmış senaryodur:
- Yazmaktan çok daha fazlasını okuyun
- Güçlü okuma yeteneği
- Kalıcılığa gerek yoktur ve veri kaybı tolere edilebilir, neyse, kaybolursa sorgulayın ve yazın.
Örneğin, kullanıcı bilgilerini kullanıcı kimliğine göre sorgulayın, her seferinde önbelleği kullanıcı kimliğine göre sorgulayın ve verileri doğrudan geri döndürün, yoksa ilişkisel veritabanındaki kimliğe göre verileri sorgulayın ve önbelleğe yazın.
Arama NoSql (---- ElasticSearch'ü temsil eder)
Geleneksel ilişkisel veritabanları, hızlı sorgu amaçlarına ulaşmak için esas olarak dizinleri kullanır, ancak tam metin araması bağlamında, dizinler güçsüzdür.Sorgular gibi, tüm belirsiz eşleştirme gereksinimlerini karşılayamaz ve ikinci olarak, kullanım sınırı çok büyüktür ve yanlış kullanım yavaşlığa neden olabilir. Sormak, Aramaya dayalı NoSql'in doğuşu, ilişkisel veritabanlarında zayıf tam metin arama yetenekleri sorununu çözmektir. ElasticSearch, aramaya yönelik NoSql'in temsili ürünüdür.
Tam metin aramanın ilkesi tersine çevrilmiş bir dizindir. Şimdi ters çevrilmiş dizinin ne olduğuna bir bakalım. Tersine çevrilmiş bir dizinden bahsetmek için, önce ileriye doğru dizinin ne olduğuna bakalım. Geleneksel ileriye doğru dizin bir belgedir - > "Tom benim arkadaşım" cümlesi gibi anahtar kelimelerin eşleştirilmesi, onu dört kelimeye böler: "Tom", "eşittir", "benim" ve "arkadaşım" ve arama yaparken belgeyi tarayın. Koşulları karşılayanları bulun. Bu yöntemin prensibi çok basittir, ancak düşük erişim verimliliği nedeniyle, temelde pratik bir değeri yoktur.
Tersine çevrilmiş indeks tam tersidir, bu bir anahtar kelimedir - > Bir tabloda gösterirsem belgenin eşlemesi daha net:
Şu anda dört cümle var demek: "Tom Tom", "Tom benim arkadaşım", "Teşekkür ederim Betty" ve "Tom Betty'nin kocası" Arama motorları bu cümleyi belirli bölümleme kurallarına göre kesecek. N anahtar kelime oluşturun ve anahtar kelime boyutundaki her metinde anahtar kelimelerin geçtiği sayıları koruyun. Dolayısıyla, bir dahaki sefere "Tom" araması yaptığınızda, Tom kelimesi "Tom Tomdur", "Tom benim arkadaşım" ve "Tom Betty'nin kocasıdır" şeklinde üç cümlede göründüğü için bu üç kayıt alınacaktır. , Ve "Tom", "Tom is Tom" cümlesinde iki kez geçtiğinden, bu kayıt "Tom" kelimesiyle en yüksek eşleşmeye sahiptir ve ilk olarak görüntülenir. Bu, arama motoru tersine çevrilmiş dizinin temel ilkesidir. Belli bir anahtar kelimenin bir belgede göründüğünü varsayarsak, ters çevrilmiş dizinde iki bölüm vardır:
- Belge Kimliği
- Belgede göründüğü yer
Aynı şekilde "Betty Tom" iki kelimesini aradığımız sonucuna varılabilir. Arama motoru, geliştirici tarafından belirtilen memnuniyet oranına göre "Betty Tom" ve "Betty" olmak üzere iki kelimeye böler, örneğin, memnuniyet oranı = 50 %, ardından iki kelimeden biri kayıtta göründüğü sürece, kayıt alınır ve ardından eşleşme derecesine göre görüntülenir.
Arama NoSql, ElasticSearch'ü örnek olarak alır. Avantajları şunlardır:
- İlişkisel veritabanlarından farklı olan en büyük özellik olan kelime segmentasyon senaryolarını, tam metin aramasını destekler
- Koşullu sorgulamayı destekleyin, ilişkisel veritabanının Grup By'sine benzer şekilde toplama işlemini destekleyin, ancak veri analizi için uygun daha güçlü işlevlerle
- Veri yazma dosyası kaybı riski yoktur ve bir küme ortamında yatay olarak kolayca genişletilebilir ve PB düzeyinde verileri taşıyabilir
- Verilerin güvenli ve erişilebilir olmasını sağlamak için yüksek kullanılabilirlik, yeni veya başarısız düğümlerin otomatik keşfi, verilerin yeniden düzenlenmesi ve yeniden dengelenmesi
Benzer şekilde, ElasticSearch de bariz dezavantajlara sahiptir:
- Performans, onu kullanırken dikkat edilmesi gereken en önemli şey olan belleğe bağlıdır.Donanım kaynaklarını ve belleği tüketir. 64G + SSD temelde büyük veri hacmi altında standart yapılandırmadır ve veritabanında Hermes olarak kabul edilebilir. Neden özellikle hafızadan bahsetmeliyim? Çünkü hafıza çok değerlidir. Aynı konfigürasyon için hafızayı ikiye katlayın ve ayda yüzlerce dolara mal olacak. ElasticSearch hafızasının kullanıldığı yerlere gelince, muhtemelen aşağıdakiler vardır:
- İndeksleme Tamponu ---- ElasticSearch, Luence'e dayanır. Lucene'nin ters çevrilmiş indeksi önce bellekte oluşturulur ve ardından disk, Segment Dosyası biçiminde periyodik olarak temizlenir. Her Segment Dosyası aslında tam tersine çevrilmiş bir indekstir
- Segment Belleği ---- Daha önce bahsedilen ters indeks anahtar kelimelere dayanmaktadır. 4.0'dan sonra, Lucene, sorguyu hızlandırmak için başlangıçta FST veri yapısı biçiminde tüm anahtar kelimeleri belleğe yükleyecektir. Hız, resmi öneri, sistem belleğinin en az yarısını Lucene'ye bırakmaktır.
- Sorgu analizi performansını iyileştirmek için kullanılan çeşitli önbellekler - Filtre Önbelleği, Alan Önbelleği, Dizin Oluşturma Önbelleği vb., Örneğin, Filtre Önbelleği, kullanılan Filtrenin sonuç kümesini önbelleğe almak için kullanılır.
- Cluter State Buffer ---- ElasticSearch, her Düğümün kullanıcı isteklerine yanıt verebilmesi için tasarlanmıştır, böylece her Düğümün belleği küme durumunun bir kopyasını içerir. Büyük ölçekli bir küme için bu durum bilgisi çok büyük olabilir
- Okuma ve yazma arasında bir gecikme var. Yazılan veriler neredeyse 1 saniye boyunca okunacak. Bu normaldir. Yazarken otomatik olarak bu kadar çok dizinin eklenmesi performansı kesinlikle etkileyecektir
- Veri yapısının esnekliği yüksek değildir. ElasticSearch için, bir alan oluşturulduktan sonra tür değiştirilemez. Oluşturulan veri tablosundaki bir alanın tam metin dizini yoksa ve onu eklemek istiyorsanız, yalnızca tüm tabloyu silebilir ve yeniden oluşturabilirsiniz
Bu nedenle, arama türü NoSql için en uygun senaryo, ilişkisel veritabanlarına alternatif olarak koşullu arama, özellikle tam metin arama senaryosudur.
Ek olarak, arama veritabanları için özellikle önemli bir uygulama senaryosu vardır. Veritabanı tablolara bölündüğünde tek bir tabloda yapılabilecek tüm toplama işlemleri ve istatistiksel işlemler başarısız olur mu diye düşünebiliriz. Örneğin sipariş tablosunu 1024 tablo içeren 16 veri tabanına bölersem emir verisi 1024 tabloya dağılır.Dün Zhejiang Eyaletinde en yüksek işlem tutarının hangi siparişe sahip olduğunu saymak istiyorum, nasıl yapılır? Dünkü tüm siparişleri kronolojik sırayla görüntülemek istiyorum, ne yapmalıyım? Bu, belge tabanlı NoSql'nin bir başka önemli işlevidir.Belge tabanlı NoSql'de alt tablolardan sonra verileri birleştirebilir ve tüm verilerin sorgusunu tamamlamak için belge tabanlı NoSql'in arama ve toplama yeteneklerini kullanabiliriz. .
İkinci yazma olarak KV tipi NoSql'den sonra neden konulduğuna gelince, çünkü genellikle arama tipi NoSql, ilişkisel veritabanını korumak için bir ön önbellek katmanı görevi de görür.
Sütunlu NoSql (temsilci-HBase)
Büyük veri çağındaki en temsili teknolojilerden biri olan Columnar NoSql, HBase tarafından temsil edilmektedir.
Sütunlu NoSql sütunlu depolamaya dayanır. Peki sütunlu depolama nedir? Sütunlu SQL ve ilişkisel veritabanları birincil anahtar kavramına sahiptir. Aradaki fark, ilişkisel veritabanlarının verileri satırlar halinde düzenlemesidir:
Her satırda üç alan olduğunu görebilirsiniz: isim, telefon ve adres Bu bir satır saklama yöntemidir ve verileri id = 2 ile gözlemleyebilirsiniz. Telefon alanı olmasa bile, yine de yer kaplar.
Sütunlu depolama tamamen başka bir yoldur, her sütun tarafından düzenlenen verilerdir:
Bunu yapmanın faydaları nelerdir? Kabaca aşağıdaki noktalar var:
- Sorgulama sırasında yalnızca belirtilen sütunlar okunacak, tüm sütunlar değil
- Depolamada yer kazanın, Null değerler depolanmaz, bazen bir sütunda çok sayıda yinelenen veri olur (özellikle numaralandırılmış veriler, cinsiyet, durum vb.), Bu tür veriler sıkıştırılabilir, satır veritabanının sıkıştırma oranı genellikle 3: 1'dir. ~ 5: 1 arasında, sütunlu veritabanlarının sıkıştırma oranı genellikle 8: 1 ~ 30: 1 civarındadır.
- Sütun verileri birlikte düzenlenir, bir disk IO bir seferde bir veri sütununu belleğe okuyabilir
İkinci nokta veri sıkıştırmayla ilgili. Bu ne anlama geliyor? Örnek olarak daha yaygın bir sözlük tablosu sıkıştırma yöntemini ele alalım:
Anlamak için resme dikkatlice bakın, anlamalısınız.
Ardından HBase tarafından temsil edilen sütun tipi NoSql'in avantajları ve dezavantajları hakkında konuşmaya devam edin, avantajları şunlardır:
- HDFS'ye (Hadoop dosya sistemi) dayalı, büyük miktarda verilerin sınırsız depolanması, PB düzeyinde verilerin rastgele depolanması, veri kalıcılığı
- Veri bağlantı noktalarına neden olacak kötüye kullanım olmadığı sürece iyi okuma ve yazma performansı, temelde rasgele oynayın
- Yatay genişletme, ilişkisel veritabanlarında ve ilişkisel olmayan veritabanlarında en uygun olanlardan biridir.Veri kapasitesinde doğrusal büyüme elde etmek için yalnızca yeni makineler eklemeniz gerekir ve maliyetten tasarruf etmek için ucuz sunucularda kullanılabilir.
- Tek bir hata noktası yok, yüksek kullanılabilirlik
- Yapılandırılmış veya yarı yapılandırılmış verileri depolayabilir
- Sütun sayısı teorik olarak sınırsızdır.HBase'in kendisi yalnızca sütun ailesi sayısı için gereksinimlere sahiptir. 1 ~ 3 önerilir
- HBase'nin birçok avantajını söyledikten sonra, HBase'nin dezavantajlarından bahsetmenin zamanı geldi:
- HBase, Hadoop ekosisteminin bir parçasıdır, bu nedenle kendisi nispeten ağır bir üründür ve birçok Hadoop bileşenine dayanır.Veri ölçeği büyük ve gereksiz değildir ve işletim ve bakım hala biraz karmaşıktır.
- KV stili, koşullu sorguyu desteklemez veya koşullu sorgu çok, çok zayıf. HBase, Tarama bir grup veriyi taradığında yine de önek eşleştirme API'si sağlar. Veri fazlalığı için birden fazla Satır Anahtarı tanımlanmadıkça koşullu sorgu
- Toplam veri sayısı sayılamadığı için sayfalama sorgusu desteklenmiyor
Bu nedenle, HBase, gelecekte veri büyümesinin tahmin edilemediği KV tipi senaryolar için daha uygundur.Ayrıca, HBase kullanımı, esas olarak RowKey'in tasarımına yansıyan belirli bir deneyim gerektirir.
Belge NoSql (Temsilci-MongoDB)
Açıkçası, iş tecrübeme göre, belge tabanlı NoSql kullanımında nispeten sığ bir deneyime sahibim, bu nedenle bu bölüm size kaba bir giriş sağlamak için yalnızca önceki makaleler ve çevrimiçi makaleler ile birlikte kullanılabilir.
Belge türü NoSql nedir? Belge türü NoSql, yarı yapılandırılmış verileri belgeler olarak depolayan bir NoSql anlamına gelir. Belge türü NoSql genellikle verileri JSON veya XML biçiminde depolar. Bu nedenle, belge türü NoSql'de Şema yoktur, çünkü Şema yoktur Özellikleri ile, verileri istediğimiz zaman saklayabilir ve okuyabiliriz, bu nedenle NoSql belgesinin ortaya çıkışı, ilişkisel veritabanı tablo yapısının uygunsuz genişlemesi sorununu çözmektir.
MongoDB, belge tabanlı NoSql'in temsili ürünüdür ve ayrıca tüm NoSql ürünlerindeki yıldız ürünlerden biridir, bu nedenle MongoDB burada örnek olarak alınmıştır. Anladığıma göre, belge tabanlı bir NoSql olarak MongoDB, ilişkisel veritabanları ile tamamen uyumlu bir ürün. Depolama açısından:
Gördüğünüz gibi ilişkisel veritabanı her alan için adım adım bir sütunda, MongDB'de ise JSON dizesi olarak saklanıyor. İlişkisel veriler isim ve telefon için indekslenebilir. MongoDB ayrıca createIndex komutunu kullanarak sütunları indeksleyebilir. İndekslemeden sonra, sorgu verimliliği büyük ölçüde iyileştirilebilir. Diğer açılardan, temel kavramlar söz konusu olduğunda, ikisi temelde benzerdir:
Bu nedenle, MongDB için, onu yalnızca bir Serbest Şema ilişkisel veritabanı olarak anlamamız gerekir. Avantajları ve dezavantajları bir bakışta nispeten açıktır. Avantajları:
- Önceden tanımlanmış alan yok, alanları genişletmesi kolay
- İlişkisel veritabanı ile karşılaştırıldığında, okuma ve yazma performansı daha üstündür, ikincil dizine ulaşan sorgu ilişkisel veritabanından daha yavaş olmayacaktır ve dizine eklenmemiş alan sorgusu genel bir kazançtır
Dezavantajlar:
- Mongodb 4.0, işlemleri desteklediğini iddia etse de işlem işlemlerini desteklemiyor, ancak etki görülmeye devam ediyor
- Birden çok tablo arasındaki ilişkilendirme sorguları desteklenmez (belgeleri yerleştirmenin yolları olsa da), birleştirme sorguları yine de birden çok işlem gerektirir
- Alan çok yer kaplar Bu MongDB'nin bir tasarım problemidir. Alan ön tahsis mekanizması + alan, veriler silindikten sonra serbest bırakılmaz.Onu onarmak için sadece db.repairDatabase () kullanılabilir.
- Şu anda, MongoDB'de olgun bir işletim ve bakım aracı olan MySql'in Navicat'ı gibi ilişkisel bir veritabanı yoktur.
Sonuç olarak, MongDB'nin kullanım senaryoları büyük ölçüde ilişkisel veri tabanlarına karşı kullanılabilir, ancak birleşimleri olmayan, güçlü tutarlılık gereksinimleri olmayan ve tablo şeması sıklıkla değişen verileri işlemek için daha uygundur.
Özet: Veritabanı ile NoSql ve çeşitli NoSql arasında karşılaştırma
Son bölüm bir özettir. Son tahlilde bu makale iki konu hakkındadır:
- İlişkisel veritabanı ne zaman ve ilişkisel olmayan veritabanı ne zaman seçilir?
- İlişkisel olmayan veritabanının kullanılacağı ilişkisel olmayan bir veritabanı seçin
Her şeyden önce, ilk konu, ilişkisel veri tabanı ve ilişkisel olmayan veri tabanı seçimi benim anlayışıma göre iki düşünceden başka bir şey değildir:
İlk nokta, çok fazla açıklama anlaşılmamalıdır, ilişkisel olmayan veritabanları, daha yüksek performans elde etmek için ACID özelliklerinden ödün verilerek elde edilir, iki tablo arasında güçlü bir tutarlılık gerekliliği olduğu varsayılırsa, bu tür veriler İlişkisel olmayan veritabanları için uygundur.
İkinci nokta, temel verilerin, kullanıcı tabloları ve sipariş tabloları gibi ilişkisel olmayan veritabanlarını kullanmamasıdır, ancak bu tür temel verilerin birden çok sorgu moduna sahip olduğu bir öncül vardır.Örneğin, kullanıcı tablosunun temel alabileceği dört ABCD alanı vardır. AB kontrolü, temel verileri varsayarak, AC kontrolüne dayalı olabilir, belki D kontrolüne dayalı olabilir, ancak bu, kullanıcının sohbet geçmişi gibi bir KV formudur, daha sonra HBase kaydedilir kaydedilmez yapılacaktır.
Son birkaç yıldaki iş deneyiminden yola çıkarak, temel olmayan veriler, özellikle günlükler ve ardışık düzenler gibi ara veriler ilişkisel veritabanlarına yazılmamalıdır.Bu tür veriler genellikle iki özelliğe sahiptir:
- Yazmak okumaktan çok daha yüksek
- Büyük yazma hacmi
İlişkisel veritabanı depolama motoru olarak kullanıldığında, ilişkisel veritabanının yeteneği büyük ölçüde azalacaktır.Normal okuma ve yazma için düşük QPS'ye sahip çekirdek hizmetler, bu tür veri okuma ve yazma ile aşağı sürüklenecektir.
Ardından ikinci soru geliyor: Depolama motoru olarak ilişkisel olmayan bir veritabanını kullanırsak, nasıl seçeriz? Aslında, yukarıdaki makaleler temelde yazılmıştır, işte sadece bir özet (tüm eksiklikler işlemin noktasını yansıtmayacaktır, çünkü bu, ilişkisel veritabanlarına kıyasla tüm NoSql'lerin ortak bir sorunudur):
Bununla birlikte, burada özellikle aşağıdaki gibi seçimin kitaba göre değil gerçek duruma dayanması gerektiği belirtilmektedir:
- Kurumsal geliştirmenin başlangıcında, ilişkisel bir veri tabanının tamamlanabileceği ve bir yıllık bir yapıyı destekleyebileceği ve geniş ve kapsamlı bir teknik çözüm geliştirilebileceği açıktır.
- Sorgu için birçok veri koşulu vardır, ilişkisel veritabanının baskısını azaltmak için depolama olarak ElasticSearch kullanmak daha uygundur, ancak şirketin maliyeti sınırlıdır, bu durumda bu tür verilerin depolanması için ilişkisel veritabanını kullanmaya devam edebilirsiniz.
- Bir tür veri formatı basittir, bir KV tipidir ve büyük miktarda büyümeye sahiptir, ancak şirketin HBase'de yetenekleri yoktur ve işletme ve bakımda bazı zorluklar olabilir.Pratik düşünceler için, ilişkisel veritabanlarını bir süre kullanabilirsiniz.
Bu nedenle, gerçek durumu dikkate almazsanız, bazı depolama motorları daha uygun olsa da, onları kullanmaya zorlamak ters etki yaratır, sonuçta size en uygun olanlarıdır.
