DBA botu Joe. Anatoly Stansler (Postgres.ai)

Bir arka uç geliştiricisi, bir SQL sorgusunun bir "ürün" üzerinde iyi çalışacağını nasıl anlar? Büyük veya hızla büyüyen şirketlerde herkesin "ürüne" erişimi yoktur. Ve erişimle, tüm istekler zahmetsizce kontrol edilemez ve veritabanının bir kopyasını oluşturmak genellikle saatler sürer. Bu sorunları çözmek için yapay bir DBA - Joe oluşturduk. Halihazırda birkaç şirkette başarıyla uygulandı ve bir düzineden fazla geliştiriciye yardımcı oldu.

Video:

Herkese selam! Benim adım Anatoly Stansler. bir şirket için çalışıyorum postgres.ai. Postgres'in çalışmalarıyla ilişkili gecikmeleri geliştiricilerden, DBA'lardan ve QA'lardan kaldırarak geliştirme sürecini hızlandırmaya kararlıyız.

Harika müvekkillerimiz var ve bugün raporun bir kısmı onlarla çalışırken karşılaştığımız vakalara ayrılacak. Oldukça ciddi sorunları çözmelerine nasıl yardımcı olduğumuzdan bahsedeceğim.

Karmaşık yüksek yüklü geçişleri geliştirirken ve gerçekleştirirken kendimize şu soruyu soruyoruz: "Bu geçiş başarılı olacak mı?" İncelemeyi kullanıyoruz, daha deneyimli meslektaşlarımızın, DBA uzmanlarının bilgilerini kullanıyoruz. Ve uçup uçmayacağını söyleyebilirler.

Ama belki de tam boyutlu kopyalarda kendimiz test edebilsek daha iyi olur. Ve bugün sadece şu anda test yaklaşımlarının ne olduğu ve bunun nasıl daha iyi ve hangi araçlarla yapılabileceği hakkında konuşacağız. Bu tür yaklaşımların artıları ve eksileri ve burada neleri düzeltebileceğimiz hakkında da konuşacağız.

Kim doğrudan ürün üzerinde dizin oluşturdu veya herhangi bir değişiklik yaptı? Birazcık. Ve bu, kimin için verilerin kaybolmasına veya kesinti sürelerine yol açtı? O zaman bu acıyı biliyorsun. Tanrıya şükür yedekler var.

İlk yaklaşım, üretimde test etmektir. Veya bir geliştirici yerel bir makinede oturduğunda, test verilerine sahip olduğunda, bir tür sınırlı seçim vardır. Ve üretime geçiyoruz ve bu durumu elde ediyoruz.

Acıtıyor, pahalı. Muhtemelen yapmamak en iyisidir.

Ve bunu yapmanın en iyi yolu nedir?

Aşamayı ele alalım ve orada üretimin bir bölümünü seçelim. Ya da en iyi ihtimalle, tüm verileri, gerçek bir ürünü ele alalım. Ve onu yerel olarak geliştirdikten sonra, aşamalandırmayı da kontrol edeceğiz.

Bu, bazı hataları ortadan kaldırmamıza, yani üretimde olmalarını engellememize izin verecektir.

Sorun ne?

• Sorun şu ki, bu sahnelemeyi meslektaşlarımızla paylaşıyoruz. Ve çoğu zaman bir tür değişiklik yaparsınız, bam - ve veri yoktur, iş boşa gider. Evreleme çok terabayttı. Ve tekrar yükselmesi için uzun süre beklemeniz gerekiyor. Ve yarın bitirmeye karar veriyoruz. İşte bu, bir gelişmemiz var.
• Ve tabii ki orada çalışan birçok arkadaşımız, birçok ekibimiz var. Ve manuel olarak yapılması gerekiyor. Ve bu uygunsuz.

Ve veritabanında bazı değişiklikler yapmak, verilere dokunmak, yapıyı değiştirmek istiyorsak, tek bir girişimimiz, tek atışımız olduğunu söylemekte fayda var. Ve bir şeyler ters giderse, taşımada bir hata olursa, o zaman hızlı bir şekilde geri almayacağız.

Bu, önceki yaklaşımdan daha iyidir, ancak yine de bir tür hatanın üretime gitme olasılığı yüksektir.

Her geliştiriciye bir test tezgahı, tam boyutlu bir kopya vermemizi engelleyen nedir? Bence neyin engel olduğu açık.

Kimin bir terabayttan daha büyük bir veritabanı var? Odanın yarısından fazlası.

Ve bu kadar büyük bir üretim varken her geliştirici için makine tutmanın çok pahalı olduğu ve ayrıca uzun zaman aldığı açıktır.

Tüm değişiklikleri tam boyutlu kopyalarda test etmenin çok önemli olduğunu fark eden müşterilerimiz var, ancak veritabanları bir terabayttan daha az ve her geliştirici için bir test tezgahı tutacak kaynak yok. Bu nedenle dökümleri yerel olarak makinelerine indirmeleri ve bu şekilde test etmeleri gerekir. Çok zaman alır.

Altyapı içinde yapsanız bile, saatte bir terabayt veri indirmek zaten çok iyi. Ancak mantıksal dökümler kullanıyorlar, yerel olarak buluttan indiriyorlar. Onlar için hız saatte yaklaşık 200 gigabayttır. Ve yine de mantıksal dökümden geri dönmek, dizinleri toplamak vb. zaman alıyor.

Ancak bu yaklaşımı, ürünü güvenilir tutmalarına izin verdiği için kullanıyorlar.

Burada ne yapabiliriz? Test tezgahlarını ucuz hale getirelim ve her geliştiriciye kendi test tezgahını verelim.

Ve bu mümkün.

Ve bu yaklaşımda her geliştirici için ince klonlar oluşturduğumuzda bunu tek bir makinede paylaşabiliyoruz. Örneğin, 10 TB'lık bir veritabanınız varsa ve bunu 10 geliştiriciye vermek istiyorsanız, XNUMX x XNUMX TB veri tabanına sahip olmanıza gerek yoktur. Bir makine kullanarak her geliştirici için ince izole kopyalar oluşturmak için yalnızca bir makineye ihtiyacınız vardır. Nasıl çalıştığını biraz sonra anlatacağım.

Gerçek örnek:

• DB - 4,5 terabayt.

• 30 saniyede bağımsız kopyalar alabiliyoruz.

Bir test standı için beklemeniz ve ne kadar büyük olduğuna bağlı olmanız gerekmez. Saniyeler içinde alabilirsiniz. Tamamen izole edilmiş ancak kendi aralarında veri paylaşan ortamlar olacaktır.

Bu harika. Burada sihirden ve paralel evrenden bahsediyoruz.

Bizim durumumuzda bu, OpenZFS sistemi kullanılarak çalışır.

OpenZFS, kutudan çıkar çıkmaz anlık görüntüleri ve klonları destekleyen bir yazma üzerine kopyalama dosya sistemidir. Güvenilir ve ölçeklenebilirdir. Yönetmesi çok kolaydır. Kelimenin tam anlamıyla iki takım halinde konuşlandırılabilir.

Başka seçenekler de var:

• lvm,

• Depolama (örneğin, Saf Depolama).

Bahsettiğim Veritabanı Laboratuvarı modülerdir. Bu seçenekler kullanılarak uygulanabilir. Ancak şimdilik OpenZFS'ye odaklandık çünkü özellikle LVM ile ilgili sorunlar vardı.

Nasıl çalışır? Verileri her değiştirdiğimizde üzerine yazmak yerine, bu yeni verilerin zamanın yeni bir noktasından, yeni bir anlık görüntüden olduğunu işaretleyerek kaydediyoruz.

Ve gelecekte, geri almak istediğimizde veya eski bir sürümden yeni bir klon yapmak istediğimizde, "Tamam, bize bu şekilde işaretlenmiş bu veri bloklarını verin" deriz.

Ve bu kullanıcı böyle bir veri seti ile çalışacaktır. Yavaş yavaş onları değiştirecek, kendi anlık görüntülerini yapacak.

Ve şubeleşeceğiz. Bizim durumumuzdaki her geliştirici, düzenlediği kendi klonuna sahip olma fırsatına sahip olacak ve paylaşılan veriler herkes arasında paylaşılacaktır.

Böyle bir sistemi evde kurmak için iki sorunu çözmeniz gerekir:

• Birincisi, verilerin kaynağı, nereden alacağınızdır. Üretim ile çoğaltmayı ayarlayabilirsiniz. Umarım yapılandırdığınız yedekleri zaten kullanabilirsiniz. WAL-E, WAL-G veya Barmen. RDS veya Cloud SQL gibi bir tür Bulut çözümü kullanıyor olsanız bile mantıksal dökümleri kullanabilirsiniz. Ancak yine de yedekleri kullanmanızı tavsiye ediyoruz, çünkü bu yaklaşımla dosyaların fiziksel yapısını da koruyacaksınız, bu da var olan sorunları yakalamak için üretimde göreceğiniz ölçümlere daha da yakın olmanızı sağlayacaktır.

• İkincisi, Veritabanı Laboratuvarını barındırmak istediğiniz yerdir. Bulut olabilir, şirket içi olabilir. Burada ZFS'nin veri sıkıştırmayı desteklediğini söylemek önemlidir. Ve bunu oldukça iyi yapıyor.

Üs ile yaptığımız işlemlere bağlı olarak bu tür her bir klon için bir tür geliştiricinin büyüyeceğini hayal edin. Bunun için dev'in de alana ihtiyacı olacak. Ancak 4,5 terabaytlık bir taban aldığımız için ZFS bunu 3,5 terabayta sıkıştıracak. Bu, ayarlara bağlı olarak değişebilir. Ve hala dev için yerimiz var.

Böyle bir sistem farklı durumlar için kullanılabilir.

• Bunlar, optimizasyon için sorgu doğrulama için DBA'lar olan geliştiricilerdir.

• Bu, üretime sunmadan önce belirli bir geçişi test etmek için QA testinde kullanılabilir. Ayrıca, yeni işlevleri test edebilecekleri, gerçek verilerle QA için özel ortamlar oluşturabiliriz. Ve ince kopyaların kullanılmadığı diğer bazı durumlarda saatlerce ve belki günlerce beklemek yerine saniyeler alacaktır.

• Ve başka bir vaka. Firmanın analitik sistem kurulumu yoksa o zaman ürün tabanının ince bir klonunu izole edip uzun sorgulara veya analitikte kullanılabilecek özel indekslere verebiliriz.

Bu yaklaşımla:

1. Tüm değişiklikleri tam boyutlu veriler üzerinde test ettiğimiz için "üretimde" düşük hata olasılığı.

2. Bizim bir test kültürümüz var çünkü artık kendi standınız için saatlerce beklemenize gerek yok.

3. Ve testler arasında hiçbir engel, bekleme yok. Aslında gidip kontrol edebilirsiniz. Ve gelişimi hızlandırdığımız için bu şekilde daha iyi olacak.

• Daha az yeniden düzenleme olacak. Prod'da daha az hata olacaktır. Bunları daha sonra yeniden düzenleyeceğiz.

• Geri dönüşü olmayan değişiklikleri tersine çevirebiliriz. Bu standart bir yaklaşım değildir.

1. Bu faydalıdır çünkü test tezgahlarının kaynaklarını paylaşırız.

Zaten iyi, ama başka ne hızlandırılabilir?

Böyle bir sistem sayesinde, böyle bir teste girme eşiğini büyük ölçüde azaltabiliriz.

Artık bir geliştiricinin gerçek boyutlu verilere erişmek için uzman olması gereken bir kısır döngü var. Böyle bir erişim konusunda ona güvenilmelidir.

Ama orada değilse nasıl büyüyecek. Ancak, kullanabileceğiniz yalnızca çok küçük bir dizi test veriniz varsa ne olur? O zaman gerçek bir deneyim elde edemezsin.

Bu çemberden nasıl çıkılır? Her seviyedeki geliştirici için uygun olan ilk arayüz olarak Slack bot'u seçtik. Ancak başka herhangi bir arayüz olabilir.

Ne yapmanıza izin verir? Belirli bir sorguyu alıp veritabanı için özel bir kanala gönderebilirsiniz. İnce bir klonu saniyeler içinde otomatik olarak konuşlandıracağız. Bu isteği çalıştıralım. Ölçümleri ve önerileri topluyoruz. Bir görselleştirme gösterelim. Ve sonra bu klon, bu sorgunun bir şekilde optimize edilebilmesi, dizin eklenebilmesi vb.

Ayrıca Slack bize alışılmışın dışında işbirliği fırsatları sunuyor. Bu sadece bir kanal olduğu için, iş arkadaşlarınıza, şirket içindeki DBA'lara ping atarak, bu talebi hemen oradaki başlıkta tartışmaya başlayabilirsiniz.

Ama tabii ki sorunlar var. Bu gerçek dünya olduğundan ve aynı anda birçok klonu barındıran bir sunucu kullandığımızdan, klonların kullanabileceği bellek miktarını ve CPU gücünü sıkıştırmamız gerekiyor.

Ancak bu testlerin makul olması için bu sorunu bir şekilde çözmeniz gerekiyor.

Önemli olan noktanın aynı veriler olduğu açıktır. Ama bizde zaten var. Ve aynı yapılandırmayı elde etmek istiyoruz. Ve neredeyse aynı konfigürasyonu verebiliriz.

Üretimdeki ile aynı donanıma sahip olmak harika olurdu, ancak farklılık gösterebilir.

Postgres'in bellekle nasıl çalıştığını hatırlayalım. İki önbelleğimiz var. Biri dosya sisteminden ve bir yerel Postgres'ten, yani Paylaşılan Tampon Önbelleği.

Yapılandırmada belirttiğiniz boyuta bağlı olarak, Postgres başladığında Paylaşılan Tampon Önbelleğinin ayrıldığına dikkat etmek önemlidir.

Ve ikinci önbellek tüm kullanılabilir alanı kullanır.

Ve bir makinede birkaç klon yaptığımızda, hafızayı yavaş yavaş doldurduğumuz ortaya çıkıyor. Ve iyi bir şekilde, Paylaşımlı Tampon Önbelleği, makinede bulunan toplam bellek miktarının %25'idir.

Ve bu parametreyi değiştirmezsek, o zaman bir makinede sadece 4 örneği, yani bu ince klonlardan toplamda 4 tanesini çalıştırabileceğiz. Ve bu elbette kötü çünkü onlardan çok daha fazlasına sahip olmak istiyoruz.

Ancak öte yandan, Buffer Cache, dizinler için sorguları yürütmek için kullanılır, yani plan, önbelleklerimizin ne kadar büyük olduğuna bağlıdır. Ve eğer bu parametreyi alıp azaltırsak, planlarımız çok değişebilir.

Örneğin, prod üzerinde büyük bir önbelleğimiz varsa, Postgres bir dizin kullanmayı tercih edecektir. Ve değilse, o zaman SeqScan olacaktır. Ve planlarımız çakışmasaydı ne anlamı kalırdı?

Ancak burada, aslında Postgres'teki planın, plandaki Paylaşılan Tamponda belirtilen belirli boyuta bağlı olmadığı, etkili_cache_size'ye bağlı olduğu sonucuna varıyoruz.

Etkili_önbellek_boyutu, bizim için kullanılabilir olan tahmini önbellek miktarıdır, yani Tampon Önbelleği ile dosya sistemi önbelleğinin toplamıdır. Bu, yapılandırma tarafından belirlenir. Ve bu hafıza tahsis edilmemiştir.

Ve bu parametre nedeniyle, bu verilere sahip olmasak bile, aslında çok fazla veriye sahip olduğumuzu söyleyerek Postgres'i kandırabiliriz. Ve böylece planlar üretimle tamamen örtüşecek.

Ancak bu, zamanlamayı etkileyebilir. Sorguları zamanlamaya göre optimize ederiz, ancak zamanlamanın birçok faktöre bağlı olması önemlidir:

• Şu anda üretimde olan yüke bağlıdır.

• Makinenin kendisinin özelliklerine bağlıdır.

Ve bu dolaylı bir parametredir, ancak aslında sonucu almak için tam olarak bu sorgunun okuyacağı veri miktarına göre optimize edebiliriz.

Ve zamanlamanın üretimde göreceğimize yakın olmasını istiyorsanız, tüm klonların uyması için en benzer donanımı ve muhtemelen daha fazlasını almamız gerekir. Ancak bu bir uzlaşmadır, yani aynı planları alacaksınız, belirli bir sorgunun ne kadar veri okuyacağını göreceksiniz ve bu sorgunun iyi (veya geçiş) veya kötü olup olmadığı sonucuna varabileceksiniz, yine de optimize edilmesi gerekiyor .

Joe'nun özel olarak nasıl optimize edildiğine bir göz atalım.

Gerçek bir sistemden istek alalım. Bu durumda, veritabanı 1 terabayttır. Ve 10'dan fazla beğeni alan yeni gönderilerin sayısını saymak istiyoruz.

Kanala mesaj yazıyoruz, bizim için bir klon konuşlandırıldı. Ve böyle bir talebin 2,5 dakikada tamamlanacağını göreceğiz. İlk fark ettiğimiz şey bu.

B Joe, plana ve ölçümlere dayalı olarak size otomatik öneriler gösterecektir.

Sorgunun nispeten az sayıda satır elde etmek için çok fazla veri işlediğini göreceğiz. Ve sorguda çok fazla filtrelenmiş satır olduğunu fark ettiğimiz için bir tür özel dizine ihtiyaç var.

Neler olduğuna daha yakından bakalım. Nitekim dosya önbelleğinden ve hatta diskten neredeyse bir buçuk gigabayt veri okuduğumuzu görüyoruz. Ve bu iyi değil çünkü sadece 142 satırımız var.

Görünüşe göre, burada bir dizin taramamız var ve hızlı bir şekilde çalışmalıydık, ancak çok fazla satırı filtrelediğimiz için (onları saymak zorundaydık), sorgu yavaş yavaş çalıştı.

Ve bu, sorgudaki koşullar ile dizindeki koşulların kısmen eşleşmemesi nedeniyle planda gerçekleşti.

Dizini daha kesin hale getirmeye çalışalım ve bundan sonra sorgu yürütmenin nasıl değiştiğini görelim.

Dizinin oluşturulması oldukça uzun sürdü, ancak şimdi sorguyu kontrol ediyoruz ve 2,5 dakika yerine sürenin sadece 156 milisaniye olduğunu görüyoruz ki bu yeterince iyi. Ve sadece 6 megabayt veri okuyoruz.

Ve şimdi sadece dizin taraması kullanıyoruz.

Bir diğer önemli hikaye de planı daha anlaşılır bir şekilde sunmak istiyoruz. Alev Grafiklerini kullanarak görselleştirmeyi hayata geçirdik.

Bu farklı bir istek, daha yoğun. Ve Alev Grafiklerini iki parametreye göre oluşturuyoruz: bu, belirli bir düğümün plan ve zamanlamada saydığı veri miktarı, yani düğümün yürütme süresidir.

Burada belirli düğümleri birbiriyle karşılaştırabiliriz. Ve diğer render yöntemlerinde yapılması genellikle zor olan hangisinin daha fazla veya daha az sürdüğü açık olacaktır.

Açıkla.depesz.com'u tabi ki herkes biliyor. Bu görselleştirmenin iyi bir özelliği, metin planını kaydetmemiz ve ayrıca sıralayabilmemiz için bazı temel parametreleri bir tabloya koymamızdır.

Ve henüz bu konuyu derinlemesine incelememiş olan geliştiriciler de, hangi ölçütlerin önemli, hangilerinin önemsiz olduğunu anlamaları daha kolay olduğu için accept.depesz.com'u kullanır.

Görselleştirmeye yeni bir yaklaşım var - bu, allow.dalibo.com. Bir ağaç görselleştirmesi yapıyorlar ama düğümleri birbiriyle karşılaştırmak çok zor. Burada yapıyı iyi anlayabilirsiniz, ancak büyük bir istek varsa, o zaman ileri geri kaydırmanız gerekecek, aynı zamanda bir seçenek de olacaktır.

işbirliği

Ve dediğim gibi, Slack bize işbirliği yapma fırsatı veriyor. Örneğin, nasıl optimize edileceği net olmayan karmaşık bir sorguyla karşılaşırsak, Slack'te bir başlıkta meslektaşlarımızla bu konuyu açıklığa kavuşturabiliriz.

Bize öyle geliyor ki, tam boyutlu veriler üzerinde test yapmak önemli. Bunu yapmak için, açık kaynakta bulunan Update Database Lab aracını yaptık. Joe botunu da kullanabilirsiniz. Hemen şimdi alıp yerinizde uygulayabilirsiniz. Tüm rehberler orada mevcuttur.

Delphix olduğu için çözümün kendisinin devrim niteliğinde olmadığına dikkat etmek de önemlidir, ancak bu bir kurumsal çözümdür. Tamamen kapalı, çok pahalı. Özellikle Postgres konusunda uzmanız. Bunların hepsi açık kaynaklı ürünlerdir. Bize katılın!

Burada bitiriyorum. Teşekkür ederim!

sorular

Merhaba! Rapor için teşekkürler! Özellikle benim için çok ilginç çünkü bir süre önce aynı sorunu çözdüm. Ve bu yüzden birkaç sorum var. Umarım en azından bir kısmını alabilirim.

Acaba bu ortamın yerini nasıl hesaplıyorsunuz? Teknoloji, belirli koşullar altında klonlarınızın maksimum boyuta büyüyebileceği anlamına gelir. Kabaca söylemek gerekirse, on terabaytlık bir veritabanınız ve 10 klonunuz varsa, o zaman her klonun 10 benzersiz veri ağırlığında olduğu bir durumu simüle etmek kolaydır. Bahsettiğiniz bu klonların yaşayacağı bu yeri, yani o deltayı nasıl hesaplıyorsunuz?

İyi soru. Burada belirli klonları takip etmek önemlidir. Ve eğer bir klonda çok büyük bir değişiklik varsa, büyümeye başlar, o zaman önce kullanıcıya bu konuda bir uyarı verebiliriz veya bu klonu hemen durdurabiliriz, böylece bir arıza durumu yaşamayız.

Evet, iç içe geçmiş bir sorum var. Yani bu modüllerin yaşam döngüsünü nasıl sağlıyorsunuz? Bu sorunumuz ve tamamen ayrı bir hikayemiz var. Bu nasıl olur?

Her klon için bir miktar ttl vardır. Temel olarak, sabit bir ttl'miz var.

Sır değilse ne?

1 saat, yani boşta - 1 saat. Kullanılmazsa, o zaman patlatırız. Ancak klonu saniyeler içinde yükseltebileceğimiz için burada sürpriz yok. Ve tekrar ihtiyacın olursa, lütfen.

Teknoloji seçimiyle de ilgileniyorum, çünkü örneğin, şu veya bu nedenle paralel olarak birkaç yöntem kullanıyoruz. Neden ZFS? Neden LVM kullanmadın? LVM ile ilgili sorunlar olduğundan bahsetmiştiniz. Sorunlar nelerdi? Bence performans açısından en uygun seçenek depolamadır.

ZFS ile ilgili temel sorun nedir? Aynı ana bilgisayarda çalışmanız gerektiği gerçeği, yani tüm örnekler aynı işletim sistemi içinde yaşayacaktır. Ve depolama durumunda, farklı ekipmanları bağlayabilirsiniz. Ve darboğaz, yalnızca depolama sistemindeki bloklardır. Ve teknolojilerin seçimi sorusu ilginç. Neden LVM değil?

Spesifik olarak, buluşmada LVM'yi tartışabiliriz. Depolama hakkında - sadece pahalı. ZFS sistemini her yerde uygulayabiliriz. Makinenizde dağıtabilirsiniz. Depoyu indirebilir ve konuşlandırabilirsiniz. Linux'tan bahsediyorsak, ZFS hemen hemen her yerde kuruludur. Yani çok esnek bir çözüm elde ediyoruz. Ve kutunun dışında, ZFS çok şey verir. İstediğiniz kadar veri yükleyebilirsiniz, çok sayıda disk bağlayabilirsiniz, anlık görüntüler vardır. Ve dediğim gibi, yönetimi kolaydır. Yani kullanımı çok hoş görünüyor. Test edildi, çok yaşında. Büyüyen çok büyük bir topluluğu var. ZFS çok güvenilir bir çözümdür.

Nikolai Samokhvalov: Daha fazla yorum yapabilir miyim? Benim adım Nikolay, Anatoly ile birlikte çalışıyoruz. Depolamanın harika olduğuna katılıyorum. Ve bazı müşterilerimizde Saf Depolama vb.

Anatoly, modülerliğe odaklandığımızı doğru bir şekilde kaydetti. Ve gelecekte, bir arayüz uygulayabilirsiniz - anlık görüntü alın, bir klon yapın, klonu yok edin. Hepsi kolay. Ve eğer öyleyse, depolama iyidir.

Ancak ZFS herkes tarafından kullanılabilir. DelPhix zaten yeterli, 300 müşterisi var. Bunlardan, servet 100'ün 50 müşterisi var, yani NASA'yı hedefliyorlar vb. Herkesin bu teknolojiye sahip olma zamanı. İşte bu yüzden açık kaynaklı bir Çekirdeğimiz var. Açık kaynak olmayan bir arayüz parçamız var. Bu, göstereceğimiz platform. Ama herkesin erişebilmesini istiyoruz. Tüm test uzmanlarının dizüstü bilgisayarlarda tahmin yürütmeyi bırakması için bir devrim yapmak istiyoruz. SELECT yazıp yavaş olduğunu hemen görmemiz gerekiyor. DBA'nın size bundan bahsetmesini beklemeyi bırakın. İşte ana hedef. Ve sanırım hepimiz buna geleceğiz. Ve bu şeyi herkesin sahip olması için yapıyoruz. Bu nedenle ZFS, çünkü her yerde mevcut olacak. Sorunları çözdüğü ve açık kaynak lisansına sahip olduğu vb. için topluluğa teşekkür ederiz.*

Selamlar! Rapor için teşekkürler! Benim adım Maksim. Aynı konuları ele aldık. Kendi başlarına karar verdiler. Kaynakları bu klonlar arasında nasıl paylaşırsınız? Her klon, herhangi bir zamanda kendi işini yapabilir: biri bir şeyi test eder, diğeri başka bir şey, biri bir dizin oluşturur, birinin ağır bir işi vardır. Ve yine de CPU'ya ve ardından IO'ya bölebiliyorsanız, nasıl bölersiniz? Bu ilk soru.

İkinci soru ise tribünlerin farklılığı ile ilgili. Diyelim ki burada ZFS'm var ve her şey yolunda, ancak ürün üzerindeki istemcide ZFS yok, örneğin ext4 var. Bu durumda nasıl?

Sorular çok iyi. Kaynakları paylaştığımız gerçeğiyle bu sorundan biraz bahsetmiştim. Ve çözüm şudur. Sahneleme üzerinde test yaptığınızı hayal edin. Aynı anda öyle bir durum da yaşayabilirsiniz ki biri bir yük verir, bir başkası. Ve sonuç olarak, anlaşılmaz ölçümler görürsünüz. Hatta aynı sorun prod ile olabilir. Bir isteği kontrol etmek ve onunla ilgili bir sorun olduğunu görmek istediğinizde - yavaş çalışır, o zaman aslında sorun istekte değil, bir tür paralel yük olması gerçeğindedir.

Dolayısıyla burada planın ne olacağı, planda hangi adımları atacağımız ve bunun için ne kadar veri toplayacağımıza odaklanmak önemli. Örneğin disklerimizin bir şeyle yüklenecek olması, özellikle zamanlamayı etkileyecektir. Ancak bu talebin ne kadar yüklü olduğunu veri miktarı ile tahmin edebiliriz. Aynı zamanda bir tür infaz olacak kadar önemli değil.

İki sorum var. Bu çok havalı bir şey. Kredi kartı numaraları gibi üretim verilerinin kritik olduğu durumlar oldu mu? Zaten hazır bir şey var mı yoksa ayrı bir görev mi? Ve ikinci soru - MySQL için böyle bir şey var mı?

Veriler hakkında. Yapana kadar şaşırtmaca yapacağız. Ancak tam olarak Joe'yu dağıtırsanız, geliştiricilere erişim vermezseniz, verilere erişim olmaz. Neden? Çünkü Joe verileri göstermiyor. Yalnızca ölçümleri, planları gösterir ve o kadar. Bu bilerek yapılmıştır, çünkü bu müşterimizin gereksinimlerinden biridir. Herkese erişim izni vermeden optimizasyon yapabilmek istediler.

MySQL hakkında. Bu sistem, durumu diskte depolayan her şey için kullanılabilir. Ve Postgres yaptığımız için, artık her şeyden önce Postgres için tüm otomasyonu yapıyoruz. Bir yedekten veri almayı otomatikleştirmek istiyoruz. Postgres'i doğru şekilde yapılandırıyoruz. Planları nasıl eşleştireceğimizi vb. biliyoruz.

Ancak sistem genişletilebilir olduğu için MySQL için de kullanılabilir. Ve böyle örnekler var. Yandex'de de benzer bir şey var ama hiçbir yerde yayınlamıyorlar. Yandex.Metrica'da kullanıyorlar. Ve sadece MySQL hakkında bir hikaye var. Ancak teknolojiler aynı, ZFS.

Rapor için teşekkürler! Ayrıca bir iki sorum var. Klonlamanın analitik için, örneğin orada ek dizinler oluşturmak için kullanılabileceğini söylediniz. Nasıl çalıştığı hakkında biraz daha bilgi verebilir misiniz?

Ben de hemen tribünlerin benzerliği, planların benzerliği ile ilgili ikinci soruyu soracağım. Plan ayrıca Postgres tarafından toplanan istatistiklere de bağlıdır. Bu sorunu nasıl çözersiniz?

Analitiklere göre belirli bir durum yok çünkü henüz kullanmadık ama böyle bir fırsat var. Dizinlerden bahsediyorsak, bir sorgunun yüz milyonlarca kayıt içeren bir tabloyu ve genellikle üretimde dizine eklenmemiş bir sütunu takip ettiğini hayal edin. Ve orada bazı verileri hesaplamak istiyoruz. Bu istek prod'a gönderilirse, o zaman prod'da basit olma olasılığı vardır, çünkü istek orada bir dakikalığına işlenecektir.

Tamam, birkaç dakika durması korkunç olmayan ince bir klon yapalım. Analitiği okumayı daha rahat hale getirmek için, verilerle ilgilendiğimiz sütunlara endeksler ekleyeceğiz.

Dizin her seferinde oluşturulacak mı?

Verilere dokunmamızı, anlık görüntüler oluşturmamızı sağlayabilirsiniz, ardından bu anlık görüntüden kurtarır ve yeni istekler yönlendiririz. Yani, önceden eklenmiş indekslerle yeni klonlar oluşturabilmeniz için bunu yapabilirsiniz.

İstatistik sorusuna gelince, eğer bir yedekten geri yüklersek, replikasyon yaparsak, istatistiklerimiz tamamen aynı olacaktır. Çünkü tüm fiziksel veri yapısına sahibiz, yani tüm istatistik metriklerle de verileri olduğu gibi getireceğiz.

İşte başka bir sorun. Bir bulut çözümü kullanıyorsanız, orada yalnızca mantıksal dökümler mevcuttur, çünkü Google, Amazon fiziksel bir kopya almanıza izin vermez. Bir sorun olacak.

Rapor için teşekkürler. Burada MySQL ve kaynak paylaşımı hakkında iki güzel soru vardı. Ancak, aslında, her şey bunun belirli bir DBMS konusu değil, bir bütün olarak dosya sistemi olduğu gerçeğine bağlı. Ve buna göre, kaynak paylaşımı sorunları da oradan çözülmelidir, sonunda Postgres değil, örneğin dosya sisteminde, sunucuda.

Benim sorum biraz farklı. Birkaç katmanın bulunduğu çok katmanlı veritabanına daha yakındır. Örneğin on terabaytlık bir imaj güncellemesi kuruyoruz, replikasyon yapıyoruz. Ve bu çözümü özellikle veritabanları için kullanıyoruz. Çoğaltma devam ediyor, veriler güncelleniyor. Sürekli olarak bu farklı çekimleri başlatan paralel çalışan 100 çalışan var. Ne yapalım? Çakışma olmadığından, bir tane başlattıklarından ve ardından dosya sisteminin değiştiğinden ve tüm bu resimlerin gittiğinden nasıl emin olunur?

Gitmeyecekler çünkü ZFS böyle çalışıyor. Çoğaltma nedeniyle gelen dosya sistemi değişikliklerini tek bir iş parçacığında ayrı ayrı tutabiliriz. Geliştiricilerin kullandığı klonları verilerin eski sürümlerinde saklayın. Ve bizim için çalışıyor, her şey buna uygun.

Görünüşe göre güncelleme ek bir katman olarak gerçekleşecek ve tüm yeni resimler zaten bu katmana göre gidecek, değil mi?

Önceki çoğaltmalardan olan önceki katmanlardan.

Önceki katmanlar düşecek, ancak eski katmana atıfta bulunacaklar ve güncellemede alınan son katmandan yeni görüntüler mi alacaklar?

Genel olarak evet.

O zaman sonuç olarak bir incir katmanına sahip olacağız. Ve zamanla sıkıştırılmaları gerekecek mi?

Evet her şey doğru. Biraz pencere var. Haftalık anlık görüntüler tutuyoruz. Hangi kaynağa sahip olduğunuza bağlıdır. Çok fazla veri saklama yeteneğiniz varsa, anlık görüntüleri uzun süre saklayabilirsiniz. Kendi başlarına gitmeyecekler. Veri bozulması olmayacak. Anlık görüntüler bize göründüğü gibi eskiyse, yani şirketteki politikaya bağlıdır, o zaman onları silip yer açabiliriz.

Merhaba, rapor için teşekkürler! Joe hakkında soru. Müşterinin herkese verilere erişim izni vermek istemediğini söylediniz. Açıkça söylemek gerekirse, bir kişi Açıklama Analizi sonucuna sahipse, verileri gözetleyebilir.

O gibi. Örneğin şunu yazabiliriz: "NEREYDEN e-posta = buna". Yani verinin kendisini görmeyeceğiz ama bazı dolaylı işaretler görebiliriz. Bu anlaşılmalıdır. Ama öte yandan, hepsi orada. Bir günlük denetimimiz var, geliştiricilerin ne yaptığını da gören diğer meslektaşlarımız üzerinde kontrolümüz var. Ve birisi bunu yapmaya çalışırsa, güvenlik servisi onlara gelecek ve bu konuda çalışacaktır.

Tünaydın Rapor için teşekkürler! Kısa bir sorum var. Şirket Slack kullanmıyorsa, şu anda herhangi bir bağlayıcılığı var mı veya geliştiricilerin bir test uygulamasını veritabanlarına bağlamak için örnekleri dağıtması mümkün mü?

Şimdi Slack'e bir bağlantı var, yani başka bir haberci yok, ama gerçekten diğer haberciler için de destek yapmak istiyorum. Ne yapabilirsin? DB Lab'i Joe olmadan dağıtabilir, REST API'nin yardımıyla veya platformumuzu kullanarak gidebilir ve klonlar oluşturabilir ve PSQL ile bağlanabilirsiniz. Ancak, geliştiricilerinize verilere erişim vermeye hazırsanız bu yapılabilir, çünkü artık herhangi bir ekran olmayacaktır.

Bu katmana ihtiyacım yok ama böyle bir fırsata ihtiyacım var.

O zaman evet, yapılabilir.

Kaynak: habr.com