MariaDB'de Tablo Bölümleme: RANGE, LIST, HASH, KEY ve Bölüm Bakımı

Bölümleme ne zaman işe yarar?

Belgeler bölümlemenin dört tipik kullanımını sayar. Birincisi büyük satır gruplarını silmektir: bir yılın tüm satırlarını DELETE ile silmek çok yavaş olabilirken o yılın bölümünü düşürmek çok hızlıdır. İkincisi, çok büyük tablolarda yalnızca birkaç bölümü okuyan sorguların hızlanmasıdır; ama bunun için sorguların dikkatle, bölümleme ifadesine uygun yazılması gerekir. Üçüncüsü dosyaları farklı depolama aygıtlarına dağıtabilmek, dördüncüsü de tüm tablo yerine yalnızca bir bölümün düzenli yedeğini alabilmektir.

Bakım sayfasındaki en iyi uygulamalar beklentileri gerçekçi tutmak için önemlidir. Belgelere göre bölümleme genellikle yalnızca bir milyondan fazla satırı olan tablolarda belirgin fayda sağlar. MariaDB 8192 bölüme kadar izin verse de bölüm sayısını 50'nin altında tutmak önerilir, çünkü çok sayıda bölüm tablonun açılmasını ve durum denetimlerini yavaşlatabilir. En önemlisi, bölümleme doğru index'in yerini tutmaz: tek bir satırı bulan nokta sorguları, bölümlenmemiş bir tabloda uygun bir index ile çoğu zaman aynı hızdadır.

Bölümleme desteğinin açık olup olmadığını SHOW PLUGINS çıktısındaki partition satırından görebilirsiniz. Belgelere göre MariaDB varsayılan olarak bölümlemeye izin verir; satır DISABLED görünüyorsa sunucu bölümleme desteği olmadan derlenmiş ya da --skip-partition benzeri bir seçenekle başlatılmıştır:

SHOW PLUGINS;
...
| Aria                          | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
| FEEDBACK                      | DISABLED | INFORMATION SCHEMA | NULL    | GPL     |
| partition                     | ACTIVE   | STORAGE ENGINE     | NULL    | GPL     |
+-------------------------------+----------+--------------------+---------+---------+

Bölümleme türleri

Bölümleme yaparken iki karar verirsiniz: satırların bölümlere nasıl dağıtılacağını belirleyen tür ve bazı türlerde gereken bölümleme ifadesi. Bölümleme ifadesi tamsayı ya da zamansal bir değer döndüren bir SQL ifadesidir ve tablodaki tüm okuma ve yazmalarda kullanılır; bu yüzden belgeler onun hızlı olması gerektiğini vurgular.

RANGE: aralığa göre bölümleme

RANGE türünde her bölüme VALUES LESS THAN (değer) ile bir üst sınır verilir. Aralıklar sıralı, bitişik ve çakışmayan olmalıdır; değerler artan sırada yazılır. İlk bölümün alt sınırı NULL'dır. Belgelerdeki örnek bir log tablosunu yıla göre bölümler:

CREATE TABLE log
(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,
    dt DATETIME NOT NULL,
    user INT UNSIGNED,
    PRIMARY KEY (id, dt)
)
    ENGINE = InnoDB
PARTITION BY RANGE (YEAR(dt))
(
    PARTITION p0 VALUES LESS THAN (2013),
    PARTITION p1 VALUES LESS THAN (2014),
    PARTITION p2 VALUES LESS THAN (2015),
    PARTITION p3 VALUES LESS THAN (2016)
);

Son bölümün üst sınırından büyük bir değer eklemeye çalışırsanız satır reddedilir. IGNORE anahtar sözcüğü kullanılmazsa bu bir hata olarak döner:

INSERT INTO log(id,dt) VALUES
  (1, '2016-01-01 01:01:01'),
  (2, '2015-01-01 01:01:01');
ERROR 1526 (HY000): Table has no partition for value 2016

Bunu önlemek için son bölüm olarak VALUES LESS THAN MAXVALUE ile her şeyi yakalayan bir bölüm tanımlanabilir. Ancak belgelere göre bu durumda sona yeni bir bölüm eklemek için ADD PARTITION kullanılamaz, REORGANIZE PARTITION ile MAXVALUE bölümünü bölmek gerekir. Belgeler aynı zamanda tarih yerine AUTO_INCREMENT kimliğine göre bölümlemenin mümkün olduğunu, ama tabloyu genellikle tarihle sorguluyorsanız iyi bir seçim olmadığını belirtir. Ay bazlı bölümleme için belgelerdeki ikinci örnek UNIX_TIMESTAMP() fonksiyonunu kullanır.

LIST ve COLUMNS türleri

LIST türünde her bölüme bir değer listesi atanır; ifade bu değerlerden birini döndürürse satır o bölüme gider. Hiçbir listeye uymayan satır hatayla reddedilir, ama DEFAULT bölümü tanımlanırsa bu satırları yakalar. LIST, sınırlı sayıda değer alan bir sütun için uygundur ve değerleri bölümlere eşit dağıtacak şekilde gruplamanıza izin verir:

CREATE OR REPLACE TABLE t1 (
  num TINYINT(1) NOT NULL
)
  ENGINE = InnoDB
  PARTITION BY LIST (num) (
    PARTITION p0 VALUES IN (0,1),
    PARTITION p1 VALUES IN (2,3),
    PARTITION p2 DEFAULT
  );

RANGE COLUMNS ve LIST COLUMNS bu iki türün çeşitlemeleridir. Tek bir ifade yerine bir veya daha çok sütun listesi alırlar; yalnızca çıplak sütunlara izin verilir, ifade yazılamaz. Sütunlar tamsayı, dize, DATE ve DATETIME tiplerinde olabilir. RANGE COLUMNS'ta satır, değer demeti sözlük sırasında ilk "küçük" kaldığı bölüme gider; LIST COLUMNS'ta tüm değerleri birebir eşleşen bölüme gider ve en fazla bir DEFAULT bölümüne izin verilir:

CREATE OR REPLACE TABLE t1 (
  date1 DATE NOT NULL,
  date2 DATE NOT NULL
)
  ENGINE = InnoDB
  PARTITION BY RANGE COLUMNS (date1,date2) (
    PARTITION p0 VALUES LESS THAN ('2013-01-01', '1994-12-01'),
    PARTITION p1 VALUES LESS THAN ('2014-01-01', '1995-12-01'),
    PARTITION p2 VALUES LESS THAN ('2015-01-01', '1996-12-01')
);

HASH ve KEY: eşit dağıtım

HASH türünde bölümü sunucu seçer ve satırları bölümlere eşit dağıtmaya çalışır. Bölümleme ifadesi sabit olmayan, deterministik bir tamsayı döndürmelidir ve her ekleme ve güncellemede hesaplanır; bu yüzden karmaşık ifadeler performans sorununa yol açabilir. Belgeler çok sütunlu karma ifadeleri genellikle önermez. PARTITIONS verilmezse bölüm sayısı birdir. Hangi bölümün seçildiği MOD(ifade, bölüm_sayısı) ile hesaplanır. Belgelerdeki örnekte TO_DAYS('2023-11-15') 739204 verir, MOD(739204,5) 4 olduğu için satır p4 bölümüne düşer:

CREATE OR REPLACE TABLE t1 (c1 INT, c2 DATETIME)
  PARTITION BY HASH(TO_DAYS(c2))
  PARTITIONS 5;

INSERT INTO t1 VALUES (1,'2023-11-15');

SELECT PARTITION_NAME,TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS
  WHERE TABLE_SCHEMA='test' AND TABLE_NAME='t1';
+----------------+------------+
| PARTITION_NAME | TABLE_ROWS |
+----------------+------------+
| p0             |          0 |
| p1             |          0 |
| p2             |          0 |
| p3             |          0 |
| p4             |          1 |
+----------------+------------+

LINEAR HASH aynı işi ikinin kuvvetlerine dayalı bir algoritmayla yapar. Belgelere göre düz HASH ile veri daha eşit dağılır, ama bölüm ekleme, düşürme, birleştirme ve bölme LINEAR HASH'e göre çok daha yavaştır.

KEY türü HASH'e benzer, fark şudur: karma işlevini kullanıcı ifadesi değil sunucu sağlar ve sütunlar tamsayıyla sınırlı değildir. Sütun listesi boş bırakılırsa tablonun birincil anahtarı, o yoksa NOT NULL bir benzersiz anahtar kullanılır; ikisi de yoksa 1488 hatası döner. KEY bölümleri sütun önekli index tanımlarını desteklemez. MariaDB 12.3 ile KEY sözdizimine bir ALGORITHM seçeneği eklendi:

PARTITION BY KEY
[ALGORITHM={MYSQL51|MYSQL55|BASE31|CRC32C|XXH32|XXH3}]
([column_names])
[PARTITIONS (number_of_partitions)]

Belgelere göre MYSQL55 varsayılandır ve 12.3 öncesinde de varsayılan olarak kullanılıyordu. CRC32C, XXH32 ve XXH3 aynı adlı yerleşik karma algoritmalarını kullanır ve önerilen seçeneklerdir; BASE31 ise basit sıralı verilerde MYSQL51 ve MYSQL55'ten daha eşit dağılan basit bir temel çizgidir. Aynı değişiklik LINEAR KEY sayfasında da 12.3 için not edilmiştir. Bu sürümün diğer yenilikleri MariaDB 12.3 LTS yenilikleri yazısında toplanıyor.

CREATE OR REPLACE TABLE oturumlar (
  oturum_id VARCHAR(64) NOT NULL PRIMARY KEY,
  kullanici_id INT UNSIGNED NOT NULL
)
  PARTITION BY KEY ALGORITHM=XXH3 (oturum_id)
  PARTITIONS 4;

Benzersiz anahtar kuralı

Bölümlemede en sık takılınan kural şudur: bölümleme ifadesinde kullanılan tüm sütunlar, tablodaki her benzersiz anahtarın parçası olmalıdır. Bu yüzden yukarıdaki log örneğinde birincil anahtar yalnızca id değil (id, dt) olarak tanımlanmıştır. Kural ihlal edildiğinde 1503 kodlu "A %s must include all columns in the table's partitioning function" hatası gelir. Pratikte bu, bölümleme sütununu birincil anahtara eklemek ya da benzersizliği uygulama tarafında sağlamak anlamına gelir.

Partition pruning ve partition selection

WHERE koşulu bölümleme ifadesiyle ilişkiliyse iyileştirici (optimizer) hangi bölümlerin gerekli olduğunu bilir ve diğerlerini hiç okumaz; buna partition pruning denir. Hangi bölümlerin okunduğunu EXPLAIN PARTITIONS çıktısındaki partitions sütununda görebilirsiniz. Koşul bu bilgiyi içermiyorsa ama hangi bölümlerin ilgili olduğunu siz biliyorsanız, tablo adından sonra PARTITION (...) yazarak MariaDB'yi yalnızca o bölümlere erişmeye zorlayabilirsiniz; buna partition selection denir ve SELECT, INSERT, UPDATE, DELETE ve REPLACE ifadelerinde desteklenir:

EXPLAIN PARTITIONS SELECT * FROM orders WHERE id < 15000000;
+------+-------------+--------+------------+-------+---------------+---------+---------+------+------+-------------+
| id   | select_type | table  | partitions | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+------+-------------+--------+------------+-------+---------------+---------+---------+------+------+-------------+
|    1 | SIMPLE      | orders | p0,p1      | range | PRIMARY       | PRIMARY | 4       | NULL |    2 | Using where |
+------+-------------+--------+------------+-------+---------------+---------+---------+------+------+-------------+

SELECT * FROM orders PARTITION (p3) WHERE user_id = 50;
SELECT * FROM orders PARTITION (p2,p3) WHERE user_id >= 40;

Belgeler tetikleyicilerle ilgili bir ayrıntıya da dikkat çeker: tabloda bir BEFORE INSERT ya da BEFORE UPDATE tetikleyicisi varsa MariaDB bölümleme sütunlarının değişip değişmeyeceğini önceden bilemez ve tüm bölümleri kilitlemek zorunda kalır. Sorgu planlarını okumak için MariaDB EXPLAIN ve ANALYZE yazısına bakın.

Bölüm ekleme, bölme ve birleştirme

ADD PARTITION mevcut bir tabloya bölüm ekler. RANGE türünde yalnızca aralığın üst ucuna ekleme yapılabilir; alt uca eklemeye çalışmak 1493 hatası verir. Bunun yerine REORGANIZE PARTITION ile mevcut bir bölüm bölünür:

ALTER TABLE t1 ADD PARTITION (
  PARTITION p4 VALUES LESS THAN (2017),
  PARTITION p5 VALUES LESS THAN (2018)
);

ALTER TABLE t1 ADD PARTITION (
  PARTITION p0a VALUES LESS THAN (2012)
);
ERROR 1493 (HY000): VALUES LESS THAN value must be strictly increasing for each partition

REORGANIZE PARTITION veri kaybetmeden bölüm yapısını değiştirir: bir bölümü birkaç bölüme ayırabilir, birkaç bölümü tek bölümde birleştirebilir, VALUES LESS THAN aralıklarını ya da VALUES IN listelerini değiştirebilir ve bölümleri yeniden adlandırabilir. Belgelere göre yeniden adlandırma bölümün bir kopyasını oluşturur. İlk örnek alt uca bir bölüm eklemek için p0'ı ikiye bölüyor, ikincisi iki bölümü birleştiriyor:

ALTER TABLE t1 REORGANIZE PARTITION p0 INTO (
    PARTITION p0a VALUES LESS THAN (2012),
    PARTITION p0b VALUES LESS THAN (2013)
);

ALTER TABLE t1 REORGANIZE PARTITION p2,p3 INTO (
    PARTITION p2 VALUES LESS THAN (2016)
);

Bölüm silme, boşaltma ve değiştirme

DROP PARTITION RANGE ve LIST türlerinde belirtilen bölümleri içindeki tüm verilerle birlikte siler; HASH ve KEY türlerinde kullanılamaz. TRUNCATE PARTITION yapıyı korur ama verileri siler ve bölümlerin bitişik olması gerekmez. COALESCE PARTITION n HASH ve KEY bölüm sayısını n kadar azaltır. REMOVE PARTITIONING ise veriye dokunmadan tüm bölümlemeyi kaldırır:

ALTER TABLE t1 DROP PARTITION p0;
ALTER TABLE t1 TRUNCATE PARTITION p0,p2;
ALTER TABLE t1 COALESCE PARTITION 2;
ALTER TABLE t1 REMOVE PARTITIONING;

EXCHANGE PARTITION bir bölümün içeriğini aynı yapıdaki bölümlenmemiş bir tabloyla takas eder. Belgelere göre MariaDB 11.4'ten itibaren bu komut WITH VALIDATION (varsayılan) ve WITHOUT VALIDATION seçeneklerini kabul eder; doğrulama her satır için yapıldığından büyük tablolarda çok yavaş olabilir. MariaDB 10.7'den beri ayrıca CONVERT PARTITION ... TO TABLE ile bir bölümü bağımsız bir tabloya, CONVERT TABLE ... TO PARTITION ile de bir tabloyu bölüme dönüştürebilirsiniz. Bu, eski bir yılı arşiv tablosuna taşımanın temiz bir yoludur:

ALTER TABLE t1 EXCHANGE PARTITION p1 WITH TABLE t2 WITHOUT VALIDATION;
ALTER TABLE t1 CONVERT PARTITION p3 TO TABLE t2;
ALTER TABLE t1 CONVERT TABLE t2 TO PARTITION p3 VALUES LESS THAN (2016);

Bakım: analiz, kontrol, onarım, optimizasyon

Bölümlenmiş tablolarda CHECK TABLE, OPTIMIZE TABLE, ANALYZE TABLE ve REPAIR TABLE her zamanki gibi çalışır. Belirli bölümleri hedeflemek için ALTER TABLE'ın ANALYZE, CHECK, REPAIR, OPTIMIZE ve REBUILD PARTITION uzantıları kullanılır; bölüm listesi yerine ALL yazılabilir:

ALTER TABLE t1 ANALYZE PARTITION p0,p1,p3;
ALTER TABLE t1 CHECK PARTITION p1,p3;
ALTER TABLE t1 REPAIR PARTITION p0,p3;
ALTER TABLE table_name REBUILD PARTITION ALL;

İki ayrıntıya dikkat edin. InnoDB bölüm bazında optimizasyonu desteklemez; OPTIMIZE PARTITION çalıştırdığınızda bir uyarı alırsınız ve tüm tablo yeniden inşa edilip analiz edilir. Belgeler bunun yerine REBUILD PARTITION ve ANALYZE PARTITION kullanmayı önerir. Ayrıca REPAIR PARTITION yinelenen anahtar hatalarında başarısız olur, bu durumda ALTER IGNORE TABLE ... REPAIR PARTITION kullanılabilir. Mevcut bölümler hakkındaki bilgileri INFORMATION_SCHEMA.PARTITIONS tablosundan okuyabilirsiniz.

Sınırlar

• Bir tablo en fazla 8192 bölüm içerebilir.
• Sorgular birden çok bölümü kapsasa da paralel çalıştırılmaz.
• Tablo ancak depolama motoru bölümlemeyi destekliyorsa bölümlenebilir ve tüm bölümler aynı motoru kullanmalıdır.
• Bölümlenmiş bir tablo yabancı anahtar içeremez ve yabancı anahtarla başvurulamaz; kısıtlar için MariaDB foreign key ve CHECK yazısına bakın.
• Sorgu önbelleği bölümlemeden habersizdir; bir bölümü değiştirmek tüm tablonun girdilerini geçersiz kılar.
• binlog_format=ROW iken bölümlenmiş tablodaki güncellemeler bölümlenmemiş eşdeğerinden yavaş çalışabilir.
• Bölümlenmiş tablolarda FULLTEXT index desteklenmez (1757 hatası); bkz. MariaDB FULLTEXT arama.
• Geçici (temporary) tablolar bölümlenemez.

Küçük bir uygulama: aylık erişim logu

Bir web sunucusunun erişim kayıtlarını aylık bölümlerde tutmak, eski ayları tek komutla silmek istediğimizi düşünelim. Belgelerin en iyi uygulamalarını birleştiriyoruz: NULL ya da geçersiz değerleri yakalamak için küçük ve boş bir başlangıç bölümü (VALUES LESS THAN (0)), sonda MAXVALUE ile bir "gelecek" bölümü ve birincil anahtarda bölümleme sütunu. Belgelere göre iyileştirici çoğu zaman ilk bölümü de taradığı için onu boş tutmak sorgu verimini artırır:

CREATE TABLE erisim_log (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  zaman DATETIME NOT NULL,
  yol VARCHAR(255) NOT NULL,
  durum SMALLINT UNSIGNED NOT NULL,
  PRIMARY KEY (id, zaman)
)
  ENGINE = InnoDB
PARTITION BY RANGE (TO_DAYS(zaman))
(
  PARTITION p_start VALUES LESS THAN (0),
  PARTITION p_2026_10 VALUES LESS THAN (TO_DAYS('2026-11-01')),
  PARTITION p_2026_11 VALUES LESS THAN (TO_DAYS('2026-12-01')),
  PARTITION p_future VALUES LESS THAN MAXVALUE
);

ALTER TABLE erisim_log REORGANIZE PARTITION p_future INTO (
  PARTITION p_2026_12 VALUES LESS THAN (TO_DAYS('2027-01-01')),
  PARTITION p_future VALUES LESS THAN MAXVALUE
);

ALTER TABLE erisim_log DROP PARTITION p_2026_10;

Her ay sonunda bir görev, p_future bölümünü bir sonraki ayın bölümü ve yeni bir p_future olarak ikiye ayırır; saklama süresi dolan ay ise DROP PARTITION ile silinir. Bu silme, belgelerin ifadesiyle satır satır silme yerine bir metadata işlemidir. Tarih aralığıyla filtrelenen sorgularınızın gerçekten yalnızca ilgili bölümleri okuyup okumadığını EXPLAIN PARTITIONS çıktısındaki partitions sütunundan doğrulayın. Bu aylık görevi sunucunun içinden zamanlamak için MariaDB event scheduler yazısındaki CREATE EVENT yaklaşımını kullanabilirsiniz.

Sık yapılan hatalar

• Küçük tabloyu bölümlemek. Belgelere göre fayda genellikle bir milyonu aşan satır sayılarında görülür.
• Bölümlemeyi index yerine kullanmak. Nokta sorguları için doğru index çoğu zaman yeterlidir.
• Birincil anahtara bölümleme sütununu eklememek. 1503 hatasının kaynağı budur.
• MAXVALUE bölümüne ADD PARTITION ile ekleme yapmaya çalışmak. REORGANIZE PARTITION gerekir.
• Sorguda bölümleme sütununu fonksiyon içine almak. Pruning, WHERE koşulu bölümleme ifadesiyle ilişkili olduğunda çalışır; EXPLAIN PARTITIONS ile kontrol edin.
• Çok fazla bölüm. 50 bölümün altı önerilir.

Sık Sorulan Sorular

Bölümleme sorgularımı otomatik hızlandırır mı?

Yalnızca sorgu koşulu bölümleme ifadesiyle ilişkiliyse ve iyileştirici gereksiz bölümleri eleyebiliyorsa. Diğer durumlarda tüm bölümler okunur ve sorgular bölümler arasında paralelleştirilmez.

RANGE mi HASH mi seçmeliyim?

Eski verileri dönemsel olarak silmek istiyorsanız RANGE (ya da RANGE COLUMNS) seçin, çünkü DROP PARTITION yalnızca RANGE ve LIST türlerinde kullanılabilir. Amaç yükü eşit dağıtmaksa HASH ya da KEY uygundur.

Mevcut bir tabloyu sonradan bölümleyebilir miyim?

Evet, ALTER TABLE mevcut bir tabloyu bölümlemeye izin verir; tablonun benzersiz anahtarlarının bölümleme sütunlarını içermesi gerekir. Büyük tablolarda bu işlem tabloyu yeniden yazacağı için MariaDB ALTER TABLE yazısındaki çevrimiçi değişiklik seçeneklerini inceleyin.

Sistem sürümlü tablolarda bölümleme nasıl çalışır?

PARTITION BY SYSTEM_TIME geçerli satırları ve geçmişi ayrı bölümlerde tutar. Ayrıntılar için MariaDB system-versioned ve temporal tablolar yazısına bakın.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · MariaDB index oluşturma · MariaDB temporal tablolar · MariaDB EXPLAIN ve ANALYZE · MariaDB event scheduler · MariaDB 12.3 LTS yenilikleri