g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

NetEase alt veritabanı alt tablo veritabanı DDB

Yazar: DDB projesinden sorumlu kişi olan Ma Jin, 2013 yılında NetEase'e katıldı ve dağıtılmış ara yazılım ile ilgili çalışmalara meraklı, veri tabanı ve alt tablo veritabanı DDB, önbellek NKV, dağıtılmış işlem ara yazılımı TCC ve dağıtılmış video işleme sistemi NTS gibi projelerde yer alıyor.

Bu makale "Programcılar" ın orijinal makalelerinin izinsiz çoğaltılmasına izin verilmez. Daha heyecan verici makaleler için lütfen "Programcılar" 2017'ye abone olun

İnternet çağı aynı zamanda ilişkisel veritabanlarının dünyaya hakim olduğu bir dönemdir.Oracle'ın ilk günlerinden MySQL'in geliştiği güne kadar ilişkisel veritabanları, veri güvenilirliği depolamasında çoğu İnternet uygulamasının "can damarı" dır.

İnternet ürünleri boyut ve ölçek olarak genişledikçe, hem Oracle hem de MySQL ilk kez disklerden, CPU'lardan ve bellekten bağımsız darboğazlarla karşı karşıya kalacak.Bu nedenle, ürün tarafının sürekli olarak kontrol edilmesi zor olan yüksek standartlı sunucular satın alması gerekiyor. , Ancak sürekli yinelemeli çevrimiçi veri geçişiyle de karşı karşıya. Bu durumda, ister büyük yapılandırılmış veriler isterse hızla büyüyen iş ölçeği olsun, depolama maliyetlerini kontrol edilebilir maliyetlerle ticari sunuculara tahsis etmek için bir yatay genişletme yöntemine acil bir ihtiyaç vardır. Aynı zamanda, doğrusal genişleme yoluyla tam veri geçişinin çevrimiçi hizmetler üzerindeki etkisini azaltması da umulmaktadır ve alt veritabanı ve sayaç altı şeması ortaya çıkmıştır.

Alt veritabanı alt tablosunun ilkesi, verileri belirli bölümleme kurallarına göre farklı ilişkisel veritabanlarına bölmek ve ardından uygulama, ara yazılım aracılığıyla her bir parçadaki verilere erişmektir. Alt veritabanı ve alt tablonun ara yazılımı, veri parçalama ve yönlendirme erişiminin ayrıntılarını gizler, böylece alt veritabanı ve tablodan sonra dağıtılmış veritabanı, çoğu uygulamada bağımsız bir veritabanı gibi kullanılabilir. Sektörde, NetEase DDB, Ali TDDL, Cobar, MyCat, HotDB ve diğer sistemler, alt veritabanı ve tablo için ara katman yazılımlarının en iyileri arasındadır.

Arka plan - on yılda bir kılıç

DDB (tam adı Dağıtılmış Veritabanı), NetEase Hangzhou Araştırma Enstitüsü'nün en eski ve en yaygın kullanılan arka uç ürünlerinden biridir ve aynı zamanda Çin'deki en eski veritabanı alt veritabanı alt tablo ara yazılımıdır.

NetEase Hangzhou Araştırma Enstitüsü'nün kurulduğu 2006 yılına kadar izlenebilir.Günlük etkinliği 800W'ın üzerinde olan NetEase blog'un büyük ölçekli uygulamasıyla baş edebilmek için, Hangzhou Araştırma Enstitüsü'nün şu anki dekanı Wang Yuan, DDB alt veritabanı ve alt tablo veritabanının geliştirilmesine öncülük etti. Blogun büyümesiyle, DDB kümesi ilk 20'den fazla düğümden 40'tan fazla düğüme ve son olarak buluttaki mevcut 100'den fazla RDS örneğine ulaştı. DDB, bloglara ek olarak, son on yılda Yixin, Cloud Music, Cloud Reading ve Koala gibi diğer birçok büyük ölçekli uygulamaya da tanık oldu. Tanıdık NetEase İnternet ürünlerinde DDB hemen hemen her yerde görülebilir.

10 yıllık geliştirme ve evrimden sonra, DDB'nin ürün formu tamamen olgunlaştı ve işlevleri ve performansı birçok ürün tarafından tam olarak doğrulandı. İşte herkesin daha fazla dikkat ettiği özelliklerden bazıları:

SQL92 standardıyla uyumluluk% 90'ın üzerindedir

Veritabanları arası JOIN ve veritabanları arası işlemi destekler, çoğu skaler işlevi destekler

COUNT, SUM, AVG, MAX, CONCAT, vb. Gibi yaygın toplama işlevlerini destekleyin.

MySQL ile tutarlı kullanıcı yönetimini destekleyin

Okuma-yazma ayrımını ve veri düğümlerinin yüksek kullanılabilirliğini destekleyin

Veri düğümlerinin çevrimiçi genişlemesini ve daralmasını, tablo dağıtımının çevrimiçi değişimini destekleyin

Eksiksiz veritabanı yönetim araçları, Web ve komut satırı araçları sağlayın

Veri düğümü Oracle ve MySQL'i destekler

Şu anda, DDB, NetEase içinde yaklaşık 50 ürün tarafından kullanılmaktadır ve en büyük küme, çoğu bulutta konuşlandırılan ve uygulamalara şeffaf, müdahaleci olmayan ve MySQL standart protokol alt veritabanı alt tablo hizmetleri sağlayan 100'den fazla veri düğümüdür.

DDB'nin evrimi

Geçtiğimiz on yıl içinde DDB, hizmet modelinde en eski Sürücü modelinden sonraki Proxy modeline ve son yıllarda bulut modeline üç büyük değişikliğe uğradı.DDB hizmet modelinin büyümesi, popüler İnternet mimarisindeki değişiklikleri de derinden yansıtıyor.

Sürücü modu

Sürücü modunun özelliği, uygulamaların, MySQL'in JDBC sürücüsü aracılığıyla MySQL'e erişmeye benzer şekilde, DDB tarafından sağlanan JDBC Sürücüsü aracılığıyla DDB'ye erişmesidir. MySQL sürücüsü Connector / J için, yalnızca belirli bir protokole göre SQL'i kodlamanız ve kod dönüştürmeniz gerekir. DDB sürücüsünün, Şekil 1'de gösterildiği gibi şeffaf alt veritabanı alt tablosu elde etmek için çok fazla ek iş yapması gerekir.

Şekil 1

DDB Sürücüsü bir SQL yürüttüğünde, aşağıdaki adımlardan geçecektir:

Dilbilgisi ayrıştırıcısı, soyut sözdizimi ağacı Parse Tree'yi oluşturmak için SQL'i ayrıştırır ve PreparedStatement olup olmadığına göre PTC (Parse Tree Cache) girilip girilmeyeceğine karar verir.PTC eşlemeyi SQL modundan dilbilgisi ağacına kaydeder. PreparedStatement SQL için önce PTC sorgu sözdizimini girecektir. ağaç;

Sözdizimi ağacına ve sezgisel kurallara göre dağıtılmış bir yürütme planı oluşturun Bu süreç, koşullu birleştirme, JOIN bölme, LIMIT dönüşümü vb. Gibi SQL dönüştürme ve optimizasyonunun birden çok adımını içerecektir;

SQL yürütücü, yürütme planına ve sözdizimi ağacına göre her veri düğümüne gönderilen gerçek SQL'i üretir ve ardından SQL'i standart veritabanı sürücüsü aracılığıyla her bir veri düğümüne gönderir Bu işlem eşzamanlı yürütmedir;

Her veri düğümü tarafından döndürülen sonuçlar, yürütme planına göre birleştirilir ve üst katmana döndürülür. Spesifik birleştirme işlemi, uygulama sonucu çağırdığında dinamik olarak yürütülebilir.

DDB tarafından uygulamaya sağlanan JDBC sürücüsü olarak DBI modülü, eksiksiz bir şeffaf alt veritabanı ve alt tablo mantığı içerir.DDB'nin temel bileşenidir.Ayrıca DDB, meta veri yönetimi ve senkronizasyonu için Ana bileşenlere ve veritabanı yönetimine de sahiptir. Şekil 2, DBAdmin aracının, komut satırı aracı ISQL'in ve DDB'nin Sürücü modunun genel mimarisini göstermektedir.

şekil 2

Yönetim işlemlerine örnek olarak tablo oluşturmayı alın:

DBA, DBAdmin penceresi aracılığıyla bir tablo oluşturur veya ISQL ile tablo oluşturma ifadesini yürütür ve ardından Ana birim için gerçek bir tablo oluşturma isteği başlatır.Master, kullanıcı kimlik doğrulamasını ve yasallık doğrulamasını tamamladıktan sonra, önce her veri düğümünde yeni bir tablo ve ardından yeni tablo oluşturur Meta veriler sistem kitaplığına kaydedilir ve son olarak Ana Birim, yeni tablonun meta verilerini her bir DBI modülüne senkronize eder.

Tablo oluşturma deyimindeki DDB'ye özgü sözdizimi için, ISQL veya DBAdmin, kendi kendine artan kimliğin ayarlanması gibi DDL'yi ayrıştırırken karşılık gelen işlemi tamamlayacaktır.

DDB'de, meta veri yönetimi, senkronizasyon ve alarm izleme için Master kullanılır. DBI modülü başlatıldığında, Master'a ilk kez kaydolacak ve metadata çekecektir Bundan sonra, metadata'nın Master tarafından senkronizasyonu, DBI modülünün metadatasının güncellenmesini garanti eder. DBI'nın SQL yürütme ve bir DB bağlantısı oluşturma sürecinde, Master ile etkileşim söz konusu olmayacaktır.

Alt veritabanı ve alt tablo ara yazılımları arasında, DDB Sürücü modu ile aynı tip, basit dağıtım, düşük maliyetli, anlaşılması ve kullanımı kolay avantajlara sahip olan Ali TDDL'dir. Dezavantajları da açıktır: yalnızca Java istemcisini destekler, sürümün yönetilmesi zordur, sorunun izlenmesi zordur ve DB bağlantısının yakınsaması zordur.Başka bir nokta da ara yazılım ve uygulamanın birbirine bağlı olmasıdır, bu da uygulamanın kendisine büyük bir izinsiz giriş ve kitaplıklara bölünmüştür. Tablo işlemi daha fazla CPU kaynağı tüketir, bu nedenle Sürücü modunda, hem çalıştırma hem de bakım ve performans ek yükünde kontrol edilemeyen faktörler vardır.

Proxy modu

Sürücü modunun çoklu dil, sürüm yönetimi ve işletim ve bakım risklerindeki sorunları ile karşılaştırıldığında, Proxy modu bu eksiklikleri giderir. Sözde Proxy, standart MySQL hizmetleri sağlamak için DDB'de bir dizi proxy sunucusu oluşturmak ve proxy sunucusu içinde alt veritabanı ve alt tablo mantığını uygulamaktır. Esasen, bağımsız hizmetler kümesi olarak DDB Proxy, MySQL sürücüleri tarafından herhangi bir dilde erişilebilen MySQL standart iletişim protokolünü uygular.Proxy'de, alt veritabanları ve tabloları uygulamak için DBI bileşenleri kullanılır.Proxy ve DBI arasındaki ilişki Şekil 3'te gösterilmiştir. Gösterildi.

resim 3

Uygulama, standart veritabanı sürücüsü aracılığıyla DDB Proxy'ye erişir.Proxy, isteği MySQL kod çözücüsü aracılığıyla dahili olarak SQL'e geri yükler ve sonuç, DBI modülü olan DDB Sürücüsü tarafından yürütülür ve son olarak MySQL kodlayıcı aracılığıyla uygulamaya geri döndürülür.

Şekil 3'ten Proxy'nin bağımsız bir standart MySQL hizmeti oluşturmak için DBI üzerinde bir MySQL codec modülü kurduğu görülebilir.MySQL codec modülünün yanı sıra DDB Proxy ayrıca aşağıdakiler gibi birçok özel komut desteği sağlar:

işlem listesini göster: MySQL ile ilgili komutlarla oldukça tutarlı olan tüm Proxy bağlantı durumunu görüntüleyin

show connection_pool: Proxy'nin bağlantı havuzu durumunu veri düğümüne sorgulayın

showtopsql: yürütme süreleri, ortalama yürütme süresi gibi SQL moduna göre toplanan çeşitli istatistiksel sonuçları sorgulayın

count..from: Geçmişteki her zaman dilimindeki aktarım hızını sorgulayın

DDB Proxy ayrıca, işletim ve bakıma büyük kolaylık sağlayan Yavaş Günlük gibi yardımcı işlevler de sağlar.

DDB Proxy modunun eksiksiz mimarisi Şekil 4'te gösterilmektedir.

Şekil 4

Sürücü modu mimarisiyle karşılaştırıldığında, DBI konumunu değiştiren QS'ye (DDBProxy'nin dahili adı, aşağıda aynıdır) ek olarak, LVS veya HAProxy + Keepalived kombinasyonu da yük dengeleme için birden çok QS düğümüne dağıtılır, böylece birden çok DDBProxy gerçekleştirilir Düğümlerin sıcak beklemesi, DDBProxy durumsuz olduğundan veya durum, veritabanı düğümü darboğaza ulaşmadığında Ana tarafından tek tip olarak senkronize edildiğinden, hizmet basitçe bir QS sunucusu eklenerek doğrusal olarak genişletilebilir.

Özel bulut modeli

NetEase özel bulut projesi başlamadan önce DDB, bağımsız kümeler ile farklı işletmelere hizmet veriyordu.Farklı DDB'lerin birbirleriyle hiçbir ilgisi yoktu.Bunun avantajı, işletmelerin tamamen izole olması ve birbirlerini etkilememesidir. Bunun dezavantajı, DDB kullanan ürünlerin sayısı artmaya devam ettikçe, bir DBA genellikle aynı anda birkaç veya hatta düzinelerce DDB kümesini çalıştırıyor. Daha önce platform tabanlı bir yönetim sistemimiz yoktu ve DBA'lar çeşitli kümeler tarafından bunalmış durumda. , Uygulamaların sorunları erken bulmasına veya bazı kullanım yöntemlerini optimize etmesine yardımcı olacak platform tabanlı bir genel planlama operasyonumuz ve bakımımız bulunmamaktadır. Örneğin, sürüm yönetimi, 2013 yılında ana sürümde bir Düzeltme yaptık ve tüm DBA'ları ilgili sürümü yükseltmeleri için bilgilendirdik, ancak yönetim eksiklikleri nedeniyle bazı kümeler zamanında çevrimiçi olamadı ve bu da işletmeye zarar verdi. O zaman, platform tabanlı bir yönetim planımız olsaydı, işletim ve bakım personeline tüm sorunlu kümeleri zamanında güncellemelerine yardımcı olacak ve hatırlatacak bazı işletim ve bakım yöntemleri sağlayabilirdik.Ayrıca, platform tabanlı yönetim araçları, otomatik yedekleme, alarm grupları vb. Gibi bazı otomatik işlevleri de özelleştirebilir. .

NetEase özel bulutun ortaya çıkışı, DDB'nin değişiklikleri düşünmesi için bir fırsat sunuyor. 2012 yılından bu yana, NetEase özel bulut tabanlı platform tabanlı bir yönetim aracı olan Cloudadmin geliştiriyoruz.Bu nedenle, DDB'deki orijinal Master işlevini parçaladık. Kütüphane yönetimi, tablo yönetimi, kullanıcı yönetimi vb. Gibi kitaplıkla ilgili işlevlerin bir kısmı Proxy'ye entegre edilmiştir ve alarm izleme gibi bazı merkezi işlevler Cloudadmin'e entegre edilmiştir.Ayrıca, Cloudadmin tek tıklamayla dağıtım, otomatik ve manuel yedekleme sağlar, Sürüm yönetimi gibi platform fonksiyonları. Özel bulut DDB'nin genel mimarisi Şekil 5'te gösterilmektedir.

Şekil 5

Bulut DDB çözümünde, Netease özel bulut LVS hizmeti de paketlenir ve Cloudadmin, DDBAgent aracılığıyla tek tıklamayla dağıtım ve alarm izlemeyi gerçekleştirir. Şimdiye kadar, NetEase'in DDB kümelerinin% 80'inden fazlası bulutu dağıttı ve bulut DDB'nin ortaya çıkışı, işletim ve bakım personeli üzerindeki yükü büyük ölçüde azalttı.

DDB özelliği tanıtımı

Dağıtılmış yürütme planı

Dağıtılmış yürütme planı, alt veritabanı ve alt tablo ortamındaki her veritabanı düğümünde SQL yürütme yöntemini, sırasını ve birleştirme kurallarını tanımlar ve DDB uygulamasının en karmaşık parçasıdır.

SQL gibi: kullanıcı siparişinden * kimlik sınırına göre 10 ofset 10 seçin;

Bu SQL, kimliği 10-20 arasında olan kullanıcılar hakkında bilgi sorgulamak istiyor. Burada iki birleştirme işlemi söz konusudur: global ID sıralama ve global LIMIT OFFSET. Global kimlik sıralaması için DDB'nin yaklaşımı, kimlik sıralamasını her veritabanı düğümüne dağıtmak ve ardından DBI katmanında veritabanı düğümünün bilgi işlem kaynaklarını tam olarak kullanabilen ve ara katman katmanının sıralama karmaşıklığını azaltabilen bir birleştirme sıralaması gerçekleştirmektir. En düşük, örneğin, ara yazılımda tam sıralama büyük ek yüke neden olacaksa, geçici dosyaları kullanması gereken bazı sıralama senaryolarıdır.

Global LIMIT OFFSET için DDB'nin yaklaşımı, OFFSET'i LIMIT'e eklemek ve bunu yayınlamaktır, çünkü tek bir veri düğümündeki OFFSET anlamsızdır ve yanlış veri ofsetine neden olur. Yalnızca ara katman katmanındaki global OFFSET, OFFSET'in doğruluğunu garanti edebilir. Seks.

Sonunda, her bir DBN'ye gönderilen SQL şu olur: kullanıcı sırasından kimlik sınırı 20'ye göre * seçin.

Başka bir örnek SQL'dir: isme göre UserTet grubundan avg (yaş) seçin

SQL yürütme planı, Şekil 6'da gösterildiği gibi EXPLAIN sözdizimi aracılığıyla elde edilebilir.

Şekil 6

Yukarıdaki SQL iki birleştirme işlemi içerir: GROUP BY gruplama ve AVG toplama. Global ORDER BY'a benzer şekilde, GROUP BY birleştirme ve tekilleştirme için veri düğümlerine ve ara katman katmanlarına da verilebilir, ancak öncül, GROUP BY alanlarının da ORDER olmasıdır BY alanı, birleştirme öncülü sıralama olduğu için verilir. AVG toplama için, tüm veri düğümlerinin ortalama değeri elde edildiğinden ve genel ortalama değer hesaplanamadığından doğrudan gönderilemez. AVG'yi DBI katmanında SUM ve COUNT'a dönüştürmek ve sonra göndermek ve ardından sonuç kümesi birleştirildiğinde ortalamak gerekir.

DDB yürütme planının maliyeti, DBI'daki sıralama, filtreleme ve bağlantıya bağlıdır. Çoğu senaryoda sıralama, ORDER BY öğesinin tek seferlik bir birleştirme sıralamasına teslim edilmesini basitleştirebilir. Bu durumda maliyet küçüktür, ancak GRUP VE SİPARİŞ için BY'nin aynı anda mevcut olduğu senaryolarda, birleştirme ve gruplama amacına ulaşmak için önce GROUP BY alanının sıralanması gerekir.Bu durumda, GROUP BY ve ORDER BY alanları aynı olmadığı sürece tüm elemanların bir kez sıralanması gerekir.

DDB'nin bağlantı işleminin iki uygulaması vardır.Birincisi doğrudan bağlantı kurmaktır.Bağlı iki tablonun veri dağılımı tam olarak aynı ise ve bölümleme alanına bağlıysa, doğrudan verilecek bağlantının koşulları karşılanmaktadır çünkü farklı verilerde Düğümün bölüm alanı aynı değere sahip olmamalıdır ve veritabanları arası bağlantı sorunu olmayacaktır. Bağlantı yayınlama koşulu karşılanmazsa, Nest Loop algoritması DBI içinde çalıştırılır ve sürücü tablosunun sırası, FROM tablosunun sırası ile tutarlıdır.Şu anda, ORDER BY tablosunun sıralaması tablo düzenlemesinin sırası ile tutarsızsa, ORDER BY düzenleme koşulu karşılanmaz , Ayrıca DBI'da tam bir sıralama yapmanız gerekir.

Bağımsız veritabanı ile karşılaştırıldığında, alt veritabanı ve alt tablonun yürütme planı maliyetinin kontrol edilmesi daha zordur.Aynı SQL modunda bile, farklı veri dağıtımı ve bölümleme alanı kullanımında büyük bir performans açığı vardır.DDB'nin kullanım gereksinimleri Geliştiriciler ve DBA'lar, yürütme planlarının ilkeleri hakkında belirli bir anlayışa sahiptir.

Örneğin, alt veritabanları ve alt tablolar, bölüm alanlarının kullanımı konusunda çok özeldir: genellikle uygulamadaki SQL sorgularının% 80'inden fazlasının bölüm alanlarına göre filtrelenmesi önerilir, böylece SQL tek bir veritabanında çalıştırılabilir. Bölme alanını takip etmeyen sorgular için, tüm veri düğümlerinde paralel olarak verilmesi gerekir ki bu büyük bir iş parçacığı ve CPU kaynağı tüketimi anlamına gelir.Veri düğümlerinin genişlemesiyle bu tüketim giderek daha şiddetli hale gelecektir. Ek olarak, bölüm alanlarının veritabanları arasında örtüşmemesi ilkesine dayanarak, gruplama, toplama, DISTINCT ve bölüm alanlarındaki bağlantı gibi işlemlerin tümü doğrudan verilebilir, böylece ara yazılım maliyeti genellikle minimumdur.

Dağıtılmış işlem

Dağıtılmış işlem uzun süredir devam eden bir konudur.Alt veri tabanı, alt tablo ve dağıtılmış işlemin amacı, alt veri tabanı verilerinin tutarlılığını sağlamaktır, veri tabanları arası işlemler ise bireysel düğümlerin kalıcı kesinti süreleri gibi çeşitli kontrol edilemeyen sorunlarla karşılaşacaktır. Bağımsız bir işlem gibi ACID beklemek imkansızdır. Ek olarak, sektördeki iyi bilinen CAP teorisi bize dağıtılmış sistemler için veri tutarlılığı, sistem kullanılabilirliği ve bölüm toleransının terazide birlikte ele alınması gerektiğini söyler.

İki aşamalı tamamlama protokolü (kısaca 2PC), dağıtılmış işlemlerin uygulanması için klasik bir çözümdür ve ara katman yazılımı gibi veri düğümlerinin birleştirilmediği senaryolar için uygundur. 2PC'nin temel prensibi, aşamalı tamamlama ve günlüğe kaydetme yöntemi aracılığıyla işlem tamamlamanın aşama durumunu kaydetmektir.Bileşen kapandıktan ve yeniden başlatıldıktan sonra, işlem tamamlamanın aşama durumu günlük aracılığıyla geri yüklenebilir ve bu durum düğümünde yeniden denenebilir. Örneğin, Koordinatör yeniden başlatıldıktan sonra, günlük, gönderimin Prepare veya PrepareAll durumunda olup olmadığını belirleyebilir. Bu eski durumsa, bazı düğümlerin Prepare'i başarılı bir şekilde hazırlayamadığı veya tüm düğümlerin Prepare'i başarılı bir şekilde hazırlayıp Commit vermediği anlamına gelir. Durum geri yüklendikten sonra, tüm düğümlere RollBack verilecektir; eğer evet ise PrepareAll durumunda, Commit'in tüm düğümlere verilmesi gerekir ve veritabanı düğümünün Commit'in idempotent olduğundan emin olması gerekir. Diğer birçok tutarlılık anlaşması gibi, 2PC de nihai tutarlılığı garanti eder.

2PC'nin tüm süreci Şekil 7'de gösterilmektedir.

Şekil 7

DDB'de, hem DBI hem de Proxy bileşenleri Koordinatör olarak bulunur. 2PC uygulandığında, yeniden başlatmanın ardından kurtarma durumunun doğru olduğundan emin olmak için Prepare ve PrepareAll'ı kaydeden günlükler senkronize edilmelidir. Koordinatörün son Commit günlüğü esas olarak önceki günlüğü geri almak için kullanılır ve eşzamansız olarak çalıştırılabilir. .

2PC, Koordinatörün günlükleri tutmasını gerektirdiğinden, işlem hacmi disk G / Ç performansı ile sınırlandırılır.Bu nedenle DDB, 2PC'nin verimini büyük ölçüde artırabilen GROUP I / O optimizasyonunu uygular. 2PC, esasen bir engelleme protokolüdür. İki aşamalı kesinleştirme işlemi, büyük miktarda iş parçacığı kaynağı gerektirir, bu nedenle CPU ve disk ek tüketime sahiptir. Tek makineli işlemlerle karşılaştırıldığında, 2PC'nin yanıt süresi ve işlem hızı açısından çok fazla farkı vardır. CAP perspektifinden 2PC'nin C'yi bir ölçüde yerine getirdiği ve A'yı feda ettiği düşünülebilir.

Ek olarak, MySQL 5.5 ve 5.6'nın en popüler sürümlerinde, XA işlem günlüğü ikincil düğüme kopyalanamaz; bu, ana veri tabanı kapandığında, ikincil veri tabanına geçtikten sonra XA durumunun kaybolacağı ve bu da veri tutarsızlığına neden olabileceği anlamına gelir. MySQL 5.7 iyileştirildi.

2PC'nin birçok eksikliği olmasına rağmen, DDB'de değerinin farkına varacağına inanıyoruz. Ara yazılım olarak DDB, veritabanının temel hizmetinden çok daha sık bir yineleme döngüsüne sahiptir. 2PC olmadan, bir güncelleme veya yeniden başlatma tutarsız uygulama verilerine neden olabilir. Uygulama bakış açısından, dağıtılmış işlemlerin gerçekliği genellikle kaçınılmazdır ve 2PC, başka çözümler sunmadan önce iyi bir seçimdir.

Alışveriş transferleri gibi e-ticaret ve finansal hizmetler için, ara katman katmanındaki 2PC ile ilgili en büyük sorun işletmenin görünür olmamasıdır.Kalıcı veri düğümü kesintisi gibi mücbir sebepler veya beklenmedik tutarlılık hasarı meydana geldiğinde, işletmenin 2PC günlüklerine göre telafi etmesi zordur. Finansal senaryolarda veri tutarlılığı can damarıdır ve işin veriler üzerinde% 100 kontrole sahip olması gerekir.TTC gibi dağıtılmış işlem modellerinin veya mesaj kuyruklarına dayalı esnek bir işlem çerçevesinin kullanılması önerilir.Her iki çözüm de iş katmanında uygulanır. Geliştiriciler yeterli kontrole sahiptir ve yapılandırmak için SOA çerçevesi ile birleştirilebilir. Prensip olarak, bu iki çözüm, küçük işlemleri bölen büyük işlemlerdir ve küçük işlemler yerel işlemler haline gelir.Son olarak, nihai tutarlılığı sağlamak için idempotent Retry kullanılır.

Esnek genişleme

Alt veritabanı ve alt tablo veritabanlarında, çevrimiçi veri geçişi de aşağıdaki iki senaryoda kullanılacak temel bir gereksinimdir:

Veri düğümlerinin elastik genişlemesi

Uygulamaların ölçeği büyümeye devam ettikçe, DDB'nin mevcut alt veritabanları bir gün daha fazla veriyi desteklemek için yeterli olmayabilir.DDB'nin veri düğümlerinin çevrimiçi olarak esnek bir şekilde genişleyebilmesi gerekir. Kümeye yeni düğümler eklendikten sonra, farklı parçalama stratejilerine göre gerekli olabilir. Orijinal verilerin bir kısmını HASH bölümü gibi yeni düğüme taşıyın veya bazı senaryolarda Aralık bölümü gibi çevrimiçi veri geçişi gerektirmeyebilir. Her durumda, çevrimiçi veri geçişine sahip olmak, DDB'nin esnek genişlemeyi desteklemesi için bir ön koşuldur.

Verilerin yeniden dağıtımı

DDB kullanma sürecinde bazen geliştiriciler ikilem içine girerler, örneğin bazı tabloların bölümleme alanları başlangıçta net olarak düşünülmez ve iş şekillenmeye başladıktan sonra diğer alanların seçilmesi gerektiği açıktır. Başka bir örnek de, bazı tabloların başlangıçta veri miktarının küçük ve tek düğüm dağılımının yeterli olduğunu düşünmesi, ancak iş değiştikçe çok düğümlü parçalamaya dönüştürülmesi gerektiğidir. Bu iki senaryonun her ikisi de geliştiricilerin DDB'nin çevrimiçi veri taşıma işlevi için potansiyel ihtiyaçlarını yansıtır.

İster esnek genişleme ister tablonun yeniden dağıtımı olsun, DDB'nin tablo veya veritabanı birimlerinde tam bir çevrimiçi veri geçişi olarak kabul edilebilir. İki aşamaya ayrılabilir: tam geçiş ve artımlı geçiş: tam geçiş, taşınması gereken verileri orijinal veritabanına veya orijinal tabloya dökmek ve aracı bölüm stratejisine göre yeni veritabanına ve yeni tabloya uygulamak için kullanmaktır. Artımlı geçiş, bölümleme stratejisine göre tam geçiş sürecinde üretilen artımlı verileri yeni veritabanına ve yeni tabloya güncellemektir.

Tam geçiş için çözüm nispeten basittir. Belirli bir bölüm stratejisine göre DUMP ve Load için DDB'nin kendi araçlarını kullanın. Artımlı geçiş için DDB, her bir veri düğümünün artan güncellemelerine abone olmak için bir dizi bağımsız taşıma aracı Hamal uygular ve Hamal, Şekil 8'de gösterildiği gibi yeni veri tabanına ve yeni tablolara artımlı güncellemeleri uygulamak için dahili olarak DBI modülüne güvenir.

Figür 8

Bağımsız bir hizmet olarak Hamal, Proxy gibi DDB tarafından tek tip olarak yapılandırılır ve yönetilir.Her Hamal işlemi, bir veri düğümünün artan geçişinden sorumludur.Başlarken, yerel olarak depolamak için Binlog'u orijinal kitaplıktan almak için Slave'i simüle eder ve ardından DBI modülünü gerçek zamanlı olarak yeni kitaplığa uygular. Hamal, temel göç işlevine ek olarak şu iki özelliğe sahiptir:

Paralel çoğaltma: Hamal'ın paralel çoğaltma bileşeni, gerçek zamanlı olarak hangi olayların paralel olarak yürütülebileceğini belirlemek için artımlı olaylar arasında yönlendirilmiş bir döngüsel olmayan grafik oluşturur Hamal'ın paralel çoğaltması, MySQL'in paralel kopyalamasından 10 kat daha hızlıdır;

Bir kesme noktasında devam ettirilebilir iletim: Hamalın artımlı Uygulaması idempotenttir ve bir ağ kesintisinden veya işlem yeniden başlatıldıktan sonra devam ettirilebilir.

Global tablo

Bir senaryo düşünün: Şehir tablosu, Çin'deki tüm şehirler hakkındaki bilgileri kaydeder Uygulamada, şehir grubuna göre işletme bilgileriyle ilgili istatistikler gibi sorgu için Şehir ile bağlantılı olması gereken birçok iş tablosu vardır. CityId birincil anahtarının ve bölüm anahtarının hem CityId olduğunu varsayarsak, bağlantı işlemi ara katman katmanında gerçekleşirse maliyet yüksektir.Bağlantı işlemini veri düğümüne göndermek için, bağlı iş tablosunun CityId'ye göre bölümlenmesi gerekir ve çoğu iş tablosu Bu koşul karşılanamaz.

Doğrudan bağlantı vermenin iki koşulu karşılaması gerekir, veri dağıtımı aynıdır ve bölüm anahtarı bağlanır, ayrıca aslında Şehir tablosunu tüm veri düğümlerine yedekleyebilen bir çözüm vardır, böylece her veri düğümü yerel olarak koleksiyona bağlanır. İstenilen sonuç budur. DDB bu tür bir tabloya global tablo adını verir.

Global tablo çok az güncelleme ile karakterize edilir ve her düğümün artıklık tablosunun tutarlılığı 2PC ile garanti edilir. Tablo oluşturma deyimine ilgili İpuçları ekleyerek global tablo türünü belirtebilirsiniz Uygulama DDB kullandığında global tablo kavramı uygulama tarafından görülmez.

Gelecekten bağımsız platform, bulutla dans ediyor

NetEase'in yoğunlaşmış 10 yıllık teknik deneyiminin ve özünün bir alt veritabanı ve alt tablo veritabanı olarak DDB, son bir veya iki yılda dahili ürün kullanımını tatmin etmenin yanı sıra, harici kurumsal müşterilerin çok büyük yapılandırılmış veri depolama sorununu çözmelerine yardımcı olmaya kademeli olarak başladı. Genel bulut teknolojisinin güçlü gelişimi ve olgunlaşmasıyla, çeşitli IaaS ve PaaS platformları, uygulama geliştirme, devreye alma, işletim ve bakım için büyük kolaylık sağlayan NetEase Honeycomb'un piyasaya sürülmesi gibi sonsuz bir akışta ortaya çıktı. IaaS katmanının ve PaaS platformunun popüler hale gelmesiyle, çeşitli SaaS hizmetleri geliştiriciler tarafından kademeli olarak kabul edilecek. Gelecekte DDB, DDBnin SaaS hizmetlerini NetEase Hive müşterileri için paketlemeye odaklanacak ve Hive ile daha zengin bir hizmet kümesi oluşturacak. Veri depolama ekosistemi.

DDB'nin SaaS hizmetinde çok kararlıyız.Aynı zamanda DDB'nin genel bulutu, özel bulutun mekanik bir yöntemi değildir.Kurumsal müşterilerin alt veritabanı ve alt tablo sorununu çözmelerine yardımcı olmak için Hive ile çalışırken, gelecekte platform bağımsızlığına da daha fazla dikkat edeceğiz. Yapılması gereken şey, DDB'nin SaaS katmanını alttaki PaaS ve IaaS katmanlarından ayırmaktır, böylece DDB platformunun bağlı olduğu PaaS ve IaaS eklentiler şeklinde enjekte edilebilir. Bu, müşterilere yalnızca daha esnek hizmet yöntemleri sağlamakla kalmaz, aynı zamanda DDB platformunun geliştirme, işletme ve bakım maliyetlerini de büyük ölçüde azaltır: tüm dahili ve harici DDB kullanıcıları için uygun bir dizi platform yönetim aracı, bu bizim devam eden ve optimize etmeye devam edeceğiz Amaç.

2016 programcılarına abone olmak için lütfen adresini ziyaret edin (iOS, Android ve basılı sürümler dahil)

Abonelik danışmanlığı: