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

Yazar | Zhang Qiujian, Tianyun Data Shanghai Genel Müdür Yardımcısı

Editör | Tang Xiaoyin

Baş resmi | Oriental IC'den indirilen CSDN

Üretildi | CSDN (ID: CSDNnews)

Son zamanlarda, PostgreSQL'in sürüm 13'ü yayınlayacağına dair söylentiler var. Bu, özellikle büyük veri kümeleri ve toplam alan kullanımı için sorgu performansının iyileştirilmesi de dahil olmak üzere, geçen yıl Eylül'de sürüm 12'nin yayınlanmasından sonra PG topluluğu tarafından gerçekleştirilen bir başka önemli eylemdir. Aynı zamanda, PostgreSQL 9'dan devralınan yerli Huawei GaussDB 200 ve Çin'deki PostgreSQL'in ekolojisi görülmemiş derecede sıcak hale geldi.

Bu, geçtiğimiz iki yılda Google F1 teorisinin temsil ettiği NewSQL veritabanıyla birlikte, bu çağda veritabanının iki boynuzunu oluşturdu ve TI'nin veri merkezi mimarisinin yeni dünyasını bir gökkuşağı gibi değiştirdi. İki teknik rota arasındaki farka bir göz atalım.

PostgreSQL'in geçmişi ve bugünü

PostgreSQL, SQL dilini kullanan ve genişleten ve en karmaşık veri iş yüklerinin güvenli şekilde depolanması ve genişletilmesi için birçok işlevi birleştiren güçlü bir açık kaynaklı nesne ilişkisel veritabanı sistemidir. PostgreSQL'in kökeni, California Üniversitesi, Berkeley'deki POSTGRES projesinin bir parçası olarak 1986 yılına kadar izlenebilir ve 30 yıldan fazla bir süredir çekirdek platformda aktif olarak geliştirilmiştir. Eylül 2019'a kadar 12 versiyonu resmi olarak yayınlandı.

Resim kaynağı: Wikipedia

Michael Stonebraker, 2014 Turing Ödülü sahibi, PostgreSQL veritabanının kurucusu. Veritabanı alanında şu anda dört Turing Ödülü sahibi var:

• 1973 Bachman (veritabanı ve ağ veritabanı)

• 1981 Codd (ilişkisel veritabanı)

• 1998 Gray (Veritabanı ve İşlem İşleme)

Berkeley, Postgres'in beşiğidir

(Resim: Berkeley'in ünlü simgesi, Suther Gate, Oriental IC'den indirilen CSDN)

PostgreSQL'in özellikleri aşağıdaki şekilde özetlenebilir: PostgreSQL'in mimarisi, kurumsal düzeydeki veritabanları için en uygun olanıdır.

PostgreSQL tabanlı açık kaynaklı proje dalı

PostgreSQL'in geçmişi hakkında konuştuktan sonra, açık kaynak topluluk dünyasında PostgreSQL'in gelişiminden bahsedelim. Son 40 yılda veri tabanlarının geliştirilmesinin temelde RDBMS'den OLTP / OLAP ayrılmasına ve ardından dağıtılmış veri tabanlarının geliştirilmesine kadar bir süreç olduğunu biliyoruz.

PostgreSQL'in geçmişi de aynıdır.PostgreSQL çekirdeğinden başlayarak, OLTP dallarını, OLAP dallarını ve daha sonra genel eğilimi tecrübe etmiştir.İki yeniden bütünleşir ve hibrit OLA / TP dağıtılmış veritabanına doğru gelişir.

Dağıtılmış PostgreSQL-X2 mimarisine giriş

PostgreSQL artık karıştırma aşamasına geldiğine göre, doğrudan bu makalenin ana noktasından başlayalım ve X2 mimarisinin özelliklerine bir göz atalım.

Her şeyden önce, X2, PostgreSQL kaynak kodundan dönüştürülmüş dağıtılmış bir veritabanıdır, bu nedenle bağımsız bir veritabanının neredeyse tüm işlevlerine sahiptir:

• Karmaşık SQL ve düğümler arası JOIN desteği;

• Küresel işlemlerin güçlü tutarlılığı;

• Destek Okunan işlem yalıtım düzeyi;

• Bağımsız veritabanlarının neredeyse tüm DDL ifadeleri desteklenir;

• Düğümler arası görünümü destekleyin;

• Düğümler arası saklı yordamları destekleyin.

İkinci olarak, X2'nin temel amacı verilerin yatay olarak parçalandığını fark etmektir, bu da verinin alt veritabanı ve tabloya dayalı doğrusal genişleme problemini çözmesi gerektiği anlamına gelir.

Yine, X2, OLAP için paylaşılmayan bir mimaridir, bu nedenle, ETL veri ambarı işlemeyi gerçekleştirebilen MPP'nin teknik bir ilkesidir.

Son olarak, API tamamen uyumludur ve harici uygulamalar şeffaf bir şekilde Postgres-X2'ye erişebilir. Jdbc gibi farklı programlama dillerinin orijinal sürücüleri, değişiklik yapmadan Postgres-X2'ye erişebilir.

Yukarıdaki şekildeki X2 mimarisinden, X2'nin esas olarak üç bölümden oluştuğunu görebiliriz:

• GTM: Küresel işlem yönetimi, küresel işlem hizmetleri sağlar;

• Koordinatör: Global meta verileri depolayın, kullanıcı isteklerini kabul edin ve genel bir sorgu planının oluşturulması ve yürütülmesinden sorumlu olun (genel sorgu planı birkaç kısmi sorgu planından oluşur ve kısmi sorgu planı yürütme sırasında veri düğümlerine dağıtılır);

• Datanode: Yerel meta verileri depolayın, koordinatörün kısmi sorgu planını kabul edin ve yürütün (kısmi sorgu planı da SQL'dir).

Dağıtılmış PostgreSQL-X2'nin CAP analizi

CAP ilkesinin bir veritabanı yükseltmesinin değerlendirme standardını dikkate almak olduğunu biliyoruz.RDBMS çağında, Oracle ve MS SQLServer CAP'a daha yakın olabilir. Dağıtılmış veritabanları çağında, CAP teorisi hala değerlendirme için ana aracımızdır. AP ilkesi, dağıtılmış bir sistemde tutarlılık (Tutarlılık), kullanılabilirlik (Kullanılabilirlik) ve bölüm toleransına (Bölme toleransı) atıfta bulunan CAP teoremi olarak da bilinir. CAP ilkesi, bu üç öğenin aynı anda yalnızca iki noktaya ulaşabileceği ve üçüne de dikkat etmenin imkansız olduğu anlamına gelir.

İlk olarak, tutarlılık açısından PostgreSQL-X2, aşağıdakileri gerçekleştirmek için GTM'yi kullanır:

GTM'nin güçlü ve tutarlı işlem koruması, üretim düzeyinde olan geleneksel RDBMS ile karşılaştırılabilir. 2PC ve MVCC ile karşılaştırıldığında ileri noktalara sahiptir. Bununla birlikte, genel ek yük nispeten büyük olacaktır.Yüz milyonlarca eşzamanlı erişim içeren büyük bir İnternet uygulaması senaryosuysa, performansın MySQL'den daha iyi olması zordur.

2PC, iki aşamalı kesinleştirme protokolü olarak da bilinir, 2pc çok klasik, güçlü, tutarlı, merkezi bir atomik kesinleştirme protokolüdür. Burada bahsedilen merkezileştirme, anlaşmada iki tür düğüm olduğu anlamına gelir: biri merkezi bir koordinatör düğüm (koordinatör) ve N katılımcı düğüm (katılımcı düğüm).

MVCC'nin İngilizce tam adı Multi-Version Concurrency Control'dur. Çince'ye çevrildiğinde, çoklu sürüm eşzamanlılık kontrolü anlamına gelir. MVCC'nin gerçekleştirilmesi, verilerin belirli bir zamanda anlık görüntüsünün kaydedilmesiyle sağlanır. Bu, bir işlem ne kadar uzun sürerse sürsün, aynı işlemde verilerin tutarlı bir görünümünün görülebileceği anlamına gelir. İşlemin başladığı zamana göre aynı zamanda farklı işlemlerin aynı anda gördüğü aynı tablodaki verilerin farklı olabileceği anlamına da gelir.

Nesnel olarak konuşursak, iyimser kilitlemenin tam bir uygulaması olduğunu düşünüyoruz, yani her satırın bir sürüm numarası var ve başarı, kaydederken sürüm numarasına göre belirleniyor.

Ölçeklenebilirlik açısından Postgres-X2, hem Koordinatör hem de Datanode'de aynı anda genişletilebilir.

Postgres-X2, dağıtılmış veritabanlarının doğrusal genişletme standardına uygundur. X86'nın yaygınlaştığı çağda, bilgisayar kaynaklarını ve depolama kaynaklarını yatay olarak eşleştirerek makineleri genişletmek, dağıtılmışın temel konseptidir. Bu noktada, Postgres-X2 aynı şeyi yapar.

Ancak Postgres'in sorunu, veri miktarının çok büyük olmamasıdır.Veri miktarı 40 TB ile 200 TB arasındadır.Büyük bir veri ambarında, veri miktarı arttıkça ve düğüm sayısı arttıkça performans düşecektir ve doğrusal genişlemeyi tam olarak izleyemez. Doğrusal performans yığınlaması yapın. Bu, kolayca eleştirilen bir noktadır.

Bir tane daha, çevrimiçi çalışırken takıp eklemeyi desteklemiyor. Yeni bir düğüm eklenirse, kapatılması ve yeniden başlatılması gerekir.Bu durumda, Postgres-X2 tarafından oluşturulan OLAP'a gerçek zamanlı ODS gibi uygulamalar uygulanamaz.

Bölüm toleransı, PostgresSQL'in ana düşüncesi değildir. Çünkü çoğu dağıtılmış sistem birden çok alt ağa dağıtılmıştır. Her alt ağa bölüm adı verilir. Bölüm hata toleransı, bölgeler arası iletişimin başarısız olabileceği anlamına gelir. Örneğin, bir sunucu Çin'de ve diğeri Amerika Birleşik Devletleri'nde bulunuyorsa, bunlar iki bölgedir ve aralarında iletişim mümkün olmayabilir.

Yukarıdaki şekilde, G1 ve G2, bölgeleri kapsayan iki sunucudur. G1, G2'ye bir mesaj gönderir ve G2 bunu alamayabilir. Sistem tasarlanırken bu durum dikkate alınmalıdır. Bu durum şu anda temel olarak Amazon QWS S3, Google Spanner ve Alibaba Cloudun Okyanus Üssü gibi büyük bulut satıcılarına odaklanıyor. Postgres-X2 sadece veri merkezinin yüksek kullanılabilirliğini tartışıyoruz:

Yüksek kullanılabilirlik açısından, Greenplum'dan farklı olarak, GTM yalnızca bir ana düğüme sahiptir ve OLTP hizmetleri için uygun değildir. Postgres-X2'nin kendisi otomatik olarak yüksek kullanılabilirliğe sahip olmasa da, farklı iş koşullarına göre yüksek kullanılabilirlik oluşturmak için SPOF (tek hata noktası) tarafından analiz edilebilir.Örneğin, yukarıdaki resim yüksek kullanılabilirlikli bir mimari oluşturmak için Birincil Bekleme yaklaşımını kullanır. Ek olarak, orijinal Postgres-XC, D-Düğümleri arasında veri iletemez ve verilerin işlenmesi için C düğümünde toplanması gerekir Postgres-X2, D-Düğümleri arasında veri aktarımına izin verir.

Yukarıda, PostgresSQL ve onun dağıtılmış projesi Postgres-X2 hakkında daha kapsamlı bir anlayışa sahibiz, özetleyebiliriz:

"Veritabanı Teknolojisinin 40 Yıllık Gelişim Tarihinden Yeni Yolculuğa Bakmak" başlıklı makalede, veritabanının gelişim geçmişini gözden geçirdik ve veritabanının tanımını yeniden anladık - veritabanı, belirli bir veri yapısına (veri yapısına dayanan, veri depolamak için bir ambar) Yapı, veri organizasyonu veya veri arasındaki bağlantı anlamına gelir) depolamayı organize etmek için, veritabanındaki verileri veritabanı tarafından sağlanan çeşitli yöntemlerle yönetebiliriz. Programlarımızın tümü bellekte çalışıyor. Program bittiğinde veya bilgisayar kapatıldığında, programdaki veriler kaybolacak, bu nedenle veri güvenliğini sağlamak için bazı programların verilerini sabit diskte saklamamız gerekiyor Seks. Açıkça söylemek gerekirse, bir veritabanı, verileri depolamak için bir depodur.

Veritabanlarının birkaç kategoriye ayrılabileceğinden daha önce bahsetmiştik:

RDBMS'den MPP'ye ve NoSQL veritabanına 40 yıllık veritabanı geliştirme sürecinden sonra, şimdi NewSQL veritabanına dikkat etmeye başlıyoruz. Her aşamanın özellikleri nelerdir?

• RDBMS - İlişkisel veritabanlarının avantajları şunlardır: işlemler, dizinler, ilişkilendirmeler ve güçlü tutarlılık Dezavantajları: sınırlı ölçeklenebilirlik, sınırlı kullanılabilirlik ve veri yapısı tablo alanına bağlıdır;

• MPP - Büyük ölçüde paralel bilgi işlem veritabanlarının avantajları güçlü ölçeklenebilirlik, işlemler, indeksler, ilişkilendirmeler ve ayarlanabilir tutarlılıktır Dezavantajlar: uygulama düzeyinde bölümleme ve veri yapısı tablo alanına bağlıdır;

• NoSQL-İlişkisel veritabanlarının ötesinde, veritabanlarının avantajları güçlü ölçeklenebilirlik, ayarlanabilir tutarlılık ve esnek veri yapılarıdır, ancak dezavantajları zayıf işlem desteği, zayıf dizin desteği ve zayıf SQL desteğidir.

En klasik olanı, esas olarak işlem işleme yapılandırılmış veritabanı için kullanılan geleneksel ilişkisel OLTP veritabanıdır.Tipik örnekler, kurumsal transfer ve muhasebe, sipariş ve ürün envanter yönetimidir. Karşılaştığı temel zorluk, yüksek eşzamanlılık, yüksek kullanılabilirlik ve yüksek performans altında veri doğruluğu ve tutarlılığıdır.

Bunun ardından, sistem karşılığında zorunlu veri tutarlılığı olmaksızın yapılandırılmamış veya yarı yapılandırılmış verileri (belgeler, grafikler, zaman serileri, zaman ve alan, KV gibi) depolamak ve işlemek için kullanılan NoSQL veritabanları ve özel veritabanları izler Üretim kapasitesinin seviye genişletilmesi ve iyileştirilmesi.

Diğeri analitik veritabanıdır (Çevrimiçi Analitik İşleme, OLAP), uygulama senaryoları, derinlemesine akıllı analizi destekleyebilen büyük veriler, karmaşık veri türleri ve karmaşık analiz koşullarıdır. Karşılaştığı temel zorluklar, yüksek performans, analiz derinliği, TP veritabanları ile bağlantı ve NoSQL veritabanları ile bağlantıdır.

Temel veri motoruna ek olarak, veri aktarımı, veri yedekleme ve veri yönetimi gibi veri tabanı dışında hizmetler ve yönetim araçları da vardır.

NoSQL veritabanı, ölçeklenebilirlik ve yüksek eşzamanlı erişim sorununu çözer, ancak yine de aşağıdaki gibi pek çok tatmin edici olmayan husus vardır:

• Dizin, dizin etkili bir şekilde kullanılamaz - > Ad Hoc Sorgu;

• Eş işlemciler bilgi işlem görevlerini dağıtamaz - > Büyük tabloların sorgusunu birleştir;

• SQL dışındaki analitik sorgular - > Veri Bilimi / Makine Öğrenimi;

• Diğer veri kaynaklarına erişin - > Mevcut Hadoop verileriyle ortak sorgu (çok kaynaklı heterojen);

• Etkileşimli analiz > Karmaşık SQL sorgularının performans sorunları.

Yani NewSQL çıkmaya hazır.

NewSQL veritabanı hakkında konuşmak için Google'ın F1 / Spanner büyük ölçekli dağıtılmış veritabanıyla başlamalıyız.

1. Google F1 / Spanner

Birçok internet şirketi gibi, Google da ilk günlerde Mysql'i yoğun bir şekilde kullanıyordu. Mysql bağımsızdır, hata toleransı için Master-Slave'i ve genişletmek için bölümü kullanabilirsiniz. Bununla birlikte, çok sayıda manuel çalıştırma ve bakım çalışması gerekir ve birçok kısıtlama vardır. Bu nedenle Google, hataya dayanıklı ve ölçeklenebilir bir RDBMS-F1 geliştirdi. Genel dağıtılmış veritabanlarının aksine F1, RDMS'nin işlevlerinden ödün vermeden karşılık gelir. İlk başta F1, MySQL'e dayanıyordu, ancak kademeli olarak Spanner'a taşınacak.

F1 aşağıdaki özelliklere sahiptir:

• 7 × 24 yüksek kullanılabilirlik. Belirli bir veri merkezi çalışmayı durdursa bile, hala kullanılabilir durumdadır;

• Aynı zamanda güçlü tutarlılık ve zayıf tutarlılık sağlayabilir;

• Ölçeklenebilir;

• SQL desteği;

• İşlem gönderme gecikmesi 50-100ms, okuma gecikmesi 5-10ms, yüksek verim.

Spanner, Google'ın Küresel Olarak Dağıtılmış Veritabanıdır. Spanner'ın ölçeklenebilirliği şaşırtıcı bir küresel düzeye ulaştı ve milyonlarca makineye, yüzlerce veri merkezine ve trilyonlarca satıra genişletilebilir. Daha da güçlü olan şey, abartılı ölçeklenebilirliğe ek olarak, aynı anda eşzamanlı çoğaltma ve çoklu sürüm aracılığıyla harici tutarlılığı da karşılayabilmesidir ve kullanılabilirlik de çok iyidir. CAP'ın zincirlerini kırın ve üçünü mükemmel şekilde dengeleyin.

Spanner, eşzamanlı çoğaltmayı da destekleyen ölçeklenebilir, çok sürümlü, küresel olarak dağıtılmış bir veritabanıdır. O, küresel ölçekte ölçeklenebilen ve harici olarak tutarlı işlemleri destekleyebilen ilk Google'dır. Spanner, GPS ve atomik saatler ile uygulanan bir zaman API'si olmadan bunu yapabilir. Bu API, veri merkezleri arasındaki zamanı 10 ms ile senkronize edebilir. Bu nedenle, birkaç temel işlev vardır: kilitsiz okuma işlemi, atomik şema modifikasyonu, blok olmadan geçmiş verileri okuma.

F1 / Spanner açık kaynak olmadığından, F1 / Spanner'a yalnızca mevcut halka açık bilgiler aracılığıyla bir göz atabiliriz. Bu nedenle, esas olarak Google'ın PostgreSQL'den çok daha değerli olan kamuya açık bilgileriyle öğrenir ve kendimizi geliştiririz.

2. F1 Query'nin NewSQL temeli

2018'de Google, F1 / Spanner mimarisine yükseltme anlamına gelen "F1 Sorgusu: Ölçekli Bildirime Dayalı Sorgulama" adlı makaleyi yayınladı. Aşağıdaki temel sorunları çözdü:

• İlk olarak, birden çok heterojen depolama platformu (Bigtable, Spanner, Google Spreadsheets, vb.) Bir arada var olur;

• İkinci olarak, farklı depolama platformlarındaki hesaplamalar tek tip değildir;

• Üçüncüsü, karmaşık iş mantığı gerçek zamanlı analiz ve veri işleme (HTAP) gerektirmeye başlar.

Böylece F1 veritabanı böyle bir veritabanına genişletildi:

• Birincisi, alt katmana bağlı farklı veri kaynaklarına sahip bağımsız bir bilgi işlem katmanıdır;

• İkinci olarak, OLTP, OLAP ve ETL'nin iş yükünü birleştirmeye çalışır;

• Üçüncüsü, aynı zamanda tam bir ETL platformudur;

• Dördüncüsü, birkaç yeni veri erişim biçimi, UDF, UDA ve TVF SQL tanıttı;

• Beşincisi, Gölgeleme-hiçbir şey, bu daha sonra ayrıntılı olarak tanıtılacaktır.

CAP ilkelerinin mükemmel entegrasyonundan sonra bir tür veri, üç senaryoda veri tabanlarının kullanımını destekleyen benzeri görülmemiş sorunu çözdü: OLTP, OLAP ve ETL. Bize "yeni" bir dünya getirdiği söylenebilir, çünkü veritabanlarında "yeni" bir çağ yaratmıştır. Bu "yeni", 451 Grup analisti Matthew Aslett tarafından "NewSQL" olarak adlandırıldı.

Üç, NoSQL perde çağrısı, NewSQL başlangıcı

NewSQL terimi 451 Group'tan analist Matthew Aslett tarafından bir araştırma makalesinde önerildi. Yerleşik veritabanı satıcılarına meydan okuyan yeni bir veritabanı sistemi türünü ifade eder. NewSQL, çeşitli yeni ölçeklenebilir / yüksek performanslı veritabanlarının kısaltmasıdır.Bu tür bir veritabanı, yalnızca büyük veriler için NoSQL depolama ve yönetim özelliklerine sahip olmakla kalmaz, aynı zamanda ACID ve SQL'i destekleyen geleneksel veritabanlarının özelliklerini de korur.

NewSQL, bu tür yeni bir ilişkisel veritabanı yönetim sistemini ifade eder.OLTP (okuma-yazma) iş yükleri için, ACID ve SQL (ölçeklenebilir ve ACID ve (ilişkisel ve ilişkisel) özelliklerini korurken, NoSQL sistemleriyle aynı genişletilmiş performansı sağlamayı amaçlamaktadır. / veya sql -erişim)).

NewSQL ortaya çıkıp geliştikten sonra, büyük bir teknoloji ailesi oluşturdu:

Yukarıdakilerden, NewSQL'in avantajlarının SQL'in destek yeteneği, ölçeklenebilirliği, gerçek zamanlı ve işlem işleme yeteneklerinde yattığını öğrenebiliriz. NewSQL'in güçlü gelişimi öncülüğünde, birçok yeni teknoloji şirketi kendi yeni nesil dağıtılmış veritabanlarını oluşturmaya başladı. Tasarım konsepti:

1. Dağıtılmış mimari

Ana düğüm tarafından verilen görevler modu sayesinde, her düğüm hizmet sağlayabilir.Ölçeklenebilirlik açısından, ana düğüm bir darboğaz olmayacaktır.

• İstemci, ana hizmet düğümü hizmetine farklı arayüz erişim formları aracılığıyla doğrudan erişir;

• Ana hizmet düğümü, analiz ve işleme için hizmet talebini alır ve yürütme için farklı dağıtım hizmeti düğümlerine dağıtır;

• Parçalama hizmet düğümü, yürütme talebini alır, SQL analizi işlemini gerçekleştirir ve SQL planını yürütür;

• SQL yürütme hizmetinin alt katmanı, verileri işleme erişimi için depolar ve işleme sonuçlarını döndürür;

• Raft protokolü aracılığıyla hizmetler arasında veri senkronizasyonunu sağlayın;

• Depolama, AP ve TP'ye göre paylaşımlı depolama ve paylaşılmayan depolama olarak ikiye ayrılır.

Bunun aksine, PostgreSQL'in mevcut dağıtılmış mimarisi MPP'dir, hiçbir şeyi paylaşmaz ve düğüm verilerinin yeniden dağıtımını artırma ve azaltma sorunu vardır.

2. Alt veritabanı ve tablodan Parçalama ve Bölümlemeye (parçalama ve bölümleme)

Önceki PostgreSQL yorumumuza göre, veri alt veritabanı alt tablosu zorunlu bir seçimdir.Alt veritabanı alt tablosunu yapamıyorsanız, bu tasarımı yapmamaya çalışın çünkü iş gereksinimleri gerektirir. Veya işi değiştirin. Bu nedenle, NewSQL tasarımında, daha fazla Sharding and Partition (sharding and partitioning) tasarımı yapmalıyız.

Veri bölümü

Bölümleme, bir tablonun verilerini N bloğa bölmektir.Mantıksal olarak, bu sadece bir tablodur, ancak alt katman N fiziksel bloktan oluşur.

Bölümleri ne zaman kullanmayı düşünmelisiniz? Bir tablonun sorgu hızı, kullanımını etkileyecek kadar yavaş olduğunda, veri miktarı büyüktür, SQL optimize edilir, tablodaki veriler bölümlere ayrılır veya verilerin işleyişi genellikle verilerin tamamını değil, yalnızca bir bölümünü içerir.

Bölümleme ile çözülen temel sorun, sorgu verimliliğini artırmaktır.

Veri parçalama

Dağıtılmış bir depolama sisteminde, verilerin birden çok cihazda depolanması gerekir Veri parçalama, verilerin birden çok depolama cihazına dağıtımını belirlemek için kullanılan bir teknolojidir. Veri parçalama üç hedefe ulaşmalıdır:

• Tek tip dağılım, yani her cihazdaki veri miktarı mümkün olduğu kadar yakın olmalıdır;

• Yük dengeleme, yani her cihazdaki istek miktarı olabildiğince yakın olmalıdır;

• Genişleme ve daralma sırasında olabildiğince az veri geçişi.

3. Veri senkronizasyonu ve tutarlılık-Raft / Paxos

Mevcut ana NewSQL veritabanı veri senkronizasyonu, Raft protokolüne dayanmaktadır.

Raft'ta üç rol vardır:

Lider: İstemci isteklerini almaktan, günlükleri diğer düğümlere kopyalamaktan ve diğer düğümlere bu günlükleri uygulamanın güvenli olduğu zamanları bildirmekten sorumludur;

Aday: Lideri seçmek için kullanılan bir rol;

Takipçi: Lider veya Adaydan gelen taleplere cevap vermekten sorumludur.

• Tüm düğümlerin başlangıç durumu, takipçi rolüdür;

• Zaman aşımı süresi içinde Liderin talebi alınmazsa, seçim için Aday'a dönüştürülür;

• Aday, çoğu düğümden oy alır ve Lidere dönüştürür; Lider bulur veya daha yüksek bir dönem için bir talep alır, Takipçi'ye dönüştürür;

• Lider, daha yüksek bir dönem için bir istek aldıktan sonra Takipçiye dönüşür.

Raft durum makinesi:

• Tüm fikir birliği algoritmaları bir durum makinesini içerir ve durum makinesi, sistemin tutarlı bir durumdan başladığını ve sonunda başka bir tutarlı duruma ulaşmak için aynı sırayla bir dizi talimatı yürütmesini garanti eder.

• Tüm düğümler, günlükleri aynı sırayla işler, böylece x, y ve z'nin son değerleri birden çok düğümde tutarlıdır.

Bu noktada, PostgreSQL-X2'nin mimarisi bir master-slave modunda belirlenir.

Dört, dağıtılmış işlem

• İşlemin başlangıcında, işlemin benzersiz kimliğini kaydedin, işlemi gerçekleştirin, değiştirilen parçayı kaydedin, ön taahhüt eylemini gerçekleştirin, kesin veya geri alın;

• Kilit mekanizması şu anda yazarken kullanılmaktadır;

• Okuma, anlık görüntü okumayı kullanır ve depolama katmanına her yazma ek bir yazma işlemidir ve veri değişiklikleri, bir üzerine yazma mekanizması aracılığıyla yapılır.

Bunun avantajı, verilerin tazeliğinin gerçek zamanlı olarak garanti edilebilmesi ve gerçek zamanlı veri ambarı gibi veri güncelleme ekleme ve analizlerinin birlikte tamamlanabilmesi ve gerçek zamanlı istatistiksel özet hesaplamanın gerçekleştirilebilmesidir. PostgreSQL'de OLAP gruplar halinde veya ekler halinde güncellenebilse de, insan müdahalesine sürekli yatırım ile manuel olarak optimize edilmesi gerekir ve performans pasif olarak garanti edilir.

Beş, depolama katmanı-KV depolama

Depolama açısından iki seçeneğimiz var:

• Yığın depolama: veriler anahtar aracılığıyla elde edilebilir ve veriler aynı anda doğrudan okunabilir;

• Yığınsız depolama: Veriler yalnızca anahtarla elde edilebilir ve veriler doğrudan okunamaz.

Yığın olmayan depolama, verileri yalnızca anahtarlar aracılığıyla elde edebilir, bu da sürekli ayrı okumaya neden olur, bu nedenle AP senaryolarına uyarlanamaz.

• İstemci, ana hizmet düğümü hizmetine farklı arayüz erişim formları aracılığıyla doğrudan erişir;

• Ana hizmet düğümü, analiz ve işleme için hizmet talebini alır ve yürütme için farklı dağıtım hizmeti düğümlerine dağıtır;

• Parçalama hizmet düğümü yürütme talebini alır, sql ayrıştırma işlemini gerçekleştirir ve SQL planını yürütür;

• SQL yürütme hizmetinin alt katmanı, verileri işleme erişimi için depolar ve işleme sonuçlarını döndürür;

• Zookeeper, ilgili servis uygulamalarının yüksek kullanılabilirliğini garanti eder;

• HDFS, temeldeki depolama verilerini korur ve verilerin kaybolmamasını sağlamak için üçlü kopyalama teknolojisini kullanır.

Bunun aksine, PostgreSQL yerelleştirilmiş bir depolamadır ve depolama da sütun depolamaya ve satır depolamaya bölünebilir.

Altı, çok kaynaklı heterojenlik ve veri konfederasyonu

NewSQL'in verileri çok kaynaklı heterojendir ve geçmiş veritabanının, özellikle de NoSQL ve Hadoop ekosistemlerinin kapsamlı desteğini dikkate almak gerekir, çünkü sonuçta bu ikisi zaten çok popüler.

Çok kaynaklı heterojenlik açısından PostgreSQL, Oracle, PG, MySQL, MongoDB, vb. Erişebilen FDW aracılığıyla çok kaynaklı heterojenliği destekler. Hadoop sistemi ve NoSQL için düşük desteği vardır ve verimlilik ve performansta en üst noktaya ulaşmak zordur.

Yedi, NewSQL tabanlı dağıtılmış veritabanı uygulaması

NewSQL aracılığıyla yukarıdaki altı noktaya dayanarak:

• Dağıtık mimari;

• Veri bölümleme;

• Veri senkronizasyonu ve tutarlılığı;

• Dağıtılmış işlem

• Depolama katmanı, KV depolama tasarımı;

• Çok kaynaklı heterojen veritabanı.

Tasarım ve geliştirmeyi entegre ettik ve kendi kendini kontrol edebilen bir yerel dağıtılmış veritabanı olan Hubble'ı başlattık. Hubble, hem OLTP hem de OLAP senaryolarını destekler, yani aynı veriler üzerinde, işlem işlemeyi uygularken gerçek zamanlı analizi destekler ve zaman alıcı ETL sürecini ortadan kaldırır.

Son olarak, PsostgreSQL-X2 ile yatay bir analiz yapmak için Hubble'ı bir temsilci olarak kullanmak, bu makalenin başında belirtildiği gibi, dağıtılmış veritabanının iki boynuzunun teknik rotalarını daha iyi anlamamıza yardımcı olabilir.

Yazar hakkında: Sky Cloud Data Shanghai Şubesi genel müdür yardımcısı Zhang Qiujian, kıdemli finans sektörü büyük veri teknolojisi mimarisi uzmanı. Bilgisayar bilimi ve teknolojisi alanında yüksek lisans derecesinin ardından IBM ve diğer şirketlerde çalıştı ve Jiu San Society'nin Finans Komitesi'nin bir üyesiydi. Şu anda ağırlıklı olarak bankacılık, menkul kıymetler ve sigorta gibi finans sektörü müşterileri için büyük veri platformu ve yapay zeka platformunun planlama ve tasarım çalışmalarını sağlamaktadır. IEEE ve diğer dergilerde birçok makale yayınladı.

30 yıllık açık kaynak kargaşası: özgür bir topluluktan multi-milyar dolarlık bir şirkete

Yapay zekanın en büyük başarılarından birini anlayın: evrişimli sinir ağlarının sınırlamaları

GitHub, en iyi Apache projesi olan ShardingSphere'in açık kaynak yolu olan 10.000'den fazla yıldıza sahiptir

KongHong Kong Bilim ve Teknoloji Üniversitesi Akademisyeni Zheng Guangting geleceği sordu ve en son AI uygulamalarını ve uygulamalarını ortaya çıkardı

Büyük promosyon altında akıllı operasyon ve bakım zorluğu: Ali "çifte 11 kedi gecesine" nasıl direniyor?

Ethereum 2.0'da Saklama Oyunu ve MPC uygulaması

Sizler için çok dikkatli bir şekilde 9 MySQL mülakat sorusu yazdım, toplamanız tavsiye edilir!

Dahi olmayan bir oyuncu olarak, sıradan programcılar nasıl geliştirebilir ve canavarlarla savaşabilir?

Aceminin anlayabileceği Java istisna yönetimi

30 yıllık açık kaynak kargaşası: özgür bir topluluktan milyarlarca dolarlık bir şirkete

Hong Kong Bilim ve Teknoloji Üniversitesi Akademisyeni Zheng Guangting geleceği sordu ve AI'nın en son uygulamalarını ve uygulamalarını ortaya çıkardı

Jack Ma, en büyük 25 anti-salgın lider olarak seçildi; Zhou Hongyi, 360 Finansal Hizmetler olarak istifa etti; Node.js 14 yayınlandı | Geek Headlines

Yalnızca lise matematiği algoritmaları keşfedebilir mi? Google'ın açık kaynaklı AutoML-Zero ne kadar güçlü?

Kubernetes'e göre PaaS nasıl seçilir?

Akıllı değişim çağında gezinmek 2020 NAVIGATE Navigator Summit bulutta yelken açıyor

Yarın gece saat 8'de "AI Face Swap" ın sırrını açıklayacağım: fotoğraflarda veya videolarda yüz değiştirmenin arkasındaki temel teknoloji ve uygulama

Süper detaylı! Bu makale, SparkStreaming'in Kafka ile nasıl bütünleştiğini ayrıntılı olarak açıklamaktadır! Kod uygulanabilir

Her dakika 1 milyar düğüm grafiği hesaplaması işleyen Plato'ya ne dersiniz?

15 Nisan'da 348 set günlük devlet ticari konut satıldı ve 175 set ikinci el konut satıldı