Önceki bir gönderide, sorgulama ve alma iş yükleri için üretilen işi ve performansı ölçeklendirmek için bir parçalama sistemi tanımlamıştım. Bu yazıda, bir parçalama veritabanı için performans ve yönetimde daha fazla avantaj sağlayan başka bir yaygın teknik olan bölümlemeyi tanıtacağım. Ayrıca, hem sorgulama hem de alma iş yükleri için bölümlerin nasıl verimli bir şekilde ele alınacağını ve okuma gereksinimlerinin sıcak (son) bölümlerden oldukça farklı olduğu soğuk (eski) bölümlerin nasıl yönetileceğini açıklayacağım.
Parçalama ve bölümleme
Parçalama, dağıtılmış bir veritabanı sistemindeki verileri bölmenin bir yoludur. Her parçadaki veriler, CPU veya bellek gibi kaynakları paylaşmak zorunda değildir ve paralel olarak okunabilir veya yazılabilir.
Şekil 1, bir parçalama veritabanı örneğidir. Bir ülkenin 50 eyaletinin satış verileri, her biri 12 veya 13 eyaletin verilerini içeren dört parçaya bölünür. Her parçaya bir sorgu düğümü atayarak, 50 durumun tümünü okuyan bir iş, paralel olarak çalışan bu dört düğüm arasında bölünebilir ve 50 durumu tek bir düğümle okuyan kuruluma kıyasla dört kat daha hızlı gerçekleştirilecektir. Parçalar ve bunların alım ve sorgu iş yükleri üzerindeki ölçeklendirme etkileri hakkında daha fazla bilgi önceki gönderimde bulunabilir.
Bölümleme, daha fazla paralel işleme için her bir parçadaki verileri örtüşmeyen bölümlere ayırmanın bir yoludur. Bu, gereksiz verilerin okunmasını azaltır ve veri saklama ilkelerinin verimli bir şekilde uygulanmasına olanak tanır.
Şekil 2’de, her bir parçanın verileri satış gününe göre bölümlenmiştir. 1 Mayıs 2022 gibi belirli bir günün satışları hakkında bir rapor oluşturmamız gerekirse, sorgu düğümlerinin yalnızca karşılık gelen 2022.05.01 bölümlerinin verilerini okuması gerekir.
Bu yazının geri kalanı bölümlemenin etkilerine odaklanacak. Hem sıcak hem de soğuk verilerde hem sorgulama hem de alma iş yükleri için bölümleri nasıl verimli bir şekilde yöneteceğimizi göreceğiz.
bölümleme efektleri
Veri bölümlemenin en yaygın üç faydası, veri budama, düğüm içi paralellik ve hızlı silmedir.
Veri budama
Bir veritabanı sistemi birkaç yıllık veri içerebilir, ancak çoğu sorgunun yalnızca son verileri okuması gerekir (örneğin, “Son üç günde kaç sipariş verildi?”). Verileri, Şekil 2’de gösterildiği gibi, örtüşmeyen bölümlere bölmek, tüm sınır dışı bölümleri atlamayı ve sonuçları hızlı bir şekilde döndürmek için yalnızca ilgili ve çok küçük veri kümelerini okuyup işlemeyi kolaylaştırır.
Düğüm içi paralellik
Çok iş parçacıklı işleme ve veri akışı, bir veritabanı sisteminde mevcut CPU ve belleği tam olarak kullanmak ve mümkün olan en iyi performansı elde etmek için kritik öneme sahiptir. Verileri küçük bölümlere ayırmak, bölüm başına bir iş parçacığı yürüten çok iş parçacıklı bir motorun uygulanmasını kolaylaştırır. Her bölüm için, o bölümdeki verileri işlemek için daha fazla iş parçacığı oluşturulabilir. Boyut ve satır sayısı gibi bölüm istatistiklerini bilmek, belirli bölümler için en uygun CPU ve bellek miktarını ayırmaya yardımcı olacaktır.
Hızlı veri silme
Birçok kuruluş yalnızca son verileri (örneğin, son üç ayın verileri) tutar ve eski verileri bir an önce kaldırmak ister. Verileri örtüşmeyen zaman pencerelerinde bölümlere ayırarak, eski bölümleri kaldırmak, verileri yeniden düzenlemeye ve diğer sorgu veya alım etkinliklerini kesmeye gerek kalmadan dosyaları silmek kadar basit hale gelir. Tüm verilerin saklanması gerekiyorsa, bu yazının ilerleyen bölümlerinde, sistemlerin her durumda mükemmel performans sağlamasını sağlamak için yeni ve eski verilerin nasıl farklı şekilde yönetileceği açıklanacaktır.
Bölümleri depolama ve yönetme
Sorgu iş yükleri için optimizasyon
Bir bölüm zaten küçük bir veri kümesi içerir, bu nedenle bir bölümü birçok küçük dosyada (veya bellek içi veritabanı durumunda parçalarda) depolamak istemiyoruz. Bir bölüm yalnızca bir veya birkaç dosyadan oluşmalıdır.
Bir bölümdeki dosya sayısını en aza indirmenin iki önemli faydası vardır. Hem bir sorgu yürütmek için veri okurken G/Ç işlemlerini azaltır hem de veri kodlama/sıkıştırmayı iyileştirir. Kodlamayı iyileştirmek, depolama maliyetlerini düşürür ve daha da önemlisi, daha az veri okuyarak sorgu yürütme hızını artırır.
Alım iş yükleri için optimizasyon
Saf Yutma. Yukarıda belirtilen okuma optimizasyonunun yararları için bir bölümün verilerini bir dosyada tutmak için, bir veri kümesi her alındığında, ayrıştırılmalı ve doğru bölümlere ayrılmalı, ardından ilgili bölümünün mevcut dosyasıyla birleştirilmelidir, Şekil 3’te gösterildiği gibi.
Yeni verileri mevcut verilerle birleştirme işlemi, pahalı G/Ç ve bölümün verilerini karıştırma ve kodlama maliyeti nedeniyle genellikle zaman alır. Bu, verinin başarıyla alındığına dair müşteriye verilen yanıtlar ve yeni alınan verinin sorguları için uzun gecikmeye yol açacaktır, çünkü bunlar hemen depolamada mevcut olmayacaktır.
Düşük gecikmeli alım. Her alımın gecikmesini düşük tutmak için süreci iki adıma ayırabiliriz: alım ve sıkıştırma.
yutma
Alım adımı sırasında, alınan veriler Şekil 4’te gösterildiği gibi bölünür ve kendi dosyasına yazılır. Bölümün mevcut verileriyle birleştirilmez. Alınan veriler başarılı bir şekilde kalıcı olur olmaz, alma istemcisi bir başarı sinyali alacak ve yeni alınan dosya sorgulama için hazır olacaktır.
Alım hızı yüksekse, Şekil 5’te gösterildiği gibi, bölümde çok sayıda küçük dosya birikir. Bu aşamada, bir bölümden veriye ihtiyaç duyan bir sorgu, o bölümdeki tüm dosyaları okumalıdır. Bu elbette sorgu performansı için ideal değildir. Aşağıda açıklanan sıkıştırma adımı, bu dosya birikimini minimumda tutar.
Sıkıştırma
Sıkıştırma, daha iyi sorgu performansı ve sıkıştırma için bir bölümün dosyalarını bir veya birkaç dosyada birleştirme işlemidir. Örneğin, Şekil 6, 2022.05.01 bölümündeki tüm dosyaların tek bir dosyada birleştirilmesini ve 2022.05.02 bölümündeki tüm dosyaların her biri 100 MB’den küçük iki dosyada birleştirilmesini göstermektedir.
Sıkıştırılmış dosyaların ne sıklıkta sıkıştırılacağına ve sıkıştırılmış dosyaların maksimum boyutuna ilişkin kararlar farklı sistemler için farklı olacaktır, ancak ortak amaç, I/O’ları (yani dosya sayısını) azaltarak ve dosyaların büyük olmasını sağlayarak sorgu performansını yüksek tutmaktır. etkili bir şekilde sıkıştırmak için yeterlidir.
Sıcak ve soğuk bölmeler
Sık sorgulanan bölümler sıcak bölümler olarak kabul edilirken, nadiren okunan bölümler soğuk bölümler olarak adlandırılır. Veritabanlarında, sıcak bölümler genellikle son satış tarihleri gibi son verileri içeren bölümlerdir. Soğuk bölümler genellikle okunma olasılığı daha düşük olan eski verileri içerir.
Ayrıca, veriler eskidiğinde, genellikle daha büyük parçalar halinde, örneğin ay, hatta yıl gibi sorgulanır. Verileri açık bir şekilde sıcaktan soğuğa kategorize etmek için birkaç örnek:
- Sıcak: Mevcut haftanın verileri.
- Daha az sıcak: Önceki haftalardan ancak mevcut aya ait veriler.
- Soğuk: Önceki aylara ait ancak cari yıla ait veriler.
- Daha soğuk: Geçen yıl ve daha eski yıllara ait veriler.
Sıcak ve soğuk veriler arasındaki belirsizliği azaltmak için iki soruya cevap bulmamız gerekiyor. İlk olarak, sıcak, daha az sıcak, soğuk, daha fazla soğuk ve belki de giderek daha fazla soğuğu ölçmemiz gerekir. İkinci olarak, soğuk veri okuma durumunda nasıl daha az I/O elde edebileceğimizi düşünmemiz gerekiyor. Her biri bir günlük veri bölümünü temsil eden 365 dosyayı sadece geçen yılın satış gelirini elde etmek için okumak istemiyoruz.
hiyerarşik bölümleme
Şekil 7’de gösterilen hiyerarşik bölümleme, yukarıdaki iki soruya yanıt sağlar. Geçerli haftanın her günü için veriler kendi bölümünde saklanır. Geçerli ayın önceki haftalarına ait veriler haftalara göre bölümlenir. Cari yıldaki önceki aylara ait veriler aya göre bölümlenir. Daha da eski olan veriler yıllara göre bölümlenir.
Bu model, geçerli tarih bölümü yerine aktif bir bölüm tanımlanarak gevşetilebilir. Etkin bölümden sonra gelen tüm veriler tarihe göre bölümlenirken, etkin bölümden önceki veriler haftaya, aya ve yıla göre bölümlenir. Bu, sistemin gerektiği kadar çok sayıda küçük yeni bölüm tutmasını sağlar. Bu bölümleme sonrası verilerindeki tüm örnekler zamana göre olsa da, bir bölüm ve bunların hiyerarşisi için ifadeler tanımlayabildiğiniz sürece zamansız bölümleme benzer şekilde çalışacaktır.
Hiyerarşik bölümleme, sistemdeki bölüm sayısını azaltarak yönetimi kolaylaştırır ve daha büyük ve daha eski parçaları sorgularken okunması gereken bölüm sayısını azaltır.
Hiyerarşik bölümleme için sorgu süreci, hiyerarşik olmayan bölümleme ile aynıdır, çünkü sadece ilgili bölümleri okumak için aynı budama stratejisini uygulayacaktır. Bölmeleri tanımlanmış hiyerarşilerinde organize etmek daha zor olacağından, alım ve sıkıştırma süreçleri biraz daha karmaşık olacaktır.
Toplu bölümleme
Birçok kuruluş eski verileri tutmak istemez, bunun yerine her ay sipariş sayısı ve her ürünün toplam satışı gibi toplamaları tutmayı tercih eder. Bu, verileri toplayarak ve aya göre bölümlere ayırarak desteklenebilir. Ancak, toplu bölümler birleştirilmiş verileri depoladığından, şemaları toplanmayan bölümlerden farklı olacak ve bu da alma ve sorgulama için fazladan çalışmaya yol açacaktır. Bu soğuk ve toplu verileri yönetmenin farklı yolları vardır, ancak bunlar gelecekteki bir gönderiye uygun büyük konulardır.
Nga Tran, bir personel yazılım mühendisidir. InfluxDatave bir üyesi InfluxDB IOx InfluxDB için yeni nesil zaman serisi depolama motorunu oluşturan ekip. InfluxData’dan önce Nga, on yıldan fazla bir süredir Vertica Analytic DBMS ile çalışıyordu. Vertica için sorgu iyileştiriciyi oluşturan kilit mühendislerden biriydi ve daha sonra Vertica’nın mühendislik ekibini yönetti.
–
New Tech Forum, ortaya çıkan kurumsal teknolojiyi benzeri görülmemiş bir derinlikte ve genişlikte keşfetmek ve tartışmak için bir alan sağlar. Seçim, önemli olduğuna inandığımız ve InfoWorld okuyucularının en çok ilgisini çeken teknolojileri seçmemize dayalı olarak özneldir. InfoWorld, yayın için pazarlama teminatı kabul etmez ve katkıda bulunan tüm içeriği düzenleme hakkını saklı tutar. Tüm sorularınızı [email protected] adresine gönderin.
Telif Hakkı © 2022 IDG Communications, Inc.
Kaynak : https://www.infoworld.com/article/3666513/partitioning-for-performance-in-a-sharding-database-system.html#tk.rss_all