paint-brush
PostgreSQL Veritabanlarını Ölçeklendirmek Artık Daha Ucuz: Timescale'in Katmanlı Depolaması Genel Kullanıma Çıktıile@timescale
620 okumalar
620 okumalar

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

ile Timescale14m2023/11/16
Read on Terminal Reader

Çok uzun; Okumak

Timescale, PostgreSQL veritabanları için devrim niteliğinde çok katmanlı bir depolama mimarisi olan Katmanlı Depolamanın Genel Kullanılabilirliğini duyurdu. Bu yenilik, geliştiricilerin zaman serileri ve analitik veritabanları için sonsuz, düşük maliyetli ölçeklenebilirlik elde etmelerine olanak tanır. Katmanlı Depolama ile daha eski ve sık erişilmeyen veriler otomatik olarak daha uygun fiyatlı bir depolama katmanına taşınarak performanstan ödün vermeden maliyetler azaltılabilir. Mimari, PostgreSQL'in hiper tablolarını kullanarak kesintisiz veri yönetimini destekleyerek büyük ölçekli dağıtımlar için basit ve uygun maliyetli bir çözüm sunar. Düşük maliyetli depolama için GB/ay başına 0,021 ABD doları tutarındaki sabit fiyatlandırma modeli, onu şeffaf ve öngörülebilir hale getirerek geliştiricilerin veritabanlarını verimli bir şekilde ölçeklendirmesini sağlar.
featured image - PostgreSQL Veritabanlarını Ölçeklendirmek Artık Daha Ucuz: Timescale'in Katmanlı Depolaması Genel Kullanıma Çıktı
Timescale HackerNoon profile picture


Amazon RDS for PostgreSQL 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.


Tablolar milyarlarca satıra ulaştığında performans düşer ve onu iyileştirmenin yolları var 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.


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:


  1. En güncel verileriniz, hızlı sorgular ve yüksek alımlar için optimize edilmiş yüksek performanslı bir depolama katmanına yazılacaktır.


  2. Bu verilere sık sık erişmediğinizde, bir katmanlama politikası oluşturarak verileri otomatik olarak daha düşük maliyetli bir nesne depolama katmanına 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). 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.


Timescale artık hem hızlı sorgu performansından hem de uygun fiyatlı ölçeklenebilirlikten yararlanmak için iki depolama katmanını birleştiren Katmanlı Depolama arka ucuna sahip



Geliştiricilerin AWS'deki 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ı da gerekiyor.


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 hipertablolar Etkili veri yönetimi için. Bir hiper tablo oluştururken artık her iki depolama katmanına da sorunsuz bir şekilde yayılabilir; bir sorgu çalıştırdığınızda 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.


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:


  • Sıkıştırmadan sonra yüksek performanslı depolama katmanımızda 5 TB depolarız. 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 (!)


  • 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 basit API 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.


Editörün Notu: 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.


Örneğin, bu politika, bir aydan eski tüm verileri events hiper tablosundaki nesne depolama alanına taşır:


 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 ( örneğin verileri doldurmanız veya güncellemeniz gerekiyorsa ), kolayca "kademesini çözebilirsiniz".


 -- 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:


Zaman Ölçeği kullanıcı arayüzündeki Genel Bakış ekranı, düşük maliyetli depolama katmanında ne kadar veriye sahip olduğunuzu ve bunun için ne kadar ödeyeceğinizle ilgili bir tahmini gösterir.


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 sıkıştırmadan sonra (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.


Verileri katmanlandırırken, yürütülen sorgular veya taranan veri miktarı için değil, yalnızca depoladığınız veriler için ödeme 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ı.


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, yani %78'e düşürebilirsiniz. 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).


Nadiren erişilen verilerinizi düşük maliyetli depolama katmanına taşımak, önemli ölçüde paradan tasarruf etmenizi sağlayacak ve depolama faturanızı oldukça uygun hale getirecektir.


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, düşük maliyetli depolamada birincil ile paylaşılan veriler için faturalandırılmazsınız . 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. .


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: ayda 4.000$'dan fazla tasarruf edersiniz! 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.


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.


Veri hacmi ön sıkıştırması, 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.


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 Apache Parquet ) 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. yerel sütunlu sıkıştırma ) 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.


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 EXPLAIN yan tümcesiyle), veritabanı nesne depolama katmanındaki verilere erişirken sorgu planının nasıl bir Foreign Scan içerdiğini görebilirsiniz. Bu örnekte, devices ve sites standart Postgres tablolarıdır (yalnızca yüksek performanslı depolamada bulunur), metrics ise her iki depolama katmanına yayılan bir hiper tablodur. Bu sorgu metrics tabloya karşı yürütülürken, onun üç parçası standart depolamadan ve beş parça ise nesne depolamadan okundu.



 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 Foreign Scan on osm_chunk_3334 , dipsiz nesne depolama katmanından veri alınmasına karşılık gelir.


İş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 device_id ve value sütunları okunur. Ek bir zamana dayalı WHERE 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.


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 fazla bilgi ve kullanım senaryosu uyumları için Dokümanlarımıza göz atın. Daha pratik bir bakış açısı arıyorsanız şunu da deneyebilirsiniz: Ü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.