Veritabanının bu performans optimizasyonlarını yaptınız mı?
İnternet projelerinde, iş ölçeği büyüdükçe ve büyüdükçe, veriler gittikçe daha da artıyor ve veri tabanı üzerindeki baskı artacaktır.
Bir önceki makalede bahsedilen önbelleğe alma şeması, SQL optimizasyonu, vb. Gibi optimize etmek için çeşitli yöntemler benimseyebiliriz. Bu yöntemlere ek olarak, burada veritabanı optimizasyonu için birkaç yaygın yöntem vardır: "veri okuma ve yazma ayrımı" ve "veritabanı Parçalama ". Bu iki nokta, temelde büyük ve orta ölçekli internet projelerinde kullanılan çok yaygın çözümlerdir.
Ayrıntılı olarak bir göz atalım.
1. Okuma ve yazmadan CQRS'ye ayrılma
(Resim kaynağı Alibaba Cloud)
İnternet iş senaryolarının çoğu, az yazmaktan çok okunduğu için, veritabanının okunmasını ve yazılmasını ayırmak çok basit ve verimli bir çözümdür.
Basitçe ifade etmek gerekirse, okuma ve yazma ayrımı, verilerin okuma ve yazma işlemlerini ayırmak ve bu iki işlemin farklı veri tabanlarına erişmesine izin vermektir.Bu şekilde veri tabanı üzerindeki baskı azaltılabilir.
Örneğin, yukarıdaki şekilde, veritabanı, esas olarak yazma işlemleri (bazen bir okuma işlemi) sağlamak için kullanılan bir "ana örneğe" sahip olacaktır. "Ana örneğe" ek olarak, birden çok "yardımcı örnek" (içinde Şekilde salt okunur bir örnek gösterilmektedir), "bağımlı durum" işlevi yalnızca okuma işlemlerini gerçekleştirmek için kullanılır.
Daha sonra birden fazla veri tabanı vardır, birden çok veri tabanı arasında veri tutarlılığı nasıl sağlanır?
Aslında, yaygın olarak kullanılan veri tabanlarımız bu tür bir senkronizasyon işleviyle birlikte gelir; örneğin, kendi başına bir ana-bağımlı işlevi olan ve ikili günlük çoğaltmaya dayanan ana veri tabanı ve ikincil veri tabanı verilerinin otomatik senkronizasyonunu gerçekleştirebilen Mysql gibi. Ana kitaplığa yazma işlemleri bir ikili günlük oluşturacak ve ardından Mysql bu günlüğü eşzamansız olarak ikincil kitaplığa senkronize edecek ve ikincil kitaplık ikili günlüğü otomatik olarak yeniden çalıştıracak, ardından veriler ana kitaplıkla tutarlı olacaktır.
Mysql'e ek olarak, Oracle gibi ticari veritabanları da benzer işlevlere sahiptir.İnternette birçok açık kaynak üçüncü taraf veri senkronizasyon aracı vardır ve birçok olgun ve kullanımı kolay araç vardır.
Tamam, "ana örnek" ve "bağımlı örnek" arasındaki veri senkronizasyonu sorunu çözüldü. Şimdi hala bir sorun var. Yazma istekleri "ana örneğe" nasıl erişir ve projedeki "bağımlı örneğe" erişmek için istekleri okur. "Örnek", bu yönlendirme kuralı nasıl uygulanır?
İki geleneksel yöntem vardır:
Kodlamayı kullan
Bu yöntem temelde öğrencilerin kodlama sırasında okuma ve yazmanın farklı işlem gereksinimlerine göre farklı veri kaynaklarını çağırmalarına dayanır. Örneğin, veri işlem katmanında (DAO katmanı), verileri okuma ve yazma verileri iki yönteme (işlevlere) ayrılır ve ardından bu iki yöntem için farklı veritabanları belirtilir.
Ancak bu yöntem biraz sabit kodlanmıştır ve geliştiriciler için bu konuya fazladan dikkat etmeniz gerekir, bu da bir kodlama maliyeti ekler ve yanlışlıkla gözden kaçması kolaydır.
Ara yazılım kullan
Bu yöntem, aşağıdaki şekilde gösterildiği gibi, arka uç veritabanının önünde bir veritabanı proxy hizmetinden önce gelir: MySQL-Proxy, okuma-yazma ayırma isteklerini uygulamak için Mysql tarafından sağlanan bir ara yazılımdır, ancak çoğu kişi bu bileşeni kullanmaz. , Bunun yerine Mycat, ProxySQL vb. Gibi diğer bazı açık kaynak bileşenlerini seçebiliriz, ancak genel prensip benzerdir.Bu şemayı bu şemadan anlamak kolaydır.
Eh, okuma ve yazmanın temel ayrımı sona erdi, ancak bu yöntemin pratik ve pratik olmasına rağmen çok zorlayıcı olmadığını hissediyorum.
Tamam, eğer zorunlu bir format istiyorsanız, lütfen sizi tatmin etmek için, o zaman başka bir zorunlu okuma ve yazma ayrımı kavramından bahsedelim: "CQRS"
CQRS: Komut Sorgusu Sorumluluk Ayrımı
Sipariş (ekleme, silme, değiştirme) ve sorgulama için sorumlulukların ayrılması
Önce resme bakalım. Yukarıdaki resim sayesinde CQRS'yi basitçe anlayabiliriz
CQRS, işteki sorumlulukları açıkça ayıran Sorgu (okuma) ve Komut (yazma) ayrımını vurgular.Komut esas olarak iş mantığının yürütülmesi için kullanılır ve Sorgu, veri sorgulama ve görüntülemeden sorumludur. Aynı zamanda bu iki işlem farklı veri kaynaklarına dayanmaktadır, hatta biri bir veritabanı, diğeri NoSQL'dir.Sorgu ile sorgulanacak veri kaynağı, veri modeline göre saklamak yerine, doğrudan etki alanı modeline göre depolanabilir, bu nedenle sorgulama Dönüştürülmeden çıktığında hemen görüntülenebilir ve sorgu verimliliği yüksektir.
Aslında, CQRS ünlü Martin Fowler tarafından önerildi ve bilgisayarlarla ilgilenen herkesin bunu bilmesi gerekir. CQRS'yi daha derinlemesine öğrenmek istiyorsanız, Martin Fowler'in halka açık bilgilerini okuyabilirsiniz.
2. Parçalama (alt veritabanı ve alt tablo)
Yukarıdaki veritabanının okuma ve yazma ayrımını bitirdikten sonra, veritabanının parçalanmasından bahsedelim.
Veritabanındaki veriler gittikçe büyüdükçe, tek tablo sorgusunun performansı artık iş gereksinimlerini karşılayamaz. Şu anda tabloyu bölmek gerekir. Büyük tabloyu birkaç küçük tabloya ve verileri farklı alt tablolara bölün Aynı şey değil Bu, sorgu baskısını yayabilir ve işlem verimliliğini artırabilir.
Bununla birlikte, gittikçe daha fazla tablo olduğunda ve tüm veriler tek bir veritabanında olduğunda, ağ G / Ç ve dosya GÇ'si de tek bir veri tabanında yoğunlaşacaktır ve bu da tek bir sunucu, CPU, bellek, dosya GÇ, ağ GÇ kapasitesini aşabilir. Sistemin darboğazı haline gelecektir ve QPS / TPS ayrıca tek bir veritabanı örneğinin işleme sınırını aşacaktır. Daha sonra şu anda veritabanının parçalanması gerekiyor.
Alt tablo ve alt kütüphane fikri benzer olduğundan, teknik çözümlerden birleşik bir şekilde bahsedelim.
Aslında, alt veritabanı alt tablosu sadece popüler ve anlaşılması kolay dilimizdir, doğru açıklama şöyle olmalıdır: veri parçalama
İki ana veri parçalama modu vardır:
Dikey bölme
Yatay bölme
İki bölünmüş uygulamanın senaryoları farklıdır:
Dikey bölme, iş modüllerine göre bölmeyi ifade eder. Basitçe ifade etmek gerekirse, iş yoğun modüllerin alanlarını / tablolarını aynı veritabanı veya sunucu üzerinde bir araya getirmektir. Farklı işletmelerin alanlarını / tablolarını ayırın ve bunları farklı veri tabanlarına veya sunuculara bölün. Örneğin, bir oyun sisteminde, temel oyuncu bilgileri, destek loncası gibi bilgilerden ayrılabilir.
Örnekte gösterildiği gibi:
(Görüntü kaynağı ağı)
Yatay bölme, yalnızca belirli bir veri kuralına / biçimine göre bölmeyi ifade eder. Örneğin, veri kimliğinin karmasına göre bölün, verilerin tarihine göre bölün, belirli bir aralığa göre bölün vb. Dinamik veri değişiklikleriyle, parça sayısının buna göre dinamik olarak ayarlanması gerekebileceği unutulmamalıdır.Ayrıca, yatay parçalama iş özelliklerini dikkate almaz, bu nedenle parçalamada iş özeti sorgusu veya işlem işleme Bazen daha zahmetli oluyor.
Örnekte gösterildiği gibi:
Ek olarak, pratik uygulamalarda, iki bölme modu genellikle daha iyi sonuçlarla birlikte kullanılır.
