Büyük PostgreSQL Veritabanlarında Sütun Sıkıştırmasını Uygulama Stratejileri

Postgres veritabanını ölçeklendirmek, büyüyen uygulamalar için bir geçiş törenidir. Tablolarınızın milyonlarca, hatta milyarlarca satırla genişlediğini gördüğünüzde, bir zamanlar hızlı olan sorgularınız gecikmeye başlar ve artan altyapı maliyetleri, kârlılığınıza uzun bir gölge düşürmeye başlar. Bir açmazın içindesiniz: sevdiğiniz PostgreSQL'den ayrılmak istemiyorsunuz, ancak görünen o ki, büyüyen veri kümelerinizle başa çıkmanın daha etkili bir yoluna ihtiyacınız olacak.

Bu makalede, PostgreSQL'in ölçeklenebilirliğini artırmak amacıyla esnek, yüksek performanslı bir sütunlu sıkıştırma mekanizmasını nasıl oluşturduğumuzun öyküsünü anlatacağız. Sütunlu depolamayı özel sıkıştırma algoritmalarıyla birleştirerek, diğer hiçbir ilişkisel veritabanında benzeri olmayan etkileyici sıkıştırma oranlarına (+%95) ulaşabiliyoruz.

Veri kümenizi sıkıştırarak PostgreSQL veritabanlarınızı daha da büyütebilirsiniz. Bu makalede göreceğimiz gibi, bu son derece etkili sıkıştırma tasarımı, büyük PostgreSQL tablolarınızın boyutunu 10-20 kata kadar azaltmanıza olanak tanır. Sorgu performansını artırırken daha küçük disklerde çok daha fazla veri depolayabilir (diğer bir deyişle paradan tasarruf edebilirsiniz). Zaman ölçeği sıkıştırması da tamamen değiştirilebilir, bu da veritabanı yönetimini ve işlemlerini kolaylaştırır: sıkıştırılmış tablolara sütun ekleyebilir, değiştirebilir ve bırakabilirsiniz ve verileri doğrudan EKLEYEBİLİR, GÜNCELLEYEBİLİR ve SİLEBİLİRSİNİZ.

Daha ölçeklenebilir bir PostgreSQL'e hoş geldiniz!

İçeriğe Genel Bakış

• PostgreSQL'in Neden Veritabanı Sıkıştırmasına İhtiyacı Var?
• Peki ya TOAST?
• Sıkıştırma Neden PostgreSQL'e Özgü Değil? Satır ve Sütun Odaklı Veritabanlarına Giriş
• Satır ve Sütun Odaklı Veritabanları: Ne Seçilmeli?
• Satır Odaklı Bir Veritabanında Sütunlu Depolama Oluşturma
• PostgreSQL'i hibrit satır sütunlu bir depoya dönüştürme
• Perde arkası: Satır verilerinden sıkıştırılmış sütunlu dizilere
• Sıkıştırılmış verileri verimli bir şekilde sorgulama
• Yaygın olarak sorgulanan verileri segmentby göre sütuna göre gruplandırma
• segmentby sütunları tanımlama
• orderby aracılığıyla gelişmiş ince ayar
• Zaman Ölçeği Sıkıştırmasının Evrimi
• Nihai Sonuç: Daha Hızlı Sorgular, Büyük PostgreSQL Veritabanları İçin Daha Az Depolama Alanı
• Sıkıştırma ve Katmanlı Depolama: Zaman ölçeğinde depolama yaşam döngüsü
• PostgreSQL'de Kalın

PostgreSQL'in Neden Veritabanı Sıkıştırmasına İhtiyacı Var?

Ancak sıkıştırmayı nasıl oluşturduğumuzun ayrıntılarına girmeden önce, birkaç dakikamızı şu soruyu yanıtlamaya ayıralım: PostgreSQL'e yeni bir veritabanı sıkıştırma mekanizması eklemek neden gerekli?

Öncelikle modern uygulamaların ihtiyaçlarını ve biraz yazılım tarihini anlayalım.

Postgres'i seviyoruz: Güvenilirlik, esneklik ve zengin ekosistem kombinasyonunun başka herhangi bir veritabanıyla eşleşmesi çok zor olduğundan, uygulama geliştirmek için en iyi temel olduğuna inanıyoruz. Ancak Postgres onlarca yıl önce doğdu; bu sağlamlığın dezavantajları da yok değil.

Günümüzde geliştiriciler PostgreSQL'i, en iyi bilinen geleneksel OLTP (Çevrimiçi İşlem İşleme) kullanım senaryosundan çok daha fazlası için kullanıyor. 7/24 çalışan ve giderek artan miktarda veriyi işleyen veri yoğunluklu, zorlu uygulamaların çoğu PostgreSQL tarafından desteklenmektedir:

• PostgreSQL veritabanları, trafik yönetim sistemlerinden, kamu hizmeti ağlarından ve kamu güvenliği monitörlerinden gelen büyük miktarda sensör verisini almak için kullanılıyor.

  
  

• Enerji şirketleri, akıllı şebekelerden ve yenilenebilir enerji kaynaklarından gelen ölçümleri depolamak ve analiz etmek için PostgreSQL'i kullanıyor.

  
  

• Finans sektöründe PostgreSQL, piyasa ilerleme verilerini gerçek zamanlı olarak takip eden sistemlerin merkezinde yer alır.

• E-ticaret platformları, kullanıcı etkileşimleri tarafından oluşturulan olayları izlemek ve analiz etmek için PostgreSQL'i kullanıyor.

  
  

• Postgres, yeni dalga yapay zeka uygulamalarını desteklemek için bir vektör veritabanı olarak bile kullanılıyor.

  
  

Sonuç olarak Postgres tabloları çok hızlı büyüyor ve tabloların milyarlarca satıra ulaşması üretimin yeni normali.

Ne yazık ki, PostgreSQL bu miktardaki veriyle başa çıkmak için doğal olarak yeterli donanıma sahip değil: sorgu performansı gecikmeye başlıyor ve veritabanı yönetimi zahmetli hale geliyor. Bu sınırlamalara çözüm bulmak için şunu geliştirdik: Zaman ÖlçeğiDB Otomatik bölümleme, sürekli toplama, sorgu planlayıcı iyileştirmeleri ve daha birçok özellik aracılığıyla PostgreSQL'in zorlu uygulamalara yönelik performansını ölçeklendiren bir uzantı.

PostgreSQL için yüksek performanslı bir sıkıştırma mekanizması oluşturmak da benzer şekilde önemli bir kilit noktasıydı. Sürekli büyüyen bu veri kümeleri yalnızca iyi performans açısından zorlu olmakla kalmıyor, aynı zamanda veri birikimleri daha büyük disklere ve daha yüksek depolama faturalarına yol açıyor. PostgreSQL'in bir çözüme ihtiyacı vardı.

Peki ya TOAST?

Peki PostgreSQL'in mevcut TOAST yöntemi ne olacak? Muhteşem ismine rağmen 🍞😋, TOAST, büyük PostgreSQL veritabanlarınızın boyutunu sistematik olarak azaltmada etkili değildir .

TOAST, PostgreSQL'in bireysel veritabanı sayfalarına sığmayan büyük değerleri depolamak ve yönetmek için kullandığı otomatik mekanizmadır. TOAST, bunu başarmak için kullandığı tekniklerden biri olarak sıkıştırmayı dahil etse de, TOAST'ın birincil rolü, depolama alanını genel olarak optimize etmek değildir.

Örneğin, küçük demetlerden oluşan 1 TB'lık bir veritabanınız varsa, ne kadar ince ayar yapmaya çalışırsanız çalışın, TOAST bu 1 TB'yi sistematik olarak 80 GB'a dönüştürmenize yardımcı olmayacaktır. TOAST, 2 KB eşiğini aştıklarında büyük boyutlu nitelikleri otomatik olarak arka arkaya sıkıştırır, ancak TOAST küçük değerler (demetler) için yardımcı olmaz ve bir aydan eski tüm verileri sıkıştırmak gibi kullanıcı tarafından yapılandırılabilen daha gelişmiş yapılandırmalar uygulayamazsınız. belirli bir tabloda. TOAST'ın sıkıştırması, daha geniş tablo veya veri kümesi özelliklerine değil, kesinlikle bireysel sütun değerlerinin boyutuna dayanmaktadır.

TOAST, özellikle sık erişilen büyük boyutlu sütunlara sahip büyük tablolar için önemli miktarda G/Ç yükü de getirebilir. Bu gibi durumlarda, PostgreSQL'in ana tabloya erişimden ayrı bir G/Ç işlemi olan TOAST tablosundan hat dışı verileri alması gerekir, çünkü PostgreSQL'in ana tablodan TOAST tablosuna giden işaretçileri takip etmesi gerekir. verileri tamamlayın. Bu genellikle daha kötü performansa yol açar.

Son olarak, TOAST'ın sıkıştırması, tüm veri türleri için tek bir standart algoritma kullandığından özellikle yüksek sıkıştırma oranları sağlayacak şekilde tasarlanmamıştır.

Sıkıştırma Neden PostgreSQL'e Özgü Değil? Satır ve Sütun Odaklı Veritabanlarına Giriş

TOAST'tan kısa bir şekilde bahsetmek aynı zamanda PostgreSQL'in verileri etkili bir şekilde sıkıştırma konusundaki sınırlamalarını anlamamıza da yardımcı olur. Az önce gördüğümüz gibi, TOAST'ın sıkıştırması verileri satır satır işler, ancak bu satır odaklı mimari, sıkıştırma algoritmalarının beslendiği homojenliği dağıtır ve bir sıkıştırmanın ne kadar işlevsel olabileceği konusunda temel bir tavana yol açar. Bu, depolama optimizasyonu söz konusu olduğunda ilişkisel veritabanlarının (yerel Postgres gibi) sıklıkla yetersiz kalmasının temel nedenidir.

Hadi bunu parçalayalım. Geleneksel olarak veritabanları iki kategoriden birine girer:

• Satır odaklı veritabanları, verileri satırlara göre düzenler; her satır, belirli bir kayda ait tüm verileri içerir. Kayıt ekleme, güncelleme ve silme işlemlerinin sık olduğu işlemsel işlemler için optimize edilmişlerdir ve işlemlerin bireysel kayıtları veya küçük veri alt kümelerini (örneğin, belirli bir müşteri hakkındaki tüm bilgilerin alınması) içerdiği OLTP sistemleri için verimlidirler.

  
  

• Sütun odaklı (diğer adıyla "sütunlu") veritabanları ise verileri sütunlara göre düzenler. Her sütun, birden fazla kayıtta belirli bir özniteliğe ilişkin tüm verileri depolar. Bunlar genellikle sorguların çoğu zaman birçok kayıtta toplama ve işlemleri içerdiği OLAP sistemleri (OnLine Analytical Processing) için optimize edilmiştir.

  
  

Bunu bir örnekle açıklayalım. Diyelim ki dört sütunlu bir users tablomuz var: user_id , name , logins ve last_login . Eğer bu tablo bir milyon kullanıcıya ait verileri saklıyorsa, etkin bir şekilde bir milyon satır ve dört sütuna sahip olacak ve her kullanıcının verilerini (yani her satırı) fiziksel olarak diskte bitişik olarak depolayacaktır.

Bu satır odaklı kurulumda, user_id = 500.000 satırının tamamı bitişik olarak depolanır ve bu da geri alma işlemini hızlandırır. Sonuç olarak, sığ ve geniş sorgular bir satır deposunda daha hızlı olacaktır (örneğin, "X kullanıcısı için tüm verileri getir"):

 -- Create table CREATE TABLE users ( user_id SERIAL PRIMARY KEY, name VARCHAR(100), logins INT DEFAULT 0, last_login TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Assume we have inserted 1M user records into the 'users' table -- Shallow-and-wide query example (faster in row store) SELECT * FROM users WHERE user_id = 500000;

Buna karşılık, sütunlu bir depo tüm user_id bir arada, tüm adları bir arada, tüm oturum açma değerlerini bir arada vb. depolayacak, böylece her sütunun verileri diskte bitişik olarak depolanacaktır. Bu veritabanı mimarisi derin ve dar sorguları destekler; örneğin, "tüm kullanıcılar için ortalama oturum açma sayısını hesaplayın":

 -- Deep-and-narrow query example (faster in column store) SELECT AVG(logins) FROM users;

Sütunlu depolar, geniş veriler üzerinde dar sorgularla özellikle iyi performans gösterir. Sütunlu bir veritabanında, ortalamayı hesaplamak için yalnızca logins sütunu verilerinin okunması gerekir; bu, her kullanıcı için veri kümesinin tamamını diskten yüklemek zorunda kalmadan yapılabilir.

Şimdiye kadar tahmin edebileceğiniz gibi, verileri satırlar ve sütunlar halinde depolamanın, verilerin ne kadar iyi sıkıştırılabileceği üzerinde de etkisi vardır. Sütunlu bir veritabanında, ayrı ayrı veri sütunları genellikle aynı türdedir ve çoğunlukla daha sınırlı bir alandan veya aralıktan alınır.

Sonuç olarak, sütunlu depolar genellikle satır odaklı veritabanlarından daha iyi sıkıştırılır. Örneğin, daha önce logins sütunumuzun tamamı tamsayı tipindeydi ve muhtemelen yalnızca küçük bir sayısal değer aralığından oluşuyordu (ve dolayısıyla iyi sıkıştırılan düşük bir entropiye sahipti). Bunu, geniş bir veri satırının tamamının birçok farklı veri türü ve aralığından oluştuğu satır odaklı formatla karşılaştırın.

Ancak OLAP tarzı sorgular ve sıkıştırılabilirlik açısından avantajlar gösterseler bile sütunlu depoların bazı ödünleri de var:

• Tek tek satırları alan sorgular çok daha az performanslıdır (hatta bazen çalıştırılması imkansızdır).

  
  

• Mimarileri geleneksel ACID işlemlerine pek uygun değil.

  
  

• Sütunlu mağazalarda güncelleme yapmak çoğu zaman mümkün olmuyor.

  
  

• Sıra bazlı mağazaların avantajdan faydalanması daha kolaydır. indeks (örneğin, B-ağacı) uygun kayıtları hızlı bir şekilde bulmak için.

  
  

• Satır deposuyla veri kümenizi normalleştirmek daha kolaydır, böylece ilgili veri kümelerini diğer tablolarda daha verimli bir şekilde depolayabilirsiniz.

Satır ve Sütun Odaklı Veritabanları: Ne Seçilmeli?

Peki hangisi daha iyi: satır odaklı mı yoksa sütunlu mu?

Geleneksel olarak, iş yükünüze bağlı olarak her ikisi arasındaki dengeyi değerlendirirsiniz. Tipik bir OLTP kullanım senaryosu çalıştırıyorsanız muhtemelen PostgreSQL gibi satır odaklı bir ilişkisel veritabanı seçersiniz; Kullanım durumunuz açıkça OLAP ise ClickHouse gibi sütunlu bir mağazaya yönelebilirsiniz.

Peki ya iş yükünüz aslında her ikisinin bir karışımıysa?

• Uygulama sorgularınız genellikle yüzeysel ve geniş kapsamlı olabilir; tek bir sorgu birçok veri sütununun yanı sıra birçok farklı cihaz/sunucu/öğe genelindeki verilere de erişebilir. Örneğin, belirli bir üretim tesisindeki tüm sensörler için son kaydedilen sıcaklık ve nemin görüntülenmesini gerektiren, kullanıcıya yönelik bir görselleştirmeyi çalıştırıyor olabilirsiniz. Böyle bir sorgunun, oluşturma kriterleriyle eşleşen tüm satırlardaki, potansiyel olarak binlerce veya milyonlarca kaydı kapsayan birden fazla sütuna erişmesi gerekir.

  
  

• Ancak sorgularınızdan bazıları aynı zamanda derin ve dar olabilir; bireysel bir sorgu, daha uzun bir süre boyunca belirli bir sensör için daha az sayıda sütun seçer. Örneğin, anormallikleri incelemek için belirli bir cihazın geçtiğimiz aydaki sıcaklık eğilimini de analiz etmeniz gerekebilir. Bu tür bir sorgu, tek bir sütuna (sıcaklık) odaklanır ancak bu bilgiyi, hedef dönem boyunca her zaman aralığına karşılık gelen çok sayıda satırdan alması gerekir.

  
  

• Uygulamanız ayrıca veri açısından yoğun olabilir ve ekleme (ekleme) yükü fazla olabilir. Daha önce de tartıştığımız gibi, saniyede yüzbinlerce yazma işlemiyle uğraşmak yeni normaldir. Veri kümeleriniz de muhtemelen çok ayrıntılıdır; örneğin, her saniye veri topluyor olabilirsiniz. Önceki örnekten devam edersek, veritabanınızın, kullanıcıya yönelik görselleştirmenizi gerçek zamanlı olarak güçlendirmek için bu ağır yazma işlemlerini sürekli okumalarla birlikte sunması gerekir.

  
  

• Verileriniz çoğunlukla eklemelidir ancak yalnızca ekleme olması gerekmez. Eski kayıtları ara sıra güncellemeniz veya muhtemelen geç gelen veya kullanım dışı verileri kaydetmeniz gerekebilir.

  
  

Bu iş yükü geleneksel anlamda ne OLTP ne de OLAP'tır. Bunun yerine her ikisinin de unsurlarını içerir. Peki ne yapmalı?

Hibrit'e geçin!

Satır Odaklı Bir Veritabanında Sütunlu Depolama Oluşturma

Önceki örnekteki gibi bir iş yüküne hizmet verebilmek için tek bir veritabanının aşağıdakileri içermesi gerekir:

• Saniyede yüzbinlerce yazmada yüksek ekleme hızlarını kolayca sürdürme yeteneği

  
  

• Geç veya sıra dışı veri ekleme ve mevcut verileri değiştirme desteği

  
  

• Büyük bir veri kümesinde hem sığ hem geniş hem de derin ve dar sorguları verimli bir şekilde işlemek için yeterli esneklik

  
  

• Depolama verimliliğini artırmak için veritabanı boyutlarını önemli ölçüde azaltabilen bir sıkıştırma mekanizması

  
  

TimescaleDB'ye (ve dolayısıyla PostgreSQL'e) sütunlu sıkıştırma eklerken elde etmeyi hedeflediğimiz şey budur.

PostgreSQL'i hibrit satır sütunlu bir depoya dönüştürme

Önceki bölümde bahsettiğimiz gibi, PostgreSQL'i daha fazla performans ve ölçeklenebilirlikle genişletmek için TimescaleDB'yi geliştirdik ve PostgreSQL'i aşağıdaki gibi zorlu iş yüklerine uygun hale getirdik: Zaman serisi verileri. TimescaleDB bir PostgreSQL uzantısı olarak uygulanır: Bunu yaparken, tam SQL, büyük sorgu ve veri modeli esnekliği, savaşta test edilmiş güvenilirlik, ateşli bir geliştirici ve kullanıcı tabanı ve en büyük veritabanı ekosistemlerinden biri gibi PostgreSQL'in harika olan her şeyini miras alır. etrafında.

Teorik olarak bu, TimescaleDB'nin aynı zamanda mütevazı sıkıştırılabilirliğiyle PostgreSQL'in satır odaklı depolama formatına da kilitlendiği anlamına gelir. Gerçekte biraz mühendisliğin çözemeyeceği hiçbir şey yoktur.

İki gözlem. Birinci, Çoğu büyük PostgreSQL iş yükü zaman serisi benzeri bir yapıya sahiptir yani, zaman damgası veya seri olay kimliği gibi gevşek sıralı bir ana anahtara sahip, ekleme ağırlıklıdırlar (güncelleme ağırlıklıya karşı). İkincisi, bu tür veri kümeleri yalnızca nokta sorgularıyla değil, taramalar veya toplamalar yoluyla da düzenli olarak sorgulanır. Eldeki bu gözlemlerle, TimescaleDB için benzersiz sıkıştırılabilirlik düzeyleri elde etmemize olanak tanıyan yeni bir sütunlu depolama özelliği tasarladık (bunu bir sonraki bölümde ayrıntılı olarak ele alacağız).

Aslında bu satırdan sütuna dönüşümün veritabanınızın tamamına uygulanması gerekmez. Bir Zaman Ölçeği kullanıcısı olarak, PostgreSQL tablolarınızı hibrit satır-sütun depolarına dönüştürebilir ve tam olarak hangi verilerin sütun biçiminde sıkıştırılacağını seçebilirsiniz. basit API'miz aracılığıyla ve uygulamanızın gerektirdiği şekilde her iki depolama mimarisinden de yararlanın.

Bunun pratikte nasıl çalıştığını bir örnekle açıklayalım. Her saniye birden fazla cihazdan okumalar toplayan, zaman damgası, cihaz kimliği, durum kodu ve sıcaklık gibi verileri depolayan bir sıcaklık izleme sistemi hayal edin.

Özellikle farklı cihazlardan gelen en son değerleri analiz etmek isteyebileceğiniz operasyonel sorgular için, en güncel sıcaklık verilerine verimli bir şekilde erişmek için, en güncel verileri (örneğin, geçen haftaya ait) geleneksel sıkıştırılmamış, satır odaklı PostgreSQL yapısında tutabilirsiniz. . Bu, yüksek alım oranlarını destekler ve aynı zamanda güncel verilerle ilgili nokta sorguları için de idealdir:

 -- Find the most recent data from a specific device SELECT * FROM temperature_data WHERE device_id = 'A' ORDER BY timestamp DESC LIMIT 1; -- Find all devices in the past hour that are above a temperature threshold SELECT DISTINCT device_id, MAX(temperature) FROM temperature WHERE timestamp > NOW() - INTERVAL '1 hour'   AND temperature > 40.0;

Ancak bu veriler birkaç günlük olduğunda, önceki gibi sığ ve geniş sorgular artık sıklıkla çalıştırılmıyor; bunun yerine derin ve dar analitik sorgular daha yaygın hale geliyor. Dolayısıyla, bu tür sorgular için depolama verimliliğini ve sorgu performansını artırmak amacıyla, bir haftadan eski tüm verileri otomatik olarak yüksek düzeyde sıkıştırılmış sütunlu biçime dönüştürmeyi seçebilirsiniz. Bunu Zaman Ölçeği'nde yapmak için şunun gibi bir sıkıştırma politikası tanımlamalısınız:

 -- Add a compression policy to compress temperature data older than 1 week SELECT add_compression_policy('temperature_data', INTERVAL '7 days');

Verileriniz sıkıştırıldıktan sonra, sıcaklık verileri üzerinde (belirli bir cihazda veya birçok cihazda) derin ve dar analitik sorgular çalıştırmak, en iyi sorgu performansını gösterecektir.

 -- Find daily max temperature for a specific device across past year SELECT time_bucket('1 day', timestamp) AS day, MAX(temperature) FROM temperature_data WHERE timestamp > NOW() - INTERVAL '1 year'   AND device_id = 'A' ORDER BY day; -- Find monthly average temperatures across all devices SELECT device_id, time_bucket('1 month', timestamp) AS month, AVG(temperature) FROM temperature_data WHERE timestamp < NOW() - INTERVAL '2 weeks' GROUP BY device_id, month ORDER BY month;

Bir satırdan sütun biçimine “geçişi” nasıl temsil ederiz? Zaman ölçeğinin hiper tabloları, zaman damgası veya diğer seri kimlik sütunu gibi bir bölümleme anahtarına dayalı olarak verileri "parçalara" bölmeye hizmet eder. Daha sonra her parça, belirli bir zaman damgası aralığına veya o bölümleme anahtarına ilişkin diğer değerlere karşılık gelen kayıtları saklar. Yukarıdaki örnekte, sıcaklık verileri haftalara göre bölünerek en son parçanın satır biçiminde kalması ve tüm eski haftaların sütunlu biçime dönüştürülmesi sağlanır.

Bu hibrit satır-sütun depolama motoru, büyük PostgreSQL veritabanlarındaki sorgu performansını optimize ederken depolama alanını önemli ölçüde azaltan inanılmaz derecede güçlü bir araçtır. Bu makalenin ilerleyen kısımlarında göreceğimiz gibi, verileri sütunlu formata dönüştürerek ve özel sıkıştırma mekanizmaları uygulayarak, yalnızca analitik sorgularınızı hızlandırmakla kalmıyoruz, aynı zamanda %98'e varan sıkıştırma oranlarına da ulaşıyoruz. Bunun depolama faturanıza ne yapacağını bir düşünün!

Perde arkası: Satır verilerinden sıkıştırılmış sütunlu dizilere

Sorgu performansı ve depolama tasarrufuyla ilgili ayrıntılara girmeden önce, öncelikle bu mekanizmanın nasıl çalıştığını ele alalım: Satırdan sütunlara dönüşümün gerçekte nasıl gerçekleştirildiği ve sütunlu verilere sıkıştırmanın nasıl uygulandığı.

Sıkıştırma politikası devreye girdiğinde, orijinal PostgreSQL hipertablosunda geleneksel olarak çok sayıda olan bireysel kayıtları (1.000 yoğun şekilde paketlenmiş satır düşünün) tekil, daha kompakt bir satır yapısına dönüştürür. Bu sıkıştırılmış formda, her özellik veya sütun artık her satırdaki tekil girişleri saklamaz. Bunun yerine, bu 1000 satırdan karşılık gelen tüm değerlerin sürekli, sıralı bir dizisini kapsüller. Bu 1000 satırı toplu iş olarak kabul edelim.

Bunu açıklamak için şöyle bir tablo hayal edelim:

 | Timestamp | Device ID | Status Code | Temperature | |-----------|-----------|-------------|-------------| | 12:00:01 | A | 0 | 70.11 | | 12:00:01 | B | 0 | 69.70 | | 12:00:02 | A | 0 | 70.12 | | 12:00:02 | B | 0 | 69.69 | | 12:00:03 | A | 0 | 70.14 | | 12:00:03 | B | 4 | 69.70 |

Bu verileri sıkıştırmaya hazırlamak için Timescale öncelikle bu tablo verilerini sütunlu bir depoya dönüştürür. Bir veri kümesi (~1.000 satır) verildiğinde, her bir sütunun verileri, her bir dizi öğesi orijinal satırlardan birindeki değere karşılık gelecek şekilde bir dizi halinde toplanır. İşlem, her sütunun söz konusu gruptan bir dizi değer depoladığı tek bir satırla sonuçlanır.

 | Timestamp | Device ID | Status Code | Temperature | |------------------------------|--------------------|--------------------|-------------------------------| | [12:00:01, 12:00:01, 12...] | [A, B, A, B, A, B] | [0, 0, 0, 0, 0, 4] | [70.11, 69.70, 70.12, 69....] |

Sıkıştırma algoritmalarını uygulamadan önce bile bu format, Timescale'in dahili satır başına yükünü büyük ölçüde azaltarak depolama alanından anında tasarruf sağlar. PostgreSQL genellikle satır başına yaklaşık 27 bayt ek yük ekler (örneğin, Çok Sürümlü Eşzamanlılık Kontrolü veya MVCC için). Yani, herhangi bir sıkıştırma olmasa bile, yukarıdaki şemamız örneğin 32 bayt ise, daha önce [1,000 * (32 + 27)] ~= 59 kilobayt alan bir gruptan gelen 1000 satırlık veri şimdi [1,000 * 32 + 27'yi alıyor ] ~= Bu formatta 32 kilobayt .

[ Bir kenara : Daha büyük bir tabloyu daha küçük gruplar halinde "gruplamak" ve ardından her bir grubun sütunlarını (tüm tablonunkiler yerine) bitişik olarak depolamak kavramı aslında Apache Parquet dosya formatındaki "satır grupları"na benzer bir yaklaşımdır. Gerçi bu benzerliği sonradan fark ettik!]

Ancak bu dönüşümün en büyük avantajı, artık benzer verilerin (zaman damgaları, cihaz kimlikleri, sıcaklık okumaları vb.) bitişik olarak depolandığı bir format verildiğinde, her dizinin ayrı ayrı sıkıştırılması için türe özgü sıkıştırma algoritmaları uygulayabilmemizdir. . Timescale bu şekilde etkileyici sıkıştırma oranlarına ulaşır.

Timescale otomatik olarak aşağıdaki sıkıştırma algoritmalarını kullanır. Bu algoritmaların tümü “ kayıpsız ”böylece sıkıştırmamız yoluyla hassasiyeti ortadan kaldırmayız veya yanlışlıklara yol açmayız; sonuçta ortaya çıkan herhangi bir dekompresyon, orijinal değerleri mükemmel bir şekilde yeniden oluşturur.

• Goril sıkıştırması şamandıralar için

  
  

• Delta-of-delta + Basit-8b ile çalışma uzunluğu kodlaması zaman damgaları ve diğer tam sayı benzeri türler için sıkıştırma

  
  

• Birkaç yinelenen değere sahip sütunlar için tam satır sözlük sıkıştırması (üstte + LZ sıkıştırması)

  
  

• Diğer tüm türler için LZ tabanlı dizi sıkıştırma

  
  

Gorilla ve Simple-8b'yi, sıkıştırılmış verileri ters sırayla işleyecek şekilde genişlettik, böylece geriye doğru tarama kullanan sorguları hızlandırabildik.

Bu türe özgü sıkıştırmayı oldukça güçlü bulduk: Daha yüksek sıkıştırılabilirliğe ek olarak, Gorilla ve delta-of-delta gibi tekniklerden bazıları kod çözme sırasında LZ tabanlı sıkıştırmaya göre 40 kata kadar daha hızlı olabilir ve bu da çok daha iyileştirilmiş sorgu performansına yol açar .

Verilerin sıkıştırması açılırken, Timescale bu bireysel sıkıştırılmış gruplar üzerinde çalışabilir, bunların sıkıştırmasını toplu olarak ve yalnızca istenen sütunlarda açabilir. Dolayısıyla, sorgu motoru, başlangıçta bir milyon satırlık veri içeren bir tablo yığınından yalnızca 20 grubun (20.000 orijinal veri satırına karşılık gelen) işlenmesi gerektiğini belirleyebilirse, okuma ve sıkıştırmayı açma işlemi nedeniyle sorgu çok daha hızlı yürütülebilir. çok daha az veri. Bunu nasıl yaptığını görelim.

Sıkıştırılmış verileri verimli bir şekilde sorgulama

Önceki dizi tabanlı format bir zorluk teşkil etmektedir: yani, bir sorguyu çözmek için veritabanı hangi satırları almalı ve sıkıştırmasını açmalıdır?

Sıcaklık verileri örneğimizi tekrar ele alalım. Çeşitli doğal sorgu türleri tekrar tekrar ortaya çıkıyor: verileri zaman aralıklarına göre seçip sıralamak veya verileri cihaz kimliğine göre seçmek (WHERE yan tümcesinde veya bir GROUP BY aracılığıyla). Bu tür sorguları etkili bir şekilde nasıl destekleyebiliriz?

Şimdi, eğer son güne ait verilere ihtiyacımız varsa, sorgunun artık sıkıştırılmış bir dizinin parçası olan zaman damgası verileri arasında gezinmesi gerekir. Peki veritabanı son güne ait verileri bulmak için tüm parçaların (hatta hipertablonun tamamının) sıkıştırmasını açmalı mı?

Veya, sıkıştırılmış bir dizi halinde gruplandırılmış bireysel "toplu grupları" tanımlayabilsek bile (yukarıda açıklanmıştır), farklı cihazlardan gelen veriler birbirine serpiştirilmiş midir, dolayısıyla belirli bir cihazla ilgili verileri içerip içermediğini bulmak için tüm dizinin sıkıştırmasını açmamız gerekir mi? Bu daha basit yaklaşım hala iyi bir sıkıştırılabilirlik sağlayabilse de, sorgu performansı açısından neredeyse o kadar verimli olmayacaktır.

Sütun biçimindeki belirli sorgulara ilişkin verileri verimli bir şekilde bulma ve sıkıştırmayı açma zorluğunu çözmek için, Zaman ölçeği, "bölümlere ayırma ölçütü" ve "sıralama ölçütü" sütunları kavramını sunar .

Yaygın olarak sorgulanan verileri segmentby göre sütuna göre gruplandırma

Zaman Ölçeği'ndeki verilerin başlangıçta parça parça sıkıştırılmış sütunlu forma dönüştürüldüğünü hatırlayın. Belirli bir sütuna göre filtreleyen sorguların verimliliğini artırmak için (örneğin, sıklıkla device_id ile sorgulama), bu belirli sütunu " sıkıştır_segmentby " kolon. Bu yaklaşım, sıkıştırılmış verileri düzenlemek için oldukça faydalıdır.

Bu segmentby sütunlar, sıkıştırılmış her yığın içindeki verileri mantıksal olarak bölmek için kullanılır. Yukarıda gösterildiği gibi sıkıştırılmış bir rastgele değer dizisi oluşturmak yerine, sıkıştırma motoru ilk olarak aynı segmentby anahtara sahip tüm değerleri bir araya gruplandırır.

Yani, Device_id A ile ilgili 1.000 satırlık veri, tek bir sıkıştırılmış satırda, Device_id B ile ilgili 1.000 satır vb. depolanmadan önce yoğun bir şekilde yedeklenir. Bu nedenle, segmentby olarak device_id seçilirse sıkıştırılmış her satır, belirli bir aygıt kimliğiyle ilgili sıkıştırılmış sütun halinde veri yığınları içerir ve bunlar, o satırda sıkıştırılmamış olarak depolanır. Zaman ölçeği ayrıca sıkıştırılmış yığın içindeki bu segment bazındaki değerler üzerinde bir dizin oluşturur.

 | Device ID | Timestamp | Status Code | Temperature | |-----------|--------------------------------|-------------|-----------------------| | A | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 0] | [70.11, 70.12, 70.14] | | B | [12:00:01, 12:00:02, 12:00:03] | [0, 0, 4] | [69.70, 69.69, 69.70] |

Verilerin bu bitişik şekilde depolanması, segmentby sütunlara göre filtrelenen sorguların verimliliğini büyük ölçüde artırır. device_id segmentby sütun olduğu, device_id tarafından filtrelenmiş bir sorgu çalıştırıldığında, Timescale, belirtilen aygıt kimliklerine sahip olan öbekteki tüm sıkıştırılmış satırları hızlı bir şekilde seçebilir (bir dizin aracılığıyla) ve verileri hızlı bir şekilde atlar (ve sıkıştırmanın açılmasını önler) ) talep edilen cihazlarla ilgisi olmayan veriler.

Örneğin, bu sorguda Zaman Ölçeği yalnızca aygıt_kimliği A'ya ilişkin verileri içeren sıkıştırılmış satırları verimli bir şekilde bulup işleyecektir:

 SELECT AVG(temperature) FROM sensor_data WHERE device_id = 'A'   AND time >= '2023-01-01'   AND time < '2023-02-01';

Ek olarak, Zaman Ölçeği hiper tabloları, her bir parça ile ilişkili, parçanın kapsadığı değer aralığını belirten meta verileri depolar. Dolayısıyla, bir hipertablonun zaman damgası haftaya göre bölümlenmişse, sorgu planlayıcı yukarıdaki sorguyu çalıştırdığında yalnızca Ocak ayını kapsayan 4-5 parçayı işleyeceğini bilir ve sorgu performansını daha da artırır.

segmentby sütunları tanımlama

Bir hiper tablonun sıkıştırmasını ilk kez etkinleştirirken segmentby için hangi sütunların kullanılacağını belirleyebilirsiniz. Hangi sütunun kullanılacağı seçimi, sorgularınızda sıklıkla hangi sütun veya sütunların kullanıldığına bağlı olmalıdır. Aslında, bölümlere ayırmak için birden fazla sütun kullanabilirsiniz: örneğin, grupları aygıt_id'sine göre gruplandırmak yerine, hem kiracı_id'ye hem de aygıt_id'sine sahip olan grupları (örneğin) gruplandırabilirsiniz.

Yine de, seçiciliği aşırıya kaçmamaya dikkat edin: çok fazla bölüm bazında sütun tanımlamak, sıkıştırma verimliliğini azaltacaktır çünkü her bir bölüm bazında sütun, verileri etkili bir şekilde giderek daha küçük gruplara böler.

Artık 1.000 kayıt kümesi veri oluşturamıyorsanız ve bunun yerine belirli bir yığın içinde belirtilen segmentby anahtarlarına sahip yalnızca beş kayda sahipseniz, hiç iyi sıkıştırılmayacaktır!

Ancak hangi sütunları segmentlere ayırmak istediğinizi belirledikten sonra, hipertablonuzda sıkıştırmayı etkinleştirirken bunları yapılandırmak kolaydır:

 ALTER TABLE temperature_data SET (   timescaledb.compress,   timescaledb.compress_segmentby = 'device_id' );

orderby aracılığıyla gelişmiş ince ayar

TimescaleDB, sıkıştırılmış veriler üzerindeki sorgu performansını, sıkıştırılmış veriler üzerinde, compress_orderby parametresi tarafından belirlenen, her bir parça içindeki stratejik veri sıralaması yoluyla geliştirir. Zaman damgasına göre sıralamanın varsayılan ayarı (zaman serisi verilerindeki tipik bölümleme anahtarı) çoğu senaryo için uygun olsa da, bu optimizasyonun anlaşılması değerli olabilir. Daha da derin bir teknik bakış açısı için okumaya devam edin.

Haftalık parçalar örneğini ve yalnızca tek bir güne ilişkin verileri talep eden bir sorguyu tekrar düşünün. Zaman damgası dizinine sahip normal bir tabloda sorgu, günün verilerini bulmak için bu dizini verimli bir şekilde yürütebilir.

Ancak sıkıştırılmış verilerde durum farklıdır: zaman damgaları sıkıştırılmıştır ve toplu işlerin tamamı açılmadan bunlara erişilemez. Her bir zaman damgası için bir dizin oluşturmak, aşırı büyüyerek sıkıştırmanın faydalarını ortadan kaldırabileceğinden verimsiz olabilir.

Zaman ölçeği, toplu işlenecek verileri temel olarak zaman damgasına göre "sıralayarak" bu sorunu giderir. Daha sonra her parti için minimum ve maksimum zaman damgalarıyla ilgili meta verileri kaydeder. Bir sorgu yürütüldüğünde, bu meta veriler, sorgu motorunun hangi sıkıştırılmış satırların (toplu işlerin) sorgunun zaman aralığıyla ilgili olduğunu hızlı bir şekilde belirlemesini sağlar ve böylece tam sıkıştırmayı açma ihtiyacını azaltır.

Bu metodoloji, bölümlere göre sütunların kullanımıyla iyi uyum sağlar. Sıkıştırma işlemi sırasında, veriler ilk önce segment bazında sütuna göre gruplandırılır, ardından sıralama parametresine göre sıralanır ve son olarak her biri en fazla 1.000 satır içeren daha küçük, zaman damgası sıralı "mini gruplara" bölünür.

TimescaleDB'nin segmentasyonu ve sıralamasının birleşimi, ortak zaman serisi ve analitik sorguların performansını önemli ölçüde artırır. Hem zaman ( orderby aracılığıyla) hem de alan ( segmentby yoluyla) genelindeki bu optimizasyon, TimescaleDB'nin büyük ölçekli zaman serisi verilerini etkili bir şekilde yönetmesini ve sorgulamasını sağlayarak sıkıştırma ve erişilebilirlik arasında optimize edilmiş bir denge sunar.

Zaman Ölçeği Sıkıştırmasının Evrimi

Sıkıştırma tasarımımızın ilk versiyonu 2019 yılında TimescaleDB 1.5 ile yayınlandı. Daha sonraki birçok sürümde, Zaman Ölçeği sıkıştırması uzun bir yol kat etti.

İlk sürümümüzün ana sınırlamalarından biri, veriler sıkıştırıldıktan sonra, içinde bulunduğu hipertablo yığının tamamını manuel olarak açmadan, verilerde daha fazla değişiklik yapılmasına (örneğin, INSERT'ler, UPDATE'ler, DELETE'ler) izin vermememizdi.

Esasen ekleme ağırlıklı olan ve güncelleme ağırlıklı olmayan analitik ve zaman serisi verilerine dayalı veri yoğun kullanım senaryoları için optimizasyon yaptığımız göz önüne alındığında, bu, geleneksel bir OLTP kullanım senaryosunda olabileceğinden çok daha az sınırlamaydı. verilerin sıklıkla güncellendiği yer (örneğin, müşteri bilgi tablosu). Fakat, bu makalede tartıştığımız gibi , dolgunun gerekli olduğu durumlar vardır ve bu, TimescaleDB'yi kullanan geliştirici işlem hatlarını önemli ölçüde karmaşık hale getirir.

İlk sıkıştırma sürümümüzün bir diğer sınırlaması da, sıkıştırılmış veriler de dahil olmak üzere tablolarda şema değişikliklerine izin vermememizdi. Bu, geliştiricilerin tüm tablonun sıkıştırmasını açmadan veri yapılarını geliştiremeyecekleri anlamına geliyordu. yeni metriklere veya yeni cihazlara uyacak yeni sütunlar eklemek gibi .

Bugün tüm bu sınırlamalar kaldırılmıştır. Zaman ölçeği artık sıkıştırılmış veriler üzerinde tam Veri İşleme Dili (DML) ve Veri Tanımlama Dili (DDL) işlemlerini gerçekleştirmenize olanak tanıyor:

• Verileri sıkıştırılmış parçalar üzerine INSERT yapabilirsiniz (mükemmel performansla).

• UPDATE'ler, UPSERT'ler ve DELETE'ler yapabilirsiniz.

  
  

• Varsayılan değerler de dahil olmak üzere sütunlar ekleyebilirsiniz.

  
  

• Sütunları yeniden adlandırabilir ve bırakabilirsiniz.

  
  

Sıkıştırılmış veriler üzerinde veri değişikliğini otomatikleştirmek (kullanıcılarımız için sorunsuz hale getirmek) amacıyla, bir "hazırlama alanı" (esasen sıkıştırılmamış olarak kalan ve "sıkıştırılmamış veriler üzerinde" işlemleri gerçekleştirdiğimiz örtüşen bir yığın) ekleyerek sıkıştırma yaklaşımımızı değiştirdik. başlık.

Kullanıcı olarak manuel olarak hiçbir şey yapmanıza gerek yoktur: Verilerinizi doğrudan değiştirebilirsiniz, bu sırada motorumuz her şeyi otomatik olarak halleder. Sıkıştırılmış verilerde değişiklik yapabilme yeteneği, Timescale'in hibrit satır-sütun depolama motorunu çok daha esnek hale getirir.

Hazırlama alanı aracılığıyla yapılan bu tasarım, INSERT'leri sıkıştırılmamış parçalara eklemek kadar hızlı hale getirir, çünkü gerçekte olan budur (sıkıştırılmış bir parçaya eklediğinizde, artık hazırlama alanına yazıyorsunuzdur). Ayrıca UPDATE'leri, UPSERT'leri ve DELETE'leri doğrudan desteklememize de olanak tanıdı: Bir değerin değiştirilmesi gerektiğinde, motor sıkıştırılmış verinin ilgili kısmını hazırlama alanına taşır, sıkıştırmasını açar, değişikliği yapar ve (asenkron olarak) tekrar taşır. ana tabloya sıkıştırılmış biçimde.

(Bu veri bölgesi genellikle, değişiklikleri desteklemek için sıkıştırılmamış olması gereken veri miktarını en aza indirmek için temeldeki PostgreSQL deposunda bir "satır" oluşturan 1.000'e kadar değerden oluşan sıkıştırılmış "mini gruplar" ölçeğinde çalışır.)

Bu "hazırlama alanı" hala düzenli işlem semantiğine sahiptir ve sorgularınız bu değerleri, buraya eklendikleri anda görür. Başka bir deyişle, sorgu planlayıcı bu satır tabanlı "hazırlama" parçaları ve normal sütunlu depolama arasında nasıl düzgün şekilde sorgulama yapılacağını anlayacak kadar akıllıdır.

Nihai Sonuç: Daha Hızlı Sorgular, Büyük PostgreSQL Veritabanları İçin Daha Az Depolama Alanı

Bu noktada sorulması gereken bir sonraki mantıksal soru şudur: Nihai sonuç nedir? Sıkıştırma sorgu performansını nasıl etkiler ve bunu kullanarak ne kadar disk boyutundan tasarruf edebilirim?

Sıkıştırmadan önce ve sonra sorgu performansı

Bu makalede tartıştığımız gibi, sütunlu depolar genellikle tek tek satırları alan sorgular için pek iyi sonuç vermez, ancak toplu değerlere bakan analitik sorgular için genellikle çok daha iyi sonuç verirler. Zaman Ölçeği'nde gördüğümüz şey tam olarak budur: ortalamaları içeren derin ve dar sorgular, sıkıştırma kullanıldığında önemli performans iyileştirmeleri görür.

Bunu, üzerinde birkaç sorgu çalıştırarak açıklayalım. NYC taksi veri kümesi Timescale'de sunduğumuz örnek veri kümelerinden biri. Bu veri kümesi, taksi yolculukları hakkında, alma ve bırakma süreleri, konumlar, mesafeler, ücretler ve daha fazlası dahil olmak üzere bilgiler içerir.

Belirli bir zaman dilimi içinde taksi veri kümesinin bir alt kümesinden en yüksek ücret tutarını soran aşağıdaki sorguyu düşünün:

 SELECT max(fare_amount) FROM demo.yellow_compressed_ht WHERE   tpep_pickup_datetime >= '2019-09-01' AND   tpep_pickup_datetime <= '2019-12-01';

Sıkıştırılmamış veri kümesiyle çalıştırıldığında sorgu yürütme süresi 4,7 saniyedir. Küçük, optimize edilmemiş bir test hizmeti kullanıyoruz ve milyonlarca satırı sorguluyoruz, dolayısıyla bu performans en iyisi değil. Ancak veriler sıkıştırıldıktan sonra yanıt süresi 77.074 milisaniyeye düşüyor:

Bir örnek daha paylaşalım. Bu sorgu, belirli bir zaman dilimi içinde belirli bir ücret koduna sahip yolculukların sayısını sayar:

 SELECT COUNT(*) FROM demo.yellow_compressed_ht WHERE   tpep_pickup_datetime >= '2019-09-01' AND   tpep_pickup_datetime <= '2019-12-01' AND   "RatecodeID" = 99;

Sıkıştırılmamış verilere karşı yürütüldüğünde bu sorgunun tamamlanması 1,6 saniye sürer. Sıkıştırılmış verilerde çalıştırılan aynı sorgu yalnızca 18,953 milisaniyede tamamlanır. Bir kez daha anında bir iyileşme görüyoruz! Bunlar yalnızca kısa örneklerdir ancak sorgularınızı hızlandırmak için sıkıştırmanın ne kadar güçlü olabileceğini göstermektedir.

Timescale'in sıkıştırması PostgreSQL depolama boyutunu nasıl azaltır: Gerçek dünyadan örnekler

Bizi buraya getiren şeyin ne olduğunu unutmayalım: PostgreSQL'i daha da ölçeklendirebilmemiz için büyük PostgreSQL veritabanlarımızın boyutunu küçültmemize olanak sağlayacak bir taktiğe ihtiyacımız vardı. Zaman Ölçeği sıkıştırmasının bu görev için ne kadar etkili olabileceğini göstermek amacıyla aşağıdaki tablo, Zaman Ölçeği müşterileri arasında görülen sıkıştırma oranlarının bazı gerçek örneklerini içerir.

Bu depolama tasarrufları doğrudan para tasarrufu anlamına gelir: Timescale platformu, depolama için kullanıma dayalı fiyatlandırmayı kullanır Yani depolama alanınız küçülürse faturanız da orantılı olarak küçülür.

Sonuçta elde edeceğiniz sıkıştırma oranı, veri türünüz ve erişim düzenleriniz dahil olmak üzere çeşitli faktörlere bağlıdır. Ancak görebileceğiniz gibi Zaman Ölçeği sıkıştırması son derece verimli olabilir. Hatta müşteriye yönelik Insights ürünümüzü %96 sıkıştırmayla güçlendirmek için dahili olarak yoğun bir şekilde kullanıyoruz .

Ekibimiz, mümkün olduğunca fazla para tasarrufu sağlamak için sıkıştırmaya ince ayar yapmanıza yardımcı olabilir. bu yüzden bize ulaşmaktan çekinmeyin .

"Sıkıştırmayla, [disk boyutunda] ortalama yüzde 97'lik bir azalma gördük."

(Michael Gagliardo, Ndustrial)

“Timescale'in sıkıştırma oranının kesinlikle olağanüstü olduğunu gördük! Şu anda 26'nın üzerinde bir sıkıştırma oranındayız, bu da tüm verilerimizi depolamak için gereken disk alanını büyük ölçüde azaltıyor."

(Nicolas Quintin, Oktav)

"Zaman ölçeğinin sıkıştırması reklamı yapıldığı kadar iyiydi, bu da bize temel hipertablomuzda +%90 [disk] alanı tasarrufu sağladı."

(Paolo Bergantino, METER Grubu)

Sıkıştırma ve Katmanlı Depolama: Zaman ölçeğinde depolama yaşam döngüsü

Son olarak Timescale'in Katmanlı Depolamasından bahsetmeden bu makaleyi bitiremeyiz. Genel Kullanıma yeni sunduğumuz .

Sıkıştırmanın yanı sıra artık PostgreSQL veritabanlarınızı Timescale platformunda daha da ölçeklendirmenize yardımcı olacak başka bir araca sahipsiniz: eski, seyrek erişilen verilerinizi düşük maliyetli bir nesne depolama katmanına katmanlayabilir ve aynı zamanda bu verilere standart aracılığıyla erişmeye devam edebilirsiniz. SQL.

Bu düşük maliyetli depolama katmanının veri için GB/ay başına 0,021 USD sabit fiyatı vardır (Amazon S3'ten daha ucuzdur), maliyetin çok küçük bir kısmı karşılığında PostgreSQL veritabanınızda çok sayıda TB saklamanıza olanak tanır.

Katmanlı Depolama arka ucumuzun Zaman Ölçeği platformunda nasıl çalıştığı ve düşük depolama katmanının sıkıştırmayla birlikte nasıl çalıştığı:

• En güncel verileriniz, hızlı sorgular ve yüksek alımlar için optimize edilmiş yüksek performanslı bir depolama katmanına yazılır. Bu katmanda, bu makalede tartıştığımız gibi, veritabanı boyutunuzu küçültmek ve analitik sorgularınızı hızlandırmak için Zaman Ölçeği sütunlu sıkıştırmayı etkinleştirebilirsiniz. Örneğin verilerinizi 1 hafta sonra sıkıştıran bir sıkıştırma politikası tanımlayabilirsiniz.

  
  

• Uygulamanız artık bu verilere sık sık erişmediğinde, bir katmanlama politikası ayarlayarak bunu 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). Örneğin, altı aydan eski tüm verilerinizi düşük maliyetli depolama katmanına taşıyan bir katmanlama politikası tanımlayabilirsiniz.

  
  

• Bu verileri artık veritabanınızda tutmak zorunda kalmadığınızda, bir saklama politikası yoluyla verileri bırakabilirsiniz. Örneğin beş yıl sonra tüm verileri silebilirsiniz.

PostgreSQL'de Kalın

Sütunlu sıkıştırma yetenekleri ekleyerek Postgres'e etkili bir veritabanı sıkıştırma mekanizması kazandırdık. Bu, günümüzün veri yoğun dünyasında PostgreSQL veritabanlarını ölçeklendirmek için önemli bir özelliktir: sıkıştırma, disk kullanımında büyük tasarruflara (daha ucuza daha fazla veri depolamaya) ve performans iyileştirmelerine (büyük hacimlerde analitik sorguları milisaniyeler içinde çalıştırmaya) olanak tanır.

Timescale'in sıkıştırma tasarımı, sınıfının en iyisi sıkıştırma algoritmalarını PostgreSQL içinde hibrit satır/sütun depolama oluşturmak için yeni bir yöntemle birleştirerek etkileyici sıkıştırma oranlarına ulaşır. Bu yetenek, Timescale'in (ve dolayısıyla PostgreSQL'in) depolama alanını özel oluşturulmuş, daha sınırlı sütunlu veritabanlarıyla aynı seviyeye getirir.

Ancak birçok sütunlu motordan farklı olarak Timescale, ACID işlem semantiğini ve sıkıştırılmış sütunlu veriler üzerindeki değişiklikler (INSERT'ler, UPDATE'ler, UPSERT'ler, DELETE'ler) için doğrudan desteği destekler. "İşlemsel iş yükleri için bir veritabanı, analitik için başka bir veritabanı" şeklindeki eski model geçerliliğini yitirdiğinden, birçok modern uygulama her iki modele de uyan iş yüklerini çalıştırır. Peki her şeyi PostgreSQL'de yapabilecekken neden iki ayrı veritabanı kullanasınız ki?

Zaman Ölçeği, PostgreSQL'de başlamanıza, PostgreSQL ile ölçeklendirmenize ve PostgreSQL'de kalmanıza olanak tanır.

Ücretsiz bir hesap oluştur ve Timescale'i bugün deneyin; yalnızca birkaç saniye sürer, kredi kartı gerekmez.

- Carlota Soto ve Mike Freedman tarafından yazılmıştır.