Merhaba arkadaşlar, bugün sizlere özellikle büyük veritabanlarıyla uğraşırken disk alanından ciddi tasarruf sağlayabileceğiniz, hatta bazı durumlarda performansı da artırabilen bir özellikten bahsedeceğim: MySQL InnoDB Tablo Sıkıştırması (Barracuda Formatı). Eğer sunucunuzdaki MySQL tablolarınız gittikçe şişiyor ve yedekleme süreleri uzuyorsa, bu rehber tam size göre.
Bu yöntemle, tablolarınızın fiziksel diskte kapladığı alanı %40-60 oranında küçültebilirsiniz. Ancak dikkat! Her senaryo için sihirli bir değnek değil. CPU kullanımında bir artış olacağını ve okuma/yazma performansının veri yapınıza göre değişeceğini baştan söylemeliyim. Gelin adım adım nasıl uygulayacağımıza ve nelere dikkat etmemiz gerektiğine bakalım.
Ön Hazırlık ve Kontroller
İlk iş olarak, mevcut sistemimizi ve tablolarımızı kontrol edelim. Hangi tabloların sıkıştırmaya en uygun olduğunu (text, varchar, blob gibi veri tipleri içeren, büyük tablolar) anlamamız lazım.
Öncelikle, InnoDB dosya formatınızın `Barracuda` olduğundan ve `innodb_file_per_table` ayarının `ON` olduğundan emin olmalıyız. Antika `Antelope` formatında bu özellik çalışmaz.
Eğer `innodb_file_per_table` kapalıysa, hemen açalım. Bu ayar, her tablonun kendi `.ibd` dosyasında olmasını sağlar. Sıkıştırma işlemi dosya bazında yapılır.
Şimdi, veritabanındaki en büyük ve potansiyel aday tablolarımızı listeleyelim.
Bu sorgu, `ROW_FORMAT` sütununda `Compact` veya `Redundant` yazan tablaları gösteriyorsa, onları `Compressed` formatına dönüştürmeyi düşünebiliriz.
Sıkıştırma İşlemi Adımları
Diyelim ki `forum_db` veritabanındaki `forum_posts` tablosunu sıkıştırmak istiyoruz. İşlem çok basit: bir `ALTER TABLE` komutu.
ÖNEMLİ UYARI: Bu işlem, tablo kilitlenmesine (lock) ve büyük tablolarda uzun sürebilir. Canlı ve yoğun bir üretim sunucusunda, trafiğin en düşük olduğu bir bakım penceresinde yapın. Önce bir test/backup sunucusunda denemenizi şiddetle tavsiye ederim.
Temel komutumuz şu:
Buradaki `KEY_BLOCK_SIZE` parametresi çok kritik. Genellikle 8 (KB) iyi bir başlangıç noktasıdır. Değer küçüldükçe (4,2) sıkıştırma oranı artar ancak CPU yükü de artar. Büyüdükçe (16) sıkıştırma azalır. Benim tecrübem, önce 8 ile deneyip, sonra performans testleriyle 4 veya 16'ya geçmek yönünde.
İşlem bittikten sonra, kazanımımızı kontrol edelim. En kolay yolu, tablonun fiziksel dosya boyutuna bakmaktır.
"Before/After" boyut karşılaştırması yaparak tasarrufunuzu görebilirsiniz.
Performans Değerlendirmesi ve İzleme
Sıkıştırma yaptık, peki ya performans? Burada iş biraz karışıyor. Okuma (SELECT) performansı genellikle artar çünkü disk I/O azalır, daha az sayfa diskten belleğe yüklenir. Ancak yazma (INSERT/UPDATE) işlemleri için CPU, veriyi sıkıştırıp açmak zorunda kalacağından ek yük biner.
Performansı izlemek için aşağıdaki metrikleri takip etmenizi öneririm:
1. CPU Kullanımı: Özellikle `sys` (sistem) zamanında artış gözlemlenebilir.
2. MySQL İstatistikleri:
`Innodb_buffer_pool_reads` değerinde bir düşüş görmeyi umuyoruz. Bu, daha az disk okuması yapıldığı anlamına gelir ve iyidir.
Dikkat Edilmesi Gerekenler ve Sınırlamalar
CPU/Memory Trade-off: Bu bir "disk alanı-CPU gücü" takasıdır. CPU'su zayıf, diski hızlı (NVMe) bir sunucuda performans düşüşü yaşayabilirsiniz.
Fragmantasyon: Sık UPDATE/DELETE yapılan tablolarda fragmantasyon artar. Periyodik olarak `OPTIMIZE TABLE forum_posts;` çalıştırmak gerekebilir. Bu komut da tabloyu yeniden yazar ve kilitler, dikkatli kullanın.
Yedekleme/Restore: Yedekleriniz (özellikle fiziksel kopya) daha hızlı alınır ve daha az yer kaplar. Ancak, yedekten dönme işlemi sırasında verinin açılması için ek CPU gerekecektir.
Tüm Tablolar İçin Değil: Zaten optimize edilmiş, çok sık güncellenen veya küçük boyutlu tablolarda buna girmeyin. Faydadan çok zarar görebilirsiniz.
Sonuç ve Tavsiyeler
Ben genellikle, arşiv niteliğindeki log tablolarında, metin içeriği bol olan (forum mesajları, blog yazıları) tablolarda ve SSD'si olmayan, disk I/O'su darboğaz sunucularda bu yöntemi gönül rahatlığıyla uyguluyorum. Özellikle yedekleme sürelerindeki kazanç benim için çok değerli.
Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? `KEY_BLOCK_SIZE` olarak hangi değeri tercih ediyorsunuz ve performans gözlemleriniz neler? Tecrübelerinizi paylaşırsanız hepimiz faydalanırız. Sorularınız ve eklemek istedikleriniz için aşağıya yazmaktan çekinmeyin. Kolay gelsin!
Bu yöntemle, tablolarınızın fiziksel diskte kapladığı alanı %40-60 oranında küçültebilirsiniz. Ancak dikkat! Her senaryo için sihirli bir değnek değil. CPU kullanımında bir artış olacağını ve okuma/yazma performansının veri yapınıza göre değişeceğini baştan söylemeliyim. Gelin adım adım nasıl uygulayacağımıza ve nelere dikkat etmemiz gerektiğine bakalım.
Ön Hazırlık ve Kontrollerİlk iş olarak, mevcut sistemimizi ve tablolarımızı kontrol edelim. Hangi tabloların sıkıştırmaya en uygun olduğunu (text, varchar, blob gibi veri tipleri içeren, büyük tablolar) anlamamız lazım.
Öncelikle, InnoDB dosya formatınızın `Barracuda` olduğundan ve `innodb_file_per_table` ayarının `ON` olduğundan emin olmalıyız. Antika `Antelope` formatında bu özellik çalışmaz.
SQL:
SHOW VARIABLES LIKE 'innodb_file_format';
SHOW VARIABLES LIKE 'innodb_file_per_table';Eğer `innodb_file_per_table` kapalıysa, hemen açalım. Bu ayar, her tablonun kendi `.ibd` dosyasında olmasını sağlar. Sıkıştırma işlemi dosya bazında yapılır.
SQL:
SET GLOBAL innodb_file_per_table=ON;Şimdi, veritabanındaki en büyük ve potansiyel aday tablolarımızı listeleyelim.
SQL:
SELECT
table_schema,
table_name,
round(((data_length + index_length) / 1024 / 1024), 2) as 'Boyut (MB)',
engine,
row_format
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema', 'mysql', 'performance_schema')
ORDER BY (data_length + index_length) DESC
LIMIT 10;Bu sorgu, `ROW_FORMAT` sütununda `Compact` veya `Redundant` yazan tablaları gösteriyorsa, onları `Compressed` formatına dönüştürmeyi düşünebiliriz.
Sıkıştırma İşlemi AdımlarıDiyelim ki `forum_db` veritabanındaki `forum_posts` tablosunu sıkıştırmak istiyoruz. İşlem çok basit: bir `ALTER TABLE` komutu.
ÖNEMLİ UYARI: Bu işlem, tablo kilitlenmesine (lock) ve büyük tablolarda uzun sürebilir. Canlı ve yoğun bir üretim sunucusunda, trafiğin en düşük olduğu bir bakım penceresinde yapın. Önce bir test/backup sunucusunda denemenizi şiddetle tavsiye ederim.
Temel komutumuz şu:
SQL:
ALTER TABLE forum_db.forum_posts
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=8;Buradaki `KEY_BLOCK_SIZE` parametresi çok kritik. Genellikle 8 (KB) iyi bir başlangıç noktasıdır. Değer küçüldükçe (4,2) sıkıştırma oranı artar ancak CPU yükü de artar. Büyüdükçe (16) sıkıştırma azalır. Benim tecrübem, önce 8 ile deneyip, sonra performans testleriyle 4 veya 16'ya geçmek yönünde.
İşlem bittikten sonra, kazanımımızı kontrol edelim. En kolay yolu, tablonun fiziksel dosya boyutuna bakmaktır.
Bash:
# MySQL datadir'inizin yolunu bilmeniz gerekir. Genelde /var/lib/mysql'dir.
ls -lh /var/lib/mysql/forum_db/forum_posts.ibd"Before/After" boyut karşılaştırması yaparak tasarrufunuzu görebilirsiniz.
Performans Değerlendirmesi ve İzlemeSıkıştırma yaptık, peki ya performans? Burada iş biraz karışıyor. Okuma (SELECT) performansı genellikle artar çünkü disk I/O azalır, daha az sayfa diskten belleğe yüklenir. Ancak yazma (INSERT/UPDATE) işlemleri için CPU, veriyi sıkıştırıp açmak zorunda kalacağından ek yük biner.
Performansı izlemek için aşağıdaki metrikleri takip etmenizi öneririm:
1. CPU Kullanımı: Özellikle `sys` (sistem) zamanında artış gözlemlenebilir.
2. MySQL İstatistikleri:
SQL:
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_pages_compressed';
SHOW GLOBAL STATUS LIKE 'Innodb_compression_time';`Innodb_buffer_pool_reads` değerinde bir düşüş görmeyi umuyoruz. Bu, daha az disk okuması yapıldığı anlamına gelir ve iyidir.
Dikkat Edilmesi Gerekenler ve SınırlamalarCPU/Memory Trade-off: Bu bir "disk alanı-CPU gücü" takasıdır. CPU'su zayıf, diski hızlı (NVMe) bir sunucuda performans düşüşü yaşayabilirsiniz.
Fragmantasyon: Sık UPDATE/DELETE yapılan tablolarda fragmantasyon artar. Periyodik olarak `OPTIMIZE TABLE forum_posts;` çalıştırmak gerekebilir. Bu komut da tabloyu yeniden yazar ve kilitler, dikkatli kullanın.
Yedekleme/Restore: Yedekleriniz (özellikle fiziksel kopya) daha hızlı alınır ve daha az yer kaplar. Ancak, yedekten dönme işlemi sırasında verinin açılması için ek CPU gerekecektir.
Tüm Tablolar İçin Değil: Zaten optimize edilmiş, çok sık güncellenen veya küçük boyutlu tablolarda buna girmeyin. Faydadan çok zarar görebilirsiniz.
Sonuç ve TavsiyelerBen genellikle, arşiv niteliğindeki log tablolarında, metin içeriği bol olan (forum mesajları, blog yazıları) tablolarda ve SSD'si olmayan, disk I/O'su darboğaz sunucularda bu yöntemi gönül rahatlığıyla uyguluyorum. Özellikle yedekleme sürelerindeki kazanç benim için çok değerli.
Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? `KEY_BLOCK_SIZE` olarak hangi değeri tercih ediyorsunuz ve performans gözlemleriniz neler? Tecrübelerinizi paylaşırsanız hepimiz faydalanırız. Sorularınız ve eklemek istedikleriniz için aşağıya yazmaktan çekinmeyin. Kolay gelsin!