PostgreSQL'de Veritabanı Boyutunu Küçültme Stratejileri: Kullanıma Dayalı Bir Yaklaşım

Veritabanı fiyatlandırma modelleri zordur. Yönetilen bir veritabanı arayan bir geliştirici olarak, arama sürecinin en sinir bozucu (ve yine de en önemli) yönlerinden biri, yalnızca veritabanı boyutunuz için çözümün ön fiyatını değil, aynı zamanda fiyatlandırmanın nasıl çalıştığını ve ne kadar iyi ölçeklenebileceğini de değerlendirmeyi içerir. .

Veritabanı fiyatlandırmasını değerlendirirken karşılaşılan nüansların yanı sıra (örneğin, "Verilerim büyüdükçe fatura ne kadar artar?", "Yazma veya okuma başına ücretlendiriliyor muyum?" ve "Yedekleme başına daha fazla ödemem gerekiyor mu?") ), geliştiriciler bir hususu gözden kaçırma eğilimindedir: Bir veritabanının fiyatlandırma modelinin yapılandırılma şekli, verilerinizi nasıl yönettiğinizi ve Postgres veritabanı boyutunuzu nasıl değerlendirdiğinizi etkileyecektir.

Farklı fiyatlandırma modelleri, PostgreSQL'in çalıştırılmasında farklı yaklaşımlar gerektirir. Örneğin, büyük bir diske kilitlenmişseniz veritabanı boyutunuzu küçültmeye öncelik vermeyebilirsiniz. Okunan veri başına ücretlendiriliyorsanız belirli sorguları çalıştırma konusunda iki kez düşünebilirsiniz; veri girişi başına ücretlendiriliyorsanız yeni alınan verilerin sıklığı ve hacmi konusunda dikkatli olabilirsiniz.

Her fiyatlandırma öğesi, benimseyeceğiniz stratejileri ve davranışları incelikli bir şekilde etkiler ve sizi hem maliyet verimliliği hem de optimum performans sağlamak için veritabanınızı belirli bir yönetim ve etkileşim yöntemine doğru iter.

Timescale'de birkaç ay önce kullanıma dayalı bir depolama modeline geçtik , harika müşteri geri bildirimleriyle. Bu blog yazısında, PostgreSQL depolamanızı kullanıma dayalı bir modelde en iyi şekilde nasıl yöneteceğinize dair taktiklerle birlikte, bu modele geçişten bu yana müşterilerimizden gözlemlediğimiz operasyonel avantajları inceleyeceğiz.

Kullanıma dayalı depolama modelleri veritabanı dünyasında giderek daha popüler hale geliyor; kim kullanmadığı disk alanı için ödeme yapmak ister? Yine de kullanıma dayalı bir modelin sonuçları olmadan gelmez ve bu modelde etkili bir şekilde gezinmek için bazı en iyi uygulamaları dikkate almanız gerekir.

PostgreSQL Depolama Modellerinin Hızlı Özeti

Veritabanı boyutunuzu kullanıma dayalı bir modelde yönetmeye ilişkin tartışmamızda ortak bir zemin oluşturmak için, PostgreSQL platformumuzda fiyatlandırmanın nasıl çalıştığını hızlı bir şekilde ele alarak başlayalım ( Zaman ölçeği ) ve Amazon RDS for PostgreSQL ve Amazon Aurora gibi diğer yönetilen PostgreSQL ürünleriyle karşılaştırması.

Dünden (💥) itibaren Timescale platformunda iki tür veritabanı hizmeti sunuyoruz:

• Dinamik PostgreSQL hizmetleri Geliştiricilerin performanstan ödün vermeden paradan tasarruf etmek için dinamik bilgi işlemle PostgreSQL veritabanları oluşturabilecekleri yer.

  
  

• Geliştiricilerin hipertablolar, sütunlu sıkıştırma, sürekli agregalar ve katmanlı depolama.

  
  

Platformumuzda depolamayı nasıl fiyatlandırdığımıza odaklanalım. Bu hizmetlerin her ikisi de depolama için kullanıma dayalı bir modelle birlikte gelir; bu şu anlama gelir:

• Geliştiricilerden, küçük harfler olmadan, kullandıkları birim için ücret alınır; minimum veritabanı boyutu veya minimum ölçeklendirme adımı yoktur. Ay sonuna kadar 128 GB kullandıysanız bunun için faturalandırılırsınız. 1 GB'tan başlayıp TB'ye kadar büyüyebilirsiniz.

• Yazılan verilere, veri aktarımlarına veya çalıştırılan sorgulara bağlı olarak herhangi bir ücret alınmaz.

• Veritabanı oluştururken veya ölçeklendirirken depolama alanı ayırmanıza gerek yoktur.

• Diskleri manuel olarak küçültmeye gerek yok.

  
  

Bunu anlayabilmek için bu model olan Amazon RDS PostgreSQL ve Amazon Aurora arasındaki farkları sıralayalım:

Özet olarak, karşılaştırmamızdan çıkan üç ana sonuç şunlardır:

• Hem Zaman Ölçeği hem de Aurora, gerçek veritabanı boyutunuz için ücret alır. Buna karşılık RDS PostgreSQL, tedarik edilen depolama için ücret alır. RDS'de birimleri küçültemezsiniz.

  
  

• Timescale, yazılan veriler, veri aktarımları veya sorgu işlemleri için ücret almaz. Hem RDS hem de Aurora, veri aktarımı ve ekstra yedekleme depolama alanı başına ücret alır ve seçtiğiniz depolama türüne bağlı olarak bazı ekstra G/Ç ücretleri ödemek zorunda kalabilirsiniz.

  
  

• Zaman ölçeğinde minimum ölçeklendirme adımları bulunmazken Aurora, 10 GB ile başladıktan sonra 10 GB'lık artışlarla ölçeklenir.

  
  

Gördüğünüz gibi Timescale'in modeli şuna daha yakın: Aurora G/Ç Optimize Edilmiş Ancak Zaman Ölçeği'nde ölçeklendirme adımları ve veri aktarımı gibi şeyler için ekstra ücretler yoktur. Buna karşılık RDS, tahsise dayalı modelin iyi bir temsilidir. RDS "depolama katmanlarından" yoksundur geleneksel olarak bu modelde çalışan veritabanı satıcılarında bulunur.

Kullanıma Dayalı Fiyatlandırma PostgreSQL Depolama Yönetimini Nasıl Geliştirir?

Daha önce de belirttiğimiz gibi, farklı fiyatlandırma modelleri farklı veritabanı deneyimlerini beraberinde getirir. Tahsis bazlı modelden kullanım bazlı modele geçtiğimizde müşterilerimiz bize üç operasyonel alanda anında iyileştirme gördüklerini söyledi:

• Bir veritabanını başlatırken depolama alanını önceden tedarik etmelerine gerek yoktu; bu da daha az aşırı tedarik hatasına ve dolayısıyla depolama faturalarının düşmesine yol açtı.
• Ölçeklendirme sırasında depolamayı düşünmeleri gerekmedi.
• Ölçeği küçültebilirler; örneğin verileri silerlerse bunun için ödeme yapmayı bırakırlar.

Kullanıma dayalı modeller, aşırı depolama tahsisi sorununu ortadan kaldırır

Geleneksel tahsise dayalı modellerde, geliştiriciler genellikle kendilerini depolama ihtiyaçlarını tahmin ederken bulurlar ve bu da sıklıkla depolamanın aşırı sağlanmasına yol açar. Timescale kullanıma dayalı bir model üzerinde çalıştığında bunu filomuz genelinde gözlemledik: Müşterilerimizin çoğunluğu disk kapasitelerinin tamamını kullanmıyordu, bu da aslında henüz kullanmadıkları depolama alanı için ödeme yaptıkları anlamına geliyordu. Kullanıma dayalı modeller bu tahmin oyununu (ve yanlış tahminlerin sonuçlarını) ortadan kaldırır.

Ölçeklendirirken depolamayı düşünmenize gerek yok

“Zaman ölçeğinin kullanıma dayalı depolaması, artık disk boyutu hakkında düşünmeme gerek olmadığı anlamına geliyor. Depolama maliyetimiz %30 azaldı ve benim hiçbir şey yapmam gerekmedi!"

Adam McCrea, Judo ölçeği (Zaman ölçeği müşterisi)

Kullanıma dayalı modellerde, veritabanınız büyüdükçe depolama alanı sorunsuz bir şekilde ölçeklenir. Geleneksel tahsise dayalı modellerdeki ana stres kaynağı, disk alanının tükenmesi tehlikesidir; bu, uygulamanın aksama süresinden ve kayıp işlemlerden en kötü senaryolarda veri bozulmasına kadar çok sayıda soruna yol açabilir.

Kullanıma dayalı modellerle, geliştiricilerin artık depolama duvarına çarpmamak için depolamalarını dikkatli bir şekilde izlemeleri gerekmiyor. Aynı zamanda, ağır otomatik ölçeklendirme adımları veya katman atlamaları konusunda endişelenmelerine de gerek yok.

Ölçeği küçültebilirsiniz (sildiğiniz veriler için ödeme yapmayı durdurabilirsiniz)

Son olarak, kullanıma dayalı modeller "ölçeği küçültmenize" olanak tanır. Verileri silerseniz (veya veritabanı boyutunuzu önemli ölçüde azaltmayı başarırsanız), depolama başına daha az ödeme yapmaya başlarsınız ki bu da kulağa adil geliyor. Bir sonraki bölümde göreceğimiz gibi Timescale'in müşterilerin PostgreSQL veritabanı boyutlarını azaltmalarına yardımcı olacak birkaç özelliği vardır. Kullanıma dayalı bir modeli benimsemek, müşterilerimizin disk kullanımını azaltırken anında tasarruf etmelerini sağladı ve bu da onları veritabanlarını yalın tutmaya teşvik etti.

Kullanıma Dayalı Bir Modelde Etkili Bir Şekilde Nasıl Gezinilir: Postgres Veritabanı Boyutunuzu Azaltmaya Yönelik İpuçları

Az önce bahsettiğimiz avantajlar, geliştiricilerin depolamayla çalışma deneyimini önemli ölçüde artırıyor; bu nedenle kullanıma dayalı modeller çok popüler hale geliyor. Ancak kullanıma dayalı fiyatlandırmanın bariz (ama derin) bir sonucu var: Geliştiricileri PostgreSQL veri tabanı boyutlarını mümkün olduğunca azaltmak için iyi veri uygulamalarını benimsemeye zorluyor.

Depolama maliyetlerinizin doğrudan kullandığınız disk boyutuna bağlı olduğunu bildiğinizde, veri depolama konusunda daha tedbirli olmaya yönelik yeni keşfedilmiş bir teşvik vardır. Depolama için kullanıma dayalı bir modelde çalışıyorsanız, verileri verimli bir şekilde depoladığınızdan emin olmak sizin sorumluluğunuz haline gelir.

Bir bakıma bu, kullanıma dayalı modellerin bir “dezavantajı” olarak değerlendirilebilir ve biraz çalışma gerektirir; ancak bu aslında kılık değiştirmiş bir lütuftur. Geleneksel tahsise dayalı modellerde, maliyetler sabit olduğundan veri hijyeni bir şekilde göz ardı edilebilir: RDS'de 500 GB'lık bir diske kilitlenmişseniz ve veritabanınız 200 GB ise, bunu yapmak için büyük bir teşvikiniz yok gibi görünüyor. Depolama kullanımını verimli hale getirin.

Ancak olay şu: İyi veri uygulamaları yalnızca para tasarrufuyla ilgili değildir. PostgreSQL veritabanını ölçeklendirmek için onu optimize etmek önemlidir. İyi PostgreSQL veri yönetimi uygulamalarını benimseyerek yalnızca daha iyi performans elde etmekle kalmayacak, aynı zamanda bir veritabanı yöneticisi olarak hayatınız çok daha kolaylaşacaktır.

Bunu aklımızda tutarak, depolama için kullanıma dayalı bir modelde mümkün olduğunca etkili bir şekilde gezinmenize ve PostgreSQL veritabanı boyutunuzu sistematik bir şekilde azaltmanıza yardımcı olacak bazı uygulamaları gözden geçirelim. Zaman Ölçeği özelinde, özellikle ele alacağımız bazı yararlı özelliklerimiz var.

PostgreSQL veritabanınızdaki şişkinliği azaltın

Kullanıma dayalı bir modelde yapılması gereken ilk şey, PostgreSQL depolamanın nasıl çalıştığına ilişkin ayrıntılara dikkat etmektir; yani şişkinliği düzenli olarak azaltmalısınız. Bu size yalnızca veritabanı boyutunuz konusunda değil aynı zamanda G/Ç gereksinimleriniz konusunda da yardımcı olacaktır. Bu bölümde sizi bazı temel bilgilere yönlendireceğiz. ancak bu HN başlığında harika tavsiyeler var ve biz de yazdık PostgreSQL'de tablo şişkinliği üzerine bir blog yazısı .

• Ölü tuple'ları izleyin. PostgreSQL depolamayı optimize etmeye yönelik proaktif bir yaklaşım, ölü kayıtları yakından takip etmekle başlar. Ölü demetler kontrol edilmezse birikebilir ve gereksiz depolama masraflarına yol açabilir. pgstattuple() uzantısı, tabloların bu demetleri nasıl yönettiğini anlamak için harika bir müttefik olabilir.

  
  

• Sık sık süpürün. Tablo şişkinliğiyle etkili bir şekilde mücadele etmek için, otomatik vakumu daha sık çalışacak şekilde yapılandırmak isteyebilirsiniz. Postgresql.conf dosyasındaki autovacuum ayarlarını genel olarak ayarlamak yerine, bu ayarlara tablo bazında ince ayar yapmak daha kesindir. Bu, farklı tabloların ölü demet biriktirme konusunda farklı eğilimlere sahip olabileceği gerçeğine hitap etmektedir. Otomatik vakum işlemlerini engelleyebilecek uzun süreli işlemleri izlemek de çok önemlidir.

  
  

• Kullanılmayan sayfaları geri alın. Otovakum ve vakum ölü demetleri ele alırken, kullanılmayan sayfaların geri kazanılması farklı bir yaklaşım gerektirir. Her ne kadar VACUUM FULL bu amaç için kullanılabilse de, tüm masanın kilitlenmesi gibi doğal bir sınırlamaya sahiptir. Pg_repack bu konuda size yardımcı olabilir.

PostgreSQL'de biraz ince ayar yapın

PostgreSQL veritabanınızın boyutunu sistematik olarak azaltmak, PostgreSQL veritabanınızı etkili bir şekilde ölçeklendirebilmeniz, yani giderek daha fazla veri eklerken işleri hızlı ve çevik tutabilmenizle yakından ilgilidir. Bazı önemli PostgreSQL parametrelerini göz önünde bulundurmak (ve belki de ayarlamak) yardımcı olabilir. Bu makalede en önemli performans parametreleri gözden geçirilmektedir . Göz önünde bulundurmanız gereken bazı hususlar şunlardır:

• shared_buffers : PostgreSQL'in sayfa önbelleği için kullanılan belleği kontrol eder ve genellikle sistemin toplam RAM'inin %25'ine ayarlanır.

  
  

• work_mem : Bir sorguda işlem başına ayrılan belleği ayarlar. Zaman Ölçeğinde önerilen ayar (25 % of RAM) / max_connections şeklindedir.

  
  

• max_connections : Veritabanına izin verilen maksimum eşzamanlı bağlantı sayısını ayarlar. Bağlantı havuzlayıcıları birçok kısa ömürlü bağlantının yönetilmesine yardımcı olabilir.

  
  

• max_worker_processes : PostgreSQL'in başlatabileceği maksimum çalışan işlem sayısını belirler. Zaman Ölçeği kullanılıyorsa bu parametreyi ayarlamak için formül şu şekildedir: max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers .

  
  

• max_parallel_workers : paralel sorguları destekleyen maksimum çalışan sayısını belirtir. Varsayılan, bunu mevcut CPU sayısına eşit olarak ayarlamaktır.

  
  

• autovacuum_max_workers : eşzamanlı autovacuum işlemlerinin maksimum sayısını belirler. Zaman Ölçeği'nde varsayılan olarak 10'a ayarlıdır.

İndeksleme hijyenini uygulayın

Dizinleri düzenli olarak optimize etmek, özellikle veritabanı ölçeklenirken PostgreSQL'inizin verimli kalmasına yardımcı olacaktır. Dizinler akıllıca kullanıldığında sorgu performansını artırmanıza yardımcı olabilirken, aşırı dizinler büyük PostgreSQL dağıtımlarında sorunlara neden olabilir.

Aşırı indekslemenin en belirgin sonucu, depolama tüketiminin artmasıdır; çünkü her indeks, tabloların boyutuyla orantılı olarak büyüyen ayrı depolama gerektirir. Bu ek yük, Timescale'in hiper tablolarında olduğu gibi tablolar bölümlendiğinde daha önemli hale gelebilir.

Her yeni veri girişi veya değişikliği eşzamanlı dizin güncellemelerini gerektirdiğinden ve daha fazla G/Ç işlemine ve potansiyel tablo şişkinliğine yol açtığından, gereksiz dizinler yazma işlemlerinizi iyileştirmede verimsiz olabilir. Dizinlerinizi izlemek, hangilerinin artık kullanılmadığını belirlemenize ve işleri yalın tutmanıza yardımcı olacaktır.

Bunu yapmanın bir yolu pg_stat_user_indexes kullanmaktır:

 -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname;

Bir indeksin idx_scan sütununda 0 değeri varsa bu, istatistiklerin son sıfırlanmasından bu yana kullanılmadığı anlamına gelir, bu da optimizasyona aday olabileceği anlamına gelir. idx_scan için düşük bir eşik ayarlayarak sık kullanılmayan dizinleri de tanımlayabilirsiniz.

Zaman Ölçeği sıkıştırmasıyla büyük tablolarınızı küçültün

Timescale'in öne çıkan özelliklerinden biri, sorgu performansından ödün vermeden büyük tablolar tarafından kullanılan disk alanını büyük ölçüde azaltabilen sütunlu sıkıştırmaya yönelik yerel desteğidir. Sıkıştırma birçok sorgunun performansını artırır.

Timescale'in sıkıştırması, normal satır tabanlı verileri daha kompakt bir sütunlu formata dönüştürerek çalışır. Bu süreç özellikle birçok sütunun yinelenen değerler içerebildiği zaman serisi verileri için etkilidir; her veri türüne bağlı olarak farklı sıkıştırma algoritmaları uygulayarak etkileyici sıkıştırma oranlarına (+%90) ulaşabiliriz. Bu, büyük masalarınızın 10 kata kadar küçültülebileceği anlamına gelir.

Zaman Ölçeği'nde sıkıştırma, zamana dayalı bir sıkıştırma ilkesi aracılığıyla tablo bazında etkinleştirilir. Örneğin, bu kod belirli bir hiper tabloda sıkıştırmayı etkinleştirir ve iki haftadan eski verileri otomatik olarak sıkıştırır:

 -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks');

Sıkıştırma hakkında daha fazla bilgi edinmek için, belgelerimize göz atın .

Bir veri yönetimi stratejisi oluşturun: Eski verileri daha ucuz bir depolama alanına taşıyın, artık ihtiyacınız olmayan verileri silin

Önceki taktikler veritabanı boyutunuzu küçültmede çok faydalıdır, ancak zaman ölçeğinde depolamanızı etkili bir şekilde ölçeklendirmek için kullanabileceğiniz başka bir yol daha vardır: katmanlı depolama.

Basit bir katmanlama politikası oluşturarak daha eski, daha az erişilen verileri dipsiz bir nesne depolama katmanına taşıyabilirsiniz:

 -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month);

Bu nesne deposu aşağıdaki özelliklere sahiptir:

• Yüksek performanslı depolamamıza göre daha düşük bir fiyatla gelir ve çok daha ucuza çok sayıda TB veri depolamanıza olanak tanır.
• Sonsuzdur, yani istediğiniz kadar veri depolayabilirsiniz.
  

Bu katmanlı depolama mimarisi, Timescale'in arka ucuna yerleştirilmiştir. Nesne depolama, veritabanınızdan ayrılmış bir "kova" değildir; bunun yerine onun ayrılmaz bir parçasıdır. Sorgular, herhangi bir işlem yapmanıza gerek kalmadan her iki depolama katmanına da şeffaf bir şekilde erişecektir; aynı şema üzerinden standart SQL'i kullanmaya devam edebilirsiniz. Katmanlama politikanız belirlendikten sonra dikkate almanız gereken başka bir şey yoktur!

Performans maliyeti olduğundan (nesne deposu normal depolamamız kadar hızlı değildir), uygulamanız tarafından sıklıkla erişilmediği durumlarda verileri düşük maliyetli depolama katmanına taşımanızı öneririz. Ancak bu veriler üzerinde anlık sorguları (örneğin, müşterilerinizin kullanıcı deneyimi açısından kritik olmayan ve en yüksek performansın gerekli olmadığı sorgular) rahatça çalıştırmaya devam edebilirsiniz.

Timescale, bu düşük maliyetli depolama katmanını sunmanın yanı sıra, artık ihtiyacınız olmayan verileri silmek için veri saklama politikaları oluşturmayı da kolaylaştırır:

 -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months');

Veri kümenizi etkili bir şekilde alt örneklemek için yukarıdaki gibi veri saklama politikalarını sürekli toplamalarla birleştirebilirsiniz; örneğin, ayrıntı düzeyini bir saniyeden bir dakikaya düşürmek, bir saniyelik değerleri silmek, ancak bir dakikalık toplamları tutmak. Bunun nasıl yapılacağına ve uzun vadeli verilerin proaktif olarak nasıl yönetileceğine ilişkin bir örnek görmek için bu blog gönderisini okuyun .

Kullanıma Dayalı Modeller ve Veri Yönetimi Paradigması

Kullanıma dayalı modeller ilk bakışta bir fiyatlandırma değişikliğinden başka bir şey gibi görünmese de, geliştiricilerin veritabanı boyutları hakkındaki düşüncelerine ve verileri nasıl algılayıp işlediklerine ilişkin bir paradigma değişikliğine neden oluyor.

Kullanıma dayalı modeller, odağın yalnızca depolama yönetiminden veritabanı sağlığı ve verimliliğine kaydığı sürekli iyileştirme kültürünü teşvik eder. Bu, başlangıçta biraz disiplin gerektirir, ancak zihniyetiniz değişip bazı teknikleri öğrendikten sonra PostgreSQL veritabanınızı verimli ve etkili bir şekilde ölçeklendirmek için en iyi yerde olacaksınız.

Timescale, PostgreSQL veritabanı boyutunuzu sistematik olarak azaltmanıza yardımcı olacak sıkıştırma, katmanlı depolama ve veri saklama politikaları gibi değerli araçlara sahiptir. Bu, PostgreSQL veritabanlarınızı kullanıma dayalı bir modelde etkili bir şekilde ölçeklendirmenize olanak tanır. Kendiniz deneyimlemek için Timescale'e kaydolun; ilk 30 gün boyunca ücretsiz olarak kullanabilirsiniz. .

- Carlota Sota tarafından yazıldı.