HBase kullanmanın teorisi ve pratiği

Tünaydın Adım Danil Lipovoy, Sbertech'teki ekibimiz operasyonel veriler için depolama alanı olarak HBase'i kullanmaya başladı. Bunu incelerken, sistematikleştirmek ve tanımlamak istediğim deneyimler birikti (birçok kişi için faydalı olacağını umuyoruz). Aşağıdaki deneylerin tümü HBase versiyonları 1.2.0-cdh5.14.2 ve 2.0.0-cdh6.0.0-beta1 ile gerçekleştirildi.

1. Genel mimari
2. HBASE'e veri yazma
3. HBASE'den veri okuma
4. Veri önbelleğe alma
5. Toplu veri işleme MultiGet/MultiPut
6. Tabloları bölgelere ayırma stratejisi (bölme)
7. Hata toleransı, kompaktlaştırma ve veri yerelliği
8. Ayarlar ve performans
9. Stres testi
10. Bulgular

1. Genel mimari

Yedek Master, ZooKeeper düğümündeki aktif olanın kalp atışını dinler ve ortadan kaybolması durumunda master'ın işlevlerini devralır.

2. HBASE'e veri yazın

Öncelikle en basit duruma bakalım; put(rowkey) kullanarak bir tabloya anahtar/değer nesnesi yazma. İstemcinin öncelikle hbase:meta tablosunu saklayan Kök Bölge Sunucusunun (RRS) nerede bulunduğunu bulması gerekir. Bu bilgiyi ZooKeeper'dan alıyor. Bundan sonra RRS'ye erişir ve hbase:meta tablosunu okur; buradan ilgilenilen tabloda belirli bir satır anahtarına ilişkin verileri depolamaktan hangi RegionServer'ın (RS) sorumlu olduğu hakkında bilgi alır. Gelecekte kullanılmak üzere meta tablo istemci tarafından önbelleğe alınır ve bu nedenle sonraki çağrılar doğrudan RS'ye daha hızlı gider.

Daha sonra, bir istek alan RS, öncelikle bunu bir çökme durumunda kurtarma için gerekli olan WriteAheadLog'a (WAL) yazar. Daha sonra verileri MemStore'a kaydeder. Bu, belirli bir bölge için sıralanmış bir anahtar kümesi içeren bellekteki bir arabellektir. Bir tablo, her biri ayrı bir anahtar kümesi içeren bölgelere (bölümlere) bölünebilir. Bu, daha yüksek performans elde etmek için bölgeleri farklı sunuculara yerleştirmenize olanak tanır. Ancak bu ifadenin bu kadar açık olmasına rağmen, bunun her durumda işe yaramadığını ileride göreceğiz.

MemStore'a bir giriş yerleştirdikten sonra istemciye girişin başarıyla kaydedildiğine dair bir yanıt gönderilir. Ancak gerçekte yalnızca bir arabellekte depolanır ve diske ancak belirli bir süre geçtikten sonra veya yeni verilerle doldurulduktan sonra ulaşır.

“Sil” işlemi yapılırken veriler fiziksel olarak silinmez. Bunlar basitçe silinmiş olarak işaretlenir ve imhanın kendisi, paragraf 7'de daha ayrıntılı olarak açıklanan ana kompakt işlevin çağrıldığı anda gerçekleşir.

HFile formatındaki dosyalar HDFS'de toplanır ve zaman zaman hiçbir şeyi silmeden küçük dosyaları daha büyük dosyalar halinde birleştiren küçük sıkıştırma işlemi başlatılır. Zamanla bu durum yalnızca veri okunurken ortaya çıkan bir soruna dönüşür (bu konuya biraz sonra tekrar döneceğiz).

Yukarıda açıklanan yükleme işlemine ek olarak, çok daha etkili bir prosedür vardır ve bu veritabanının belki de en güçlü tarafı olan BulkLoad'dur. HFiles'ı bağımsız olarak oluşturup bunları diske koymamız gerçeğinde yatıyor, bu da mükemmel ölçeklendirmemize ve çok iyi hızlara ulaşmamıza olanak tanıyor. Aslında buradaki sınırlama HBase değil, donanımın yetenekleridir. Aşağıda 16 RegionServers ve 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı), HBase sürüm 1.2.0-cdh5.14.2'den oluşan bir kümedeki önyükleme sonuçları verilmiştir.

Burada, tablodaki bölüm (bölge) sayısını ve Spark uygulayıcılarını artırarak indirme hızında bir artış elde ettiğimizi görebilirsiniz. Ayrıca hız, kayıt hacmine bağlıdır. Büyük bloklar MB/sn'de artış sağlarken, küçük bloklar zaman birimi başına eklenen kayıt sayısında artış sağlar, diğer her şey eşitse.

Ayrıca aynı anda iki tabloya yükleme yapmaya başlayabilir ve hızı iki katına çıkarabilirsiniz. Aşağıda, 10 KB'lık blokların iki tabloya aynı anda yazılmasının, her birinde yaklaşık 600 MB/sn (toplam 1275 MB/sn) hızında gerçekleştiğini görebilirsiniz; bu, bir tabloya yazma hızı olan 623 MB/sn'ye denk gelir (bkz. Yukarıda 11 numara)

Ancak 50 KB'lık kayıtlarla yapılan ikinci çalıştırma, indirme hızının biraz arttığını gösteriyor, bu da sınır değerlere yaklaştığını gösteriyor. Aynı zamanda, HBASE'in kendisinde pratik olarak hiçbir yük oluşturulmadığını aklınızda tutmanız gerekir; bunun için gereken tek şey, önce hbase:meta'dan veri vermek ve HFiles'ı sıraladıktan sonra BlockCache verilerini sıfırlayıp kaydetmektir. Boş değilse MemStore arabelleğini diske aktarın.

3. HBASE'den veri okuma

İstemcinin hbase:meta'daki tüm bilgilere zaten sahip olduğunu varsayarsak (2. maddeye bakın), o zaman istek doğrudan gerekli anahtarın depolandığı RS'ye gider. İlk olarak arama MemCache'de gerçekleştirilir. Orada veri olup olmadığına bakılmaksızın arama BlockCache arabelleğinde ve gerekirse HFiles'ta da gerçekleştirilir. Dosyada veri bulunursa BlockCache'e yerleştirilir ve bir sonraki istekte daha hızlı döndürülür. Bloom filtresinin kullanımı sayesinde HFile'da arama yapmak nispeten hızlıdır; Az miktarda veri okuduktan sonra, bu dosyanın gerekli anahtarı içerip içermediğini hemen belirler ve yoksa bir sonrakine geçer.

Bu üç kaynaktan veri alan RS, bir yanıt oluşturur. Özellikle, istemcinin sürüm oluşturma talebinde bulunması durumunda, bir nesnenin birden fazla bulunan sürümünü aynı anda aktarabilir.

4. Veri Önbelleğe Alma

MemStore ve BlockCache arabellekleri, tahsis edilen yığın üstü RS belleğinin %80'ini kaplar (geri kalanı RS hizmeti görevleri için ayrılmıştır). Tipik kullanım modu, süreçlerin aynı verileri yazması ve hemen okuması şeklindeyse, BlockCache'i azaltmak ve MemStore'u artırmak mantıklı olacaktır, çünkü Yazma verileri okumak için önbelleğe girmediğinde BlockCache daha az kullanılacaktır. BlockCache arabelleği iki bölümden oluşur: LruBlockCache (her zaman yığında) ve BucketCache (genellikle yığın dışında veya bir SSD'de). BucketCache, çok fazla okuma isteği olduğunda ve LruBlockCache'e uymadığında kullanılmalıdır, bu da Çöp Toplayıcının aktif çalışmasına yol açar. Aynı zamanda, okuma önbelleğini kullanarak performansta radikal bir artış beklememelisiniz, ancak buna 8. paragrafta geri döneceğiz.

RS'nin tamamı için bir BlockCache vardır ve her tablo için bir MemStore vardır (her Sütun Ailesi için bir tane).

Gibi tarif teoride, yazarken veriler önbelleğe girmez ve aslında tablo için CACHE_DATA_ON_WRITE ve RS için "Yazmada Önbellek Verileri" gibi parametreler yanlış olarak ayarlanmıştır. Ancak pratikte MemStore'a veri yazarsak, ardından onu diske atarsak (böylece temizleriz), ardından ortaya çıkan dosyayı silersek, ardından bir alma isteği yürüterek verileri başarıyla alırız. Üstelik BlockCache'i tamamen devre dışı bırakıp tabloyu yeni verilerle doldursanız, ardından MemStore'u diske sıfırlayıp silseniz ve başka bir oturumdan talep etseniz bile, bunlar yine de bir yerden alınacaktır. Yani HBase yalnızca verileri değil aynı zamanda gizemli gizemleri de saklar.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

"Okunduğunda VERİLERİ Önbelleğe Al" parametresi yanlış olarak ayarlandı. Herhangi bir fikriniz varsa, yorumlarda tartışmaya hoş geldiniz.

5. Toplu veri işleme MultiGet/MultiPut

Tekli isteklerin işlenmesi (Al/Put/Sil) oldukça pahalı bir işlemdir, bu nedenle mümkünse bunları bir Liste veya Liste halinde birleştirmelisiniz, bu da önemli bir performans artışı elde etmenizi sağlar. Bu özellikle yazma işlemi için geçerlidir, ancak okuma sırasında aşağıdaki tuzakla karşılaşılır. Aşağıdaki grafik MemStore'dan 50 kaydın okunma süresini göstermektedir. Okuma tek bir iş parçacığında gerçekleştirildi ve yatay eksen istekteki tuşların sayısını gösteriyor. Burada, bir istekte bin anahtara çıkarıldığında yürütme süresinin düştüğünü görebilirsiniz; hız artar. Ancak MSLAB modu varsayılan olarak etkinleştirildiğinde, bu eşikten sonra performansta radikal bir düşüş başlar ve kayıttaki veri miktarı ne kadar büyük olursa çalışma süresi de o kadar uzun olur.

Testler, 8 çekirdekli, HBase 2.0.0-cdh6.0.0-beta1 sürümüne sahip bir sanal makinede gerçekleştirildi.

MSLAB modu, yeni ve eski nesil verilerin karıştırılması nedeniyle oluşan yığın parçalanmasını azaltmak için tasarlanmıştır. Geçici bir çözüm olarak, MSLAB etkinleştirildiğinde veriler nispeten küçük hücrelere (parçalara) yerleştirilir ve parçalar halinde işlenir. Sonuç olarak, talep edilen veri paketindeki hacim tahsis edilen boyutu aştığında performans keskin bir şekilde düşer. Öte yandan bu modun kapatılması da yoğun veri işleme anlarında GC nedeniyle duraklamalara yol açacağından tavsiye edilmez. Okumayla aynı anda yazma yoluyla aktif yazma durumunda hücre hacmini arttırmak iyi bir çözümdür. Kayıttan sonra MemStore'u diske sıfırlayan temizleme komutunu çalıştırdığınızda veya BulkLoad kullanarak yükleme yaptığınızda sorunun oluşmayacağını belirtmekte fayda var. Aşağıdaki tablo, MemStore'dan daha büyük (ve aynı miktarda) veriye yönelik sorguların yavaşlamalara yol açtığını göstermektedir. Ancak parça boyutunu artırarak işlem süresini normale döndürüyoruz.

Parça boyutunu artırmanın yanı sıra, verileri bölgeye göre bölmek de yardımcı olur; masa bölünmesi. Bu, her bölgeye daha az istek gelmesine neden olur ve bunlar bir hücreye sığarsa yanıt iyi kalır.

6. Tabloları bölgelere ayırma stratejisi (bölme)

HBase bir anahtar-değer deposu olduğundan ve bölümlendirme anahtara göre yapıldığından, verilerin tüm bölgelere eşit şekilde bölünmesi son derece önemlidir. Örneğin, böyle bir tablonun üç parçaya bölünmesi, verilerin üç bölgeye bölünmesiyle sonuçlanacaktır:

Daha sonra yüklenen veriler, örneğin çoğu aynı rakamla başlayan uzun değerlere benziyorsa, bu durum keskin bir yavaşlamaya yol açar, örneğin:

1000001
1000002
...
1100003

Anahtarlar bir bayt dizisi olarak saklandığından, hepsi aynı şekilde başlayacak ve bu anahtar aralığını depolayan aynı bölge #1'e ait olacaktır. Birkaç bölümleme stratejisi vardır:

HexStringSplit – Anahtarı, "00000000" => "FFFFFFFF" aralığında onaltılık kodlanmış bir dizeye dönüştürür ve solda sıfırlarla doldurulur.

ÜniformaSplit – Anahtarı, "00" => "FF" aralığında onaltılık kodlamaya sahip ve sağda sıfırlarla doldurulan bir bayt dizisine dönüştürür.

Ayrıca, bölme için herhangi bir aralık veya tuş kümesini belirtebilir ve otomatik bölmeyi yapılandırabilirsiniz. Bununla birlikte, en basit ve en etkili yaklaşımlardan biri, ÜniformaSplit ve karma birleştirmenin kullanılmasıdır; örneğin, anahtarın CRC32(satır anahtarı) işlevi ve satır anahtarının kendisi aracılığıyla çalıştırılmasından elde edilen en önemli bayt çifti:

karma + satır anahtarı

Daha sonra tüm veriler bölgelere eşit olarak dağıtılacaktır. Okurken ilk iki bayt atılır ve orijinal anahtar kalır. RS ayrıca bölgedeki veri ve anahtar miktarını da kontrol eder ve sınırlar aşılırsa bunları otomatik olarak parçalara ayırır.

7. Hata toleransı ve veri konumu

Her anahtar grubundan yalnızca bir bölge sorumlu olduğundan, RS çökmeleri veya hizmet dışı bırakılmasıyla ilgili sorunların çözümü, gerekli tüm verileri HDFS'de depolamaktır. RS düştüğünde, ana cihaz bunu ZooKeeper düğümünde bir kalp atışı olmaması yoluyla algılar. Daha sonra hizmet verilen bölgeyi başka bir RS'ye atar ve HFiles dağıtılmış bir dosya sisteminde saklandığından yeni sahibi bunları okur ve veriyi sunmaya devam eder. Ancak verilerin bir kısmı MemStore'da olabileceğinden ve HFiles'a girmek için zamanları olmadığından, işlem geçmişini geri yüklemek için yine HDFS'de depolanan WAL kullanılır. Değişiklikler uygulandıktan sonra RS isteklere yanıt verebilir ancak bu hareket, bazı verilerin ve bunlara hizmet eden süreçlerin farklı düğümlerde bulunmasına neden olur; yerellik azalıyor.

Sorunun çözümü büyük sıkıştırmadır - bu prosedür, dosyaları kendilerinden sorumlu olan düğümlere (bölgelerinin bulunduğu yere) taşır, bunun sonucunda bu prosedür sırasında ağ ve disklerdeki yük keskin bir şekilde artar. Ancak gelecekte verilere erişim gözle görülür şekilde hızlanacak. Ayrıca major_compaction, bir bölge içindeki tüm HFiles'ın tek bir dosyada birleştirilmesini gerçekleştirir ve ayrıca tablo ayarlarına bağlı olarak verileri temizler. Örneğin, bir nesnenin korunması gereken sürüm sayısını veya nesnenin fiziksel olarak silinme süresini belirtebilirsiniz.

Bu prosedürün HBase'in çalışması üzerinde çok olumlu bir etkisi olabilir. Aşağıdaki resim, aktif veri kaydı sonucunda performansın nasıl düştüğünü göstermektedir. Burada 40 iş parçacığının bir tabloya nasıl yazdığını ve 40 iş parçacığının aynı anda verileri nasıl okuduğunu görebilirsiniz. Yazma iş parçacıkları, diğer iş parçacıkları tarafından okunan giderek daha fazla HFiles üretir. Sonuç olarak, giderek daha fazla verinin bellekten kaldırılması gerekir ve sonunda GC çalışmaya başlar, bu da neredeyse tüm işi felç eder. Büyük sıkıştırma işleminin başlatılması, ortaya çıkan kalıntıların temizlenmesine ve üretkenliğin yeniden sağlanmasına yol açtı.

Test, 3 DataNode ve 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı) üzerinde gerçekleştirildi. HBase sürüm 1.2.0-cdh5.14.2

Verilerin aktif olarak yazıldığı ve okunduğu "canlı" bir tabloda büyük sıkıştırmanın başlatıldığını belirtmekte fayda var. İnternette bunun veri okunurken yanlış yanıtlara yol açabileceğine dair bir açıklama vardı. Kontrol etmek için yeni veriler üreten ve bunları bir tabloya yazan bir süreç başlatıldı. Bundan sonra hemen okudum ve ortaya çıkan değerin yazılanlarla örtüşüp örtüşmediğini kontrol ettim. Bu işlem devam ederken, büyük sıkıştırma yaklaşık 200 kez gerçekleştirildi ve tek bir arıza bile kaydedilmedi. Belki de sorun nadiren ve yalnızca yüksek yük sırasında ortaya çıkıyor, bu nedenle bu tür GC bozulmalarını önlemek için yazma ve okuma işlemlerini planlandığı gibi durdurup temizlik yapmak daha güvenlidir.

Ayrıca, büyük sıkıştırma MemStore'un durumunu etkilemez; diske aktarmak ve sıkıştırmak için floş (connection.getAdmin().flush(TableName.valueOf(tblName)) kullanmanız gerekir.

8. Ayarlar ve performans

Daha önce de belirtildiği gibi, HBase en büyük başarısını BulkLoad'u çalıştırırken hiçbir şey yapmasına gerek olmadığı yerde gösterir. Ancak bu çoğu sistem ve insan için geçerlidir. Ancak bu araç, verileri büyük bloklar halinde toplu olarak depolamak için daha uygundur; oysa süreç birden fazla birbiriyle yarışan okuma ve yazma isteği gerektiriyorsa yukarıda açıklanan Al ve Koy komutları kullanılır. Optimum parametreleri belirlemek için, çeşitli tablo parametre ve ayar kombinasyonlarıyla başlatmalar gerçekleştirildi:

• 10 iş parçacığı aynı anda 3 kez arka arkaya başlatıldı (buna iş parçacığı bloğu diyelim).
• Bir bloktaki tüm iş parçacıklarının çalışma süresinin ortalaması alındı ​​ve bu, bloğun işleminin nihai sonucuydu.
• Tüm konular aynı tabloyla çalıştı.
• İplik bloğunun her başlangıcından önce büyük bir sıkıştırma gerçekleştirildi.
• Her blok aşağıdaki işlemlerden yalnızca birini gerçekleştirdi:

-Koymak
-Elde etmek
—Al+Put

• Her blok, işleminin 50 yinelemesini gerçekleştirdi.
• Bir kaydın blok boyutu 100 bayt, 1000 bayt veya 10000 bayttır (rastgele).
• Bloklar, farklı sayıda istenen anahtarla (bir anahtar veya 10) başlatıldı.
• Bloklar farklı tablo ayarları altında çalıştırıldı. Parametreler değiştirildi:

— BlockCache = açık veya kapalı
— BlockSize = 65 KB veya 16 KB
— Bölümler = 1, 5 veya 30
— MSLAB = etkin veya devre dışı

Yani blok şöyle görünüyor:

A. MSLAB modu açıldı/kapatıldı.
B. Aşağıdaki parametrelerin ayarlandığı bir tablo oluşturuldu: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
C. Sıkıştırma GZ'ye ayarlandı.
D. 10/1/10 baytlık kayıtlarla bu tabloya 100/1000 put/get/get+put işlemleri yapılarak, arka arkaya 10000 sorgu (rastgele anahtarlar) gerçekleştirilerek 50 iş parçacığı aynı anda başlatıldı.
e. D noktası üç kez tekrarlandı.
F. Tüm iş parçacıklarının çalışma süresinin ortalaması alındı.

Olası tüm kombinasyonlar test edildi. Kayıt boyutu arttıkça hızın düşeceği veya önbelleğe almanın devre dışı bırakılmasının yavaşlamaya neden olacağı öngörülebilir. Ancak amaç, her parametrenin etkisinin derecesini ve önemini anlamaktı, böylece toplanan veriler, t-istatistiği kullanılarak anlamlılığın değerlendirilmesini mümkün kılan doğrusal bir regresyon fonksiyonunun girdisine beslendi. Put işlemlerini gerçekleştiren blokların sonuçları aşağıdadır. Tam kombinasyon seti 2*2*3*2*3 = 144 seçenek + 72 tk. bazıları iki kez yapıldı. Bu nedenle toplamda 216 çalıştırma vardır:

Test, 3 DataNode ve 4 RS'den (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı) oluşan bir mini küme üzerinde gerçekleştirildi. HBase sürüm 1.2.0-cdh5.14.2.

3.7 saniyelik en yüksek ekleme hızı, MSLAB modu kapalıyken, tek bölümlü bir tabloda, BlockCache etkinken, BlockSize = 16, 100 baytlık kayıtlar, paket başına 10 parça ile elde edildi.
82.8 saniyelik en düşük ekleme hızı, MSLAB modu etkinken, tek bölümlü bir tabloda, BlockCache etkinken, BlockSize = 16, her biri 10000 baytlık kayıtlarla elde edildi.

Şimdi modele bakalım. R2'ye dayanan modelin kalitesinin iyi olduğunu görüyoruz, ancak burada ekstrapolasyonun kontrendike olduğu kesinlikle açıktır. Parametreler değiştiğinde sistemin gerçek davranışı doğrusal olmayacaktır; bu model tahminler için değil, verilen parametreler dahilinde ne olduğunu anlamak için gereklidir. Örneğin, burada Öğrenci kriterinden BlockSize ve BlockCache parametrelerinin Put işlemi için önemli olmadığını görüyoruz (ki bu genellikle oldukça tahmin edilebilir):

Ancak bölüm sayısını artırmanın performansta düşüşe yol açması biraz beklenmedik bir durum (BulkLoad ile bölüm sayısını artırmanın olumlu etkisini zaten gördük), ancak anlaşılabilir bir durum. Öncelikle işleme için 30 yerine XNUMX bölgeye istek oluşturmanız gerekiyor ve veri hacmi de bundan kazanç sağlayacak düzeyde değil. İkincisi, toplam çalışma süresi en yavaş RS tarafından belirlenir ve DataNode sayısı RS sayısından az olduğundan bazı bölgelerin lokasyonu sıfırdır. Peki, ilk beşe bakalım:

Şimdi Get bloklarını çalıştırmanın sonuçlarını değerlendirelim:

Bölüm sayısı önemini kaybetmiştir, bu muhtemelen verilerin iyi bir şekilde önbelleğe alınması ve okuma önbelleğinin (istatistiksel olarak) en önemli parametre olmasıyla açıklanmaktadır. Doğal olarak bir istekteki mesaj sayısını artırmak da performans açısından oldukça faydalıdır. En iyi skorlar:

Son olarak önce get ve ardından put işlemlerini gerçekleştiren bloğun modeline bakalım:

Burada tüm parametreler önemlidir. Ve liderlerin sonuçları:

9. Yük testi

Nihayet az çok makul bir yük başlatacağız, ancak karşılaştırılacak bir şeyin olması her zaman daha ilginçtir. Cassandra'nın ana geliştiricisi DataStax'ın web sitesinde bulgular HBase sürüm 0.98.6-1 de dahil olmak üzere bir dizi NoSQL deposunun NT'si. Yükleme 40 iş parçacığı, veri boyutu 100 bayt, SSD diskler tarafından gerçekleştirildi. Okuma-Değiştirme-Yazma işlemlerinin test edilmesinin sonucu aşağıdaki sonuçları gösterdi.

Anladığım kadarıyla okuma 100 kayıtlık bloklar halinde yapıldı ve 16 HBase düğümü için DataStax testi saniyede 10 bin işlem performansı gösterdi.

Kümemizin de 16 düğüme sahip olması bir şans, ancak her birinin 64 çekirdeğe (iş parçacığına) sahip olması çok "şanslı" değil, DataStax testinde ise yalnızca 4 tane var. Öte yandan, onların SSD sürücüleri var, bizim ise HDD'lerimiz var veya daha fazlası, HBase'in yeni sürümü ve yük sırasında CPU kullanımı pratikte önemli ölçüde artmadı (görsel olarak yüzde 5-10 oranında). Ancak bu yapılandırmayı kullanmaya başlamayı deneyelim. Varsayılan tablo ayarları, okuma 0 ile 50 milyon arasında rastgele (yani esasen her seferinde yeni) anahtar aralığında gerçekleştirilir. Tablo 50 bölüme ayrılmış 64 milyon kayıt içermektedir. Anahtarlar crc32 kullanılarak karma hale getirilir. Tablo ayarları varsayılandır, MSLAB etkindir. 40 iş parçacığı başlatarak, her iş parçacığı 100 rastgele anahtardan oluşan bir seti okur ve oluşturulan 100 baytı hemen bu anahtarlara geri yazar.

Stand: 16 DataNode ve 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı). HBase sürüm 1.2.0-cdh5.14.2.

Ortalama sonuç saniyede 40 bin işleme yakın ve bu da DataStax testinden önemli ölçüde daha iyi. Ancak deneysel amaçlarla koşulları biraz değiştirebilirsiniz. Tüm işlerin yalnızca tek bir masa üzerinde ve yalnızca benzersiz anahtarlar üzerinde gerçekleştirilmesi pek olası değildir. Ana yükü oluşturan belirli bir "etkin" anahtar kümesinin olduğunu varsayalım. Bu nedenle, 10 farklı tabloda, 100'lük gruplar halinde, daha büyük kayıtlara (4 KB) sahip ve istenen anahtar aralığını 50 bin ile sınırlayan bir yük oluşturmaya çalışalım.Aşağıdaki grafik, her bir iş parçacığının okuduğu 40 iş parçacığının başlatılmasını göstermektedir. 100 anahtardan oluşan bir set ve bu anahtarların üzerine hemen rastgele 10 KB yazıyor.

Stand: 16 DataNode ve 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı). HBase sürüm 1.2.0-cdh5.14.2.

Yükleme sırasında, yukarıda gösterildiği gibi ana sıkıştırma birkaç kez başlatılmıştır, bu prosedür olmadan performans giderek düşecektir, ancak uygulama sırasında da ek yük ortaya çıkar. Düşüşler çeşitli sebeplerden kaynaklanmaktadır. Bazen iş parçacıklarının çalışması bitti ve yeniden başlatılırken duraklamalar yaşandı, bazen üçüncü taraf uygulamalar küme üzerinde yük oluşturdu.

Okumak ve hemen yazmak HBase için en zor çalışma senaryolarından biridir. Yalnızca 100 bayt gibi küçük koyma istekleri yaparsanız, bunları 10-50 bin parçalık paketler halinde birleştirirseniz, saniyede yüzbinlerce işlem alabilirsiniz ve durum salt okunur isteklerde de benzerdir. Sonuçların, özellikle 50 binlik bloklardaki talepler nedeniyle DataStax tarafından elde edilenlerden çok daha iyi olduğunu belirtmekte fayda var.

Stand: 16 DataNode ve 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 iş parçacığı). HBase sürüm 1.2.0-cdh5.14.2.

10. bulgular

Bu sistem oldukça esnek bir şekilde yapılandırılmıştır ancak çok sayıda parametrenin etkisi hala bilinmemektedir. Bazıları test edildi ancak sonuçta ortaya çıkan test setine dahil edilmedi. Örneğin, ön deneyler, rastgele oluşturulan veriler için anlaşılabilir olan, komşu hücrelerden gelen değerleri kullanarak bilgileri kodlayan DATA_BLOCK_ENCODING gibi bir parametrenin önemsiz önemini gösterdi. Çok sayıda yinelenen nesne kullanırsanız kazanç önemli olabilir. Genel olarak HBase'in, büyük veri blokları ile işlemler gerçekleştirirken oldukça verimli olabilen, oldukça ciddi ve iyi düşünülmüş bir veritabanı izlenimi verdiğini söyleyebiliriz. Hele ki okuma ve yazma süreçlerini zamana göre ayırmak mümkünse.

Yeterince açıklanmayan bir konu varsa size daha detaylı anlatmaya hazırım. Sizi deneyiminizi paylaşmaya veya bir şeye katılmıyorsanız tartışmaya davet ediyoruz.

Kaynak: habr.com