Barracuda'nın Faydaları ve Sıkıştırma


12

MySQL'in Antelope ve Barracuda dosya formatlarını bir süre önce okuyordum ve Barracuda ve Compression'a sahip olmaktan faydalanıp yararlanamayacağımı merak ediyorum.

Sunucum şu anda MySQL'in varsayılanı olduğu için Antelope kullanıyor.
Ben büyük veritabanı nedeniyle bellek ile birçok kez sorunları yaşadım. Veritabanım her geçen gün artıyor.

Sıkıştırma, birkaç kişiye fayda sağlıyor gibi görünüyor:
http://www.mysqlperformanceblog.com/2008/04/23/real-life-use-case-for-barracuda-innodb-file-format/

Bellek ve disk alanı daha düşük olabilir anlıyorum, ama bunu anlıyorum emin değilim (makaleden alıntı):
"~% 5 ​​CPU yükü üst göre (% 80-100 çoğunlukla G / Ç bekliyor)
0.01 Birincil anahtarla saniyede ortalama arama süresi (dönüşümden 1-20 sn önce) "

Bu iki şeyin iyileşmeyeceğini düşündüm, çünkü veriler sıkıştırılırsa, sunucunun orijinal verileri tekrar almak için sıkıştırması gerekir, bu yüzden CPU kullanımının artacağı mantıklı değil mi?

Bu, okuma / yazma yoğun uygulamalarda size fayda sağlıyor mu? Barracuda ve Compression değiştirmemi tavsiye eder misiniz?

Barracuda'nın herhangi bir sorununun farkında mısın?
Aşağıdaki sorunun cevabı birkaç konuyu işaret ediyor gibi görünüyor, ancak 2011'den beri, şimdi sabit olduklarını söyleyebilirim: /server/258022/mysql-innodb-how-to-switch to-barracuda format

Yanıtlar:


14

Sıkıştırılmamış sadece Barracuda formatı olan "Dynamic" ile ilgili olarak , özellikle blob'ların (ve herhangi bir çok dinamik alanın) nasıl saklandığı konusunda kompakttan çok az şey değişmiştir . Kompakt ve dinamik ile ilgili herhangi bir sorun yaşamadım, bu yüzden Barracuda'nın dinamiğini güvenle önerebilirim. Barracuda'nın eski yedekli ve kompakt satır biçimlerini de desteklediğini unutmayın .

Bahsettiğiniz makale muhtemelen çok eski (5.1) ve Percona CEO'su Peter Z.'nin yorumlarda biraz yanıltıcı olabileceğinden bahsediyor. Bu, iş yüklerine bağlı olarak sıkıştırmanın büyük bir kazanç olamayacağı anlamına gelmez. Ancak, hem Facebook hem de Oracle bu konuda birçok iyileştirme yaptıkları için> = 5.6 sürümlerinde denemenizi tavsiye ederim.

Daha yeni referans materyalleri olarak size tavsiye ederim:

Özellikle, Facebook materyallerini üçüncü taraf oldukları için seviyorum (gündeme gerek yok) ve dünyadaki en büyük MySQL dağıtımlarından birine sahipler. Gördüğünüz gibi SSD teknolojisini sıkıştırma ile birleştiren çok başarılı kurulumlar yaptılar.

Size fayda sağlayacak mı? Bu, iş yükünüze, çalışma setinize ve kurulumunuza (IOPS, bellek) bağlı olacaktır . GÇ bağlı, CPU bağlı veya bellek bağlı olmanıza bağlı olarak, bazı durumlarda fazladan CPU, bellek gereksinimleri (hem sıkıştırılmış hem de sıkıştırılmamış sayfalar InnoDB arabellek havuzunda depolanır) ekleyerek veya çok fazla sıkıştırma hatası oluşturarak sıkıştırma artabilir gecikme. Ayrıca veri türüne de bağlıdır: sıkıştırma, büyük metin bloblarında çok yardımcı olabilir, ancak zaten sıkıştırılmış verilerle işe yaramayabilir.

Deneyimlerime göre, pratikte, sıkıştırmanın performansın kutsal bir kâsesi olduğu ve bundan çok mutlu olduğu insanlar var, ancak diğer durumlarda, hiçbir kazanç elde edilmediğinden sıkıştırılmamış verilere geri dönmeliydik. Çok ağır bir yazma iş yükü sıkıştırma için kötü bir ortam gibi görünse de, özel durumunuzda cpu-bağlı ve belleğe bağlı değilseniz, ancak iops-bağlı değilseniz, daha az yardımcı olabilir.

Genel olarak, sonuçları tahmin etmek çok zordur, genellikle kıyaslama için bir test ortamı kurmalı ve daha sonra neden daha iyi veya daha kötü sonuçlar elde ettiğinizi (ve böylece farklı blok boyutları ile oynayabileceğinizi) keşfetmelisiniz. Barracuda tamamen güvenlidir. Sıkıştırma sizin için olabilir veya olmayabilir. Ve her zaman blobs'un istemci tarafı sıkıştırması (örneğin, CPU'ya bağlıysanız) veya RocksDB ve TokuDB gibi diğer sıkıştırma yöntemlerini veya sıkıştırmanın odaklandığı gibi büyük bir öncelik olduğu diğer üçüncü taraf motorlarını deneyebilirsiniz. InnoDB'nin işleyebileceğinden daha büyük veri kümeleri için performans.

Özetle: Barracuda'yı kullanmanın ana nedenleri BLOB kullanımı, innodb_large_prefixuyumluluk (büyük indeksler) ve sıkıştırmadır. Dinamik, MySQL 8.0'da varsayılan dosya formatıdır.


1
Bu gerçekten harika ve açık bir cevap! Tüm mantıklı ve tam olarak istediğim cevap türüdür. MySQL 5.6'dan (son zamanlarda yükselttiğim şey) bahsediyorsunuz ve Facebook'u istediğim gibi örnek olarak atıfta bulunuyorsunuz, çünkü genellikle herkesten önce zorlukların üstesinden gelmek zorundalar. Ne yazık ki ilk önce bunu test etmek kolay olmayacak, çünkü bir test ortamı üretim ile aynı CPU / IO / RAM yüküne sahip olmayacak, ama gerçekten denemek zorundayım! Zaman ayırdığınız için çok teşekkürler.
Nuno

Satır formatı tablo düzeyinde seçilebildiğinden, üretim üzerinde test etmek için biraz esneklik sağlayabilir (ayrı bir makinede uygun testlerden sonra). Bununla birlikte, bu yaklaşım potansiyel olarak hata ayıklama ve kıyaslamayı zorlaştıracaktır.
jynus

Evet, muhtemelen birkaç tabloyu ilk önce dönüştürmeye çalışabilirdim (belki çok büyük / kullanılmış olmayanlar). Ancak, büyük olanlar için, hepsini bir kerede dönüştüreceğim 1 kesinti yerine, birkaç kesinti gerekir. En iyi yaklaşımın ne olduğunu görmem gerekecek. Ancak, hata ayıklamayı neden daha zor hale getireceğini anlamıyorum. Burada tam olarak ne demek istiyorsun? Çok teşekkür ederim.
Nuno

1
Çevrimiçi bir şekilde tabloları yeniden oluşturmak için pt-online-schema-change percona.com/doc/percona-toolkit/2.2/… gibi araçlarınız var . Sadece bazı tabloları karıştırmanın, motor değişikliği nedeniyle cpu / bellek / iops değişikliklerini ölçmenin ve bunları normal yük değişikliklerinden veya yeniden oluştururken önbellek değişikliklerinden farklılaştırmanın daha zor olabileceğini belirttim. Farklı donanımlara sahip farklı bir makinede görmek de zordur, bu yüzden sadece iyi şanslar!
jynus

ZFS'de, dosya sisteminde LZ4 kullanırken kesinlikle iyi değil.
Denis Denisov
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.