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

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. Postgres Bu makalede, 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. PostgreSQL'in ölçeklenebilirliğini artırmak amacıyla esnek, yüksek performanslı bir sütunlu sıkıştırma mekanizmasını 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 göre sütuna göre gruplandırma segmentby sütunları tanımlama segmentby aracılığıyla gelişmiş ince ayar orderby 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: ve Zaman ÖlçeğiDB Otomatik bölümleme, sürekli toplama, sorgu planlayıcı iyileştirmeleri 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: 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. Satır odaklı 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. Sütun odaklı (diğer adıyla "sütunlu") veritabanları Bunu bir örnekle açıklayalım. Diyelim ki dört sütunlu bir tablomuz var: , , ve . 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. users user_id name logins last_login 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 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": user_id -- Deep-and-narrow query example (faster in column store) SELECT AVG(logins) FROM users; Sütunlu depolar, dar sorgularla özellikle iyi performans gösterir. Sütunlu bir veritabanında, ortalamayı hesaplamak için yalnızca sütunu verilerinin okunması gerekir; bu, her kullanıcı için veri kümesinin tamamını diskten yüklemek zorunda kalmadan yapılabilir. geniş veriler üzerinde logins Ş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, Örneğin, daha önce 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. sütunlu depolar genellikle satır odaklı veritabanlarından daha iyi sıkıştırılır. logins 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. (örneğin, B-ağacı) uygun kayıtları hızlı bir şekilde bulmak için. indeks 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 ancak gerekmez. Eski kayıtları ara sıra güncellemeniz veya muhtemelen geç gelen veya kullanım dışı verileri kaydetmeniz gerekebilir. çoğunlukla eklemelidir yalnızca ekleme olması 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: 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. Zaman serisi verileri. 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, 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). Çoğu büyük PostgreSQL iş yükü zaman serisi benzeri bir yapıya sahiptir 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ı olarak kabul edelim. toplu iş 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, İşlem, her sütunun söz konusu gruptan bir dizi değer depoladığı tek bir satırla sonuçlanır. 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. | 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 alan bir gruptan gelen 1000 satırlık veri şimdi alıyor . [1,000 * (32 + 27)] ~= 59 kilobayt [1,000 * 32 + 27'yi ] ~= Bu formatta 32 kilobayt [ : 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!] Bir kenara 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, . Timescale bu şekilde etkileyici sıkıştırma oranlarına ulaşır. her dizinin ayrı ayrı sıkıştırılması için türe özgü sıkıştırma algoritmaları uygulayabilmemizdir. Timescale otomatik olarak aşağıdaki sıkıştırma algoritmalarını kullanır. Bu algoritmaların tümü “ ”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. kayıpsız şamandıralar için Goril sıkıştırması Delta-of-delta + ile zaman damgaları ve diğer tam sayı benzeri türler için sıkıştırma Basit-8b çalışma uzunluğu kodlaması 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 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ırması 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 göre sütuna göre gruplandırma segmentby 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 ile sorgulama), bu belirli sütunu " " kolon. Bu yaklaşım, sıkıştırılmış verileri düzenlemek için oldukça faydalıdır. device_id sıkıştır_segmentby Bu 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ı anahtara sahip tüm değerleri bir araya gruplandırır. segmentby segmentby 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, olarak 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. segmentby device_id | 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ı, sütunlara göre filtrelenen sorguların verimliliğini büyük ölçüde artırır. sütun olduğu, 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. segmentby device_id segmentby device_id Ö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. sütunları tanımlama segmentby 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 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. birden fazla 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' ); aracılığıyla gelişmiş ince ayar orderby TimescaleDB, sıkıştırılmış veriler üzerindeki sorgu performansını, sıkıştırılmış veriler üzerinde, 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. compress_orderby 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 ( aracılığıyla) hem de alan ( 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. orderby segmentby 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 ile yayınlandı. Daha sonraki birçok sürümde, Zaman Ölçeği sıkıştırması uzun bir yol kat etti. TimescaleDB 1.5 İ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, , 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. bu makalede tartıştığımız gibi İ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. 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. NYC taksi veri kümesi 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, içerir. Zaman Ölçeği müşterileri arasında görülen sıkıştırma oranlarının bazı gerçek örneklerini 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ş 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. yüksek performanslı bir depolama katmanına Uygulamanız artık bu verilere sık sık erişmediğinde, bir katmanlama politikası ayarlayarak bunu 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). Örneğin, altı aydan eski tüm verilerinizi düşük maliyetli depolama katmanına taşıyan bir katmanlama politikası tanımlayabilirsiniz. daha düşük maliyetli bir nesne depolama katmanına 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. ve Timescale'i bugün deneyin; yalnızca birkaç saniye sürer, kredi kartı gerekmez. Ücretsiz bir hesap oluştur - tarafından yazılmıştır. Carlota Soto ve Mike Freedman Burada da yayınlandı.