TiDB'nin 58 Gruptaki uygulaması ve uygulaması
58 Grup, 58.com, Ganji.com, Anjuke, 58 Finans Şirketi, ChinaHR.com, Driving School Yidian, vb. Dahil olmak üzere çok çeşitli işletmelere sahiptir. Veritabanı türleri arasında MySQL, Redis, MongoDB, ES, TiDB bulunur. Tüm veritabanlarının entegre çalışma ve bakımını entegre ederek "58 Bulut DB Platformunu" kendimiz oluşturduk.
Bu makale TiDB'nin 58 Grubunda uygulanmasına ve işletme ve bakım perspektifinden takip planlarına odaklanacaktır.
1. 58 Grupta TiDB'ye Genel Bakış
Şu anda 50+ TiDB sunucu kullanıyoruz.Sunucular 24 çekirdekli CPU, 128G bellek ve Baocun'dan bir flash bellek kartı ile yapılandırılmıştır. Birden fazla TiDB sürümünü içeren 88 TiKV örneği, toplamda 7 küme, her işletme için bir küme dağıtın. Tek bir kümede birden fazla kitaplık olduğundan, mevcut kitaplık sayısı yaklaşık 21'dir. Diskin mevcut veri hacmi 10T civarında büyük değil. Şu anda 58 işe alım, TEG, Anjuke, kullanıcı büyümesi, bilgi güvenliği, finans şirketleri ve araba ticareti dahil olmak üzere yaklaşık 7 iş kolu bulunmaktadır.Gelecekte daha fazla iş tanıtımı olacaktır.
2. İşletme ihtiyaçları ve çözümleri
Şekil 1 İş ve gereksinimler
Şu anda 4 iş gereksinimi vardır:
- Uzun süre saklanması gereken büyük miktarda veri var
- Şu anda MySQL bağımsız bir depolamadır ve fiziksel makine kapasitesi sınırlıdır, yaklaşık 3T bağımsız kapasite Disk alanı darboğazı nedeniyle, MySQL genişletmesi daha zahmetlidir.
- Yüksek iş kullanılabilirliği sağlayın
- Şu anda MySQL'de yaptığımız şey master-slave replication + MHA'dır.Bu çözümle ilgili bir problem, master veritabanı çalışmadığında master-slave'in değiştirilmesi gerektiğidir, bu da belirli bir süre için yazımı etkileyecek ve bu da iş üzerinde nispeten büyük bir etkiye sahiptir. .
- Daha yüksek okuma ve yazma performansına ihtiyacınız var
- MySQL şu anda tek noktalı yazma kullanıyor, yani ana kitaplığa yazıyor Okumak istiyorsanız, etki alanı adından bağımlı kitaplığa okumalısınız.Okuma gecikmesi nispeten yüksektir ve okuma trafiğindeki artış gecikmeyi daha da artıracaktır. Sorun.
- Alt veritabanı ve alt tablo zahmetli
- Özellikle büyük miktarda veri olması durumunda, alt veritabanı ve alt tabloya ihtiyaç duyulur.Herkes için alt veritabanı ve alt tabloya daha zahmetlidir.Kümeleme daha zor olduğundan, iş tarafı geliştirme çalışanlarının da veritabanı tablosunun ilgili yönlendirme bilgilerini tutması gerekir.
Yukarıdaki noktalar TiDB üzerinde iyi çözülmüştür. Örneğin, TiDB yatay olarak ölçeklenebilir. Hesaplama gücü yeterli değilse, doğrudan düğümleri ekleyin ve TiDB, veri güvenliğini ve yüksek kullanılabilirliği sağlamak için birden fazla kopyaya sahiptir. Ek olarak, TiDB Sunucusunun durumu yoktur ve çok noktalı okuma ve yazmayı destekler. TiDB'nin alt veritabanı ve tabloya ihtiyacı yoktur, işlem nispeten basittir ve verileri düzenli olarak temizlemeye gerek yoktur.
3. TiDB çevre yapısı
TiDB'nin ortam yapısı, yavaş SQL analizi için araçlar geliştirmeyi, izleme sistemini iyileştirmeyi ve TiDB'yi "58 Bulut DB Platformu" na bağlamayı, verileri toplamayı, görsel raporlar oluşturmayı vb. İçerir.
1. Mimari
Şekil 2 TiDB dağıtım mimarisi
58 Group'taki TiDB'nin uygulama yapısı yukarıdaki şekilde gösterildiği gibidir. Esas olarak dört modüle ayrılmıştır: yönetim makinesi, bulut platformu, izleme ve TiDB kümesi:
- Yönetim makinesi
- Ortam dağıtımından, izleme programından, topoloji sorgusundan, SQL analizinden, rapor programından, TiDB küme durum kontrol aracından temelde sorumludur.
- 58 Bulut DB Platformu
- Platformun ana işlevleri arasında meta bilgi bakımı, iş emri işleme, küme bilgilerinin özel gösterimi, izleme genel görünümü ve ilgili işletmelerin TiDB küme durumunu görüntülemek için self servis sorgularının geliştirilmesi ve kullanılması gibi bazı self servis sorgulara erişim bulunur. Ayrıca operasyon raporları ve TiDB cluster uygulaması gibi fonksiyonlar da bulunmaktadır.
- monitör
- Örnek izleme, sunucu izleme ve alarm dahil.
- Belirli TiDB kümesi
- Temel olarak okuma-yazma DNS ve salt okunur DNS olarak bölünmüştür, bunlar sırasıyla okuma-yazma TGW ve salt okunur TGW'ye (TGW, Tencent'in Tencent GateWay'i) bağlıdır ve okuma-yazma hesapları veya salt okunur hesaplar aracılığıyla belirli TiDB kümelerine yönlendirilir.
2. TiDB ekolojik araçlar
Yakın zamanda aşağıdaki işletim ve bakım araçlarını geliştirdik.
(1) Topoloji sorgu aracı: qtidb
Bir kümenin belirli topolojisini görüntülemek için kullanılır.
(2) SQL analiz aracı: tidb_slow_query
TiDB 2.X sürümünün yavaş SQL toplama ve analizi bundan daha karmaşıktır ve pt-query-degist aracı henüz desteklenmemektedir (en son 2.1 ve 3.0 sürümlerinde desteklenmiştir), bu nedenle elle bir SQL analiz aracı yazdık. Doğrudan bir yavaş SQL günlük dosyasını analiz edin ve sonuçları özetleyin (bu sorun TiDB 3.0'da iyi bir şekilde çözüldü, sonuçları doğrudan SLOW_QUERY tablosundan çıkarın ve doğrudan özet gösterimini gerçekleştirin).
Şekil 3 Yavaş SQL analiz aracı
TiDB 2.X sürümü için bu yavaş SQL analiz aracı, esas olarak yavaş günlüklerin toplama aralığını belirlemek, tüm SQL'i biçimlendirmek ve mantıksal hale getirmek, her SQL türünün türünü ve belirli bilgilerini toplamak ve ardından bu mantığı kullanmak içindir. Spesifik SQL SQL belirli bir dosyaya yerleştirilir ve ardından aşağıdaki şekilde gösterildiği gibi özel durumu gösterilir.
Şekil 4 Yavaş SQL analizi sonuçlarına örnekler
Ana bilgiler, örneğin, sıralama durumu, kitaplık adı, hesap numarası, ortalama yürütme süresi, yürütme süreleri, belirli mantıksal SQL vb. İçerir.
(3) Durum kontrol aracı: tidb_check
Kesinti kontrolü gibi belirli bir kümenin durumunu geçici olarak kontrol edeceğiz. Bu, küme meşgul olduğunda yanlış alarmları önlemek için izlemeye benzer bir araçtır. Mevcut izlememiz Prometheus aracılığıyla veri elde etmek olduğundan, ancak Prometheus tek bir noktadır. Prometheus başarısız olursa veya TiDB kümesi özellikle meşgulse, Prometheus'tan gelen veri toplama gecikmesi yüksek olabilir ve ardından herkes TiDB kümesinin çalışmadığına karar verir , Daha sonra TiDB kümesinin gerçek durumunu kontrol etmek için tidb_check kullanacağız.
Şekil 5 TiDB durum kontrol aracı
Ana uygulama yöntemi, meta bilgiye dayalı bir örneğin topolojisinin bir dosyasını oluşturmaktır. Kümenin tüm topolojilerini kontrol ettikten sonra, verileri Prometheus'tan alır ve ardından özetleriz ve son olarak sonuçları alarm hizmeti için Zabbix'e göndeririz (şu anda birleşik izleme için Zabbix kullanıyoruz , Alarm platformu, şu an için resmi olarak önerilen bir Altermanager bulunmamaktadır) ve ardından sergilenmek üzere kitaplığa koyun. Aslında, küme durumunun yanlış bildirilmesi sorunu başka bir açıdan da çözülebilir. Prometheus tek noktalarının veya diğer sorunların yanlış alarmlara neden olmasını önlemek için her bileşenin bir arayüzünden bir küme durumu elde edin. Bu özellik şu anda geliştirme aşamasındadır.
(4) Rapor bilgi toplama aracı: tidb_report
Rapor bilgi toplama aracı ayrıca verileri elde etmek, mevcut veri tabanını ve tablo durumunu elde etmek ve belirli kümeyi kontrol etmek için bir Prometheus arayüzünü kullanır.TiDB 3.0 sürümünde, yavaş SQL durumunu özetlemek için bazı Yavaş Sorgu tablolarını da kontrol eder. .
(5) İzleme otomasyon aracı: tidb_monitor
İzleme için, Prometheus'tan her düğümün izleme verilerini elde etmek için tidb_monitor aracını kullanıyoruz, mantıksal olarak izleme platformumuz olan Zabbix'e gönderiyoruz ve ardından trend grafiği ekranı ve alarm için Zabbix'i kullanıyoruz.
3. Platformlaştırma
Şekil 6 İşletim ve bakım yönetimi platformu mimarisi
Platformlaştırma açısından, TiDB'yi "58 Bulut DB Platformu" na bağladık ve DDL / DML iş emirlerini işlemek için açık kaynak başlangıcı kullandık. Platform, bir yönetim terminali ve bir kullanıcı terminaline bölünmüştür.Yönetim terminali, DBA tarafından meta bilgi bakımı, iş emri işleme, operasyon raporları, izleme genel bakış vb. İçin kullanılır. Kullanıcı tarafında, işletme TiDB kümeleri, DDL / DML iş emirleri, hesap yönetimi için başvuracak, küme bilgilerini ve izleme koşullarını görüntüleyecek ve ayrıca veritabanındaki verileri kendileri de sorgulayabilecekler.
Şekil 7 İşletim ve bakım yönetimi platformu ekranı (1/2)
Şekil 8 İşletim ve bakım yönetimi platformu ekranı (2/2)
TiDB operasyon ve bakım yönetimi, temel olarak küme bilgilerini görüntüleme, küme izleme görüntüleme veya TiDB / TiKV / PD düğümleri ekleme ile ilgilidir. Ek olarak, örnekleri toplu olarak ekleyebilir, makineyi seçebilir, rolü eşleştirebilir ve ardından geliştirmeden sorumlu kişiyi belirleyebilir ve bunları doğrudan ekleyebilirsiniz.
4. Görsel Rapor
Şekil 9 Görsel rapor sınıflandırması
Görsel raporun işi, platformdaki sunucunun Prometheus veya Zabbix izleme verilerini özetlemek ve bunları geliştiricilere ve DBA'lara görüntülemek için sağlamaktır.Ana boyutlar arasında sunucu yükü, CPU belleği, disk, ağ, IO vb. Yer alır. Kümede, kümenin mevcut kullanımı ve toplam kapasitesi Prometheus arayüzü ile elde edilir, kütüphane ve tablonun veri büyümesi toplanarak düzenli olarak gözlemlenir.
Dördüncü olarak, iş ve TiDB kullanımı
Şekil 10 Şu anda TiDB kullanan işletmeler
Şu anda, Grubun TiDB kullanan 58 şirketi arasında ağırlıklı olarak TEG işi, Anjuke (günlükler), kullanıcı büyütme işi (58 danışmanlık, adres defteri veri depolama), bilgi güvenliği (kimlik doğrulama merkezi), finans şirketleri (depolamanın altında yatan finansal gerçek zamanlı veri ambarı bulunmaktadır. ), otomobil ticareti (ikinci el otomobil faturalarının dağıtımı) vb. en çok kullanılan TEG işi.
TEG'in işi ağırlıklı olarak WList, WTable yönetim geçmişi, arama indeksi vb. İçerir. Bunlar kendi geliştirdiğimiz veritabanımızın yönetim uçlarıdır. Şu anda yazma miktarı nispeten büyük, veri hacmi yaklaşık 6T ve veri artışı yaklaşık 500G / ay. Son altı ayda TEG işi Sekiz flash bellek kartı hasar gördü, ancak hiçbiri işi etkilemedi.TiDB'nin yüksek kullanılabilirliğinin avantajlarını tam olarak hissettik.
Şekil 11 Toplam TiDB veri tabanı sayısının büyüme eğilimi
Şu anda, 58 Grup içindeki toplam TiDB uygulamalarının sayısı hızla artıyor. 2018'in ortasından itibaren TiDB, mevcut TiKV bulut sunucusu sayısına bağlandı ve TiKV bulut sunucusu sayısı özellikle bu yılın ikinci çeyreğinden bu yana yaklaşık 22'ye ulaştı. Büyümek için çaba gösterin.
5. Takip planı
Gelecekte, hizmet yönetimi platformu ve PMC sipariş akışı dahil olmak üzere 18 MySQL kümesinin tamamını TiDB'ye taşımayı planlıyoruz.Toplam disk hacmi 30T ve veri hacmi 200 milyar. En önemlilerinden biri PMC sipariş akışı veritabanıdır.Hepsi alt veritabanı olan 8 MySQL kümesine sahiptir.Her kümenin disk hacmi 2T'dir.TiDB'yi taşıma süreci çok zorlayıcı olmalıdır.
Şekil 12 Gelecekte TiDB kullanmayı planlayan işletmeler
İşletim ve bakım açısından, sürüm yükseltmeleri için hazırlıklara çoktan başladık ve hepimiz TiDB 3.0'a geçebiliriz. Şu anda bir seti yükselttik ve hala çok kararlı. İzlemenin iyileştirilmesine gelince, daha sonra, izleme araçları, tek nokta sorunlarının yanlış alarmlara neden olmasını önlemek için çoklu bileşen arayüzleri aracılığıyla veri elde edecektir. Raporlama işlevleri açısından, örneğin 3.0 sürümü altında yavaş SQL sorgularının optimizasyonu dahil olmak üzere, geliştirmeye ve iyileştirmeye de devam ediyoruz. Ek olarak, bir veri ambarı işi olduğu için, sistem performansını iyileştirmek için TiSpark ve TiFlash kullanmayı da düşünüyoruz. Son olarak, otomatik dağıtım, kapasite genişletme ve hata işleme için de geliştirme yapıyoruz.
