Teknoloji
Veritabanlarınız hızlı, kurtarılabilir ve güncellenebilir kalsın
PostgreSQL, MongoDB ve Redis, yük arttıkça her biri kendine özgü biçimde bozulmaya başlar. Sizinkilerin nerede zorlandığını ölçer, nedenleri risk sırasına göre düzeltir ve ekibinizin kullanabileceği işletim kılavuzları bırakırız.
Görüşme talep edin Veri Mimarisi ve Migrasyon hizmetine bakın
- Süre
- 4 ila 12 hafta
- Model
- Ölç, düzelt, devret
- Çıktı
- Ayarlanmış veri depoları ve denenmiş işletim kılavuzları
Bu hizmete ihtiyaç duyduğunuzun işaretleri
Bunların her biri zaten kullandığınız motorun içinde düzeltilebilir.
pg_stat_statementsiçindeki birkaç sorgu veritabanı zamanının büyük kısmını harcıyor ve aylardır kimse planlarına bakmadı.- Otomatik ölçekleme uygulamaya yeni pod’lar ekliyor; PostgreSQL, CPU’su tükenmeden çok önce bağlantı sınırına dayanıyor.
- Satır sayıları sabitken tablolar ve indeksler büyümeye devam ediyor; autovacuum en büyük tablolara hiç yetişemiyor.
- Sıradan bir şema migrasyonu bir kilidi bekledi ve arkasında sıraya giren bütün sorguları durdurdu.
- Failover hiç denenmedi ya da bir kez denendi ve uygulama yeniden bağlanabilmek için yeniden başlatılmak zorunda kaldı.
- Shard anahtarı zamanla arttığı için yazmaların çoğu tek bir MongoDB shard’ına gidiyor; bu anahtarı içermeyen sorgular bütün shard’lara dağılıyor.
- Redis önbellek olarak başladı, şimdi oturumları ve arka plan işlerini de tutuyor; bir yeniden başlatma ya da bir eviction, kuyruktaki işlerin sessizce kaybolmasına yol açıyor.
Alışılmış çözümler neden kalıcı olmaz
Veri depoları nadiren bir anda çöker; yavaş yavaş bozulur. Tablo büyüyünce bir sorgu planı değişir, ölü satırlar autovacuum’un temizleyebildiğinden hızlı birikir, açılışta iyi çalışan bir shard anahtarı bir yıl sonra yazmaları tek bir noktada toplar, eviction politikası olmayan bir önbellek dolar.
Alışılmış tepkiler zaman kazandırır ama nedeni ortadan kaldırmaz. Daha büyük bir sunucu, eksik bir indeksi veri yeniden ikiye katlanana kadar gizler. Yavaş bir sorgunun önüne konan önbellek, yavaş sorguyu yerinde bırakır ve üstüne bir geçersiz kılma sorunu ekler. Motoru değiştirmek, aynı erişim desenini ekibin daha az tanıdığı bir sisteme taşır. Biz bunun yerine ölçümle başlarız: sorgu planları, bekleme olayları, replikasyon gecikmesi, eviction’lar ve anahtar dağılımı.
Bu hizmet, zaten kullandığınız motorların içinde çalışır. Hangi verinin nerede duracağına karar vermek ya da veriyi sistemler arasında taşımak Veri Mimarisi ve Migrasyon hizmetinin konusudur; ikisi çoğu zaman art arda yürür.
Kapsama girenler ve girmeyenler
Dahildir
- PostgreSQL sorgu planları, indeksler ve en büyük tabloların bölümlenmesi (partitioning)
- Autovacuum ayarı, şişkinlik (bloat) kontrolü ve transaction ID wraparound denetimi
- Bağlantı havuzu, örneğin PgBouncer ile
- Ölçülmüş kurtarma süreleriyle replikasyon, failover ve yedekten geri dönüş testleri
- Şema değişiklikleri ve ana sürüm yükseltmeleri; en az kesintiyle ve geri dönüş yoluyla
- MongoDB doküman modeli, indeksler, shard anahtarı ve çok dokümanlı transaction’ların sınırları
- Redis önbellek desenleri, geçersiz kılma, eviction politikası, kalıcılık ve sıcak anahtarlar
Dahil değildir
- Kurum genelinde hangi verinin hangi sistemde duracağına karar vermek
- Ölçülmüş bir gerekçe olmadan veritabanı motorunu değiştirmek
- BI, raporlama ve veri ambarı tasarımı
- Devirden sonra günlük veritabanı yönetimi ve nöbet
İş nasıl ilerler
- Hafta 1 ila 2Motorları ölçün. Sorgu istatistiklerine, planlara, replikasyon durumuna ve bellek metriklerine salt okunur erişimle yükün çoğunu taşıyan sorguları, tabloları ve anahtarları buluruz.
- Hafta 3Düzeltmeleri sıralayın. Her bulguya bir risk, bir efor ve önerilen bir değişiklik yazılır; bu, tek bir ayardan bölümleme ya da yeni bir shard anahtarı gibi planlı bir değişikliğe kadar uzanabilir.
- Hafta 4 ve sonrasıGeri alınabilir adımlarla düzeltin. Değişiklikler normal dağıtım hattınızdan tek tek geçer; her birinin öncesi ve sonrası ölçülür ve bir geri dönüş yolu vardır. Bir aşama için verilen yazma yetkisi aşama bitince kaldırılır.
- Süreç boyuncaArızayı prova edin. Failover, yedekten geri dönüş ve bir önbellek düğümünün kaybı ekibinizle birlikte denenir; kurtarma süreleri varsayılmaz, ölçülür.
- Son haftaDevredin. Panolar, işletim kılavuzları ve karar kayıtları, bunları sahiplenecek mühendislerle birlikte tek tek geçilir.
Elinize ne geçiyor
Kod ve her diyagramın kaynak dosyaları dahil tüm çıktılar size aittir.
Hangi durumda doğru hizmet değil
- Yavaşlığı başka bir yerde olan sistemler. İstekler kuyrukta beklerken veritabanı boştaysa Performans ve Ölçeklenebilirlik ile başlayın.
- Asıl sorusu veri modeli ya da başka bir platforma taşınma olan projeler; bu, Veri Mimarisi ve Migrasyon hizmetinin konusudur.
- Kalıcı bir veritabanı yöneticisi ya da kesintisiz işletim arayan ekipler. Biz düzeltir, belgeler ve devrederiz.
Sık sorulanlar
Hangi sürümler ve barındırma seçenekleriyle çalışıyorsunuz?
PostgreSQL, MongoDB ve Redis ile, Valkey gibi Redis uyumlu motorlar dahil; kendi barındırdığınız kurulumlarda ya da Amazon RDS, Cloud SQL veya MongoDB Atlas gibi yönetilen servislerde. Yönetilen servisler neyi ayarlayabileceğinizi değiştirir, motorların nasıl davrandığını değiştirmez. Destek sonuna yaklaşan bir ana sürüm varsa yükseltme planı işin parçası olur.
Üretim sistemine dokunacak mısınız?
Yalnızca sizin dağıtım hattınızdan ve inceleme sürecinizden geçerek. Erişim varsayılan olarak salt okunurdur; yazma yetkisi aşama bitince kaldırılır. Her değişikliğin ölçülmüş bir öncesi, sonrası ve geri dönüş yolu vardır.
Ana sürüm yükseltmesini uzun bir kesinti olmadan nasıl yapıyorsunuz?
Veri boyutuna ve kabul edilebilir kesintiye bağlıdır. PostgreSQL’de pg_upgrade hızlıdır ama kısa bir kesinti ister; yeni bir kümeye mantıksal replikasyon geçişi kısa bir duraklamaya indirir ama daha fazla hazırlık gerektirir. Her iki durumda da yükseltme bir kopya üzerinde prova edilir, sorgu planları karşılaştırılır ve geri dönüş yolu önceden belirlenir.
Ekibimizin ne kadar zamanını alıyor?
Zamanın çoğu, veri katmanının ve en yoğun servislerin sahibi olan mühendislerden gelir. İlk haftalarda görüşmelere katılır, sonra her değişiklikte bizimle birlikte çalışırlar; böylece bilgi onlarda kalır.
Çalışma bittikten sonra ne oluyor?
Değişikliklerin, panoların ve işletim kılavuzlarının sahibi ekibinizdir. Birçok ekip kendi başına devam eder; bazıları bir sonraki aşama için haftada 2 ila 3 gün çalışan bir gömülü mimarla devam eder.
Önce kısa bir teknik sohbetle başlayalım
Otuz dakika. Sistemi ve veri katmanının nerede zorlandığını anlatırsınız, biz nereden başlayacağımızı söyleriz.