Alt veritabanı ve alt tablo nasıl doğru bir şekilde alınır?
Yazar | Cai Cai
Baş Editör | Guo Rui
Rahibe YY: Kardeş Cai, lider benden yeni bir sistem geliştirmemi istedi.
Caicai: Yani liderlik hala sana güveniyor.
Rahibe YY: Gerekli, bu yeni sistemi tasarlamak için veri tabanı tasarımı üzerine epey düşündüm.
Caicai: Bir sistem yapmak için bir veritabanıyla başlamamız gerektiğini düşünmüyorum.Bir iş modeli tasarlamakla başlamalıyız.Önce bundan bahsetmeyelim, veritabanı tasarımınızın avantajlarından bahsedelim.
Sister YY: Yüksek performans için, önce geleceğin temelini atmak için bir alt veritabanı ve alt tablo stratejisi tasarladım.
Caicai: Gelecekte veri hacminiz büyük olacak mı? Alt veritabanı ve alt tablo aslında pek çok sorunu barındırıyor, anladınız mı?
Rahibe YY: Veritabanını ve tabloyu bölmenin kolay olduğunu düşünüyorum.
Caicai: Gerçekten mi?
Puanlara ihtiyacınız var mı?
Veritabanı alt veritabanı alt tablosundan bahsetmişken, neden alt veritabanı alt tablosuna ihtiyacımız olduğunu anlamalıyız. Artık pek çok kişi, alt veri tabanı ve alt tabloların veri miktarıyla nasıl başa çıktığını savunuyor, ancak birçok insanın işi için alt veri tabanı ve alt tablo stratejisinin sihirli bir değnek değil, endişeli bir çukur olabileceğini bilmiyorlar.
Alt veritabanı ve alt tablo, belirli bir aşamaya kadar iş geliştirme ve belirli bir seviyeye kadar veri biriktirmeden elde edilen bir çözümdür. DB'nin veri seviyesi bir aşamaya ulaştığında, bir indeks olsa bile yazma ve okuma hızı darboğaz olacak, indeks çok büyük olacak ve veritabanının fiziksel dosyası yedekleme ve geri yükleme işlemlerini zorlaştıracaktır. . Şu anda, DB'nin darboğazı işletmeye ciddi şekilde zarar verdiğinden, en etkili çözüm DB'nin alt veritabanı ve alt tablosudur.
Bazı liderler ve hatta mimarlar, işin ilk aşamalarında kendi öznel isteklerine göre alt veri tabanları ve tablolar oluşturacaklar, bu da gelecekte işin hızlı gelişiminin yolunu açacaktır. Ama burada birkaç noktayı ifade etmek istiyorum:
-
Mevcut iş şirketin ana işi değilse ve iş hayatta kalıp kalamayacağını bilmiyorsa, birincil tasarım o kadar karmaşık olmamalıdır. Her işletme için sistem mimarisini Taobao ölçeğinde tasarlarsak, bu sadece gelecekte işletmeyi öldürmekle kalmaz, aynı zamanda programcıları da geride bırakır.
-
Tek bir veritabanının yeteneği hayal edildiği kadar kırılgan değildir. Tek bir MySQL tablosundaki veri miktarı çoğu senaryoda milyon düzeyinde olsa bile (elbette bu depolanan belirli veri formatıyla ilgilidir), SQLServer daha da önemlidir.Şirketimiz tarafından kullanılan SQLServer, on milyonlarca tek bir tablo ile çok fazla veriye sahiptir. Oracle'dan bahsetmeye gerek yok, birkaç yüz milyon seviyeli olanlar var.
-
İş döngüsü nispeten kısaysa veya insan gücü ve malzeme kaynakları yetersizse, alt veri tabanını ve alt tabloları erken aşamada körü körüne tasarlamak kendinize bir performans geri D seti verecektir.
-
Sistemin ilk tasarımı doğrudan şirketin temel verileri ile ilgilidir. gibi WeChat Böyle bir veri ölçeğiyle, küçük bir sistem on milyonlarca hatta yüz milyonlarca veri seviyesine sahip olabilir, ancak bu seviyeye kaç startup sahip olabilir?
İyi bir sistem tasarımcısı, tasarımın başlangıcında tüm yönlerin kapsamlı faktörlerini tam olarak dikkate alacaktır.
Alt kütüphane
İş bölümüne göre
Alt kütüphanelerden bahsetmişken bir şey daha söylemek istiyorum: Onu işinize göre bölmenizi tavsiye ederim.Bir sistemin kalitesi ve iş sınırlarının bölünmesi belirleyici bir rol oynar. İş, kurallara göre sınırlara bölünmüştür ve her işletmeye karşılık gelen veri tabanı doğal olarak doğmuştur.İş için veri tabanı düzeyinde alt veri tabanına girmeyin. Bazı Liderler şöyle davranacaktır: belirli bir tablodaki veri miktarı çok büyüktür ve ayrı bir veritabanına tahsis edilmiştir Sonuç olarak birçok SQL ifadesinin veritabanları arasında birleştirilmesi gerekir.
Belirli bir iş nasıl bölünür? Her şirketin iş formu farklıdır ve bölünmenin boyutları farklı olacaktır. Basit bir örnek verelim: Tipik bir e-ticaret sistemi, işletmeye göre emtialara ve siparişlere ayrılabilir.Bu aynı zamanda birçok şirketin tipik bir iş bölümüdür, ancak şirketimiz onu kendi iş kurallarına göre mallara, siparişlere ve ödemelere ayırır. Şirketimizde ödeme sistemi bağımsız bir iş olduğu için sadece siparişlerin ödenmesini değil, diğer birçok ödeme senaryosunu da içermektedir. İş bölümüne göre, DB düzeyinde emtia DB, sipariş DB ve ödeme DB vardır.
Aynı işletmenin yatay bölünmesi
İşletmeye göre dikey segmentasyon stratejisine ek olarak, yaygın olarak kullanılan başka bir veritabanı segmentasyon şeması vardır. Belirli bir iş verisi hacmi nispeten büyükse, iş veritabanı belirli kurallara göre yatay olarak bölünebilir. Örneğin, kullanıcı bilgileri işinde, kullanıcı sayısı belirli bir seviyeye ulaştığında, bazı şirketler kullanıcı bilgilerini birden çok veritabanına böler - bunun birden çok tabloya bölmekten farkı nedir?
Kullanıcı bilgileri aynı veritabanında birden çok tabloya çapraz kesilmişse, bu tablolar fiziksel bir diskte bulunuyorsa, bu iş için maksimum yazma ve okuma GÇ değerini artırmak yararlı olmayacaktır, ancak birden çok sunucuya dağıtılmışsa , Bu, işletmenin genel maksimum IO'sunun bir dereceye kadar iyileştirildiği anlamına gelir, masanın yıkılmasından daha iyidir. Tabii ki, tablo bölümleri kullanılıyorsa, her bölüm farklı fiziksel disklere dağılır ve bu, veritabanı bölümleme yönteminden mutlaka daha kötü değildir.
Belirli bir işletmenin DB'sini kurallara göre yatay olarak böldükten sonra elbette yeni sorunlar ortaya çıkacaktır. Çoğu durumda, bölümleme kuralı kalanı hashing için en çok kullanılan yöntemdir.Vaktimiz olduğunda bunu tartışacağız.
Alt kütüphane karmaşıklığı getirir
Yukarıda bahsettiğim gibi alt kütüphane ve alt tablo sihirli bir değnek değildir, herhangi bir çözüm bir sorunu çözebilir, ancak başka sorunları da beraberinde getirebilir. Dünya adil, bilgisayar dünyası da öyle.Alt kütüphane hangi sorunları ortaya çıkaracak?
-
Alt veritabanını gerçekleştirdikten sonra, başlangıçta mantıksal olarak ilişkili verileri farklı tablolara ve farklı kitaplıklara bölmekten kaçınmak zordur.Şu anda, tablo ilişkilendirme işlemi kısıtlanacaktır.Çoğu durumda, farklı alt bölümlere katılamayız. Veritabanı tabloları (çünkü çoğu şirket, veritabanları arası SQL'i açıkça yasaklamaktadır) Sonuç olarak, tek bir sorgu ile tamamlanabilen bir işin tamamlanması için birden çok sorgu gerekebilir.
-
Tek bir DB ortamında, DB işlemlerinin bazı işlemlerin atomik işlemlerini sağlamak için kullanılabileceği, ancak birden fazla veri tabanına dağıtıldığında bu işlemlerin tek tip olarak yönetilmesinin zor olduğu ortaya çıktı. Bazı büyük üreticiler aynı zamanda veritabanları arası işlem çözümleri sunsa da, performans gerçekten tatmin edici değildir, bu nedenle çoğu durumda pratik değildir. Örneğin yukarıda belirtilen emtia stok ödemesi Tek bir uygulama olması durumunda üç işletme aynı veri tabanındadır.Ödeme işi gerçekleştiğinde, emtia envanterinin değiştirilmesi ve sipariş durumunun güncellenmesi gibi iki işlem veri tabanının sağladığı şeyler kullanılarak tamamlanabilir. Ve performans kabul edilebilir aralıkta ... Bu üç işletme farklı veri tabanlarında dağıtılırsa, işlemlerden sadece birinin gerçekleştirilme şansı vardır, aslında bu da dağıtılmış şeylerle çözülmesi gereken bir sorundur. Çoğu durumda, dağıtılmış şeyler kaçınılmazdır.Ayrıca, kapsamlı iş durumuna göre dağıtılmış şeyleri uygun şekilde benimsemek için etkili bir çözümdür.En kötü durumda, manuel müdahale gerekebilir.
-
Alt veritabanı, DBA için iş yükünün katlanarak arttığı anlamına gelir. Başlangıçta yalnızca bir DB'nin yönetilmesi gerekir, ancak şimdi N DB'lerin yönetilmesi gerekir ve her DB'nin yedeklenmesi, izlenmesi ve hatta yüksek kullanılabilirlik, genişletme ve diğer görevler gerekir. Sadece bir DBA yöneticisine ihtiyaç duyulabileceği ve veri tabanı bölündükten sonra iki hatta üçüne ihtiyaç duyulabileceği ortaya çıktı, bu da şirketin insan gücü yatırımında bir artışa neden oluyor.
Rahibe YY: Kardeş Cai Cai, bana alt masadan biraz daha bahsedebilir misin?
Caicai: Aslında alt tablodaki alt kütüphaneye benzer birçok durum var.
Rahibe YY: Başka bir durum var mı?
Caicai: Evet, veritabanları ve tablolar aslında farklı seviyelerdeki şeylerdir, bu nedenle farklılıklar olmalıdır.
Rahibe YY: O zaman bana bir şey söyleyebilirsin.
Cai Cai: Bir fincan kahveye ne dersiniz?
Neden bölünsün?
Resmi olarak başlamadan önce, veri tablonuzun bölünmesi gerekip gerekmediğinin, iş verileri miktarının bölünmesi gereken büyüklük sırasına ulaşıp ulaşmadığı gibi birçok faktörün kapsamlı bir şekilde değerlendirilmesini gerektirdiğini vurgulamak istiyorum. Mevcut sorunu çözmek için başka bir çözüm var mı?
Bunu bir kereden fazla gördüm Bazı Liderler saati genel durumu dikkate almadan körü körüne böldüler.Sonuçta herkes arka arkaya 996 hafta fazla mesai yapıyor Liderin saçınızı kaybedeceğini düşünmüyor musunuz? Bazı mimarlar küçük bir işletmenin başlangıcında masayı böldüler.Sizinle işbirliği yapmak için, aynı zamanda yetişmek için aralıksız fazla mesai yapıyorlar. Çevrimiçi olduktan sonra, işletme verilerinin miktarının çok küçük olduğunu, ancak kodun tablo bölme stratejisi tarafından çok fazla kısıtlandığını görüyorlar. . Tabloların sökülmesinden kaynaklanan sorunlar, bazı senaryolarda bazen gerçekten maliyetlidir.
Veritabanı tablolarının bölünmesiyle çözülen problemler başlıca depolama ve performans problemleridir.Tek bir tablonun veri hacmi belirli bir seviyeye ulaştıktan sonra MySQL'in performansı keskin bir şekilde düşecektir.SQL Server ve Oracle gibi şarjlı DB'lerle karşılaştırıldığında MySQL hala Bir dezavantaj olarak, tablo bölme stratejisi neredeyse tüm ilişkisel veritabanlarına uygulanabilir.
Veritabanındaki tabloları bölmek için fazla kör olmayın.
Alt tablo stratejisi
Tablonun bölünmesi ve veritabanının bölünmesi benzerdir, ancak bölmenin kuralları da farklıdır. Aşağıdaki bölme kuralı bir tabloyu bölmek içindir.
Yatay segmentasyon
Yatay bölümleme, birçok işletmede en yaygın kullanılan bölümleme yöntemidir. Esas olan, bir tablodaki veri satırlarını, en yaygın kimlik aralığı ve iş birincil anahtarının karma değeri gibi kurallara göre birden çok tabloya dağıtmaktır. Bölünecek tablo verilerinin büyüklük sırasına gelince, bu tabloda depolanan veri formatı ile ilgilidir.Örneğin, sadece birkaç sütun int alan içeren bir tablo, metin tipi tabloların birkaç sütunluk saklama sınırından daha yüksek olmalıdır. 10 milyon. Ancak bir sistemin sorumlusu veya mimarı olarak, tablonun veri seviyesi on milyonlara ulaştığında dikkat edilmelidir, çünkü bu, sistem performansı darboğazının gizli bir tehlikesidir.
Veri tablosunun yatay bölümlemesine kıyasla, tabloyu iş için optimize edilmiş bir senaryoda bölümlendirmeyi ve farklı fiziksel disklere kurallara göre farklı bölümler atamayı tercih ediyorum.Bu şekilde, işletmedeki SQL ifadeleri neredeyse hiç değiştirilemez. Şirketimizin bir SQL Server veritabanı, belirli bir iş tablosu bölümlendirildikten sonra birkaç milyarlık bir veri hacmine ulaştı, ancak sorgu ve eklemek Hız, işletmenin ihtiyaçlarını hala karşılayabilir (bir sistemi optimize etmek veya işletme seviyesini optimize etmek).
Dikey bölme
Dikey bölmeden bahsetmişken tablolar da işletmeye göre bölünebilir.Örneğin, bir veri tabanında işletmeye göre temel bilgiler ve genişletilmiş bilgiler olarak bölünebilen kullanıcı bilgileri bulunur.İşletmeye yararlı ise tamamen temel bilgi tablolarına bölünerek genişletilebilir Bilgilendirme sayfası. Tabii ki, sıkça erişilen bilgileri bir tabloya ve diğer nadir bilgileri tek bir tabloya bölmek gibi diğer kurallara göre de bölünebilir Spesifik bölme kuralları hala o anda çözülecek soruna bağlıdır. Dikey bölme biraz karmaşıklık getirebilir. Örneğin, bir kullanıcının temel bilgilerinin orijinal sorgusu ve genişletilmiş bilgiler, sonuçları bir seferde sorgulayabilir. Tablo bölündükten sonra, sonuçları sorgulamak için bir Birleştirme işlemi veya iki sorgu gerekir.
Alt tablo maliyeti
-
Veri tablosu dikey olarak bölündükten sonra, orijinal sorgu tablolarla bir birleştirme sorgusu haline gelebilir ve bu da bir dereceye kadar performans kaybına neden olur.
-
Veri tablosu yatay bölümleme belirli kurallar gerektirir.Genel olarak kullanılan iki ana kural vardır: aralık bölümleme ve karma değer bölümleme. Aralık segmentasyonu, belirli bir alanın aralığına göre segmentasyonu ifade eder.Örneğin, kullanıcı tablosu kullanıcı kimliğine göre segmentlere ayrılır. 1'den 100.000'e kadar olan ID'ler Kullanıcı1'de ve 1001'den 20 milyona kadar olanlar Kullanıcı2'de bulunur. Bu segmentasyonun avantajları Veri geçişi sorunu dikkate alınmadan kapasite süresiz olarak genişletilebilir.Dezavantaj, yeni tablonun ve eski tablonun veri dağılımının tek tip olmaması ve alt tablo aralığının seçiminin zor olmasıdır.Çok küçük bir aralık çok fazla tabloya yol açacak ve çok büyük bir boyut temel soruna yol açacaktır Çözülmemiş kafa karışıklığı. Başka bir tablo bölme stratejisi, bir sütunu hash değerine göre farklı tablolara yönlendirmektir.Ayrıca örnek olarak kullanıcı kimliğini de alın.Başta 10 veritabanı tablosu planlayacak olursak, yönlendirme algoritması user_id% 10'u kullanabilir Değeri, verinin ait olduğu veritabanı tablo numarasını temsil eder 985 kimliğine sahip kullanıcı, 5 numaralı alt tabloya yerleştirilir ve 10086 numaralı kullanıcı, 6 numaralı kelime tablosuna yerleştirilir. Bu bölümleme kuralının avantajı, her tablonun veri dağılımının nispeten tekdüze olmasıdır, ancak daha sonraki genişletme verilerin bir kısmını taşımak için tasarlanacaktır.
-
Tablo bölündükten sonra, işleme göre bir sipariş varsa, veritabanı güçsüz hale gelir ve yalnızca iş kodu veya veritabanı ara yazılımı ile yapılabilir.
-
Bir arama işi gereksinimi olduğunda, SQL deyimi yalnızca tabloları sorgulamak için birden çok tabloyu birleştirebilir ve benzer şekilde, sayım istatistiksel işlemleri gibi istatistiksel gereksinimler de vardır.
Yazar: Cai Cai, İnternet yüksek yolunun yönetilmesinde lider bir mühendis, İnternet teknolojisine meraklı. Şu anda bir İnternet eğitim şirketinde çalışıyor, uygulama sunucusundan sorumlu asıl kişi. 10 yıllık İnternet geliştirme tecrübesiyle, yüksek performans, yüksek eşzamanlılık ve dağıtılmış teknoloji alanındaki araştırmalara meraklıdır.Ana çalışma dilleri C # ve Golang'dır.
Feragatname: Bu makale yazar tarafından sunulmuştur ve telif hakkı kendisine aittir.
SON
