Aşağıdakilerden bir tanesi 1. bölümden alınmıştır: Database Performans Ölçümü (Ücretsiz olarak sunulan açık erişim kitabı). Joan'ın çok gerçekçi veritabanı performans zorlukları ile yüksek fictionalized maceralarını izleyin. Sen kahkaha olacak. Sen ağlayacaksın. Nasıl bu “kırmızı hikaye” derin bir teknik kitap haline çalıştığımızı merak edeceksiniz. Database Performans Ölçümü Joan, “hibrid bulut”, “serverless” ve “edge first” gibi etkileyici sözcüklerden etkilenmiş ve yeni bir şirkete katılmaya başladı. ilk projesini son zamanlarda, müşteri sayısı ile aynı hızda büyüyen bir veri tabanı sisteminin içsel uygulanmasından, endüstri standardı veri tabanı yönetimi çözümlerinden birine geçişe başladı. SGK’da tanınan bir dünya. Asit Günümüzde her yıl ortaya çıkan birkaç yeni veri koruma yasası nedeniyle, şirketin yönetim kurulu, hassas bilgileri depolamak için popüler bulut tedarikçilerinden birini kullanmak yerine kendi veri merkezlerini korumaya karar verdi. Çok yüksek bir seviyede, şirketin ana ürünü sadece iki katmandan oluşuyordu: Kullanıcılar için giriş noktası olan frontend, aslında kendi tarayıcılarında çalışıyor ve sistemin geri kalanıyla iletişim kurarak bilgi değiştiriyor ve devam ediyor. Her şey-else, genellikle “backend” olarak bilinir, ancak aslında yük dengeleri, kimlik doğrulama, yetkilendirme, çoklu cache katmanları, veri tabanları, yedekleme ve benzeri içerir. Joan'ın ilk giriş görevi, veritabanından çeşitli istatistikleri toplamak ve özetlemek için çok basit bir hizmet uygulamak ve bu hizmeti tüm ekosistemle entegre etmekti, böylece gerçek zamanlı olarak verileri veritabanından alır ve DevOps ekibinin istatistikleri canlı olarak incelemesine izin verir. Yönetimi etkilemek ve Joan'ı işe almanın bu çeyrekte kesinlikle en iyi kararı olduğuna emin olmak için, Joan ilk gününde bir kavram kanıtı uygulamasını sunmaya karar verdi! Şirketin sözsüz politikası Rust'ta yazılım yazmaktı, bu yüzden kısa bir crates.io aramasında veri tabanları için ilk sürücüyü yakaladı ve kendi kendine düzenlenmiş bir hackathon'a oturdu. Rust’un ergonomiye odaklanan ekosistemi üstün bir geliştirme deneyimi sunarak gün gerçekten düzgün geçti.Ama o zaman Joan, gerçek bir sistem üzerinde ilk duman testlerini gerçekleştirdi.Her üçüncü isteğin (ortalama olarak) hataya düştüğünü fark ettiğinde hayal kırıklığına ve yardımsızlığa dönüştü. Ne yazık ki, sürücü Joan çabucak çalışmasının temeli için seçti, ancak açık kaynak tek başına, önceden kompile edilmiş, mirasçı C kodu üzerinde sadece ince bir kapaktı, kaynağı bulunamadı. gizemi çözmek için güçlü bir arzu ve sağlıklı bir öfke dozu tarafından beslenen Joan, ağ iletişimini kontrol etmek için birkaç saat geçirdi. ve bir bilge tahmin yapmıştı ki, Şirket tarafından kullanılan veritabanında, anahtarlar uygun düğmelere sonraki yönlendirme istekleri için hash edilir. eğer bir hash değer yanlış hesaplanırsa, bir isteğin yanlış düğmeye yönlendirilebilir ve bunun yerine bir hata iade edebilir. Wireshark Hakkında Bug, hashing anahtar uygulamasında bulunmalıdır Kaynak kodunun eksikliği nedeniyle iddiayı doğrulayamadı, Joan daha basit bir yoldan karar verdi - başlangıçta seçilen sürücüyü bırakmak ve çözümü, sağlam bir kullanıcı tabanına ve düzenli olarak güncellenmiş bir yayın programına sahip, veri tabanının sağlayıcısı tarafından desteklenen, resmi olarak desteklenen açık kaynaklı sürücülere yeniden uygulamak. Joan's Diary of Lessons Learned, Bölüm I İlk dersler şunları içerir: Bir sürücüyi dikkatlice seçin.Bu, kodunuzun performansının, dayanıklılığının ve güvenilirliğinin merkezindedir. Sürücülerin de hataları vardır ve bunlardan kaçınmak imkansızdır. İyi bir sebep olmaksızın, resmi olarak desteklenen sürücüyü tercih edin (varsa); Açık kaynaklı sürücülerin avantajları vardır: Sadece topluluk tarafından doğrulanmazlar, aynı zamanda kodun derinlemesine incelenmesine ve hatta sürücü kodunu daha fazla bilgi almak için değiştirmesine izin verirler. İyi kurulmuş bir sürüm programına sahip sürücülere güvenmek daha iyidir, çünkü makul bir süre içinde hata düzeltmeleri (güvenlik açığı dahil) almaları daha olasıdır. 3. Wireshark, ağ paketlerini yorumlamak için harika bir açık kaynak aracıdır; programınızın kapağının altına bakmak istiyorsanız bir deneyin. Giriş görevi nihayet başarılı bir şekilde tamamlandı ve Joan ilk gerçek görevini almaya hazır hale geldi. Tuning Hakkında Başlangıç görevi üzerinde çalıştığı deneyimle donatılmış olan Joan, yeni görevine nasıl yaklaşacağını planlamaya başladı: kötü davranışlı bir uygulama. uygulamalardan biri, bilinen bir şekilde tüm sistem için istikrar sorunları yarattı, her karşılaştığında diğer çalışma yüklerini bozuldu. Bu özel hizmet, eski sistemden yedeklenmiş verileri yeni veritabanına enjekte etme sorumluluğu taşıyordu. Şirket çok acele etmediği için, uygulama düşük önceliklere sahip olmak ve kullanıcı iş yüklerine müdahale etmemek için yazılmıştı. Ne yazık ki, her birkaç günde bir kez bir şey anomali tetikliyordu. Normal olarak barışçıl bir uygulama, kendi veritabanında bir hizmet reddetme saldırısı yapmaya çalışıyor gibi görünüyordu, arka kısmı ekosistemin diğer bölgelerine sorunlar yaratmak için yeterince aşırı yüklenene kadar taleplerle sızıyordu. Joan, Grafana tablosunda sunulan metrikleri izlerken, bu uygulama tarafından oluşturulan taleplerin oranının anomali zamanında yükselmeye başladığını açıkça gösterirken, Dünya'da bu çalışma yükünün nasıl böyle davranabileceğini merak etti. İşbirliği, şirketin “ruhu ve kültürel temellerinden” birisi olarak yerinde bir antrenörle onboarding seansları sırasında büyük ölçüde tanıtıldıktan sonra, konuyu meslektaşları Tony ile tartışmak için en iyisi olduğuna karar verdi. “Bak, Tony, bu konuda kafamı saramam,” açıklıyor. “bu hizmet 100'ü zaten uçuşta olduğunda yeni bir isteği göndermez. ve günlüklere doğru bakın: 100 isteği devam ediyor, biri bir zaman hatası döndü ve ...” o zaman durdu, kendi epifanyında şaşırdı. “Evet, teşekkürler Tony, sen bir sevgilin – en iyisi Her zaman!” dedi ve kodun düzeltilmesi için geri döndü. Tırtıl Duck Temel nedeni keşfetmeye yol açan gözlem oldukça basitti: talep aslında bir zaman hatası vermedi çünkü veritabanı sunucu böyle bir yanıt göndermedi. talep sadece sürücü tarafından zamanlandırılmış olarak nitelendirildi ve atıldı. Ama sürücü artık belirli bir isteğe yanıt beklemediği tek gerçek, veritabanın bunu işlediği anlamına gelmiyor! Bu bilgiyle, 100 isteğin müşteri tarafında bir kez bittiğini düşünmek kolaydır, uygulama yanlışlıkla artık ilerlemediklerini düşünebilir ve mutlulukla veritabanına 100 daha fazla isteği gönderebilir, uçuşta yapılan taleplerin toplam sayısını 200'e yükseltebilir. Joan's Diary of Lessons Learned, Bölüm 2 Dersler devam ediyor: Client-side timeouts, programcılar için uygundur, ancak sunucu-side timeouts ile kötü etkileşime girebilirler. Parmağınızın kuralı: Sunucu-side timeouts'u sunucu-side timeout'lara göre iki kat daha uzun yapın, aksi takdirde çok iyi bir sebep yoksa. Bazı sürücüler, sunucu-side timeout'un sunucu-side'den daha küçük olduğunu tespit ederse bir uyarı verebilir veya hatta sunucu-side timeout'u uyumlu hale getirmek için değiştirebilirler, ancak genel olarak çift kontrol etmek en iyisidir. Belli beklenmedik koşullar altında sabit eşzamanlı görünen görevler aslında zirveye neden olabilir. günlükleri ve panoları incelemek bu tür durumları araştırmak için yararlıdır, bu nedenle gözlemsel araçların hem veritabanı kümesinde hem de tüm müşteri uygulamaları için kullanılabilir olduğundan emin olun. dağıtılmış izleme için bonus noktaları, OpenTelemetry entegrasyonu gibi. Müşteri tarafında zamanlamalar düzgün şekilde değiştirildiğinde, uygulama çok daha az sıklıkla ve daha küçük bir ölçüde boğuldu, ancak dağıtılmış sistemde hala mükemmel bir vatandaş değildi. Bazen bir kurban veritabanı düğmesini seçti ve çok fazla talep ile onu rahatsız etmeye devam etti, diğer yedi düğmenin çok daha az yüklendiği gerçeğini görmezden geldiğinde ve çalışma yükünü de yönetmeye yardımcı olabildiğini kaydetti. Diğer zamanlarda, aynı anda konfigürasyon tarafından beklenenden tam olarak% 200 daha büyük olduğu bildirildi. İki anomalinin zaman içinde birleştiği zaman, kötü düğme bombaladığı tüm taleplerle başa çıkamadı ve bunların adil bir kısmını vazgeçmek zorunda kaldı. Şoför belgelerinin uzun bir çalışması, neyse mevcuttu formatta ve oldukça güncel tuttu, Joan da bu acıları hafifletmeye yardımcı oldu. mdbook Hakkında İlk sorun, basitçe mevcut olanların hepsinden “en az yüklü” veritabanı düğmesini seçmek için çok çaba sarf eden varsayılan olmayan yük dengeleme politikasının yanlış yapılandırılmasıydı, veri tabanının kendisi tarafından zaman zaman güncellenen heuristik ve istatistikleri temelinde. Ne yazık ki, bu politika aynı zamanda “en iyi çaba”ydı ve veritabanından gelen istatistiklerin her zaman meşru olduğu gerçeğine dayanıyordu – ancak stresli bir veritabanı düğmesi zamanında güncellenmiş istatistikleri geri göndermediği kadar aşırı yüklenebilirdi! İkinci sorun (konkuransın geçici olarak ikiye katlanması) başka bir yanlış yapılandırma nedeniyle meydana geldi: aşırı derecede spekülatif yeniden yapılandırma politikası. Veri tabanından bir onay almadan önceden yapılandırılmış bir süre bekledikten sonra, sürücüler başarı şansını en üst düzeye çıkarmak için bir isteği spekülatif olarak yeniden gönderirler. Bu mekanizma, isteğin başarı oranını arttırmak için çok yararlıdır. Ancak, orijinal isteğin de başarılı olursa, spekülatif isteğin boşuna gönderildiği anlamına gelir. Avantajları ve dezavantajlarını dengelemek için, spekülatif yeniden yapılandırma, orijinal isteğin başarısız olabileceğinin çok muhtemel olduğu durumlarda yalnızca yeniden göndermelere yapılandırılmalıdır. Aksi takdirde, Joan'ın durumunda olduğu gibi, Whew, hiçbir şey aynı anda endorfin çabası ve dopamin çarptırma seansına benzer ve şaşırtıcı bir başarıyla sona erer (doğal olarak derin bir teknik kitapta peynirli bir hikaye yazmaktan başka). harika iş, Joan! Ve sonu . Eğer bu kadar ileri gittiyseniz ve peynirli veritabanı performans hikayelerine yeterince ulaşamıyorsanız, fakir yaşlı Patrick'e ne olduğunu görün. Ve eğer bu mizah duygusunu takdir ederseniz, Piotr'un . Editor’s note: A Tale of Database Performance Woes: Patrick's Unlucky Green Fedoras Hakkında yeni kitap yazma mühendislik blog yazıları
