PostgreSQL Veritabanlarını Ölçeklendirmek Artık Daha Ucuz: Timescale'in Katmanlı Depolaması Genel Kullanıma Çıktı

Amazon RDS for gibi ürünler daha küçük dağıtımlar için uygundur ancak PostgreSQL'i ölçeklendirmek farklı bir hikaye. Proje terabaytlara ulaştığında, bu yönetilen veritabanları yavaşlar ve pahalılaşır, bu da veri yönetimini çok daha karmaşık hale getirir. PostgreSQL Tablolar milyarlarca satıra ulaştığında performans düşer ve veriler büyümeye devam edecek. Uygun veri yönetimi olmadan, geliştiriciler yalnızca disklerinin (ve faturalarının) boyutlarının artmasını izleyebilirler. onu iyileştirmenin yolları var Ama artık değil. Bugün, Zaman Ölçeği platformundaki zaman serileriniz ve analitik veritabanlarınız için sonsuz, düşük maliyetli ölçeklenebilirlik sağlamak üzere tasarlanmış çok katmanlı bir depolama mimarisi olan Katmanlı Depolamanın Genel Kullanılabilirliğini duyurmaktan mutluluk duyuyoruz. Artık eski, seyrek erişilen verilerinizi düşük maliyetli bir depolama katmanında depolayabilir ve sık eriştiğiniz verilerinizin performansından asla ödün vermeden bu verilere erişmeye devam edebilirsiniz. Yeni çok katmanlı depolama arka ucumuzla Zaman Ölçeği zaman serisi veritabanına veri eklediğinizde aşağıdakiler gerçekleşir: En güncel verileriniz, hızlı sorgular ve yüksek alımlar için optimize edilmiş yazılacaktır. yüksek performanslı bir depolama katmanına Bu verilere sık sık erişmediğinizde, bir katmanlama politikası oluşturarak verileri otomatik olarak katmanlandırabilirsiniz. Düşük maliyetli depolama katmanındaki veriler, veritabanınızda tamamen sorgulanabilir durumda kalır ve depolayabileceğiniz veri miktarında herhangi bir sınırlama yoktur (yüzlerce TB'ye kadar veya daha fazla). daha düşük maliyetli bir nesne depolama katmanına Düşük maliyetli depolama katmanımızın veri için GB başına aylık 0,021 USD sabit fiyatı vardır; bu, Amazon S3'ten daha ucuzdur. Geliştiricilerin büyük PostgreSQL veritabanlarını performanstan ödün vermeden ölçeklendirmenin ucuz bir yoluna ihtiyacı var. Nesne depoları inanılmaz derecede ölçeklenebilir ve uygun fiyatlı olsa da en hızlıları değiller ve geliştiricilerin uygulamaları için milisaniyelik sorgu yanıtları alması gerekiyor. AWS'deki da Ancak veriler yaşlandıkça ve nadiren erişildikçe, gerçek zamanlı performans çoğu zaman o kadar önemli olmuyor. Geliştiricilerin geçici sorgular, veri analizi veya mevzuata uygunluk için bu geçmiş verilere hâlâ erişebilmesi gerekir, ancak bu tür sorgular için bir miktar gecikme olduğunu varsayabilirler. Artık geliştiricilerin istediği şey, bu geçmiş verileri mümkün olduğunca uygun maliyetli ve verimli bir şekilde saklama yeteneğidir. Bu yeni Katmanlı Depolama mimarisi, geliştiricilerin gerçek zamanlı uygulamalar için depolama maliyetleri ve performans ödünleri arasında seçim yapma zorunluluğunu ortadan kaldırır. Güncel ve sık erişilen verilerini yüksek performans katmanında tutarak Timescale'in milisaniyelik sorgu hızından ve alma özelliklerinden yararlanacaklar ve eski verilerini katmanlayarak PostgreSQL veritabanlarında ihtiyaç duydukları sayıda TB'yi tutabilecekler. az. Katmanlı Depolama ile PostgreSQL Veri Yönetimi: Bilmeniz Gerekenler Timescale'in Katmanlı Depolama mimarisi PostgreSQL'in esnekliğinden yararlanır ve Etkili veri yönetimi için. Bir hiper tablo oluştururken artık her iki depolama katmanına da sorunsuz bir şekilde yayılabilir; Timescale, yanıt oluşturmak için hangi depolama katmanlarına erişilmesi gerektiğini sorunsuz bir şekilde belirler, en güncel verileriniz için performansı artırır ve daha eski veriler için depolama maliyetlerini düşürür. Sorgu başına veya veri okuma başına ekstra ücret yoktur ve gizli ücretler yoktur; böylece basit, uygun maliyetli veri yönetimi sağlanır. hipertablolar bir sorgu çalıştırdığınızda Bu depolama mimarisi aynı zamanda Timescale hizmetlerinde her türlü depolama sınırlamasını da ortadan kaldırır: Düşük maliyetli depolama katmanımız sonsuz olduğundan, istediğiniz kadar TB depolayabilirsiniz. Örneğin, Insights ürünümüzü destekleyen devasa Zaman Ölçeği veritabanını depolamak için dahili olarak Katmanlı Depolamadan yararlanıyoruz. Bu Insights veritabanı, müşteri filomuzdaki sorgu istatistiklerini sürekli olarak topluyor ve analiz ediyor; bugün 350 TB'ı aştı ve hızla büyüyor. Bu 350 TB'ın 250 TB'ı düşük maliyetli depolamaya ayrılmıştır. Hadi matematik yapalım: Elbette, sıkıştırmayı etkinleştirdik ve 20x sıkıştırma oranları elde ediyoruz; bu, başlangıçta 100 TB olan Postgres verilerinin, sıkıştırma sayesinde artık 5 TB'lık bir diske sığdığı anlamına gelir (!) Sıkıştırmadan sonra yüksek performanslı depolama katmanımızda 5 TB depolarız. Geriye kalan 250 TB veri, düşük maliyetli depolama katmanında depolanır. Bu katmanlama, veriler şu anda birkaç haftalık olan belirli bir yaşa ulaştığında otomatik olarak gerçekleşir. Büyük dağıtımlara sahip müşterilerimiz de zaten Katmanlı Depolamadan yararlanıyor: "Piyasa verileri üzerinde çok fazla analiz gerçekleştiriyoruz ve depolamamız gereken veri hacmi, normal disk tabanlı bir veritabanı çözümünü olanaksız hale getiriyor (bu çok pahalı). Timescale'in Katmanlı Depolaması, büyük hacimli verileri sorunsuz bir şekilde nesne depolama katmanı. Bu, büyük hacimli geçmiş verileri depolamak ve analiz sonrası gerçekleştirmek için harika bir çözüm. Bu olmasaydı, şirket içinde bir çözüm geliştirmek zorunda kalırdık." - Tescilli bir Dijital Varlık Ticaret Şirketinde Teknolojiden Sorumlu Başkan Basitlik, Katmanlı Depolamanın temel özelliğidir. Verilerinizi yüksek performanslı katmandan düşük maliyetli nesne katmanına taşımak için tek yapmanız gereken Verilerinizi belirli bir hiper tabloda yaşlandıkça katmanlandıracak politikaları tanımlamak için. Veri katmanlama politikaları yığın esasına göre çalışır (politika, tam parçaları, politika tarafından tanımlanan yaşa ulaştıklarında katmanlandırır). Herhangi bir ETL (çıkarma-dönüştürme-yükleme) işlemine veya altyapı değişikliğine gerek yoktur. basit API Zaman ölçeği hiper tabloları zamana göre otomatik olarak bölümlenen PostgreSQL tablolarıdır. Bu bölümlere parçalar denir. Parçalar, Zaman Ölçeği'ndeki kullanıcı tanımlı politikaların birimidir: örneğin, bir veri saklama ilkesi tanımladığınızda, tüm bölümleri (parçaları) sileceksiniz ve verileri depolama katmanları arasında taşıdığınızda, tüm parçaları taşıyacaksınız. . Bu, verileri kaynak kullanımı ve geliştirici deneyimi perspektifinden yönetmenin çok kullanışlı bir yoludur. Editörün Notu: Örneğin, bu politika, bir aydan eski tüm verileri hiper tablosundaki nesne depolama alanına taşır: events SELECT add_tiering_policy('events', INTERVAL '1 month'); İhtiyacınız olan tek şey bu! Yalnızca uygun katmandaki SQL sorgularını yürüten akıllı sorgu planlaması da dahil olmak üzere geri kalan her şey otomatik olarak gerçekleşir. Halihazırda düşük maliyetli depolama katmanında depolanan verileri bırakmak için, verilerin belirli bir süre sonra (örneğin beş yıl sonra) otomatik olarak silinmesini sağlayacak bir veri saklama politikası tanımlayabilirsiniz. . Ayrıca belirli parçaları manuel olarak da silebilirsiniz Ayrıca, belirli bir parçayı düşük maliyetli depolama katmanından yüksek performanslı katmana "geri taşımak" istiyorsanız ( ), kolayca "kademesini çözebilirsiniz". örneğin verileri doldurmanız veya güncellemeniz gerekiyorsa -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk'); Zaman Ölçeği konsolunda ne kadar verinin katmanlandığını (ve ay sonunda ne kadara mal olacağını) takip edebilirsiniz: Ve fatura tahminlerinden bahsetmişken… Katmanlı Depolama ile ne kadar tasarruf edebilirim? Yüksek performanslı depolama katmanımızın geçerli fiyatı GB/ay veri başına 0,177 USD'dir (Filomuz genelinde gördüğümüz beklenen sıkıştırma oranı dikkate alındığında). Buna artık tüm bulut bölgelerinde aynı fiyatla GB/ay veri başına 0,021 ABD doları sabit ücretle düşük maliyetli bir depolama katmanı da eklendi. sıkıştırmadan sonra Verileri katmanlandırırken, yürütülen sorgular veya taranan veri miktarı için değil, yaparsınız: bu gerçekten sabit bir fiyattır. Bu fiyatlandırma yapısıyla amacımız, toplam veri depolama maliyetini hesaplamanın şeffaf, net ve basit bir yolunu sağlayarak verilerinizi yönetmeyi kolaylaştırmaktı. yalnızca depoladığınız veriler için ödeme Kısa bir örnek olarak, 5,2 TB depolama alanına sahip bir hipertablonuz olduğunu varsayalım; en yeni hipertablo parçaları ve diğer Postgres tabloları yaklaşık 200 GB ve bir aydan daha eski olan yaklaşık 5 TB hipertablo verisini kaplıyor. Bu eski verilere sık sık erişmiyorsunuz veya bunları sorgulamıyorsunuz, bu da uygulamanızın günlük işlemleri için bu verilere ihtiyacınız olmadığı anlamına geliyor. Yine de, geçici sorgular veya uyumluluk gereklilikleri için veritabanınızda erişilebilir kalmasını isteyebilirsiniz (bu tür durumları müşterilerimiz arasında çok görüyoruz). Uygun maliyetli bir veri yönetimi stratejisi olarak, bir aydan eski tüm parçaları düşük maliyetli katmana katmanlandırabilir ve bu 5 TB veriyi depolamanın maliyetini ayda yaklaşık 478 ABD Dolarından yaklaşık 105 ABD Dolarına, düşürebilirsiniz. ( yani %78'e Depolama faturanızda. Bu tahmin için, hiper tablonuz için sıkıştırmayı etkinleştirdiğinizi varsayıyoruz ve tüm Zaman Ölçeği hizmetlerinde ortalama genel sıkıştırmayı dikkate alıyoruz). Verilerinizle birlikte tasarruf da artacaktır: Birden fazla terabaytı bu düşük maliyetli katmana taşıdığınızda, depolama faturanız binlerce dolardan birkaç yüze düşecektir. Aşağıdaki referans tablosu, düşük maliyetli depolama katmanımızın gerçekte ne kadar uygun fiyatlı olduğunu göstermektedir. Demek istediğimi anladınız! Katmanlı Depolamanın tasarrufları çarpma etkisi Katmanlı Depolamayı daha da şaşırtıcı kılan bir şey daha var: Verileri düşük maliyetli depolama katmanında tuttuğunuzda, hizmetinizde yüksek kullanılabilirliğe sahip bir replika veya okuma replikalarının çalışıp çalışmadığından bağımsız olarak bu veriler için yalnızca bir kez ödeme yaparsınız. . Aynı durum çatallar için de geçerlidir. Timescale'de, örneğin testleri çalıştırmak veya geliştirme ortamları oluşturmak için kullanıcı arayüzündeki bir düğmeyi tıklatarak birincil veritabanınızın kopyalarını (biz bunlara çatal diyoruz) oluşturabilirsiniz. Bir (veya daha fazla) çatal oluşturduğunuzda, . Birincil olmayan daha fazla veriyi katmanlandırmaya karar verirseniz, bunu düşük maliyetli katmanda depolamak için ödeme yaparsınız ancak yine de verileri çatalın yüksek performans katmanından daha ucuz katmana taşıyarak önemli tasarruflardan yararlanırsınız. . düşük maliyetli depolamada birincil ile paylaşılan veriler için faturalandırılmazsınız Bunu netleştirmek için bir örnek verelim. 6,5 TB veri içeren bir birincil hizmetiniz olduğunu ve şunları da ayarladığınızı düşünün: Arızalardan kaynaklanan kesinti ve veri kaybı riskini önemli ölçüde azaltan yüksek kullanılabilirliğe sahip bir kopya Okuma sorgularınıza hizmet edecek ve birincilin kendisini tamamen yazma işlemlerine adamasını sağlayacak bir okuma kopyası Bu hizmetin geliştirme ve test amaçlı bir çatalı Faturalandırma açısından bakıldığında, yüksek performanslı depolama katmanındaki birincil hizmetinizdeki 6,5 TB veriyi sakladıysanız, iki kopyayı (çatal ve) hesaba katacak şekilde depolama faturanıza [6,5 TB x 4] yansıtıldığını görürsünüz. birincil hizmet - toplamda 26 TB. Medyan sıkıştırma oranımızı varsayarsak, bu maliyetli olacaktır: yaklaşık 4.602$/ay. Peki uygulamanızın yalnızca en güncel 500 GB'lık verilere aktif olarak erişmesi gerekiyorsa ne olur? 6 TB'yi düşük maliyetli depolamaya katmanlayabilir ve yüksek performanslı depolama katmanınızda yalnızca 500 GB'ı tutabilirsiniz. Düşük maliyetli depolama katmanınızdaki veriler için yalnızca bir kez ödeme yapacağınız için yeni depolama faturanız şu şekilde görünecektir: [500 GB x 4] = Yüksek performanslı depolamada 2 TB (26 TB yerine) Düşük maliyetli depolama katmanında [6 TB x 1] Yukarıdaki depolama faturası ayda yaklaşık 480$'a ulaşır: Bu, Katmanlı Depolamanın tasarrufları çarpma etkisidir. Özellikle replika veya çatal çalıştırıyorsanız, düşük maliyetli depolama katmanından yararlanmak harika bir fikirdir; genel faturanızda göreceğiniz tasarruflar çok önemli olacaktır. ayda 4.000$'dan fazla tasarruf edersiniz! Kademeli Depolama Yolculuğumuz Mart ayında Timescale platformunda Katmanlı Depolama işlevimizin erken bir sürümünü Erken Erişim olarak yayınladık. Birçok iyileştirmeden sonra artık Genel Kullanılabilirliğe ulaştı. İlk sürümünden bu yana Katmanlı Depolamayı istikrarlı, güvenilir ve daha hızlı hale getirmek için çok çalıştık. Ayrıca, düşük maliyetli depolama katmanımızı fiyatlandırmak için birden fazla yolu sürekli olarak yineleyerek fiyatlandırma modelimiz hakkında uzun uzun düşündük. Son olarak en basitine yöneldik: veri hacmi ön sıkıştırması üzerinden sabit bir oran. Basit ve öngörülebilir fiyatlandırmaya ne kadar değer verdiğimizi zaten belirtmiştik, ancak GB/ay başına mümkün olduğunca düşük bir fiyat sunmak da bizim için önemliydi. Fiyatımız 0,021 ABD dolarına düştü; karşılaştırma olarak, dosyaları Amazon S3'te depolama maliyetleri . GB başına 0,023 USD/ay Şahsen ben (Yannis), lider ekiplerin on yılı aşkın bir süre boyunca bulutta yerel çözümler üretmesine rağmen, hâlâ geriye dönüp çeşitli bulut fiyatlandırma sayfalarındaki birden çok ücret tablosunu ara sıra yeniden kontrol etmem, özellikle de her seferinde ekstra ücretler aramam gerektiğini itiraf etmeliyim. Hizmetlerimizin toplam maliyetini doğru bir şekilde hesaplamak istiyorum. Timescale olarak, bir veritabanı hizmetini çalıştırabilmek veya depolama katmanları hakkında bilinçli seçimler yapabilmek için karmaşık bir elektronik tablo oluşturmanıza gerek olmadığına inanıyoruz. Geliştiricilerin hayatlarını kolaylaştırma taahhüdümüz bizi GB başına aylık 0,021 ABD doları sabit ücrete götürdü; tahmine dayalı bir çalışma, gizli maliyetler veya sorgu veya veri okuma başına ücret yok. Zaman Ölçeği sıkıştırması uygulanmadan önceki veri hacmi anlamına gelir. Örneğin, Zaman Ölçeği sıkıştırması nedeniyle, yüksek performanslı depolama katmanındaki 500 GB'lik bir birim, sıkıştırıldıktan sonra yalnızca 50 GB disk alanına ihtiyaç duyabilir. Bu verileri düşük maliyetli depolamaya katmanlamaya karar verirseniz faturanız, aylık [500 GB * 0,021 ABD doları] şeklinde olduğu gibi orijinal 500 GB hacim üzerinden hesaplanır. Veri hacmi ön sıkıştırması, Katmanlı Depolama Nasıl Çalışır: Perde Arkası Timescale'e eklenen tüm veriler başlangıçta yüksek performanslı depolama katmanımıza yazılır. En güncel verileriniz için daha hızlı diskler kullanmak, en güncel değerleriniz için en iyi ekleme ve sorgulama performansını sunacaktır; bu, veri yoğunluklu uygulamaların ihtiyaçlarına uygun bir kullanım modelidir. Aksine, düşük maliyetli depolama katmanı Amazon S3 üzerine kurulu bir nesne deposudur. Ancak bu nesne deposu, verilerinizi arşivlemek için kullanılan harici bir paketten çok daha fazlasıdır: veritabanınızın ayrılmaz bir parçasıdır. Verileri bu nesne depolama katmanına taşıdığınızda, veritabanınız tüm anlambilim ve meta verilerden tamamen haberdar olmaya devam edecek ve standart SQL ile (daha düşük performansla da olsa) her zamanki gibi sorgulamaya devam edebileceksiniz. Perde arkasında, verileri sıkıştırılmış sütunlu bir formatta (özellikle ) saklıyoruz. Veriler katmanlı hale getirildiğinde, parçalar Timescale'in yerel dahili veritabanı formatında (tipik olarak bizim veri tabanımızda) depolanır. ) eşzamansız olarak Parquet formatına dönüştürülür ve temeldeki S3 nesnesinde depolanır. Katmanlı parçaların yüksek performanslı katmandan işlemsel olarak kaldırılmadan önce düşük maliyetli depolama katmanında dayanıklı bir şekilde depolanmasını sağlamak için çeşitli mekanizmalar geliştirdik. Apache Parquet yerel sütunlu sıkıştırma SQL sorgunuzu çalıştırdığınızda, gerektiği şekilde yüksek performanslı depolama katmanından, nesne depolama katmanından veya her ikisinden şeffaf bir şekilde veri çeker. Şeffaf derken, şeffaf demek istiyoruz: Zaman ölçeği, karmaşık yüklemler, JOIN'ler, CTE'ler, pencereleme, hiper işlevler ve daha fazlası dahil olmak üzere standart ve katmanlı verileri genelinde keyfi olarak karmaşık sorguları destekler. Aşağıdaki örnek sorguda (bir yan tümcesiyle), veritabanı nesne depolama katmanındaki verilere erişirken sorgu planının nasıl bir içerdiğini görebilirsiniz. Bu örnekte, ve standart Postgres tablolarıdır (yalnızca yüksek performanslı depolamada bulunur), ise her iki depolama katmanına yayılan bir hiper tablodur. Bu sorgu tabloya karşı yürütülürken, onun üç parçası standart depolamadan ve beş parça ise nesne depolamadan okundu. EXPLAIN Foreign Scan devices sites metrics metrics EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text) Yukarıdaki sorgu planında , dipsiz nesne depolama katmanından veri alınmasına karşılık gelir. Foreign Scan on osm_chunk_3334 İşleme parçalarının sorgunun zaman penceresinin dışına çıkmasını önlemek için, yalnızca sorguyu karşılamak için gereken parçalara dokunmak üzere parça hariç tutma işlemi gerçekleştiririz. Veritabanı, nesne depolama içindeki satır gruplarının ve sütunsal uzaklıkların bir "haritasını" oluşturmak için çeşitli meta veri biçimlerini saklar. Ayrıca bir sorgu çalıştırıldığında okuduğu veriler konusunda daha seçici olur. Sorgunuz yalnızca belirli bir satır aralığına ve birkaç sütuna dokunuyorsa, düşük maliyetli depolama katmanının arkasındaki S3 nesnesinden yalnızca verilerin bu alt kümesi okunur. Örneğin yukarıda, nesne depolama katmanından yalnızca ve sütunları okunur. Ek bir zamana dayalı filtresi eklenseydi, veritabanı ilk önce meta verilerini (yüksek performanslı depolamada depolanan ve bellekte önbelleğe alınan) kullanarak sorguyu yürütmek için hangi Parquet dosyalarının ve satır gruplarının okunması gerektiğini daha da azaltırdı. Bunların hepsi, bu dipsiz depolamaya PostgreSQL aracılığıyla şeffaf bir şekilde erişirken bile sorgu gecikmesini azaltmak için. device_id value WHERE Katmanlı Depolamayı Deneyin Geçmiş verilere ilişkin depolama kararlarının maliyetli olması gerekmez. Timescale'de artık uygulamanızın performansından ödün vermeden veritabanı depolama alanınızı uygun bir fiyata ölçeklendirmenize olanak tanıyan, hiçbir fiyatlandırma avantajı olmayan düşük maliyetli, sonsuz bir depolama katmanına erişiminiz var. Bunun kullanım durumunuz için iyi bir çözüm olup olmadığını merak ediyorsanız, Daha pratik bir bakış açısı arıyorsanız şunu da deneyebilirsiniz: . Daha fazla bilgi ve kullanım senaryosu uyumları için Dokümanlarımıza göz atın. Ücretsiz denememiz aracılığıyla Timescale platformunda kendiniz için Katmanlı Depolama'yı ücretsiz yapın (kredi kartı gerekmez) - Yannis Roussos, Carlota Soto ve Ana Tavares tarafından yazılmıştır. Burada da yayınlandı.