Büyük veri hacimlerinin dağıtımı iki ana yöntemle gerçekleştirilir:
Paralel Bölme (partitioning): Bir veritabanı içindeki bir tablonun belirli bir anahtara göre (genellikle tarih veya değer aralığı) bölümlere (partition) mantıksal olarak ayrılmasıdır. Bu, ayrı bölümler üzerinde işlemleri hızlı bir şekilde gerçekleştirmeyi sağlar, aramaları hızlandırır ve bakımı kolaylaştırır.
Sharding (sharding): Verilerin belirli bir algoritmaya göre birden fazla veritabanı/servise fiziksel olarak ayrılmasıdır — tablo, her biri kendi veri segmentini içeren farklı kümelerde aslında kopyalanır.
Partitioning'in avantajları — ayrı bir iş mantığı yönlendirme gereksinimi yoktur, her şey uygulama için 'şeffaf' gerçekleşir; dezavantajları — bir veritabanının sınırlarıyla sınırlıdır.
Sharding, yatay ölçeklenmeyi sağlar (sınırlama yalnızca sunucu sayısına bağlıdır), ancak karmaşık senkronizasyon, yönlendirme ve "shardlar arası" sorguların işlenmesini gerektirir.
-- Temel paralel bölmeli tablo CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT, order_date DATE ) PARTITION BY RANGE (order_date); CREATE TABLE orders_2023 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
Soru: Ana tabloyu kilitlemeden "anında" parçalar arasında satırları taşıyabilir miyiz?
Cevap: Çoğu veritabanında, bir parçalar arasında satır taşımak, silme ve ekleme işlemine eşdeğerdir — bu tür işlemler satırları hatta tabloyu bile kilitleyebilir, özellikle tetikleyiciler veya dış anahtarlar devreye girdiğinde. Bu, bölümler arasında büyük veri "geçişleri" gerçekleştirilirken dikkate alınmalıdır.
-- ALTER TABLE ... MOVE PARTITION genellikle kilitlere ekstra dikkat gerektirir. Daha az yoğun saatlerde yapılması daha iyidir.
Hikaye 1: Projede tüm parçalar üzerinden analitik raporlar oluşturuldu, ancak binlerce bölüm içeren bölümlü tablonun devasa sorgu yürütme planları oluşturduğunu göz ardı ettiler. Sonuç olarak — yürütme süresinin ve sunucu üzerindeki yükün ani artışı. Çözüm: Gerçek iş eksenlerine uygun bölüm sayısını artırmak ve tarama planlarını optimize etmek.
Hikaye 2: Sharding eklerken shardlar arasında kimliklerin benzersizliğini dikkate almadılar. Sık sık shardlar arası agregasyonda anahtar çatışmaları meydana geldi.
Hikaye 3: "Eski" parçaların otomatik arşivlenmesi, dış ilişkilerin yeniden kontrol edilmeden silinmesine yol açtı, bu da diğer tablolarla bağlantının kaybolmasına ve "canlı" verilerin bir kısmının kaybolmasına neden oldu. Bu nedenle, bölüm silme mantığını çoklu bağlantı testleri ile yeniden yazdılar.