Veritabanı alt veritabanı alt tablo fikirleri
- 1. Veri segmentasyonu
- 1. Dikey (boyuna) segmentasyon
- 2. Yatay (yatay) segmentasyon
- 2. Alt veritabanı ve alt tablodan kaynaklanan sorunlar
- 1. İşlem tutarlılığı sorunları
- 2. Çapraz düğüm ilişkili sorgu birleştirme sorunu
- 3. Düğümler arası sayfalama, sıralama ve işlev sorunları
- 4. Küresel birincil anahtar kaçınma sorunu
- 5. Veri taşıma ve genişletme sorunları
- 3. Segmentasyonu ne zaman düşünmelisiniz
- 1. Bölmeden bölmemeye çalışın
- 2. Veri miktarı çok fazla ve normal işletim ve bakım iş erişimini etkiliyor
- 3. İşletme geliştikçe bazı alanların dikey olarak bölünmesi gerekir
- 4. Veri hacminin hızlı büyümesi
- 5. Güvenlik ve kullanılabilirlik
- 4. Vaka analizi
- 1. Kullanıcı merkezi iş senaryosu
- 2. Yatay segmentasyon yöntemi
- 3. uid olmayan sorgu yöntemi
- 5. Alt veritabanı ve alt tablo ara yazılımını destekleyin
1. Veri segmentasyonu
İlişkisel veritabanının kendisinin bir sistem darboğazı haline gelmesi nispeten kolaydır ve tek bir makinenin depolama kapasitesi, bağlantı sayısı ve işleme kapasitesi sınırlıdır. Tek bir tablonun veri hacmi, çok sayıda sorgu boyutu nedeniyle 1000W veya 100G'ye ulaştığında, veritabanı eklenip dizin optimize edilse bile, birçok işlem gerçekleştirildiğinde performans ciddi şekilde düşmeye devam edecektir. Şu anda segmentasyonu dikkate almak gerekir Segmentasyonun amacı veri tabanı üzerindeki yükü azaltmak ve sorgu süresini kısaltmaktır.
Dağıtılmış veritabanının temel içeriği, veri bölümlemeden (parçalama) ve bölümlemeden sonra verilerin konumlandırılması ve entegrasyonundan başka bir şey değildir. Veri segmentasyonu, verileri birden çok veritabanında depolamaktır, böylece tek bir veritabanındaki veri miktarı azaltılır ve tek bir veritabanının performans sorunları, veritabanı işlem performansının iyileştirilmesi amacına ulaşmak için ana bilgisayarların sayısı artırılarak hafifletilir.
Veri segmentasyonu, segmentasyon türüne göre iki yola ayrılabilir: dikey (dikey) segmentasyon ve yatay (yatay) segmentasyon
1. Dikey (boyuna) segmentasyon
İki yaygın dikey bölme türü vardır: dikey alt kitaplık ve dikey alt tablo.
Dikey alt veritabanı, iş birleştirmesine göre farklı veri tabanlarında düşük korelasyonlu farklı tabloların saklanmasıdır. Yaklaşım, büyük bir sistemin, işletme sınıflandırmasına göre bağımsız olarak bölünen çok sayıda küçük sisteme bölünmesine benzer. "Mikro hizmet yönetişimi" yaklaşımına benzer şekilde, her mikro hizmet ayrı bir veritabanı kullanır. Gosterildigi gibi:
img
Dikey tablo bölme, veritabanındaki "sütunlara" dayanır.Bir tabloda birçok alan varsa, genişletilmiş bir tablo oluşturabilir ve sık kullanılmayan alanları veya alan uzunluğu genişletilmiş tabloya bölebilirsiniz.
Birçok alan olması durumunda (örneğin, büyük bir tablonun 100'den fazla alanı vardır), "büyük tablo bölünmüş küçük tablo" aracılığıyla geliştirilmesi ve sürdürülmesi daha kolaydır ve ayrıca sayfalar arası sorunları önleyebilir MySQL'in alt katmanı veri sayfaları aracılığıyla saklanır. Çok fazla yer kaplayan kayıtlar, sayfa aralıklarına yol açarak ek performans yüküne neden olur.
Ek olarak, veritabanı verileri satır birimleri halinde belleğe yükler, böylece tablodaki alanların uzunluğu daha kısa ve erişim frekansı daha yüksek, bellek daha fazla veri yükleyebilir, isabet oranı daha yüksek ve disk IO azaltılarak veritabanı performansı artırılır.
img
Dikey segmentasyonun avantajları:
- Net bir iş ile iş sistemi düzeyinde birleştirmeyi çözün
- Mikro hizmetlerin yönetişimine benzer şekilde, farklı işletmelerin verilerinin hiyerarşik yönetimini, bakımını, izlenmesini ve genişletilmesini de gerçekleştirebilir.
- Yüksek eşzamanlılık senaryolarında dikey bölümleme, GÇ, veritabanı bağlantıları ve tek makineli donanım kaynaklarının darboğazını belirli bir ölçüde iyileştirir.
Dezavantajları:
- Bazı tablolar birleştirilemez ve yalnızca geliştirmenin karmaşıklığını artıran arabirim birleştirme ile çözülebilir
- Karmaşık dağıtılmış işlem işleme
- Hala tek bir tabloda aşırı veri hacmi sorunu var (yatay bölümleme gereklidir)
2. Yatay (yatay) segmentasyon
Bir uygulamanın ince taneli dikey bölümlemenin zor olması veya bölümlemeden sonraki veri satırlarının sayısı çok büyük olduğunda ve tek bir kitaplık okuma / yazma ve depolama performansı darboğazı olduğunda, yatay bölümleme gereklidir.
Yatay segmentasyon, veritabanı alt tablosu ve alt veritabanı alt tablosu olarak ikiye ayrılır.Tabloda yer alan verilerin dahili mantıksal ilişkisine göre, aynı tablo, farklı koşullar altında birden çok veritabanına veya birden çok tabloya dağıtılır ve her tablo yalnızca Verilerin bir kısmı, böylece tek bir tablodaki veri miktarı küçülür ve dağıtılmış bir etki elde edilir. resim gösterdiği gibi:
img
Veritabanındaki alt tablo, sadece tek bir tablodaki aşırı miktarda veri sorununu çözer, ancak tabloları farklı makinelerin kitaplıklarına dağıtmaz, bu nedenle MySQL veritabanı üzerindeki baskıyı azaltmak pek faydalı olmaz, herkes hala aynı fiziksel makine için yarışıyor. CPU, bellek ve ağ GÇ'si en iyi şekilde alt veritabanı ve tablo ile çözülür.
Yatay segmentasyonun avantajları:
- Sistem kararlılığını ve yük kapasitesini artıran tek bir veritabanında aşırı veri hacmi ve yüksek eşzamanlılığın neden olduğu performans darboğazı yoktur
- Uygulama tarafında daha az dönüşüm, iş modüllerini bölmeye gerek yok
Dezavantajları:
- Parçalar arasında işlem tutarlılığını garanti etmek zordur
- Veritabanları arası birleştirme ilişkilendirme sorgusunun düşük performansı
- Veri genişletme zordur ve bakımı çok büyüktür
Yatay bölmeden sonra, aynı tablo birden çok veri tabanında / tabloda görünecek ve her bir veri tabanının / tablonun içeriği farklı olacaktır. Birkaç tipik veri parçalama kuralı şunlardır:
1. Sayısal aralığa göre
Zaman aralığına veya kimlik aralığına göre bölün. Örneğin: farklı aylara ve hatta günlere ait verileri tarihe göre farklı veritabanlarına dağıtın; 19999 kullanıcı kimliğine sahip kayıtları ilk veritabanına atayın, 19999 kullanıcı kimliğine sahip kayıtları ikinci veritabanına atayın, vb. Bir anlamda, bazı sistemlerde kullanılan "soğuk ve sıcak veri ayrımı", daha az kullanılan bazı geçmiş verileri diğer kitaplıklara taşır ve yalnızca iş işlevlerinde sıcak veri sorguları sağlar, bu da benzer bir uygulamadır.
Bunun avantajları:
- Tek masa boyutu kontrol edilebilir
- Doğal olarak yatay olarak genişletmek kolaydır. Parçalanmış kümenin tamamını daha sonra genişletmek isterseniz, diğer parçalardan veri taşımanıza gerek kalmadan yalnızca düğüm eklemeniz gerekir.
- Aralık araması için parça alanını kullanırken, sürekli kırıklar, hızlı sorgu için parçaları hızlı bir şekilde bulabilir ve çapraz parça sorgusu sorununu etkili bir şekilde önleyebilir.
Dezavantajları:
- Sıcak veriler, bir performans darboğazı haline gelir. Sürekli parçalarda, zaman alanına göre parçalama gibi veri etkin noktaları olabilir. Bazı parçalar, verileri en son zaman diliminde depolar ve sık sık okunup yazılabilirken, bazı parçalarda depolanan geçmiş veriler nadiren sorgulanır.
2. Değere göre modülü alın
Genel olarak, hash modulo modunun segmentasyon yöntemi benimsenir, örneğin, Müşteri tablosu cusno alanına göre 4 kütüphaneye bölünür, 0'ın geri kalanı birinci kütüphaneye yerleştirilir ve 1'in geri kalanı ikinci kütüphaneye yerleştirilir. Ve bunun gibi. Bu şekilde, aynı kullanıcının verileri aynı veritabanına dağılacaktır.Sorgu koşulunun bir cusno alanı varsa, sorgu için ilgili veritabanını net bir şekilde bulabilirsiniz.
avantaj:
- Veri parçalama nispeten tek tiptir ve sıcak noktaların ve eşzamanlı erişimin darboğazlarına eğilimli değildir.
Dezavantajları:
- Parçalanmış küme sonraki aşamada genişletildiğinde, eski verilerin taşınması gerekir (tutarlı bir karma algoritması kullanmak bu sorunu daha iyi önleyebilir)
- Çapraz parça sorgusunun karmaşık sorunuyla yüzleşmek kolaydır. Örneğin yukarıdaki örnekte sık kullanılan sorgu koşulu cusno içermiyorsa, veritabanının bulunamamasına neden olacağı için aynı anda 4 veritabanına bir sorgu başlatmak ve ardından bellekteki verileri birleştirmek, en küçük seti alıp uygulamaya geri döndürmek gerekir. Kütüphane sürükleyici hale geldi.
2. Alt veritabanı ve alt tablodan kaynaklanan sorunlar
Alt veritabanı ve sayaç altı, tek makinenin ve tek bir veritabanının getirdiği performans darboğazlarını ve baskıyı etkili bir şekilde birbirine bağlayabilir, ağ GÇ, donanım kaynakları ve bağlantı sayısındaki darboğazı aşabilir ve ayrıca bazı sorunları da beraberinde getirebilir. Bu teknik zorluklar ve ilgili çözümler aşağıda açıklanacaktır.
1. İşlem tutarlılığı sorunları
Dağıtılmış işlem
Güncellenen içerik aynı anda farklı kitaplıklara dağıtıldığında, kaçınılmaz olarak veritabanları arası işlem sorunlarına yol açacaktır. Cross-shard işlemler de dağıtılmış işlemlerdir.Basit bir çözüm yoktur.Genel olarak, işlem için "XA protokolü" ve "iki aşamalı kesinleştirme" kullanılabilir.
Dağıtılmış işlemler, veritabanı işlemlerinin atomikliğini en üst düzeye çıkarabilir. Bununla birlikte, bir işlemi gerçekleştirirken birden fazla düğümün koordine edilmesi gerekir, bu da işlemi gerçekleştirme zaman noktasını geciktirir ve işlemin yürütme süresini uzatır. Sonuç olarak, işlemler paylaşılan kaynaklara eriştiğinde çakışma veya kilitlenme olasılığı artar. Veritabanı düğümlerinin artmasıyla, bu eğilim giderek daha ciddi hale gelecek ve böylece sistemin veritabanı düzeyinde yatay genişlemesi için bir zincir haline gelecektir.
Nihai tutarlılık
Yüksek performans gereksinimleri, ancak düşük tutarlılık gereksinimleri olan sistemler için, nihai tutarlılık izin verilen süre içinde elde edildiği sürece sistemin gerçek zamanlı tutarlılığı genellikle talep edilmez ve işlem telafisi kullanılabilir. Yürütme sırasında bir hata oluştuktan hemen sonra işlemin geri alınmasından farklı olarak işlem tazminatı, bir son kontrol ve düzeltici önlemdir. Bazı yaygın uygulama yöntemleri şunlardır: mutabakat ve veri kontrolü, günlüklere dayalı karşılaştırma ve standart veri kaynaklarıyla normal veri kaynakları Senkronize et vb. İşlem tazminatı da iş sistemi ile bağlantılı olarak düşünülmelidir.
2. Çapraz düğüm ilişkili sorgu birleştirme sorunu
Segmentasyon öncesinde sistemdeki birçok liste ve detay sayfasının ihtiyaç duyduğu veriler sql join ile tamamlanabilir. Segmentasyondan sonra veriler farklı düğümlere dağıtılabilir.Şu anda birleşmeden kaynaklanan sorunlar daha zahmetlidir.Performansı dikkate alarak birleştirme sorgularını kullanmaktan kaçınmaya çalışın.
Bu sorunu çözmenin bazı yolları:
1) Global tablo
Global tablolar, sistemdeki tüm modüllerin güvenebileceği tablolar olan "veri sözlüğü tabloları" olarak da kabul edilebilir. Veritabanları arası birleştirme sorgularından kaçınmak için, bu tür tablonun bir kopyasını her veritabanına kaydedebilirsiniz. Bu veriler genellikle nadiren değiştirilir, bu nedenle tutarlılık konusunda herhangi bir endişe yoktur.
2) Alan yedekliliği
Zaman için alan kullanan ve performans için birleştirme sorgularını önleyen tipik bir anti-paradigma tasarımı. Örneğin, userId sipariş tablosuna kaydedildiğinde, userName de fazladan bir kopyaya kaydedilir, böylece sipariş ayrıntılarını sorgularken "alıcı kullanıcı tablosunu" sorgulamaya gerek kalmaz.
Ancak bu yöntemin uygulama senaryoları da sınırlıdır ve daha az bağımlı alan içeren durumlar için daha uygundur. Gereksiz alanların veri tutarlılığını garanti etmek de zordur.Yukarıdaki sipariş tablosu örneğinde olduğu gibi, alıcı userName'i değiştirdikten sonra geçmiş sırada güncellenmesi gerekir mi? Bu aynı zamanda gerçek iş senaryoları ile birlikte düşünülmelidir.
3) Veri montajı
Sistem düzeyinde, sorgu iki kez bölünür İlk sorgunun sonucu, ilişkili veri kimliğini bulmaktır ve daha sonra, ilişkili verileri elde etmek için id'ye göre ikinci istek başlatılır. Son olarak, elde edilen verileri sahada bir araya getirin.
4) ER parçalanması
İlişkisel bir veritabanında, ilk önce tablolar arasındaki ilişkiyi belirleyebilir ve ilişkiye sahip tabloların kayıtlarını aynı parça üzerinde depolayabilirseniz, çapraz parça birleştirme sorununu daha iyi önleyebilirsiniz. 1: 1 veya 1: n durumunda, genellikle ana tablonun ID birincil anahtarına göre bölümlere ayrılır. Aşağıda gösterildiği gibi:
img
Bu şekilde, Veri Düğümü1'deki sipariş sipariş tablosu ve sipariş ayrıntı sipariş ayrıntı tablosu, sipariş kimliği aracılığıyla sorgu ile kısmen ilişkilendirilebilir ve aynı şey Veri Düğümü2'de de olabilir.
3. Düğümler arası sayfalama, sıralama ve işlev sorunları
Düğümler ve çoklu veritabanları arasında sorgulama yaparken, sayfalamayı sınırlama ve sıralayarak sıralama gibi sorunlar ortaya çıkacaktır. Sayfalamanın belirtilen alana göre sıralanması gerekir.Sıralama alanı bir parça alanı olduğunda, belirtilen parçayı parçalama kuralları ile bulmak daha kolaydır; sıralama alanı bir parça alanı olmadığında daha karmaşık hale gelir.
Verilerin sıralanması ve önce farklı parça düğümlerinde döndürülmesi gerekir, ardından farklı parçalar tarafından döndürülen sonuç kümeleri özetlenir ve yeniden sıralanır ve son olarak kullanıcıya geri döndürülür. resim gösterdiği gibi:
img
Yukarıdaki şekil yalnızca ilk sayfanın verilerini alır ve performans üzerindeki etkisi çok büyük değildir. Bununla birlikte, elde edilen sayfa sayısı büyükse, durum çok daha karmaşık hale gelir, çünkü her bir parça düğümündeki veriler rastgele olabilir.Sıralama doğruluğu için, tüm düğümlerin ilk N veri sayfasının sıralanması ve birleştirilmesi gerekir. Ardından genel sıralamayı gerçekleştirin Bu tür bir işlem CPU ve bellek kaynaklarını tüketir, bu nedenle sayfa sayısı ne kadar büyükse, sistemin performansı o kadar kötü olur.
Hesaplamaları yapmak için Max, Min, Sum ve Count gibi işlevleri kullanırken, önce her parça üzerinde karşılık gelen işlevi yürütmek, ardından her bir parçanın sonuç kümesini toplayıp yeniden hesaplamak ve son olarak sonucu döndürmek gerekir. resim gösterdiği gibi:
img
4. Küresel birincil anahtar kaçınma sorunu
Bir alt veritabanı ve alt tablo ortamında, tablodaki veriler aynı anda farklı veritabanlarında bulunduğundan, genellikle birincil anahtar değeri tarafından kullanılan kendi kendine büyümenin yararı olmayacak ve bölümlenmiş bir veritabanının kendi kendine oluşturduğu kimliğinin küresel olarak benzersiz olduğu garanti edilemez. Bu nedenle, küresel birincil anahtarın, veritabanları arası birincil anahtar çoğaltma sorununu önlemek için ayrı ayrı tasarlanması gerekir. Bazı yaygın birincil anahtar oluşturma stratejileri vardır:
1) UUID
UUID standart formu, 5 parçaya bölünmüş 32 onaltılık rakam, 8-4-4-4-12 biçiminde 36 karakter içerir, örneğin: 550e8400-e29b-41d4-a716-446655440000
UUID birincil anahtardır, yerel olarak oluşturulmuş, yüksek performanslı, ağda zaman kaybettirmeyen en basit çözümdür. Ancak dezavantajları da açıktır.UUID çok uzun olduğu için çok fazla depolama alanı kaplayacaktır, ayrıca birincil anahtar olarak indeksleme sırasında performans sorunları ve indekse dayalı sorgu olacaktır. InnoDB altında, UUID bozukluğu veri konumunda sık değişikliklere neden olacaktır. , Sayfalandırmayla sonuçlanıyor.
2) Veritabanıyla bağlantılı olarak birincil anahtar kimliği tablosunu koruyun
Veritabanında bir sıra tablosu oluşturun:
TABLO "dizisi" ( `id` bigint (20) unsigned NOT NULL auto_increment, `stub` char (1) BOŞ varsayılan DEĞİL '', BİRİNCİL ANAHTAR ("kimlik"), EŞSİZ ANAHTAR "saplama" ("saplama") ) MOTOR = MyISAM;Saplama alanı benzersiz bir dizin olarak ayarlanır Aynı saplama değerinin sıra tablosunda yalnızca bir kaydı vardır ve aynı anda birden çok tablo için genel kimlik üretilebilir. Sıra tablosunun içeriği aşağıdaki gibidir:
+ ------------------- + ------ + | id | saplama | + ------------------- + ------ + | 72157623227190423 | a | + ------------------- + ------ +Daha yüksek performans için InnoDB yerine MyISAM depolama motorunu kullanın. MyISAM, tablo düzeyinde kilitler kullanır ve tabloya okuma ve yazma işlemleri seridir, bu nedenle aynı kimlik değerini eşzamanlı olarak iki kez okuma konusunda endişelenmenize gerek yoktur.
Küresel olarak benzersiz bir 64 bit kimlik gerektiğinde, şunu yürütün:
REPLACE INTO Sekans (saplama) VALUES ('a'); SELECT LAST_INSERT_ID ();Bu iki ifade Bağlantı düzeyindedir, select last_insert_id (), yeni eklenen yeni kimliği almak için replace ile aynı veritabanı bağlantısında olmalıdır.
Eklemek yerine yerine koymanın avantajı, aşırı tablo satırlarından kaçınmak ve düzenli temizlemeye gerek olmamasıdır.
Bu şema nispeten basittir, ancak eksiklikler de açıktır: DB'ye büyük ölçüde bağımlı olan tek bir sorun noktası vardır, DB anormal olduğunda tüm sistem kullanılamaz. Master-slave konfigürasyonu kullanılabilirliği artırabilir, ancak master veritabanı kapatıldığında ve master-slave değiştirildiğinde, özel durumlarda veri tutarlılığını garanti etmek zordur. Ek olarak, performans darboğazı, tek bir MySQL'in okuma ve yazma performansıyla sınırlıdır.
Flickr ekibi tarafından kullanılan birincil anahtar oluşturma stratejisi, yukarıdaki sıra tablosu çözümüne benzer, ancak tek nokta ve performans darboğazı sorunlarını daha iyi çözer.
Bu planın genel fikri şudur: ikiden fazla global ID oluşturma sunucusu kurmak, her sunucu sadece bir veritabanı kullanır ve her veritabanı mevcut global ID'yi kaydetmek için bir sıralama tablosuna sahiptir. Tablodaki kimlik büyümesinin adım uzunluğu, kitaplıkların sayısıdır ve başlangıç değerleri sırayla kademelendirilir, böylece kimlik üretimi her bir veritabanına karma hale getirilebilir. Aşağıda gösterildiği gibi:
img
Kimlikler iki veritabanı sunucusu tarafından üretilir ve farklı auto_increment değerleri ayarlanır. İlk dizinin başlangıç değeri 1'dir ve her adım 2 artırılır ve diğer dizinin başlangıç değeri 2'dir ve her adım 2 artırılır. Sonuç olarak, birinci istasyon tarafından üretilen kimliklerin tümü tek sayılardır (1, 3, 5, 7) ve ikinci istasyon tarafından üretilen kimliklerin tümü çift sayılardır (2, 4, 6, 8).
Bu çözüm, ID üretimi için baskıyı iki makineye eşit olarak dağıtır. Aynı zamanda sistemde hata toleransı sağlar.İlk makinede bir hata varsa ID'yi almak için otomatik olarak ikinci makineye geçebilir. Bununla birlikte, birkaç eksiklik vardır: sistem, yatay genişletme sırasında daha karmaşık olan makineleri ekler; her kimlik elde edildiğinde DB okunmalı ve yazılmalıdır ve DB üzerindeki baskı hala çok yüksektir ve performans yalnızca istifleme makineleri ile iyileştirilebilir.
Çözümü flickr'a göre optimize etmeye devam edebilir, veritabanı yazma baskısını azaltmak için toplu yöntemleri kullanabilir, her seferinde bir dizi kimlik numarası alabilir ve ardından kullanımdan sonra almak için veritabanına gidebilir, bu da veritabanı üzerindeki baskıyı büyük ölçüde azaltabilir. Aşağıda gösterildiği gibi:
img
Kullanılabilirliği sağlamak için yine de iki DB kullanın ve veritabanında yalnızca geçerli maksimum kimlik saklanır. Kimlik oluşturma hizmeti, her seferinde toplu halde 6 Kimliği çeker, ilk olarak max_id'yi 5'e değiştirir. Uygulama, kimlik oluşturma hizmetine eriştiğinde, veritabanına erişmesi gerekmez ve 05'in kimlikleri, sayı bölümü önbelleğinden sıralı olarak dağıtılır. Bu kimlikler gönderildikten sonra, max_id 11 olarak değiştirilir ve 611 kimliği bir dahaki sefere dağıtılabilir. Sonuç olarak, veri tabanı üzerindeki baskı orijinalin 1 / 6'sına düşürülür.
3) Snowflake dağıtılmış kendi kendine artan kimlik algoritması
Twitter'ın kar tanesi algoritması, küresel kimlikler oluşturmak için dağıtılmış sistemlerin ihtiyaçlarını çözer ve 64 bit Uzun tip numaralar üretir. Bileşenler şunlardır:
- İlk kullanılmayan
- Sonraki 41 bit milisaniye zamandır ve 41 bitin uzunluğu 69 yıllık süreyi temsil edebilir
- 5 datacenterId ve 5 workerId. 10 bit uzunluk, 1024'e kadar düğümün dağıtımını destekler
- Son 12 bit, milisaniye içindeki sayıdır, 12 bitlik sayı sıra numarası, milisaniye başına 4096 ID dizisi oluşturmak için her düğümü destekler
img
** Bunun avantajı şudur: ** Milisaniye sayısı yüksektir ve oluşturulan kimlik bir bütün olarak zaman trendine göre artmaktadır; üçüncü taraf sistemlere dayanmaz ve yüksek kararlılık ve verimliliğe sahiptir. Teorik olarak, QPS yaklaşık 409,6 w / s'dir (1000 * 2 ^ 12) ve tüm dağıtılmış sistemde kimlik çakışması meydana gelmez; bitler, kendi hizmetlerine göre esnek bir şekilde tahsis edilebilir.
** Eksiklik şudur: ** Kesinlikle makine saatine güvenin, eğer saat geri çevrilirse, yinelenen kimlik oluşturmaya neden olabilir.
Sonuç olarak
Veritabanı ve kar tanesinin benzersiz kimlik şemasını birleştirerek, sektördeki daha olgun çözümlere başvurabilirsiniz:
https://tech.meituan.com/MT_Leaf.html
Ve yüksek kullanılabilirlik, olağanüstü durum toleransı ve dağıtılmış saatler gibi konuları düşünün.
5. Veri taşıma ve genişletme sorunları
İşletme hızla geliştiğinde ve performans ve depolama darboğazları ile karşı karşıya kaldığında, parçalanma tasarımı dikkate alınacaktır.Şu anda, tarihsel veri geçişi sorununu dikkate almak kaçınılmazdır. Genel uygulama, önce geçmiş verileri okumak ve ardından verileri belirtilen parçalama kurallarına göre her bir parçalama düğümüne yazmaktır.
Ayrıca mevcut veri hacmi ve QPS'ye göre kapasitenin planlanması ve iş geliştirme hızına göre planlanması ve ihtiyaç duyulan yaklaşık parça sayısının hesaplanması gerekir (genellikle tek bir parçadaki tek bir tablonun veri hacminin 1000W'ı geçmemesi önerilir)
Sayısal aralık parçalama kullanırsanız, yalnızca kapasiteyi genişletmek için düğüm eklemeniz gerekir ve parçalanmış verileri taşımanız gerekmez. Sayısal modulo dilimlemeyi kullanırsanız, daha sonraki genişletme problemini düşünmek nispeten zahmetlidir.
3. Segmentasyonu ne zaman düşünmelisiniz
Aşağıda, veri segmentasyonunu ne zaman düşünmeniz gerektiği açıklanmaktadır.
1. Bölmeden bölmemeye çalışın
Tüm tabloların bölümlere ayrılması gerekmez, esas olarak verilerin büyüme hızına bağlıdır. Segmentasyon sonrasında işin karmaşıklığı bir ölçüde artacaktır.Veritabanı tarafından taşınan verilerin depolanması ve sorgulanmasının yanı sıra işletmenin gereksinimlerini daha iyi yerine getirmesine yardımcı olmak da önemli görevlerinden biridir.
"Aşırı tasarım" ve "erken optimizasyon" dan kaçınmak için alt veritabanı ve alt tablonun büyük hilesini kullanmak gerekli değildir. Alt veritabanı alt tablosundan önce, alt bölümler için bölmeyin, önce elinizden geleni yapmaya çalışın, örneğin: donanımı yükseltme, ağı yükseltme, ayırma okuma ve yazma, dizin optimizasyonu vb. Veri miktarı tek bir tablonun darboğazına ulaştığında, alt veritabanı alt tablosunu düşünün.
2. Veri miktarı çok fazla ve normal işletim ve bakım iş erişimini etkiliyor
Burada bahsedilen operasyon ve bakım aşağıdakileri ifade eder:
** 1) Veritabanı yedeklemesi için, tek tablo çok büyükse, yedekleme için çok fazla disk GÇ ve ağ GÇ'si gerekir. ** Örneğin, 1T verisi için, ağ iletimi 50MB kapladığında, iletimi tamamlamak 20.000 saniye sürer.Tüm sürecin riski nispeten yüksektir.
** 2) Büyük bir tablo üzerinde DDL modifikasyonu yaparken MySQL tüm tabloyu kilitleyecektir.Bu süre çok uzun olacaktır.Bu süre zarfında işletme büyük bir etkisi olan bu tabloya erişemez. ** pt-online-schema-change kullanırsanız, kullanım sırasında tetikleyiciler ve gölge tablolar oluşturulur ve bu da uzun zaman alır. Bu işlem sırasında tümü risk süresi olarak sayılır. Toplam miktarı azaltmak için veri tablosunu bölmek bu riskin azaltılmasına yardımcı olur.
** 3) Büyük tablolara sıklıkla erişilir ve güncellenir ve kilit bekleme süreleri daha olasıdır. ** Verileri bölün, zaman için yer kullanın, gizlice erişim baskısını azaltın
3. İşletme geliştikçe bazı alanların dikey olarak bölünmesi gerekir
Örneğin, projenin başında tasarlanan kullanıcı tablosunun aşağıdaki gibi olduğunu varsayalım:
id bigint # Kullanıcı Kimliği isim varchar # Kullanıcının adı last_login_time datetime #Son oturum açma zamanı kişisel_bilgi metni # özel bilgiler ..... # Diğer bilgi alanlarıProjenin ilk aşamasında, bu tasarım basit iş ihtiyaçlarını karşılar ve hızlı yinelemeli geliştirmeyi kolaylaştırır. İş hızla gelişince, kullanıcı sayısı 10w'den 1 milyara çıktı ve kullanıcılar çok aktifti last_login_name alanı her girişte güncellenerek kullanıcı tablosunun sürekli güncellenmesine neden oldu ve bu da büyük baskı yarattı.
Diğer alanlar: id, name, personal_info değiştirilmemiştir veya nadiren güncellenmiştir Bu zamanda, iş açısından bakıldığında last_login_time bölünmeli ve yeni bir user_time tablosu oluşturulmalıdır.
Personal_info özniteliği güncellenir ve daha az sıklıkla sorgulanır ve metin alanı çok fazla yer kaplar. Şu anda, user_ext tablosunu dikey olarak bölmek gerekir.
4. Veri hacminin hızlı büyümesi
İşin hızla gelişmesiyle birlikte tek tablodaki veri miktarı artmaya devam edecektir.Performans darboğaza yakın olduğunda yatay bölümleme ve alt veritabanı alt tablosunu dikkate almak gerekir. Şu anda, uygun bölümleme kuralını seçmeli ve veri kapasitesini önceden tahmin etmelisiniz.
5. Güvenlik ve kullanılabilirlik
Yumurtaları tek sepete koymayın. İşletme düzeyinde dikey bölümleme, ilgisiz işletmelerin veri tabanlarını ayırır, çünkü her işletme farklı miktarlarda veri ve erişime sahiptir ve bir işletme veri tabanını bağladığı için diğer işletmelerde yer alamaz. Yatay bölümlemenin kullanılması, bir veritabanında bir sorun olduğunda, kullanıcıların% 100'ünü etkilemeyecektir.Her veritabanı, iş verilerinin yalnızca bir kısmını taşır, böylece genel kullanılabilirlik geliştirilebilir.
4. Vaka analizi
1. Kullanıcı merkezi iş senaryosu
Kullanıcı merkezi, temel olarak kullanıcı kaydı, oturum açma, sorgulama / değiştirme ve diğer işlevleri sağlayan çok yaygın bir iştir. Temel tablosu:
Kullanıcı (uid, login_name, passwd, sex, age, nickname) uid, kullanıcı kimliği, birincil anahtar login_name, passwd, sex, age, nickname, user attributesİş dışı kalan herhangi bir mimari tasarım sahtekarlıktır.Alt veritabanı ve tablodan önce, iş senaryosu gereksinimlerini sıralamanız gerekir:
** Kullanıcı tarafı: ** Çok sayıda ziyaret içeren ön plan ziyaretleri ve yüksek kullanılabilirlik ve yüksek tutarlılık sağlanması gerekir. İki ana gereksinim türü vardır:
- Kullanıcı girişi: kullanıcı bilgilerini login_name / telefon / e-posta yoluyla sorgulayın, taleplerin% 1'i bu türe aittir
- Kullanıcı bilgileri sorgusu: Oturum açtıktan sonra kullanıcı bilgilerini uid üzerinden sorgulayın, isteklerin% 99'u bu türe aittir
** İşlem tarafı: ** Operasyon ihtiyaçlarını desteklemek için sahne arkası erişimi ve yaşa, cinsiyete, oturum açma saatine ve kayıt zamanına göre sayfalama sorguları gerçekleştirin. Düşük trafik ve düşük kullanılabilirlik ve tutarlılık gereksinimleri olan dahili bir sistemdir.
2. Yatay segmentasyon yöntemi
Veri miktarı büyüdükçe ve büyüdüğünde, veri tabanının yatay olarak bölümlere ayrılması gerekir Yukarıda anlatılan bölümleme yöntemleri "sayısal aralığa dayalı" ve "sayısal değere dayalı" içerir.
* "Sayısal aralığa göre": Birincil anahtar kullanıcı kimliğine bağlı olarak, veriler, kullanıcı kimliği aralığına göre yatay olarak birden fazla veritabanına bölünür. * Örneğin: user-db1, verileri 01000w'lık bir uid aralığı ile depolar ve user-db2, verileri 1000w2000wuid'lik bir uid aralığında depolar.
** Avantajı: ** Kapasite yeterli değilse genişletmek kolaydır, sadece yeni bir db ekleyin.
** Eksiklik şudur: ** İstek miktarı eşit değildir. Genel olarak, yeni kayıtlı kullanıcıların etkinliği daha yüksek olacaktır, bu nedenle yeni kullanıcı-db2, kullanıcı-db1'den daha yüksek bir yüke sahip olacak ve bu da dengesiz sunucu kullanımına neden olacaktır.
* "Sayısal değere dayalı modül": Aynı zamanda birincil anahtar kullanıcı kimliğine de dayanır ve veriler, uid modulo değerine göre yatay olarak çoklu veritabanlarına bölünür. * Örneğin: user-db1, uid modulo 1 verilerini depolar, user-db2, uid modulo 0 verilerini depolar.
** Avantajı: ** Veri hacmi ve istek hacmi eşit olarak dağıtılır
** Eksiklikler şunlardır: ** Genişletme zahmetlidir, kapasite yeterli olmadığında yeni bir db eklenir ve yeniden çalıştırma gerekir. Verilerin sorunsuz taşınmasını göz önünde bulundurmanız gerekir.
3. uid olmayan sorgu yöntemi
Yatay bölümlemeden sonra, kullanıcı kimliğine göre sorgulama talebi iyi karşılanabilir ve doğrudan belirli bir veritabanına yönlendirilebilir. Login_name gibi kullanıcı tanımlı olmayan sorgular için, hangi kütüphaneye erişeceğinizi bilemezsiniz. Şu anda, tüm kütüphaneleri dolaşmanız gerekir ve performans çok düşer.
Kullanıcı tarafı için "uid olmayan öznitelikler ile uid arasındaki eşleştirme ilişkisinin kurulması" çözümü benimsenebilir, işlem tarafında "ön plan ile arka planı ayırma" çözümü benimsenebilir.
3.1. Uid olmayan özniteliklerden uid ile bir eşleme ilişkisi kurun
1) Haritalama ilişkisi
Örneğin: login_name veritabanını doğrudan bulamaz, login_name uid eşleme ilişkisini kurabilir ve saklamak için indeks tablosunu veya önbelleği kullanabilirsiniz. Login_name'ye erişirken, önce eşleme tablosu aracılığıyla login_name'ye karşılık gelen kullanıcı kimliğini sorgulayın ve ardından belirli kitaplığı uid aracılığıyla bulun.
Eşleme tablosunun yalnızca iki sütunu vardır ve çok fazla veri taşıyabilir.Veri miktarı çok büyük olduğunda, eşleme tablosu yatay olarak da bölünebilir. Bu tür bir kv formatı dizin yapısı, sorgu performansını optimize etmek için önbelleği kullanabilir ve eşleme ilişkisi sık sık değişmeyecek ve önbellek isabet oranı yüksek olacaktır.
2) Genetik yöntem
Alt veritabanı geni: Eğer veritabanı uid ile 8 kütüphaneye bölünmüşse ve yönlendirme uid% 8 tarafından yapılıyorsa, bu sefer kullanıcı verisinin hangi kütüphaneye düştüğünü son 3 biti belirler, bu durumda bu 3 bit olabilir Bunu bir alt kütüphane geni olarak görün.
Yukarıdaki eşleme yöntemi, eşleme tablosunun ek depolanmasını gerektirir ve uid olmayan alana göre sorgulama yapıldığında, bir tane daha veritabanı veya önbellek erişimi gerekir. Gereksiz depolamayı ve sorguyu ortadan kaldırmak istiyorsanız, login_name genini uid'in alt veritabanı geni olarak almak için f işlevini kullanabilirsiniz. Uid oluştururken, yukarıda açıklanan dağıtılmış benzersiz kimlik oluşturma şemasına başvurun ve bit değerinin son 3 bitini = f (oturum_adı) ekleyin.
Login_name sorgulanırken, belirli kütüphaneyi bulmak için sadece f (login_name)% 8 değerini hesaplamanız gerekir. Bununla birlikte, kapasiteyi önceden planlamak, önümüzdeki birkaç yıl içinde kaç veri tabanında veri miktarının bölünmesi gerektiğini tahmin etmek ve belirli bir alt veri tabanı genini ayırmak gerekir.
img
3.2, ön plan ve arka planın ayrılması
Kullanıcı tarafı için ana gereksinim tek satırlı sorgudur ve bu alanların sorgu sorununu çözmek için login_name / phone / email ve uid arasındaki eşleme ilişkisinin kurulması gerekir.
İşlem tarafına gelince, toplu sayfalama ve çeşitli koşullara sahip birçok sorgu vardır.Bu tür bir sorgu, büyük miktarda hesaplamaya sahiptir ve büyük miktarda veri döndürür ve veri tabanında yüksek performans tüketir. Şu anda, aynı hizmet grubu veya veritabanı kullanıcı tarafıyla paylaşılırsa, arka planda az sayıda istek, büyük miktarda veritabanı kaynağını işgal edebilir ve bu da kullanıcı tarafının performans düşüşüne veya zaman aşımına erişmesine neden olabilir.
Bu tür bir iş için, "ön uç ve arka uç ayırma" çözümünü benimsemek en iyisidir ve işletim tarafı arka uç işi, ön uç iş sistemi ile bağlantıyı çözmek için bağımsız hizmet ve db'yi çıkarır. İşlem tarafı, kullanılabilirlik ve tutarlılık için düşük gereksinimlere sahip olduğundan, gerçek zamanlı veritabanına erişmek gerekli değildir, ancak erişim için verileri binlog aracılığıyla eşzamansız olarak işlem veritabanına senkronize etmek gerekir. Büyük miktarda veri olması durumunda, arka planda karmaşık sorgu yöntemlerini karşılamak için ES arama motorunu veya Hive'ı da kullanabilirsiniz.
5. Alt veritabanı ve alt tablo ara yazılımını destekleyin
Devlerin omuzlarında durmak çok fazla çabadan tasarruf sağlayabilir. Şu anda, alt kütüphane ve alt tablo için bazı daha olgun açık kaynaklı çözümler var:
- sharding-jdbc (Dangdang): https://github.com/shardingjdbc
- TSharding (Mantar Sokağı): https://github.com/baihui212/tsharding
- Atlas (Qihoo 360): https://github.com/Qihoo360/Atlas
- Cobar (Alibaba): https://github.com/alibaba/cobar
- MyCAT (Cobar'a göre):
- Oceanus (58 aynı şehir): https://github.com/58code/Oceanus
- Vitess (Google): https://github.com/vitessio/vitess
:-D WeChat Kimliği Arama (ID: Taro kaynak kodu ), çeşitli Java kaynak kodu analizi, ilke açıklaması, mülakat soruları ve çalışma kılavuzları edinebilirsiniz.
:-D Ve yanıtla [ kitabın Bundan sonra, yazarın önerdiği mimariye girişten başlayarak 100 adet Java kitabı alabilirsiniz.
Hadi, Sao Nian ~
