Tek sunuculu PostgreSQL için Azure Veritabanı uygulama oluşturmaya yönelik en iyi yöntemler
ŞUNLAR IÇIN GEÇERLIDIR:
PostgreSQL için Azure Veritabanı - Tek Sunucu
Önemli
PostgreSQL için Azure Veritabanı - Tek Sunucu kullanımdan kaldırma yolundadır. PostgreSQL için Azure Veritabanı - Esnek Sunucu'ya yükseltmenizi kesinlikle öneririz. PostgreSQL için Azure Veritabanı - Esnek Sunucu'ya geçiş hakkında daha fazla bilgi için bkz. PostgreSQL için Azure Veritabanı Tek Sunucuya ne oluyor?.
PostgreSQL için Azure Veritabanı kullanarak buluta hazır bir uygulama oluşturmanıza yardımcı olacak bazı en iyi yöntemler aşağıdadır. Bu en iyi yöntemler uygulamanızın geliştirme süresini kısaltabilir.
Uygulama ve veritabanı kaynaklarının yapılandırması
Uygulamayı ve veritabanını aynı bölgede tutma
Uygulamanızı Azure'da dağıtırken tüm bağımlılıklarınızın aynı bölgede olduğundan emin olun. Örneklerin bölgelere veya kullanılabilirlik alanlarına yayılması ağ gecikme süresine neden olur ve bu durum uygulamanızın genel performansını etkileyebilir.
PostgreSQL sunucunuzun güvenliğini sağlama
PostgreSQL sunucunuzu güvenli olacak ve genel olarak erişilmeyecek şekilde yapılandırın. Sunucunuzun güvenliğini sağlamak için şu seçeneklerden birini kullanın:
Güvenlik için her zaman SSL üzerinden PostgreSQL sunucunuza bağlanmanız ve PostgreSQL sunucunuzu ve uygulamanızı TLS 1.2 kullanacak şekilde yapılandırmanız gerekir. Bkz. SSL/TLS'yi yapılandırma.
Bağlantı bilgileri için ortam değişkenlerini kullanma
Veritabanı kimlik bilgilerinizi uygulama koduna kaydetmeyin. Ön uç uygulamasına bağlı olarak, ortam değişkenlerini ayarlamak için yönergeleri izleyin. App service kullanımı için bkz . Uygulama ayarlarını yapılandırma ve Azure Kubernetes hizmeti için bkz . Kubernetes gizli dizilerini kullanma.
Performans ve dayanıklılık
Uygulamanızla ilgili performans sorunlarının hatalarını ayıklamaya yardımcı olmak için kullanabileceğiniz birkaç araç ve uygulama aşağıdadır.
Bağlan ion Havuzu Kullanma
Bağlantı havuzu ile, başlangıç zamanında sabit bir bağlantı kümesi kurulur ve korunur. Bu yaklaşım ayrıca veritabanı sunucusunda kurulan yeni dinamik bağlantılardan kaynaklanan bellek parçalanmasının azaltılmasına da yardımcı olur. Uygulama çerçevesi veya veritabanı sürücüsü destekliyorsa, bağlantı havuzu uygulama tarafında yapılandırılabilir. Bu desteklenmiyorsa önerilen diğer seçenek, uygulamanın dışında çalışan ve veritabanı sunucusuna bağlanan PgBouncer veya Pgpool gibi bir proxy bağlantı havuzu oluşturucu hizmetinden yararlanmaktır. Hem PgBouncer hem de Pgpool, PostgreSQL için Azure Veritabanı ile çalışan topluluk tabanlı araçlardır.
Geçici hataları işlemek için yeniden deneme mantığı
Uygulamanız, veritabanına bağlantıların aralıklı olarak bırakıldığı veya kaybolduğu geçici hatalarla karşılaşabilir. Bu gibi durumlarda sunucu, 5-10 saniye içinde bir-iki yeniden denemeden sonra çalışır durumdadır. İlk yeniden denemenizden önce 5 saniye beklemek iyi bir yöntemdir. Ardından beklemeyi kademeli olarak 60 saniyeye kadar artırarak her yeniden denemeyi izleyin. Uygulamanızın işlemin başarısız olduğunu düşündüğü en fazla yeniden deneme sayısını sınırlayın, böylece daha fazla araştırma yapabilirsiniz. Daha fazla bilgi edinmek için bkz . Bağlantı hatalarını giderme.
Yük devretmeleri azaltmak için okuma çoğaltmasını etkinleştirme
Yük devretme senaryoları için Veri İçi Çoğaltmayı kullanabilirsiniz. Okuma amaçlı çoğaltmaları kullanırken, kaynak ve çoğaltma sunucuları arasında otomatik yük devretme gerçekleşmez. Çoğaltma zaman uyumsuz olduğundan kaynak ile çoğaltma arasında bir gecikme olduğunu fark edeceksiniz. Ağ gecikmesi, kaynak sunucuda çalışan iş yükünün boyutu ve veri merkezleri arasındaki gecikme süresi gibi birçok faktörden etkilenebilir. Çoğu durumda çoğaltma gecikmesi birkaç saniye ile birkaç dakika arasında değişir.
Veritabanı dağıtımı
CI/CD dağıtım işlem hattını yapılandırma
Bazen değişiklikleri veritabanınıza dağıtmanız gerekir. Böyle durumlarda, PostgreSQL sunucunuz için GitHub Actions aracılığıyla sürekli tümleştirmeyi (CI) kullanarak veritabanını ona karşı özel bir betik çalıştırarak güncelleştirebilirsiniz.
El ile veritabanı dağıtım işlemini tanımlama
El ile veritabanı dağıtımı sırasında kapalı kalma süresini en aza indirmek veya başarısız dağıtım riskini azaltmak için şu adımları izleyin:
- pg_dump kullanarak yeni bir veritabanında üretim veritabanının kopyasını oluşturun.
- Yeni veritabanını yeni şema değişikliklerinizle veya veritabanınız için gereken güncelleştirmelerle güncelleştirin.
- Üretim veritabanını salt okunur duruma getir. Dağıtım tamamlanana kadar üretim veritabanında yazma işlemleriniz olmamalıdır.
- Uygulamanızı 1. adımdaki yeni güncelleştirilmiş veritabanıyla test edin.
- Uygulama değişikliklerinizi dağıtın ve uygulamanın artık en son güncelleştirmeleri içeren yeni veritabanını kullandığından emin olun.
- Değişiklikleri geri alabilmeniz için eski üretim veritabanını koruyun. Daha sonra eski üretim veritabanını silmek veya gerekirse Azure Depolama'de dışarı aktarmak için değerlendirebilirsiniz.
Not
Uygulama bir e-ticaret uygulaması gibiyse ve bunu salt okunur duruma getiremiyorsanız, yedekleme yaptıktan sonra değişiklikleri doğrudan üretim veritabanına dağıtın. Bazı kullanıcılar başarısız isteklerle karşılaşabileceğinden, etkiyi en aza indirmek için uygulamaya yönelik trafiğin düşük olduğu yoğun olmayan saatlerde bu değişiklik gerçekleşmelidir. Uygulama kodunuzun başarısız istekleri de işlediğine emin olun.
Veritabanı şeması ve sorguları
Veritabanı şemanızı ve sorgularınızı oluştururken aklınızda bulundurmanız gereken birkaç ipucu aşağıdadır.
Birincil Anahtarlar için BIGINT veya UUID kullanma
Özel uygulama veya bazı çerçeveler oluştururken birincil anahtarlar yerine BIGINT kullanıyor INT olabilirler. kullandığınızda INT, veritabanınızdaki değerin veri türünün depolama kapasitesini aşabileceği yer INT riskini çalıştırırsınız. Mevcut bir üretim uygulamasında bu değişikliğin yapılması, daha fazla geliştirme süresine mal olacak şekilde zaman alabilir. Bir diğer seçenek de birincil anahtarlar için UUID kullanmaktır. Bu tanımlayıcı, örneğina0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11, otomatik olarak oluşturulan 128 bitlik bir dize kullanır. PostgreSQL veri türleri hakkında daha fazla bilgi edinin.
Dizinleri kullanma
Postgres'te farklı şekillerde kullanılabilecek birçok dizin türü vardır. Dizin kullanmak, sunucunun belirli satırları dizin olmadan bulabileceğinden çok daha hızlı bulmasına ve almasına yardımcı olur. Ancak dizinler de veritabanı sunucusuna ek yük getirir, bu nedenle çok fazla dizine sahip olmaktan kaçının.
Otomatik vakum kullanma
Sunucunuzu PostgreSQL için Azure Veritabanı bir sunucuda otomatik vakumla iyileştirebilirsiniz. PostgreSQL daha fazla veritabanı eşzamanlılığı sağlar, ancak her güncelleştirmede ekleme ve silme işlemine neden olur. Silme işlemi için kayıtlar geçici olarak işaretlenir ve bunlar daha sonra temizlenir. Bu görevleri gerçekleştirmek için PostgreSQL bir vakum işi çalıştırır. Zaman zaman vakumlamazsanız, biriken ölü demetler aşağıdakilere neden olabilir:
- Daha büyük veritabanları ve tablolar gibi veri kabarması.
- Daha büyük iyi olmayan dizinler.
- Artan G/Ç.
Otomatik vakum ile iyileştirme hakkında daha fazla bilgi edinin.
pg_stats_statements kullanma
Pg_stat_statements, PostgreSQL için Azure Veritabanı'de varsayılan olarak etkinleştirilen bir PostgreSQL uzantısıdır. Uzantı, bir sunucu tarafından yürütülen tüm SQL deyimleri için yürütme istatistiklerini izlemek için bir yol sağlar. pg_statement kullanmayı öğrenin.
Sorgu Deposu'nı kullanma
PostgreSQL için Azure Veritabanı'daki Sorgu Deposu özelliği, sorgu istatistiklerini izlemek için bir yöntem sağlar. Bu özelliği pg_stats_statements kullanmaya alternatif olarak öneririz.
Toplu eklemeleri iyileştirme ve geçici verileri kullanma
Geçici veriler içeren veya toplu olarak büyük veri kümeleri ekleyen iş yükü işlemleriniz varsa, kaydedilmemiş tabloları kullanmayı göz önünde bulundurun. Varsayılan olarak bölünmezlik ve dayanıklılık sağlar. ACID özelliklerini atomiklik, tutarlılık, yalıtım ve dayanıklılık oluşturur. Toplu eklemeleri iyileştirmeyi öğrenin.