Ali'nin yeni nesil veritabanı teknolojisi: Veritabanını bir kaba koymak artık bir efsane değil
Alibaba Group veritabanı teknolojisi ekibi başkanı Zhang Rui, Alibaba araştırmacısı, Oracle ACE. Double Eleven veritabanının baş teknik sorumlusu iki kez baş teknik garanti şefi olarak görev yaptı. 2005 yılında Alibaba'ya katıldığından beri, Alibaba'nın veritabanı teknolojisinin sürekli inovasyonuna liderlik ediyor.
Geçtiğimiz günlerde Pekin'de düzenlenen 2017 Çin Veritabanı Teknolojisi Konferansı'nda Alibaba Group'tan bir araştırmacı olan Zhang Rui, "Geleceğe Yönelik Veritabanı Mimarisi Üzerine Düşünceler" başlıklı bir açılış konuşması yaptı. Ali veri tabanı teknik ekibinin Ali'nin yeni nesil veri tabanı teknolojisi sistemini kurmadaki fikirlerini ve deneyimlerini, Ali'nin başarılarını, çukurlarını ve geleceğe yönelik düşüncesini katılımcılara tanıtmayı ve Çin'in veri tabanı teknolojisinin gelişimine katkıda bulunmayı umarak esas olarak tanıtır. .
Konuşmanın tam metni:
Önce kendimi tanıtmama izin verin. Alibaba'ya 2005 yılında katıldım ve veritabanları üzerinde çalışıyorum. Bugünün konusu, Alibaba'nın yeni nesil veritabanı sistemi hakkındaki son düşüncelerim. Burada sizlerle paylaşacağım ve bir sıçrama yapacağım. Bugün paylaştığım gerçek sahnelerle birlikte biraz deneyim ve fikir edinebilirseniz, bugün paylaşmamın amacına ulaşmış olursunuz.
Bugün şu hususlardan bahsedeceğim: İlk olarak, çekirdekteki bazı yeniliklerimizden, esnek veri tabanı planlamasının nasıl sağlanacağından, zeka üzerine düşündüğümüzden ve son olarak, üzerine basılan çukurlardan ve geleceğin yönünden bahsedelim.
Ali senaryolarında veritabanlarının karşılaştığı sorunlar
Öncelikle Alibaba tarafından kullanılan ilk nesil veritabanı teknolojisi Oracle'dır. Daha sonra herkes bilir ki bir şey IOE'ye gitmek olur. IOE'ye geçme sürecinde açık kaynak veritabanlarını kullanma çağına girdik. Bu dönem bugün geçti ve bu süreç muhtemelen devam edecek. Beş veya altı yıl sonra, tüm Alibaba'nın iyi bilinen bir açık kaynak MYSQL şubesi var: AliSQL. Üzerinde birçok iyileştirme yaptık, bu nedenle AliSQL'de bazı iyileştirmeler listeledim, ancak bugün aslında bunu yapmak istemiyorum Bundan bahsetmişken, geleceğe yönelik yeni nesil veritabanı teknolojisi ve veritabanı mimarisinden bahsetmek istiyorum.
Bence durum bu, çünkü bugünün Alibaba bir teknoloji şirketi, o kadar çok kez Google'a veya bazı büyük internet şirketlerine bakacağız Teknolojik yenilikleri nereden geliyor? Problemden. Yani bugün buradaki herkes benimle aynı Sahnede karşılaştığınız problem nedir ve problemin derinliğini nasıl gördüğünüz bugün yarattığınız yeniliğin ne kadar büyük olduğunu belirler.
Öyleyse bugün, Ali'nin karşı karşıya olduğu sorunlara bir göz atalım. Buradaki herkesin aynı fikre sahip olması gerektiğine inanıyorum. Ali'nin karşılaştığı sorunlar ille de sizin sorunlarınız değil, ama Ali'nin bugün karşılaştığı sorunlar ve gördüklerimiz hakkında konuşmak istiyorum. Bu problemlerden sonra size referans getirmeyi sabırsızlıkla bekliyorum, umarım hangi problemlerle karşılaştığınızı ve nasıl düşüneceğinizi de görebilirsiniz.
Alibaba'nın uygulamaları ile Facebook ve Google'ın uygulamaları arasında aslında büyük bir fark olduğu görülebiliyor. Onlarla da konuştuk ve iş senaryolarının gerçekten farklı olduğunu gördük. Her şeyden önce ana uygulamalarımız işlemsel. Uygulamanın gereksinimleri nelerdir Bu noktaları göreceksiniz (resme bakın) Aşağıdakiler esas olarak düşüncemiz hakkında konuşmaktadır.
Günümüzün yüksek kullanılabilirliği ve güçlü veri tutarlılığı çok önemlidir. Veri tutarsızlığından kaynaklanan sorunlar çok çok büyüktür. Herkes ayrıca Taobao kullanır ve bazı Alibaba hizmetlerinin de kullanıcısıdır. Tutarsız verilerin neden olduğu sorunlar, hatta her kullanıcı Ailem bunlara dikkat ediyor.
İkincisi, depolama maliyetleri bugün çok yüksek.Bütün veri merkezleri zaten SSD kullanıyor, ancak veri depolama maliyeti hala büyük bir işletmenin karşılaştığı çok büyük bir sorundur.Bu gerçek bir para sorunudur.
Ek olarak, daha önce de belirtildiği gibi, verilerin bir yaşam döngüsü vardır, bu nedenle verilerin, özellikle işlem verilerinin çok bariz bir soğuk ve sıcak durumu vardır. Bir yıl önce Taobao'daki satın alma kayıtlarınıza nadiren bakmanız gerekir, ancak mevcut satın alımlar Kayıt okunacaktır, bu nedenle sistemin onu okuması ve sık sık güncellemesi gerekir.
Diğer bir özellik ise, bugünün Ali'nin işinin nispeten basit olmasıdır, örneğin OLTP performansında en üst seviyeye ulaşmamız gerekiyor. Alibaba'ya özgü bir diğer nokta ise Double Eleven'dır: Double Eleven esasen teknik olarak çok sıcak nokta efekti yaratmaktır. Bu bize ne tür bir talep getiriyor? Talep son derece esnek bir kabiliyettir.Aslında veritabanları bu yönde çok eksiktir.Veritabanlarının esnek ölçeklendirilmesini sağlamak çok zordur.
Son olarak DBA'lardan bahsetmek istiyorum.Buradaki birçoğunuz DBA olabilirsiniz.Ali'nin zeka yönündeki düşüncelerinin neye benzediğinden bahsetmek istiyorum. Çok miktarda verimiz var ve ayrıca birçok deneyimli DBA'mız var. , Peki bu DBA'lar bir sonraki dönüşümü nasıl tamamlıyor ve işte nasıl bir darboğaz haline gelmiyor? Veritabanının kendi kendine teşhis ve kendi kendine optimizasyonu nasıl sağlanır Gördüğümüz sorun bu ve sonunda bu yöndeki düşüncelerimi paylaşacağım.
Ali veritabanı çekirdeğinin yönünü düşünüyor
Öncelikle veritabanı çekirdeği hakkındaki düşüncelerimizden bahsedeyim. Her şeyden önce, yerli veritabanı üreticilerine saygı duyuyorum.Kerneli geliştiren herkes bilir ki her fonksiyon için bir satır kod yazmanın kolay olmadığını bilir.Bu teknik kişiler de dahil olmak üzere yerel veritabanı satıcılarına fikrimi ifade etmek istiyorum. Saygı. Bugün konuşmak istediğim konu ilk yurt içi konferanstay, önce AliSQL X-Cluster'dan bahsedeceğim. X-Cluster, AliSQL üzerine inşa edilmiş üç düğümlü bir kümedir. Bu, MySQL'in bir küme haline gelmesini ve bu kümenin güçlü veri tutarlılığına sahip olmasını, uzaktan dağıtıma yönelik olmasını ve yüksek ağ gecikmesini tolere edebilmesini sağlamak için Paxos tutarlılık protokolünün tanıtımıdır. Ve bir dizi özellik.
Bugün pek çok veritabanı, Google'ın Spanser veritabanı gibi herkesin bildiği gibi Paxos ile bağlantılıdır. Ancak daha önce, veritabanı ile Paxos arasındaki ilişkiyi herkes düşünmemişti. Aslında daha önce gerçekten bir ilişki yoktu, ancak bugünün veritabanları birkaçında Paxos protokolünün yerlerde kullanılması gerekiyor. Öncelikle, özellikle yüksek kullanılabilirlik senaryosunda, Paxos'u seçmek için kullanmalıyız, Paxos kullanımını gerektiren bir düğümü benzersiz bir şekilde ana düğüm olarak seçmemiz gerekir; ikincisi Paxos protokolünü kullanmaktır. Veritabanındaki verilerin paylaşılan depolama olmadan güçlü tutarlılığını sağlamak, yani verilerin birden çok düğüm arasında güçlü bir şekilde tutarlı olmasını sağlamak ve yüksek kullanılabilirliği sağlamak.
Bu nedenle Paxos, veritabanı mimarisi tasarımında yaygın olarak kullanılmaktadır.Günümüzde, Goolge Spanser dahil, dışarıdaki birçok katılımcı, bunu birlikte yapmak için Paxos protokolünü ve veritabanını da kullanıyor. Bu nedenle, AliSQL'in üç düğümlü kümesi aynıdır ve güçlü veri tutarlılığına sahip bir küme haline gelmek için Paxos protokolünü kullanır. Aşağıda Paxos protokolünün veritabanındaki rolünü kabaca açıklayacağım.
Esasen, Paxos artık ortak bir teknolojidir. Herkes veri tabanlarıyla meşgul. Basitçe ifade etmek gerekirse, veritabanımızda Paxos protokolü kullanılıyor, yani bir işlem grubu bir düğüme gönderildikten ve indirildikten sonra, aynı anda birden fazla düğüme indirilmesi gerekir. Yani, orijinal yazının sadece bir düğüme yazılması gerekiyor, ancak şimdi ağ üzerindeki başka bir düğüme yazılması gerekiyor.Bu düğüm farklı bir yerde olabilir veya dünyadaki başka bir şehir olabilir ve çok uzun bir ağdan geçmesi gerekiyor. Yan, şu anda bazı temel teknolojilere ihtiyaç var.
Amacımız ne? Her şeyden önce, fiziksel gecikmeye direnmenin bir yolu yoktur. Geçmişte, veritabanı üzerindeki işlemlerin yalnızca yerel olarak gönderilmesi gerekiyordu, ancak şimdi veritabanı küresel olarak, uzaktan veya hatta ağ üzerinde konuşlandırılıyor. Bu gecikme özelliğinin üstesinden gelmenin bir yolu yok, ancak bu durumda yapabiliriz Ne yapalım Gecikmeli büyüme durumunda, verimin mümkün olduğu kadar azalmamasını sağlamak mümkündür.Orijinal olarak kaç tane QPS ve TPS kullanılacağı garanti edilebilir.Proje iyi yapıldığı sürece garanti edilebilir, ancak gecikme kesinlikle artacaktır.
Bu aynı zamanda herkesin Goolgle Spanser kağıtlarında sıkça gördüğü "gecikmem çok yüksek" tanımlamadır. Bu yüksek gecikme durumunda, kullanılabilirliği ve yüksek verimi sağlamak için iyi bir uygulama nasıl yazılır? Başka bir konu. Herkes uzun süredir bir konsepte alışmış, yani veritabanı çok düşük gecikme süresine sahip olmalı ve yüksek gecikme uygulama sorunlarına neden olacaktır.Aslında bu konu hakkında konuşmak için başka bir alana ihtiyaç vardır, yani uygulama Bu yüksek gecikmeli veritabanı sistemine uyum sağlamak için. Tabii ki, esasen genel bir mühendislik optimizasyonu olan ve ağ üzerinde birden fazla kopyanın senkronize ve verimli olmasına izin veren Gruplama ve Ardışık Düzenleme teknolojileri kullanılır, ancak gecikme kesinlikle artacaktır.
Aslında, herkes veri tabanının üç kopyaya veya üç düğüme sahip olması gerektiğini bilir ki bu temelde güçlü veri tutarlılığı sağlamaktır ve herkes bu yönde çok çalışmaktadır.Örneğin, Oracle tarafından bir süre önce başlatılan Grup replikasyonu aynı zamanda üç düğümlü bir teknoloji olan X-Cluster'dır. Aradaki fark, başlangıçtaki amacımızın şehirleri geçmekti. İlk tasarladığımızda, bu düğümün çok uzun bir mesafeye yerleştirilmesi gerektiğini düşündük. Tasarımın başlangıcında, bu hedef önerildi, bu da bizi tasarlamaya, mühendisliğe ve Nihai performanstaki büyük fark dahil.
Burada ayrıca X-Cluster ve Oracle'ın Group replikasyonu arasında bazı karşılaştırmalar yaptık.Aynı şehir ortamında, onlardan daha iyiyiz; uzak sahnede, fark daha da büyük, çünkü başlangıçta onu uzak sahne için tasarladık . Ali'nin farklı yerlerde yaşama kavramından bahsettiğini de biliyor olabilirsiniz, yani IDC'ler arasında farklı yerlerde nasıl daha fazla yaşanır, bu yüzden başlangıçta farklı yerlerdeki sahneler için tasarladık.
Bu, X-Cluster'ın çok sayıda etkinliğe sahip uzak bir konumda nasıl çalıştığını gösteren tipik bir mimari diyagramdır. Bu tipik bir 3 şehir, 4 veri ve 5 günlük mimarisidir. Veri depolamayı basitleştirmek ve maliyetini göz önünde bulundurmak istiyorsanız, aslında yapabilirsiniz 3 nüshaya kadar veri ve 5 adet log kopyası Bu sayede şehir düzeyinde, bilgisayar odası makinelerinde, bağımsız makineler dahil herhangi bir arızanın önlenmesi sağlanabilir ve sıfır veri kaybı yaşanır.Bugün bunu yapabiliyoruz, verilerin sıfır kayıp olduğunu garanti edebiliyoruz. Kesinlikle tutarlı. Herhangi bir noktadaki veriler, en azından başka bir şehrin veri merkezinin veri tabanına yazılacaktır.Bu, X-Cluster tasarımımızın ilk amacıdır ve bu aynı zamanda farklı yerlerde birden çok etkinliğin olduğu tipik bir mimaridir.
Herkesin ilgisini çekebilecek küçük ama çok pratik bir yenilikten bahsedeyim, bu X-KV. Burada ayrıca tüm yeni nesil teknoloji bileşenlerimizin X ile başladığını da belirteyim. Bu X-KV, orijinal MYSQL Memcached eklentisine dayalı bir iyileştirmedir. Çok yüksek performansa ulaşır. Herkes MySQL Memcached eklentisini bilebilir. InnoDB tamponundaki verilere Memcached eklenti arayüzü üzerinden doğrudan erişebilirsiniz. Okuma performansı yapılabilir. En önemlisi, bunun herkes, sözde mimar veya tasarım süreci için önemi nedir?
Yani, birçok senaryoda önbelleğe almaya gerek yoktur, çünkü veritabanı + önbellek yapısı temelde tüm işletmeler için ortak bir senaryodur, ancak önbelleğe alma ile ilgili sorun, önbellekteki ve veritabanındaki verilerin her zaman tutarsız olması ve bunu yapmak için bir senkronizasyon veya geçersiz kılma mekanizmasına ihtiyaç duyulmasıdır. . X-KV'yi kullandıktan sonra okuma sorunu temelde çözülebilir. Bunun nedeni, bir veri parçasına bu arabirim üzerinden erişildiği sürece, temelde önbelleğe orijinal erişimle aynı yeteneği elde etmesi veya çoğu durumda önbelleğe alınması gerekmemesidir.
İkincisi, uygulamanın yanıt süresini kısaltmasıdır. Başlangıçta, SQL erişimi kullanılırsa yanıt süresi daha yüksek olacaktır. Bu konuda bazı iyileştirmeler yaptık. Başlangıçta, Memcached eklentisinde bazı dizin türleri için destek dahil olmak üzere bazı veri desteği kısıtlamaları vardır. Çok iyi değil, bu yüzden iyileştirmeler yaptık.Bu herkesin kullanabileceği bir şey.Bu yöntemi kullanırsanız, temelde birçok önbellek sistemine ihtiyaç duyulmaz.
Bahsetmek istediğim üçüncü şey, sıcak ve soğuk veri ayrımının nasıl çözüleceğidir. Doğal olarak MySQL çerçevesini kullanıyoruz. Burada doğrudan MySQL'in büyük resmini gösteriyoruz. MySQL'in temelde bir İstemci, ortada bir Sunucu ve altında bir depolama katmanı vardır.Depolama katmanında çeşitli motorlar olabilir, bu nedenle farklı motorlar aracılığıyla farklı özellikler gerçekleştirilebilir. Günümüzde herkes tarafından en yaygın olarak kullanılan InnoDB motorudur.Her bir depolama motorunun özellikleri esas olarak yapısından kaynaklanmaktadır. Örneğin, InnoDB, B + Ağacı yapısını benimser ve getirdiği özellik, okuma ve yazmanın nispeten dengeli olmasıdır, çünkü gerçekten de yıllar süren gelişimden sonra nispeten olgunlaşmıştır.
Örneğin, şimdi RocksDB'yi seçiyoruz. Bunun nedeni, Facebook ile MySQL'i tanıtmak için RocksDB üzerinde bazı işbirliğimiz var. Asıl yapısı LSM Ağacı. Bu yapının faydaları arasında kolay yazım ve sıkıştırılmış İyi özellikler vb. Bunu reformlarımıza dahil etmek sadece bir yapının tanıtımı değil, bugün bu iki motoru bugün veri ayırma sorunumuzu çözmek için kullanıyoruz. Facebook ile de bazı alışverişlerimiz oldu.RocksDB bugün çok istikrarlı ve iyi değil, ancak InnoDB depolama motoruna ek olarak çok etkili.
Özellikle kararlı bir veritabanı bağlamında, bugün kullanıcılar verilerinin sıcak ve soğuk olduğu konusunda nasıl pek bir şey hissetmezler, çünkü daha önce bazı veri ayrımlarınız olduğunu da biliyor olabilirsiniz, ancak uygulama tarafında verileri ayırmanız gerekir. Belirli bir depolamadan belirli bir depoya dökün ve ardından silin; veya DBA her zaman işletme geliştiricisinden depolama alanınızın yeterli olmadığını ve çok fazla alan kapladığını söylemesini ister. Bazı verileri silebilir veya bu verileri daha düşük bir maliyetle içe aktarabilir misiniz? Depolama motorunda. Bunu sık sık yapıyoruz. Açık konuşmak gerekirse, herkesin bunu daha önce yaptığına inanıyorum.
Ancak bu çift motorlu yapı ile RocksDB'nin yüksek sıkıştırma oranı, özellikle OLTP satır depolama senaryosunda bize nispeten büyük faydalar sağlayabilir. Böylece bu iki motoru MySQL özelliği altında birleştirebiliriz ve daha ucuz bir mimari kullanabiliriz, özellikle ucuz depolama ortamlarına daha uygun olan LSM Tree mimarisi, çünkü onun yazdıkları tamamen Sırayla yazılmıştır. Bu, bugün veritabanı çekirdeği hakkındaki düşüncelerimizin bir kısmı.
Veritabanının neden esnek zamanlamayı gerçekleştirmesi gerekiyor?
İkinci bölümde, esnek veritabanı planlamasından bahsetmek istiyorum.Herkes Ali'nin Double Eleven olduğunu biliyor. Double Eleven'da bizim için en büyük zorluk, uygulamaların bulut geçişi ve elastik genişleme dahil esnek zamanlamayı gerçekleştirmenin zaten kolay olabilmesidir. Ve küçülüyor, ancak veritabanı gerçekten zor, bunu da bir süredir araştırdık ve bugün düşüncelerimizi sizinle paylaşacağız.
Pek çok kişinin veritabanı konteynırlaştırmanın yanlış bir teklif olduğunu söylediğini duydum.Neden konteynere koymamız gerekiyor ve neden veritabanını bir konteynere koymalıyız? İkincisi, bazı yeni teknolojiler var: Örneğin, paylaşım yapan konuklar, depolama alanını ağ üzerinden uzaktan depolamanın mümkün olduğundan da bahsetti. Ama olumlu bir perspektiften düşünüyoruz Esnek veri tabanı çizelgeleme olasılığını düşünmeyin Veri tabanı esnek zamanlamaya ulaşmaksa, önermesi nedir?
Öncelikle veritabanının bir uygulama gibi nasıl çok basit ve esnek olması gerektiğini düşünelim, o halde veritabanı ne yapmalı? Bence yapılması gereken iki ana bina var: 1. Bir konteynere konulmalı, 2. Hesaplama ve depolama ayrılmalıdır. Çünkü bilgi işlem ve depolama doğası gereği ayrılmıyorsa, veritabanı temelde esnek bir zamanlama yöntemine sahip değildir. Herkes, bilgi işlem kaynaklarının taşınmasının kolay olduğunu bilir, ancak depolama kaynaklarını kısa sürede taşımak temelde zordur, bu nedenle esneklik sağlamak çok çok zordur. Yani bunlar iki temel koşul.
Senaryomuzda, bu tür bir problemle de karşılaşırsanız, bu yanlış bir öneri değil, bu şeyin mantıksız olduğunu düşünüyorum.Çoğunlukla teknolojinin doğru olup olmadığından ziyade senaryonuzda gerekli olup olmadığıdır. Yani bugün iki şey yaptık: Birincisi onu konteynere koymak. Şu anda fiziksel makineleri, VM'leri ve Docker'ı destekliyoruz. Konteynerin karmaşıklığını koruyan bir katman var. Veritabanı konteynere yerleştirilmelidir. . Uygulamalar genellikle dağıtım için konteynerlere konur, ancak veritabanını planlama için konteynere koyarız çünkü veritabanının kendisinin çok sayıda sürümü yoktur ve uygulamalar kadar sık yayınlanması gerekmez. Konteynırlaştırmadan sonra, veritabanı fiziksel bir makinede diğer konteynerlerle karıştırılabilir.
Hepimizin DBA olarak bazı geleneksel görünümleri vardır.Örneğin, uygulamalar veritabanı sunucularında çalıştırılmamalı ve kapsayıcılar veritabanlarında kullanılmamalıdır. Buradaki herkesi tanımıyorum. Ne zaman biri veya patronunuz size bu soruyu sorsa, onu her zaman hemen reddediyor musunuz ve "Veritabanları bunu kesinlikle yapamaz" diyor musunuz, ancak bugün patronunuza denemesini söyleyebilirsiniz. Ölçek.
Depolama ve hesaplama birbirinden ayrıldı.Veritabanı ilk oluşturulduğunda, depolama ve hesaplama fiilen ayrıldı.Bir Oracle veritabanı kullanıldı, bir SAN ağı kullanıldı ve altına bir depolama bağlandı. Depolama ve hesaplamanın kendisi ayrıldı ve SAN ağı ortasına bağlandı. Daha sonra yerel diskleri, SSD diskleri ve PC'leri sunucu olarak kullanmak için geliştirildi. Gelecekte, depolama ve bilgi işlem ayrımına geri döneceğiz. Bugünün ağ teknolojisinin gelişimi, sadece tescilli ağlar değil, aynı zamanda genel 25G ağları ve RDMA ve SPDK gibi yeni teknolojilerin kullanımı, Depolama ve hesaplamayı ayırma yeteneği ve veritabanı depolama ile bilgi işlemin ayrılması için gerekli koşullar halihazırda mevcuttur.
Bugün, veritabanında GÇ'yi azaltabilen, ayrık GÇ'yi sıralı GÇ'ye dönüştürebilen ve temeldeki depolama için çok kolay olabilen çok sayıda optimize edilmiş özellik gördük. Depolama maliyetleri açısından, paylaşılan depolama, maliyetleri büyük ölçüde azaltacaktır çünkü depolama parçaları büyük ölçüde sıkıştırılacaktır, çünkü her makinedeki orijinal alanın% 30 ve% 50'si boştur ve diğer makinelerin kullanımı zordur. , Bugün bu parçaları bir Havuza dönüştürdüğünüzde büyük faydalar var.
Buna ek olarak, eğer veritabanı gelecekte depolama ve bilgi işlem ayrımını benimserse, mevcut ana veri tabanı tek ana tek yedekleme mimarisini bozacaktır.Bu mimarinin bilgi işlem kaynaklarının en az yarısı, yedekleme veritabanınızın raporlama için kullanılıp kullanılmadığına bakılmaksızın tamamen boşa harcanır. Veya diğer uygulamalar, ama temelde savurgan. Paylaşılan depolama elde edilebilirse, bu büyük bir fayda sağlayacaktır. Planlama üzerine düşüncemiz bu. Yarın şube toplantısında size bu konudaki kapsayıcılar ve depolama kaynakları hakkında ayrıntılı bir giriş yapmak için bir Ali sınıf arkadaşı olacak. Bunun hakkında sadece bugün konuştum.
DBA'nın gelecekteki iş içeriği nedir?
Son olarak DBA'dan bahsedeceğim. Az önce otomasyondan zekaya geçmekten bahsettiğimi ve içten self servisten zekaya geçeceğimizi söyledim. Herkesin sorunlu olup olmadığını bilmiyorum. İş geliştirme hızı DBA'ların sayısından çok daha fazla. Büyüme, eğer aşağıdakilere sahip değilseniz, bunun hakkında konuşmama gerek yok ama duyarsanız bu alandaki düşüncelerimizi dinleyebilirsiniz. Aynı sorunla da karşılaşıyoruz. DBA ne tür bir gelişme? Otomasyonda bir sonraki adım olmalı Ne yapmalı, birçok kişi DBA'nın ortadan kaldırılıp kaldırılmayacağını söylüyor, en azından bu sorunları net olarak düşündükten sonra, Ali'nin DBA'sı bu konuyu karıştırmayacak, bu yüzden bugün sizlerle bu düşünceyi paylaşacağım.
Her şeyden önce bugün bir şeyler yaptık, orijinal fikirden vazgeçtik, orijinal fikir neydi? En başta, çevrimiçi olan her SQL'e bakmak için bir DBA'ya ihtiyacımız vardı; ikinci aşamada, bir sistem kurduk.Her SQL çevrimiçi olmadan önce, sistemin performansını tahmin etmesi gerekiyordu ve eğer iyiyse çevrimiçi oldu. Bugün hissettiğimiz en büyük değişiklik ve düşünce nedir? Tek bir ifadeye dayalı tüm optimizasyonlar özellikle anlamlı değildir, çünkü yalnızca büyük verilere ve hesaplamalara dayalı olarak akıllıca bir şey olabilir, aksi takdirde kurallara dayanır.
Kural tabanlı bir sistemin özellikle uzun ömürlü bir canlılığa sahip olması zordur, çünkü asla yazılamayan kurallar vardır. Biz de böyle bir girişimde bulunduk.Bir SQL geldiğinde, sistem onun üzerinde bazı yargılarda bulunmalı ve sonunda asla yazılamayacak kuralları bulmalıdır. Böylece daha sonra başka bir yön bulduk.Bugün buradaki herkesin, şirketinizin, ne kadar büyük ya da küçük olursa olsun bir izleme sistemine sahip olduğuna inanıyorum, bu izleme sisteminden başlayacağız, bir izleme sistemini nasıl akıllı hale getireceğiz Motoru optimize ederken, burada beyinden bahsetmiyoruz, sadece motorun iyi olduğunu söylüyoruz. Bu motor ne yapacak?
Öncelikle tek bir SQL tabanlı optimizasyondan vazgeçtik çünkü bu anlamsız, DBA tek bir SQL'i incelememiş ve sistem tek bir SQL'e bakmak pek mantıklı gelmiyor. Bugünkü ilk senaryomuz büyük miktarda veriyle ilgili Büyük miktarda veri nedir? İzleme sistemimizden başlayarak, örnekleme değil, çalışan her SQL'i toplamak için ilk hedefi ortaya koyduk. Büyük ölçekli bir sistemde, çok fazla yan ürün üreteceği için depolama üzerinde büyük bir baskı oluşturur.
Tıpkı Facebook'un ürünleri takip ederken ürettiği zaman serisi veritabanı gibi bugün ürettiğimiz yan ürünler de zaman serisi veri tabanına baskı yapıyor, bugün buna özel olarak başlamayacağım. Çekirdekte iyileştirmeler yaptığımız için her SQL'in çalışma durumunu topluyoruz, veritabanındaki her SQL'in tüm kaynağını, yolunu ve tüm bilgilerini toplayabiliyoruz. İzleme göstergelerini ikinci seviyeye bastırmak için, tüm izleme öğelerinin göstergeleri en azından ikinci seviye olmalıdır, bu da mevcut teknolojimizin başarabileceği şeydir.
Ek olarak, uygulama tarafındaki günlükleri ve veritabanlarını birleştiriyoruz. Veritabanı üzerinde çalışırken, uygulama ekibi "Veritabanında herhangi bir sorun var mı?" Diye bağırdı DBA herhangi bir sorun olmadığını söyledi. Ancak uygulama tarafından, yanıt süresi de dahil olmak üzere uygulama hataları da dahil olmak üzere veritabanında pek çok sorun olduğunu görebiliyoruz.Uygulama tarafındaki hatalar, özellikle veritabanında bildirilen hatalar ve tüm zincir ile veritabanı ile birleştirilmelidir. yol.
Yanıt süresi, yalnızca uygulama tarafının yanıt süresi, veritabanının kendisinin nasıl olduğunu, hangi yükün düşük olduğunu ve CPU kullanımının ne kadar olduğunu değil, veritabanının iyi olup olmadığını ölçebilen gerçek bir göstergedir. Tüm bu veriler toplandıktan sonra, bu büyük miktardaki zaman serisi verilerini bir yan ürün olarak adlandırıyoruz ve bu da tüm bağlantımıza büyük bir baskı uyguluyor. Tüm izleme sistemi platformunda çalışan sınıf arkadaşlarımız, orijinal depolama sistemi destekleyemediği, analiz sistemi destekleyemediği ve orijinal platform bunu hesaplayamadığı için hayatta kalamayacaklarını düşünüyorlar. Öyleyse önce bu hedefi göz önünde bulundurun ve ucuz depolamanın nasıl sağlanacağı ve depolama ve bilgi işlem için gereksinimler olan gerçek zamanlı olarak nasıl analiz edileceği dahil olmak üzere bağlantıya dayalı olarak büyük iyileştirmeler yapın.
Bugün hedefimiz Alibaba'da açıkça belirtiliyor. DBA'nın çalışmalarının çoğunu iki ila üç yıl içinde değiştirmeyi umuyoruz. İki ila üç yıl içinde başarılabilir mi bilmiyorum. Umarım başarılabilir. Aslında, DBA bugün böyledir. DBA'nın çalışması esasen iki kategoriye ayrılmıştır. İlk kategori, işletim ve bakımdır, ancak ister bulut, ister küçük şirketler bulutu kullanıyor ve büyük şirketler olsun, işletim ve bakımın çözümü doğal olarak daha kolaydır. Temelde bazı otomatik işletim ve bakım sistemleri vardır.
Ancak çözülmesi en zor şey, az önce bahsettiğim teşhis ve optimizasyon. Google ve Facebook gibi pek çok şirket hakkında da bilgi edindim. Neden bir DBA'nız yok? Bizim bir DBA'ya sahip olmadığımızı ve yerli olan gibi teşhis ve performans optimizasyonu için böyle özel bir geleneksel DBA bulunmadığını ve bu tür sorumlulukların çok az olduğunu söylediler. Bu yüzden umarım bu şey yapılabilir.
Son olarak, verilerimiz ve hesaplamalarımız var.Geleceğin yönünün şu anda nispeten popüler olan makine öğrenimi olabileceğini düşünüyoruz. Yarın bu konuyu paylaşacak bir Ali sınıf arkadaşı da olacak.Burada makine öğrenimi hakkında konuşmayacağım çünkü biz de düşünüyorum Başlangıçta bahsetmeye değer bir şey yok ama biz bu tasarımın oldukça ilginç olduğunu düşünüyoruz Yeterli veri ve hesaplama yaptığınız sürece bu şey oldukça ilginç.
Veritabanlarının geleceği hakkındaki diğer düşüncelerimiz
PPT'nin son sayfasında, tüm veritabanı sistemi hakkındaki anlayışım hakkında konuşmak için yerel dili kullanacağım.
Günümüzde, bir şirkette tüm sorunları çözebilecek bir depolama veya veritabanı yoktur.Günümüzde, satır depolama ve sütun depolamanın avantajları nedeniyle veri depolama çeşitliliğinin var olmaya mahkum olduğunu giderek daha fazla eğilim görmektedir. Depolamanın avantajları, hesaplamaların hesaplama avantajları vardır, analizin analiz yapmanın avantajları vardır ve OLTP'nin OLTP avantajları vardır. Beklemeyin, bir sistemin her şeyi yapmasını beklemek zordur. Bu pek iyi olmayabilir dedim. , Ama gerçekten zor, ama ne görüyoruz? Bu, her teknolojinin veya ürünün üretimde en iyi olanı yapabileceği ve probleminizi çözmek için onun yaptığı en iyi şeyi kullanabileceğiniz anlamına gelir.
Bu bizi bir önceki soruya geri getiriyor.Ayrıca bazı yollardan geçtik. Gittikçe daha fazla veri depolama türü var. Bunu bugün ve yarın kullanırsam ne yapmalıyım? Operasyonumuz ve bakımımız yapılamaz, bu destek çok acı vericidir.
Bu nedenle bugün iki platform kurmayı öneriyoruz: 1. Alt katman depolamanın karmaşıklığını mümkün olduğunca koruyan ve üst katmana birleşik arabirimler ve hizmetler sağlayan bir destekleyici platform oluşturun; 2. Açıkça bir hizmet platformu oluşturun; Ar-Ge odaklı platformlar için, Ar-Ge personeli bu platform üzerinden veritabanı hizmetlerini doğrudan kullanabilmektedir. Birçok şirketin işletim ve bakım platformunu DBA geliştirme platformuyla karıştırdığını gördüm, ancak Alinin fikri, destek platformu ve hizmet platformunun iki katmanlı platform olması, destek platformunun aşağıda olması ve üst hizmet platformunun tüm geliştiricilere hizmet etmesidir. , Geliştiriciler hangi veritabanını kullandığımı, performansın nasıl olduğunu ve bu platformda neler yapılabileceğini görebilir, bu da çok fazla DBA insan gücü tasarrufu sağlayabilir.
İçimizde "İnsan gücünden tasarruf etmeyen platformlar ve maliyetten tasarruf etmeyen teknolojiler holiganlıktır" diye bir şaka var. Bunu nasıl söylersin? Yani otomasyon sistemlerimiz, özellikle büyük şirketler, giderek daha çok inşa ediyorlar.Son sonuç, insanların aciz olması.Bu problemin var mı bilmiyorum, bahsettiğim son nokta, otomasyon sistemlerinin paradoksu. Her şirketteki herkes Bugün otomasyon sistemleri yapma sürecinde bir şey oluyor mu? Her neyse Ali'de oldu, yani insan yetenekleri zayıfladı.
Bu otomatik sistemin paradoksu, istemeden gördüğümüz şeydir.Uçağın otomatik sürüşünden bahsederken, otomatik sürüş yeterince iyi olduğu için, acil bir sorun ortaya çıktığında, pilotun acil durumla başa çıkmak için yeterli yeteneği yoktur. Durum, bu otomatik sistemlerin paradoksudur.
Kıyaslanabilir.Bugün birçok otomasyon sistemi yaptık.Sonuç olarak insanlar sadece sisteme tıklarlar.Sistem takıldıktan sonra biter.İkincil arızaların çoğu sistemden kaynaklanır. Bugün düşünülmesi gereken soru bu Bu süreçte takımı yöneten ya da bugün sistemde yer alan tüm kişilerin sorun hakkında düşünmesi gerekiyor Biz de doğrudan bu sorunla karşı karşıyayız ki insanların yetenekleri ve sistemin yeteneği birleştirilebilsin. , Bu başka bir konu, bugün cevap veremem ama bu sorulara özellikle dikkat etmeliyiz.
Süresi dolan efsanelere inanmayın. Veritabanı depolama ve hesaplama ayrılabilir ve veritabanı bir kaba da yerleştirilebilir, ancak gerçekten orijinal mitlere veya arkasındaki sorunlara bakmanız gerekir. Aslında, Şu anda bir çözüm olabilir, yani buradaki herkes, patronunuz, CTO veya biri size "Bunu yapabilir misin?" Diye sorduğunda, umarım ona "yapabilirim!"
İçimizde bir cümle var DBA'mız DBA kavramı nedir diye bir makaleyi nerede okudu? Çok etkilendim. Bir geliştirme sınıf arkadaşının aşağıdaki cevabı şuydu: "DBA her zaman hayır diyen bir grup insan" ama böyle olamaz. Bugün sanırım gelecekte her zaman "evet" diyebilecek bir grup insan olacağız. "Evet" insanlar, teşekkür ederim!
