Uzak gelecekte bir gün, gereksiz verilerin otomatik olarak kaldırılması, bir DBMS'nin önemli görevlerinden biri olacaktır [1]. Bu arada, gereksiz verileri silme veya daha ucuz depolama sistemlerine taşıma işini bizim de halletmemiz gerekiyor. Diyelim ki birkaç milyon satırı silmeye karar verdiniz. Oldukça basit bir görev, özellikle de durum biliniyorsa ve uygun bir indeks varsa. "Tablo1'DEN DELETE FROM WHERE col1 = :value" - daha basit ne olabilir, değil mi?
Video:
-
İlk yıldan beri, yani 2007'den beri Highload program komitesinde yer alıyorum.
-
2005'ten beri Postgres'teyim. Birçok projede kullandık.
-
Grup ayrıca 2007'den beri RuPostges'la birlikte.
-
Meetup'ta 2100'den fazla katılımcıya ulaştık. Burası uzun zaman önce San Francisco'yu geride bırakan New York'tan sonra dünyada ikinci sırada yer alıyor.
-
Birkaç yıldır Kaliforniya'da yaşıyorum. Büyük olanlar da dahil olmak üzere çoğunlukla Amerikan şirketleriyle çalışıyorum. Aktif Postgres kullanıcılarıdırlar. Ve orada her türlü ilginç şey ortaya çıkıyor.
– burası benim şirketim. Geliştirme yavaşlamalarını ortadan kaldıran görevleri otomatikleştirme işindeyiz.
Bir şey yaparsanız bazen Postgres'te bazı aksaklıklar olabilir. Diyelim ki yönetici size bir test tezgahı verene kadar beklemeniz gerekiyor veya DBA size yanıt verene kadar beklemeniz gerekiyor. Bu tür darboğazları geliştirme, test etme ve yönetim süreçlerinde buluyoruz ve otomasyon ve yeni yaklaşımlar kullanarak bunları ortadan kaldırmaya çalışıyoruz.
Geçenlerde Los Angeles'ta VLDB'deydim. Bu en büyük veritabanı konferansıdır. Ve gelecekte DBMS'lerin verileri yalnızca depolamakla kalmayıp aynı zamanda otomatik olarak sileceği yönünde bir rapor vardı. Bu yeni bir konudur.
Dünyada giderek daha fazla veri var. Zetabaytlar 1 petabayttır. Ve şimdi dünyada 000 zettabayttan fazla verinin depolandığı tahmin ediliyor. Ve giderek daha fazlası var.
Peki bununla ne yapmalı? Silinmesi gerektiği açıktır. İşte bu ilginç raporun bağlantısı. Ancak şu ana kadar bu DBMS'de uygulanmadı.
Para saymayı bilenler iki şey isterler. Silmemizi istiyorlar, yani teknik olarak bunu yapabilmemiz gerekiyor.
Bundan sonra anlatacağım şey, bir dizi gerçek durumu içeren soyut bir durumdur, yani benim ve etrafımdaki veritabanlarının başına defalarca, uzun yıllar gerçekte olanların belirli bir derlemesidir. Tırmıklar her yerdedir ve herkes her zaman üzerlerine basar.
Diyelim ki bir tabanımız var ya da büyüyen birkaç üssümüz var. Ve bazı kayıtların bariz bir şekilde çöp olduğu ortada. Örneğin kullanıcı orada bir şeyler yapmaya başladı ama bitirmedi. Ve bir süre sonra bu tamamlanmamış işin artık saklanamayacağını anlıyoruz. Yani, yerden tasarruf etmek, performansı artırmak vb. için bazı gereksiz şeyleri temizlemek istiyoruz.
Genel olarak görev, bir tablodaki belirli şeylerin, belirli satırların silinmesini otomatikleştirmektir.
Bir de bugün konuşacağımız bir talebimiz var yani çöplerin kaldırılmasıyla ilgili.
Deneyimli bir geliştiriciden bunu yapmasını istedik. Bu isteği aldı, kendisi kontrol etti - her şey çalışıyor. Aşamada test ettim - her şey yolunda. Dışarı çıktı - her şey çalışıyor. Bunu günde bir kez çalıştırıyoruz - her şey yolunda.
Veritabanı büyüyor ve büyüyor. Günlük DELETE biraz daha yavaş çalışmaya başlar.
Daha sonra artık bir pazarlama şirketi olduğumuzu ve trafiğin birkaç kat daha fazla olacağını anlıyoruz ve gereksiz şeyleri geçici olarak duraklatmaya karar veriyoruz. Ve onu iade etmeyi unutuyoruz.
Birkaç ay sonra hatırladılar. Ve o geliştirici işi bıraktı ya da başka bir şeyle meşguldü, onu iade etmesi için başkasını görevlendirdiler.
Geliştirmeyi ve aşamalandırmayı kontrol etti - her şey yolunda. Doğal olarak birikenleri de temizlemeniz gerekiyor. Kontrol etti, her şey çalışıyor.
Sonra ne olur? O zaman bizim için her şey mahvolur. O kadar düşüyor ki bir noktada her şey yıkılıyor. Herkes şokta, kimse ne olduğunu anlamıyor. Ve sonra sorunun bu DELETE olduğu ortaya çıktı.
Bir şeyler yanlış gitti? İşte yanlış gidebilecek şeylerin bir listesi. Bunlardan hangisi en önemlisidir?
-
Mesela inceleme yapılmadı, yani DBA uzmanı bakmadı. Deneyimli bir gözle sorunu hemen bulur ve ayrıca birkaç milyon satırın biriktiği prod'a da erişebilir.
-
Belki yanlış bir şeyi kontrol ettiler.
-
Belki donanım güncel değildir ve bu veritabanını yükseltmeniz gerekebilir.
-
Veya veritabanının kendisinde bir sorun var ve Postgres'ten MySQL'e geçmemiz gerekiyor.
-
Ya da belki operasyonda bir sorun var.
-
Belki işin organizasyonunda bazı hatalar var ve birini kovmanız ve daha iyi insanları işe almanız gerekiyor?
DBA kontrolü yoktu. Eğer bir DBA olsaydı, bu birkaç milyon satırı görürdü ve hiçbir deney yapmadan bile şöyle derdi: “Bunu yapmıyorlar.” Diyelim ki bu kod GitLab'da, GitHub'da olsaydı ve kod inceleme süreci olsaydı ve DBA onayı olmadan bu işlem prod üzerinde gerçekleşecek diye bir şey olmasaydı, o zaman DBA açıkçası şöyle derdi: “Bunu yapamazsınız. ”
Ve disk IO ile ilgili sorun yaşayacağınızı ve tüm süreçlerin çılgına döneceğini, kilitlenmeler olabileceğini ve ayrıca otovakumun birkaç dakika boyunca bloke edileceğini, yani bunun iyi olmadığını söylerdi.
İkinci hata ise yanlış yere kontrol etmeleridir. Prod'da çok fazla çöp verinin biriktiğini, ancak geliştiricinin bu veritabanında veri biriktirmediğini ve hiç kimsenin bu çöpü hazırlama sırasında gerçekten yaratmadığını gördük. Buna göre 1 hat vardı ve bunlar hızla tamamlandı.
Testlerimizin zayıf olduğunu, yani oluşturulan sürecin sorun yakalamadığını anlıyoruz. Yeterli bir DB deneyi yapılmadı.
İdeal bir deney tercihen aynı ekipman üzerinde yapılmalıdır. Bunu aynı donanım üzerinde yapmak her zaman mümkün olmayabilir ancak veritabanının tam boyutlu bir kopyası olması çok önemlidir. Birkaç yıldır vaaz ettiğim şey bu. Ve bir yıl önce bundan bahsetmiştim, hepsini YouTube'da izleyebilirsiniz.
Belki ekipmanımız kötüdür? Bakarsanız gecikmenin sıçradığını görürsünüz. Geri dönüşümün %100 olduğunu gördük. Elbette bunlar modern NVMe sürücüleri olsaydı bizim için muhtemelen çok daha kolay olurdu. Ve belki de bu yüzden uzanmayız.
Bulutlarınız varsa yükseltme kolaydır. Yeni donanımda yeni kopyalar başlattık. Değiştir. Ve her şey yolunda. Çok kolay.
Bir şekilde daha küçük disklere dokunmak mümkün mü? Ve burada DBA'nın yardımıyla kontrol noktası ayarlama adı verilen belirli bir konuya dalıyoruz. Kontrol noktası ayarlaması yapmadığımız ortaya çıktı.
Kontrol noktası nedir? Bu herhangi bir DBMS'de mevcuttur. Belleğinizdeki veriler değiştiğinde disklere hemen yazılmaz. Verilerin değiştiği bilgisi ilk önce yazma öncesi günlüğündeki ileri günlüğüne yazılır. Ve bir noktada DBMS, gerçek sayfaları diske atma zamanının geldiğine karar verir, böylece bir hatayla karşılaşırsak daha az REDO yapabiliriz. Bir oyuncak gibi. Öldürülürsek oyuna son kontrol noktasından başlayacağız. Ve tüm DBMS bunu uygular.
Postgres'teki ayarlar gecikiyor. 10-15 yıllık veri ve operasyon hacimleri için tasarlanmıştır. Ve kontrol noktası bir istisna değildir.
Bu bilgi Postgres check-up yani otomatik sağlık kontrolü olan raporumuzdan alınmıştır. Ve işte birkaç terabaytlık bir veritabanı. Ve vakaların neredeyse %90'ında kontrol noktalarının zorlandığı açıktır.
Bu ne anlama geliyor? Orada iki ayar var. Denetim noktası zaman aşımında, örneğin 10 dakika içinde gerçekleşebilir. Veya oldukça fazla veri doldurulduğunda ortaya çıkabilir.
Ve varsayılan olarak max_wal_saze 1 gigabayt olarak ayarlanmıştır. Aslında Postgres'te bu durum aslında 300-400 megabayttan sonra oluyor. Çok fazla veriyi değiştirdiniz ve bir kontrol noktanız var.
Ve eğer kimse onu ayarlamadıysa, ancak hizmet büyüdüyse ve şirket çok para kazanıyorsa, çok fazla işlem varsa, o zaman kontrol noktası dakikada bir, bazen her 30 saniyede bir gerçekleşir ve hatta bazen birbirleriyle örtüşürler. . Bu gerçekten kötü.
Ve bunun daha az sıklıkla geldiğinden emin olmalıyız. Yani max_wal_size değerini yükseltebiliriz. Ve daha az sıklıkla saldıracak.
Ancak bunun nasıl daha doğru bir şekilde yapılacağına, yani ayarların seçimine ilişkin kararların açıkça belirli verilere dayanarak nasıl alınacağına dair bütün bir metodoloji geliştirdik.
Buna göre iki dizi veri tabanı deneyi gerçekleştiriyoruz.
İlk seri - max_wal_size'yi değiştiriyoruz. Ve çok büyük bir operasyon gerçekleştiriyoruz. İlk önce bunu 1 gigabyte varsayılan ayarında yapıyoruz. Ve milyonlarca satırdan oluşan devasa bir SİLME işlemi gerçekleştiriyoruz.
Bizim için ne kadar zor olduğunu görüyorsunuz. Disk IO'nun çok kötü olduğunu görüyoruz. Bakalım ne kadar WAL ürettik, çünkü bu çok önemli. Bakalım kontrol noktası kaç kez yaşandı. Ve bunun iyi olmadığını görüyoruz.
Daha sonra max_wal_size'ı arttırıyoruz. Tekrar ediyoruz. Artırın, tekrarlayın. Ve pek çok kez. Prensip olarak 10, 1, 2, 4 gigabayt olmak üzere 8 puan iyidir. Ve belirli bir sistemin davranışına bakıyoruz. Buradaki ekipmanın üründeki gibi olması gerektiği açıktır. Aynı disklere, aynı miktarda belleğe ve aynı Postgres ayarlarına sahip olmalısınız.
Ve bu şekilde sistemimizi değiştireceğiz ve kötü bir kitle SİLME durumunda DBMS'nin nasıl davranacağını, nasıl kontrol noktası olacağını biliyoruz.
Kontrol noktası Rusça'da kontrol noktaları anlamına gelir.
Örnek: Birkaç milyon satırı dizine göre SİLİN, satırlar sayfalar arasında "dağılmıştır".
İşte bir örnek. Bu bir miktar temeldir. Ve max_wal_size için varsayılan 1 gigabayt ayarıyla, kayıt disklerimizin rafa gideceği çok açıktır. Bu resim çok hasta bir hastanın tipik bir belirtisidir, yani kendini gerçekten kötü hissetmiştir. Ve sadece tek bir işlem vardı, burada sadece birkaç milyon satırın SİLİNMESİ vardı.
Dürtüde böyle bir işleme izin verilirse, o zaman düşeceğiz, çünkü bir SİLME'nin bizi rafta öldüreceği açık.
Ayrıca 16 gigabaytın olduğu yerde dişlerin çoktan çıkmaya başladığını görebilirsiniz. Dişler zaten daha iyi, yani tavana vuruyoruz ama o kadar da kötü değil. Orada biraz özgürlük ortaya çıktı. Sağda kayıt var. Ve işlem sayısı ikinci grafiktir. Ve 16 gigabaytla şimdiden biraz daha rahat nefes aldığımız açık.
Ve 64 gigabaytın görülebildiği yer tamamen daha iyi hale geldi. Zaten dişler açıkça görülebiliyor, diğer operasyonlardan sağ çıkmak ve diskle bir şeyler yapmak için daha fazla fırsat var.
Neden ki?
Biraz ayrıntılara ineceğim ama kontrol noktası ayarının nasıl yapılacağına dair bu konu bütün bir raporla sonuçlanabilir, bu yüzden çok fazla ayrıntıya girmeyeceğim, ancak ne tür zorluklar olduğunu biraz özetleyeceğim.
Kontrol noktası çok sık oluyorsa ve satırlarımızı sırayla güncellemiyorsak, ancak bunları dizine göre buluyorsak, bu iyidir, çünkü tablonun tamamını silmiyoruz, o zaman önce ilk sayfaya, sonra bininci sayfaya dokunmuş olabiliriz. ve sonra ilkine geri döndüm. Ve eğer ilk sayfaya yapılan bu ziyaretler arasında kontrol noktası onu zaten diske kaydetmişse, onu ikinci kez kirlettiğimiz için tekrar kaydedecektir.
Ve kontrol noktasını birçok kez kaydetmeye zorlayacağız. Sanki bunun için gereksiz işlemler varmış gibi.
Ama hepsi bu değil. Postgres'te sayfaların ağırlığı 8 kilobayt, Linux'ta ise 4 kilobayttır. Ve full_page_writes ayarı var. Varsayılan olarak etkindir. Ve bu doğrudur, çünkü kapatırsak, bir arıza durumunda sayfanın yalnızca yarısının kaydedilme tehlikesi vardır.
İletme günlüğünün WAL'indeki girişin davranışı öyledir ki, bir kontrol noktamız olduğunda ve bir sayfayı ilk kez değiştirdiğimizde, sayfanın tamamı, yani 8 kilobaytın tümü, yalnızca biz değiştirmemize rağmen, ileri günlüğünde sona erer. 100 bayt ağırlığındaki bir satırı değiştirdi. Ve tüm sayfayı yazmak zorunda kalıyoruz.
Sonraki değişikliklerde yalnızca belirli bir demet olacak, ancak ilk defa her şeyi yazıyoruz.
Ve buna göre, kontrol noktası tekrar olursa, her şeye yeniden sıfırdan başlamamız ve tüm sayfayı doldurmamız gerekir. Sık kontrol noktalarında, aynı sayfalarda dolaştığımızda full_page_writes = on değeri olabileceğinden daha büyük olacaktır, yani daha fazla WAL üreteceğiz. Daha fazlası kopyalara, arşive, diske gönderilir.
Ve buna göre iki işten çıkarmamız var.
max_wal_size değerini arttırırsak hem checkpoint'in hem de wal yazarının işini kolaylaştırdığımız ortaya çıkıyor. Ve bu harika.
Bir terabayt yükleyelim ve onunla yaşayalım. Bunun nesi kötü? Bu kötü, çünkü başarısızlık durumunda saatlerce kalkacağız çünkü kontrol noktası uzun zaman önceydi ve çok şey değişti. Ve tüm bunlar için REDO yapmamız gerekiyor. Ve böylece ikinci bir dizi deney yapıyoruz.
Operasyonu yapıyoruz ve kontrol noktasının tamamlanmaya yaklaştığını görüyoruz, bilerek -9 Postgres'i öldürüyoruz.
Ve bundan sonra tekrar başlatıyoruz ve bu ekipmanın yükselmesinin ne kadar süreceğini, yani bu kötü durumda ne kadar REDO yapacağını görüyoruz.
Durumun kötü olduğunu iki kez belirteceğim. Öncelikle kontrol noktası bitmeden düştük, dolayısıyla kaybedecek çok şeyimiz var. İkincisi ise büyük bir operasyon gerçekleştirdik. Ve eğer kontrol noktalarında zaman aşımı olsaydı, son kontrol noktasından bu yana büyük ihtimalle daha az WAL üretilmiş olurdu. Yani bu iki kez kaybedendir.
Bu durumu farklı max_wal_size için ölçüyoruz ve max_wal_size 64 gigabayt ise, o zaman iki kat en kötü durumda 10 dakika boyunca yükseleceğimizi anlıyoruz. Ve bunun bize yakışıp yakışmadığını düşünüyoruz. Bu bir iş meselesidir. Bu resmi iş kararlarından sorumlu olanlara gösterip şunu sormamız gerekiyor: “Bir sorun olması durumunda bekleyebileceğimiz maksimum süre ne kadardır? Daha kötü bir durumda 3-5 dakika uzanabilir miyiz?” Ve bir karar verirsin.
Ve burada ilginç bir nokta var. Konferansta Patroni ile ilgili birkaç raporumuz var. Ve belki de onu kullanıyorsun. Bu Postgres için otomatik yük devretmedir. GitLab ve Data Egret bundan bahsetti.
Ve eğer 30 saniye içinde gerçekleşecek bir otomatik yük devretme işleminiz varsa, o zaman belki 10 dakika uzanabiliriz? Çünkü bu noktada kopyaya geçeceğiz ve her şey yoluna girecek. Bu tartışmalı bir konudur. Net bir cevap bilmiyorum. Bu konunun sadece felaket kurtarma ile ilgili olmadığını düşünüyorum.
Bir başarısızlıktan sonra uzun süre toparlanırsak, diğer birçok durumda da rahatsız oluruz. Örneğin aynı deneylerde bir şey yaptığımızda bazen 10 dakika beklemek zorunda kalıyoruz.
Otomatik yük devretme olsa bile yine de fazla ileri gitmem. Kural olarak 64, 100 gigabayt gibi değerler iyi değerlerdir. Bazen daha azını seçmeye bile değer. Genel olarak bu ince bir bilimdir.
Örneğin max_wal_size = 1, 8 yinelemesi için toplu işlemi birçok kez tekrarlamanız gerekir. Sen yaptın. Ve bunu aynı temelde tekrar yapmak istiyorsunuz, ancak zaten her şeyi silmişsiniz. Ne yapalım?
Size daha sonra çözümümüzü ve bu gibi durumlarda yinelemek için ne yaptığımızı anlatacağım. Ve bu en doğru yaklaşımdır.
Ancak bu durumda şanslıydık. Burada yazdığı gibi “BEGIN, DELETE, ROLLBACK” ise SİL işlemini tekrarlayabiliriz. Yani kendimiz iptal edersek tekrarlayabiliriz. Ve fiziksel olarak verileriniz orada olacak. Hiç şişkinlik bile yapmıyorsun. Böyle bir DELETE işlemini yineleyebilirsiniz.
ROLLBACK ile yapılan bu DELETE, uygun şekilde konuşlandırılmış bir veritabanı laboratuvarınız olmasa bile kontrol noktası ayarlaması için idealdir.
Tek sütunlu “i” işareti yaptık. Postgres'in servis sütunları vardır. Özellikle istenmedikçe görünmezler. Bunlar: ctid, xmid, xmax.
Ctid fiziksel adrestir. Sayfa sıfır, sayfadaki ilk demet.
ROOLBACK sonrasında tuple'ın aynı yerde kaldığı görülmektedir. Yani tekrar deneyebiliriz, aynı şekilde davranacaktır. Ana şey bu.
Xmax, Tuple'ın ölüm zamanıdır. Girilir ancak Postgres bu işlemin geri alındığını bilir, bu nedenle 0 veya geri alınmış bir işlem olması fark etmez. Bu, DELETE'in sistem davranışının büyük işlemlerini yinelemek ve test etmek için kullanılabileceğini göstermektedir. Yoksullar için veritabanı laboratuvarları oluşturabilirsiniz.
Bu programcılarla ilgili. DBA konusunda da programcıları sürekli azarlıyorlar: “Neden bu kadar uzun ve zor işlemler yapıyorsunuz?” Bu tamamen farklı bir dikey konudur. Eskiden yönetim vardı ama şimdi kalkınma olacak.
Açıkçası onu parçalara ayırmadık. Apaçık. Milyonlarca satırlık böyle bir DELETE'i parçalara ayırmak imkansızdır. Yapılması 20 dakika sürecek ve her şey yatacak. Ancak maalesef deneyimli geliştiriciler bile çok büyük şirketlerde hata yapıyor.
Kırılmak neden önemlidir?
-
Diskin sert olduğunu görürsek onu yavaşlatalım. Ve eğer bozulursak, duraklamalar ekleyebiliriz, kısılmayı yavaşlatabiliriz.
-
Ve başkalarını uzun süre engellemeyeceğiz. Bazı durumlarda bunun önemi yoktur, eğer kimsenin üzerinde çalışmadığı gerçek çöpleri kaldırıyorsanız, o zaman büyük olasılıkla autovacuum'un çalışması dışında kimseyi engellemezsiniz çünkü o, işlemin tamamlanmasını bekleyecektir. Ancak başka birinin isteyebileceği bir şeyi silerseniz o kişi engellenir, bir tür zincirleme reaksiyon meydana gelir. Web siteleri ve mobil uygulamalarda uzun işlemlerden kaçınılmalıdır.
Bu ilginç. Geliştiricilerin sıklıkla "Hangi paket boyutunu seçmeliyim?" sorusunu sorduğunu görüyorum.
Parti büyüklüğü ne kadar büyük olursa işlem yükünün, yani ek işlem yükünün o kadar düşük olacağı açıktır. Ancak aynı zamanda bu işlemin süresi de artıyor.
Çok basit bir kuralım var: Mümkün olduğu kadar çok alın, ancak saniye başına yürütmeyi aşmayın.
Neden bir saniye? Açıklama çok basit ve herkes için, hatta teknik bilgisi olmayanlar için bile anlaşılabilir. Tepkiyi görüyoruz. 50 milisaniyeyi alalım. Bir şeyler değiştiyse gözümüz tepki verecektir. Daha az olursa daha zor olur. Bir şey 100 milisaniye sonra yanıt veriyorsa, örneğin fareye tıkladıysanız ve o da 100 milisaniye sonra yanıt veriyorsa, bu hafif gecikmeyi zaten hissediyorsunuz. Bir saniye zaten bir fren olarak algılanıyor.
Buna göre toplu operasyonlarımızı 10 saniyelik patlamalara bölersek birilerini engelleme riskiyle karşı karşıya kalırız. Ve birkaç saniyeliğine çalışacak ve insanlar bunu zaten fark edecekler. Bu yüzden bunu bir saniyeden fazla yapmamayı tercih ediyorum. Ancak aynı zamanda çok küçük parçalara ayırmayın çünkü işlem yükü fark edilebilir olacaktır. Taban için daha ağır olacak ve başka çeşitli sorunlar ortaya çıkabilecektir.
Paket boyutunu seçiyoruz. Her durumda bunu farklı şekilde yapabiliriz. Otomatikleştirilebilir. Ve tek bir paketin işlenmesinin verimliliğine inanıyoruz. Yani bir paketi SİLİYORUZ veya GÜNCELLİYORUZ.
Bu arada sana anlatacağım her şey sadece SİL ile ilgili değil. Tahmin ettiğiniz gibi bunlar veriler üzerinde yapılan toplu işlemlerdir.
Ve planın mükemmel olduğunu görüyoruz. Dizin taramasını, hatta daha iyi yalnızca dizin taramasını görebilirsiniz. Ve elimizde az miktarda veri var. Ve her şey bir saniyeden daha kısa sürede çalışır. Süper.
Ve yine de herhangi bir bozulma olmadığından emin olmamız gerekiyor. İlk partiler hızla hallediliyor ve sonra her şey daha da kötüye gidiyor, daha da kötüleşiyor. Süreç öyle ki, çok fazla test yapmanız gerekiyor. Veritabanı laboratuvarlarına tam olarak bunun için ihtiyaç duyulmaktadır.
Ve yine de üretimde bunu doğru bir şekilde takip etmemizi sağlayacak bir şeyler hazırlamamız gerekiyor. Örneğin loga saati yazabiliriz, şu anda nerede olduğumuzu ve kimi sildiğimizi yazabiliriz. Bu da daha sonra neler olduğunu anlamamızı sağlayacak. Ve bir şeyler ters giderse sorunu hızla bulun.
Sorguların verimliliğini kontrol etmemiz gerekiyorsa ve birçok kez yinelememiz gerekiyorsa, o zaman kardeş bot diye bir şey var. O zaten hazır. Her gün onlarca geliştirici tarafından kullanılmaktadır. Ve talep üzerine devasa bir terabaytlık veritabanını, kendi kopyanızı 30 saniyede sağlayabilir. Ve orada bir şeyi silip RESET diyip tekrar silebilirsiniz. Bunu bu şekilde deneyebilirsiniz. Bu işte bir gelecek görüyorum. Ve bunu zaten yapıyoruz.
Bölümlendirme stratejileri nelerdir? Geliştiricilerin pakette kullandığı 3 farklı bölümleme stratejisi görüyorum.
İlki çok basit. Sayısal bir kimliğimiz var. Hadi bunu farklı aralıklara bölelim ve bununla çalışalım. Dezavantajı açıktır. İlk segmentte 100 satır gerçek çöp olabilir, ikinci 5 satırda hiç olmayabilir veya 1 satırın tamamı çöp olabilir. Çok düzensiz bir çalışma, ancak kırılması kolay. Maksimum kimliği alıp parçaladılar. Bu naif bir yaklaşımdır.
İkinci strateji dengeli bir yaklaşımdır. Gitlab'da kullanılır. Masayı alıp taradık. Kimlik paketlerinin sınırlarını, her pakette tam olarak 10 kayıt bulunacak şekilde bulduk. Ve beni bir çeşit kuyruğa soktular. Ve daha da işliyoruz. Bunu birkaç başlıkta yapabilirsiniz.
Bu arada, ilk stratejide bunu birkaç başlıkta da yapabilirsiniz. Zor değil.
Ancak daha havalı ve daha optimal bir yaklaşım var. Bu üçüncü stratejidir. Ve mümkün olduğunda onu seçmek daha iyidir. Bunu özel bir indekse dayanarak yapıyoruz. Bu durumda büyük ihtimalle çöp durumumuza ve kimliğimize dayalı bir indeks olacaktır. Yığına gitmememiz için yalnızca dizin taraması olacak şekilde kimliği ekleyeceğiz.
Genellikle yalnızca dizin taraması, dizin taramasından daha hızlıdır.
Ve silmek istediğimiz kimliklerimizi hızla buluyoruz. BATCH_SIZE'ı önceden seçiyoruz. Ve biz onları sadece almakla kalmıyoruz, onları özel bir şekilde alıyoruz ve hemen düzeltiyoruz. Ama onları öyle bir şekilde kilitliyoruz ki, eğer zaten kilitliyse, kilitlemeyiz, devam edip sonrakilere geçeriz. Bu, güncelleme atlamanın kilitli olması içindir. Bu Postgres süper özelliği, istersek birden fazla iş parçacığında çalışmamıza olanak tanır. Muhtemelen tek bir iş parçacığında. Ve sonra CTE var - bu bir istek. Ve bu CTE'nin ikinci katında gerçek bir taşınma olayı yaşanıyor - returning *. Kimliği iade edebilirsin, ama daha iyi *, her satırda çok az veriniz varsa.
buna neden ihtiyacımız var? Raporlama için buna ihtiyacımız var. Aslında artık o kadar çok satırı sildik ki. ID'ye veya created_at'e göre sınırlarımız da bu şekilde. Min, max yapabilirsiniz. Başka bir şey yapılabilir. Buraya sığdırabileceğin çok şey var. Ve bu izleme için çok uygundur.
Endeksle ilgili bir not daha var. Bu özel görev için özel bir dizine ihtiyacımız olduğuna karar verirsek, bunun yalnızca yığın güncellemelerini bozmadığından emin olmamız gerekir. Yani Postgres'in böyle istatistikleri var. Bu, tablonuz için pg_stat_user_tables'da görülebilir. Sıcak güncellemelerin kullanılıp kullanılmadığını görebilirsiniz.
Yeni dizininizin onları kolayca kesebileceği durumlar vardır. Zaten çalışmakta olan diğer tüm güncellemeler de yavaşlayacaktır. Sadece indeks göründüğü için değil (her indeks güncellemeleri biraz yavaşlatır, ama sadece biraz), ama burada yine de işleri karıştıracaktır. Ve bu tabloya özel optimizasyon yapmak mümkün değil. Bu bazen olur. Bu çok az kişinin hatırladığı bir inceliktir. Ve bu tırmığa basmak çok kolay. Bazen diğer taraftan bir yaklaşım bulmanız gerekebilir ve yine de bu yeni indeks olmadan da yapabilirsiniz, veya başka bir indeks oluşturabilirsiniz veya başka bir şey yapabilirsiniz, örneğin ikinci yöntemi kullanabilirsiniz.
Ancak bu, gruplara nasıl bölüneceği ve tek bir istekle gruplar halinde nasıl çekileceği, her seferinde biraz silineceği vb. için en uygun stratejidir.
Uzun işlemler -
Bloke edilmiş otovakum
Engelleme sorunu
Hata #5 büyük bir hatadır. Okmeter'den Nikolay Postgres takibinden bahsetti. Ne yazık ki mükemmel Postgres izleme mevcut değil. Kimisi daha yakın, kimisi daha uzak. Okmeter mükemmel olmaya yeterince yakın ama eksik ve eklenmesi gereken çok şey var. Bunun için hazırlıklı olmanız gerekir.
Örneğin ölü tuple'ları izlemek daha iyidir. Masanızda çok fazla ölü şey varsa, o zaman bir şeyler ters gidiyor demektir. Şimdi tepki vermek daha iyi, yoksa orada bozulma olabilir, biz de yatabiliriz. Olur.
Büyük bir IO varsa, bunun iyi olmadığı açıktır.
Uzun işlemler de var. OLTP'de uzun işlemlere izin verilmemelidir. Ve işte bu snippet'i almanıza ve zaten uzun işlemlerin bir kısmını izlemenize olanak tanıyan snippet'e bir bağlantı.
Uzun işlemler neden kötüdür? Çünkü tüm kilitler ancak sonunda açılacaktır. Ve herkesi kilitliyoruz. Ayrıca tüm masalar için otomatik vakumlamayı engelliyoruz. Bu hiç de iyi değil. Kopyada çalışırken beklemeyi etkinleştirmiş olsanız bile bu yine de kötüdür. Genel olarak herhangi bir yerde uzun işlemlerden kaçınmak daha iyidir.
Eğer süpürülmemiş çok sayıda masamız varsa uyarı almamız gerekir. Burada böyle bir durum mümkün. Otovakumun çalışmasını dolaylı olarak etkileyebiliriz. Bu Avito'dan biraz geliştirdiğim bir pasaj. Ve otovakumla ilgili elimizde ne olduğunu görmek için ilginç bir araç olduğu ortaya çıktı. Mesela orada bekleyen masalar var ve sıralarını beklemiyorlar. Ayrıca izlemeye almanız ve bir uyarı almanız gerekir.
Ve bloklar çıkarır. Ağaçların engellendiği orman. Birinden bir şey alıp onu geliştirmeyi seviyorum. Burada Data Egret'ten kilitlenen ağaçlardan oluşan bir ormanı gösteren harika bir özyinelemeli CTE aldım. Bu teşhis açısından iyi bir şey. Ve izleme de onun temelinde oluşturulabilir. Ancak bu dikkatli bir şekilde yapılmalıdır. Kendiniz için küçük birstatement_timeout yapmanız gerekiyor. Ve lock_timeout arzu edilir.
Bazen bu hataların tümü bir arada ortaya çıkar.
Bana göre buradaki en önemli hata organizasyoneldir. Organizasyonel çünkü teknoloji çalışmıyor. Bu 2 numara; yanlış yeri işaretlemişler.
Yanlış yere kontrol ettik çünkü kontrol edilmesi kolay bir üretim klonumuz yoktu. Geliştiricinin üretime hiç erişimi olmayabilir.
Ve yanlış yere kontrol ettik. Orayı kontrol etselerdi biz de görürdük. Geliştirici, aynı miktarda verinin ve aynı düzenlemenin olduğu iyi bir ortamda kontrol ederse, DBA olmadan bile tüm bunları görebilir. Bütün bu aşağılanmaları görür ve utanırdı.
Araba süpürgesi hakkında daha fazla bilgi. Birkaç milyon satırlık devasa bir temizlik yaptıktan sonra hâlâ bir REPACK yapmamız gerekiyor. Bu özellikle indeksler için önemlidir. Orada her şeyi temizledikten sonra kendilerini kötü hissedecekler.
Ve eğer günlük sıyırma işini geri getirmek istiyorsanız, bunu daha sık ama daha küçük miktarlarda yapmanızı öneririm. Dakikada bir veya daha sık, biraz daha sık olabilir. Ve iki şeye dikkat etmemiz gerekiyor: Bu şeyin hatasız olması ve geride kalmaması. Gösterdiğim hile bunu çözmenize olanak sağlayacak.
Yaptığımız şey açık kaynaktır. Bu GitLab'da yayınlandı. Ve bunu insanların DBA olmadan da kontrol edebilmeleri için yapıyoruz. Bir veritabanı laboratuvarı yapıyoruz, yani Joe'nun şu anda üzerinde çalıştığı temel bileşeni çağırıyoruz. Ve üretimin bir kopyasını alabilirsiniz. Artık Joe'nun gevşeklik için bir uygulaması var, orada şunu söyleyebilirsiniz: "şöyle bir isteği açıklayın" ve hemen veritabanı kopyanız için sonucu alın. Orada DELETE bile yapabilirsiniz ve kimse fark etmez.
Diyelim ki 10 terabaytınız var, biz de 10 terabaytlık bir veritabanı laboratuvarı yapıyoruz. Ve 10 geliştirici, eşzamanlı 10 terabaytlık veritabanlarıyla eş zamanlı olarak çalışabilir. Herkes istediğini yapabilir. Silebilir, bırakabilir vb. Bu harika. Bunu yarın konuşacağız.
Buna ince provizyon denir. Bu ince bir provizyondur. Bu, geliştirme ve testlerdeki gecikmeleri büyük ölçüde ortadan kaldıran ve dünyayı bu konuda daha iyi bir yer haline getiren bir tür fantezidir. Yani, toplu operasyonlarda sorunlardan kaçınmanıza izin verir.
Örnek: 5 terabaytlık veritabanı, bir kopyanın 30 saniyeden kısa sürede alınması. Ve boyutuna bile bağlı değil, yani kaç terabayt olduğu önemli değil.
Bugün gidebilirsiniz ve araçlarımızı inceleyin. Kayıt olup neler olduğunu görebilirsiniz. Bu botu kendiniz kurabilirsiniz. Bedava. Yazmak.
sorular
Çoğu zaman gerçek durumlarda, tabloda kalması gereken verilerin silinmesi gerekenden çok daha az olduğu ortaya çıkar. Yani, böyle bir durumda, yeni bir nesne oluşturmak, oraya yalnızca gerekli verileri kopyalamak ve eski tabloyu yazıya dökmek daha kolay olduğunda, bu yaklaşımı uygulamak genellikle daha kolaydır. Geçiş yaparken bu an için bir yazılım yaklaşımına ihtiyacınız olduğu açıktır. Bu yaklaşım nasıldır?
Bu çok güzel bir yaklaşım ve çok güzel bir görev. pg_repack'in yaptığına çok benzer, insanları 4 bayt yaptığınızda yapmanız gerekenlere çok benzer. Birçok çerçeve bunu birkaç yıl önce yaptı ve plakalar daha da büyüdü ve bunların 8 bayta dönüştürülmesi gerekiyor.
Bu görev oldukça zordur. Yaptık. Ve çok dikkatli olmanız gerekiyor. Kilitler vs. var ama yapılıyor. Yani standart yaklaşım pg_repack kullanmaktır. Böyle bir işareti duyuruyorsunuz. Ve onu anlık görüntü verileriyle doldurmaya başlamadan önce, tüm değişiklikleri izleyen bir tablo da bildirirsiniz. Orada bazı değişiklikleri bile takip edemeyeceğiniz bir hile var. İncelikler var. Daha sonra değişiklikleri yayınlayarak geçiş yaparsınız. Herkesi kilitlediğimizde kısa bir duraklama olacak ama genel olarak bu yapılıyor.
GitHub'da pg_repack'e bakarsanız, kimliği int 4'ten int 8'e dönüştürme görevi olduğunda, pg_repack'in kendisini kullanma fikri ortaya çıktı. Bu da mümkün ama bu biraz hacker yöntemi ama bunda da işe yarayacaktır. pg_repack kullanan tetikleyiciye müdahale edip orada “Bu verilere ihtiyacımız yok” diyebilirsiniz, yani sadece ihtiyacımız olanı aktarıyoruz. Ve sonra sadece geçiş yapıyor ve hepsi bu.
Bu yaklaşımla, verilerin zaten indekslendiği ve güzel indekslerle çok düzgün bir şekilde düzenlendiği tablonun ikinci bir kopyasını da elde ederiz.
Hayır, bu iyi bir yaklaşım. Ama bunun için otomasyon geliştirme, yani evrensel bir çözüm üretme çabalarının olduğunu biliyorum. Sizi bu otomasyonla tanıştırabilirim. Python'da yazılmış, güzel şeyler.
MySQL dünyasından biraz uzaktayım, bu yüzden dinlemeye geldim. Biz de bu yaklaşımı kullanıyoruz.
Ancak bu ancak %90'ımız varsa mümkündür. Eğer %5'imiz varsa, onu kullanmak pek iyi değil.
Rapor için teşekkürler! Ürünün tam kopyasını oluşturacak kaynak yoksa yükü veya boyutu hesaplayacak herhangi bir algoritma veya formül var mı?
İyi soru. Şu ana kadar çok terabaytlık veritabanlarını bulabildik. Oradaki donanım aynı olmasa da, örneğin daha az bellek, daha az işlemci ve diskler tam olarak aynı olmasa da yine de yapıyoruz. Kesinlikle hiçbir yer yoksa, o zaman düşünmeniz gerekir. Yarına kadar düşüneyim, sen geldin, konuşuruz, bu güzel bir soru.
Rapor için teşekkürler! İlk önce şu ve bu sınırlamaları olan harika bir Postgres'in varlığından bahsetmeye başladınız, ancak gelişiyor. Ve bunların hepsi genel olarak bir koltuk değneği. Bütün bunlar, bir tür DELETE deferent'in ortaya çıkacağı veya burada kendi garip araçlarımızdan bazılarıyla örtbas etmeye çalıştığımız şeyi düşük seviyede tutması gereken başka bir şeyin ortaya çıkacağı Postgres'in gelişimiyle çelişmiyor mu?
SQL'de tek bir işlemde birçok kaydın silinmesi veya güncellenmesi gerektiğini söylüyorsak Postgres bunu nasıl dağıtabilir? Operasyonlarda fiziksel olarak sınırlıyız. Uzun bir süre daha bunu yapmaya devam edeceğiz. Ve şu anda kilitleyeceğiz vb.
Aynısını indekslerde de yaptılar.
Aynı kontrol noktası ayarının otomatikleştirilebileceğini varsayabilirim. Bir gün bu gerçekleşebilir. Ama sonra soruyu gerçekten anlamıyorum.
Soru şu: Tam oraya giden ve sizinkine paralel giden bir gelişme vektörü var mı? Onlar. Henüz düşünmüyorlar mı?
Şimdi kullanılabilecek prensiplerden bahsettim. Başka bir bot var , bununla otomatik kontrol noktası ayarlaması yapabilirsiniz. Postgres'te bu olacak mı? Bilmiyorum, bu henüz tartışılmıyor bile. Henüz bundan çok uzaktayız. Ama yeni sistemler yapan bilim insanları da var. Ve bizi otomatik indekslere itiyorlar. Gelişmeler var. Örneğin, otomatik ayarlamaya bakabilirsiniz. Parametreleri otomatik olarak seçer. Ancak henüz sizin için kontrol noktası ayarlaması yapmayacak. Yani performans, kabuk arabelleği vb. için seçim yapacaktır.
Kontrol noktası ayarlaması için aşağıdakileri yapabilirsiniz: Bulutta binlerce kümeniz, farklı donanımlarınız, farklı sanal makineleriniz varsa botumuzu kullanabilirsiniz. otomasyon yapın. Ve max_wal_size hedef ayarlarınıza göre otomatik olarak seçilecektir. Ancak şu ana kadar bu ne yazık ki çekirdekte olmaya yakın bile değil.
Tünaydın Uzun işlemlerin tehlikelerinden bahsettiniz. Silme durumunda otovakumun engellendiğini söylediniz. Bu bize başka nasıl zarar verir? Çünkü daha çok yer açmaktan ve onu kullanabilmekten bahsediyoruz. Kaybedecek başka neyimiz var?
Otovakum buradaki en büyük sorun olmayabilir. Uzun bir işlemin diğer işlemleri engelleyebilmesi ise daha tehlikeli bir olasılık. Karşılaşabilir de tanışmayabilir de. Eğer tanışırsa işler çok kötü olabilir. Otovakumda bu da bir sorundur. OLTP'de uzun işlemlerde iki sorun vardır: kilitler ve otomatik vakum. Ve kopyada etkin bekleme geri bildirimini etkinleştirdiyseniz, otomatik vakum engelleme de ana makineye ulaşacak, kopyadan gelecektir. Ama en azından orada kilit olmayacak. Ve burada kilitler olacak. Veri değişikliklerinden bahsediyoruz, dolayısıyla burada kilitler önemli bir nokta. Ve eğer bu çok uzun bir süre devam ederse, giderek daha fazla işlem engellenir. Başkalarını tuzağa düşürebilirler. Ve kilit ağaçları belirir. Parçanın bağlantısını verdim. Ve bu sorun, yalnızca birikebilen otovakum sorununa göre hızla daha belirgin hale gelir.
Rapor için teşekkürler! Raporunuza yanlış test yaptığınızı söyleyerek başladınız. Aynı ekipmanı, tabanı tamamen aynı şekilde almamız gerektiği fikrimizi sürdürdük. Diyelim ki geliştiriciye bir temel verdik. Ve bu isteğe uydu. Ve durumu iyi görünüyor. Ama canlı yayında kontrol etmiyor ama canlı yayında mesela yükümüz %60-70. Ve bu ayarı kullansak bile pek iyi sonuçlanmaz
Ekibinizde bir uzmanın olması ve gerçek arka plan yükü altında ne olacağını tahmin edebilecek DBA uzmanlarından faydalanmanız önemlidir. Saf değişimlerimizi basitçe uyguladığımızda resmi görüyoruz. Ancak daha gelişmiş bir yaklaşımla aynı şeyi tekrar yaptık ama üretim yükünü simüle ettik. Bu çok hoş. Bu noktaya kadar hâlâ büyümemiz gerekiyor. Olgun. Tamamen sahip olduklarımıza baktık ve aynı zamanda yeterli kaynağa sahip olup olmadığımıza da baktık. Bu iyi bir soru.
Zaten bir çöp seçimi yaptığımızda ve örneğin silinmiş bir bayrağımız olduğunda
Autovacuum'un Postgres'te otomatik olarak yaptığı şey budur.
Ah, bunu o mu yapıyor?
Autovacuum çöp toplayıcıdır.
Teşekkürler!
Rapor için teşekkürler! Ana tablodaki tüm çöplerin yan tarafta bir yerde kaldırılması için bölümlemeli bir veritabanını hemen tasarlama seçeneği var mı?
Tabii ki, yoktur.
Kullanılmaması gereken bir masayı kilitlersek kendimizi koruyabilir miyiz?
Elbette var. Ancak bu bir tavuk ve yumurta sorusudur. Eğer hepimiz gelecekte ne olacağını biliyorsak, o zaman elbette her şeyi harika yapacağız. Ancak iş değişiyor, yeni sütunlar ve yeni istekler ortaya çıkıyor. Ve sonra - ah, onu silmek istiyoruz. Ancak bu ideal bir durumdur; hayatta olur ama her zaman değil. Ama genel olarak iyi bir fikir. Sadece kısaltın ve bu kadar.
Kaynak: habr.com