Sharding

Sharding — katta ma’lumotlar to‘plamini bir nechta mustaqil database yoki node orasida bo‘lib saqlash usuli. Har shard umumiy datasetning ma’lum qismini saqlaydi.

Sharding horizontal scale, storage capacity va write throughputni oshirish uchun ishlatiladi. Buning evaziga routing, distributed query, transaction va rebalancing murakkablashadi.

Shard

Shard — datasetning mustaqil bo‘lagi.

Masalan, userlar ID bo‘yicha:

Shard 1: 1–1 000 000
Shard 2: 1 000 001–2 000 000
Shard 3: 2 000 001–3 000 000

Har shard alohida database server yoki cluster bo‘lishi mumkin.

Shard key

Record qaysi shardga tushishini belgilaydigan field yoki ifoda shard key.

Misollar:

user ID;
tenant ID;
region;
order ID;
hash;
vaqt oralig‘i.

Shard key tanlovi keyinchalik o‘zgartirish qiyin bo‘lgan arxitektura qaroridir.

Hash sharding

Shard key hash qilinadi va natija shardga xaritalanadi.

hash(user_id) mod shard_count

Afzalligi — data odatda tengroq taqsimlanadi.

Kamchiligi:

range query bir nechta shardga tarqaladi;
shard sonini o‘zgartirishda ko‘p data ko‘chishi mumkin.

Consistent hashing rebalancing hajmini kamaytiradi.

Range sharding

Key oralig‘i shardlarga bo‘linadi.

Masalan:

A–F
G–M
N–Z

yoki sana bo‘yicha:

2025
2026
2027

Range query samarali.

Kamchiligi — yangi write’lar bitta oxirgi range’ga tushib hot shard yaratishi mumkin.

Directory-based sharding

Alohida metadata xizmati har key qaysi shardda ekanini saqlaydi.

Afzalligi — record yoki tenantni erkin shardga joylashtirish.

Kamchiligi — directory service availability va consistency uchun critical dependencyga aylanadi.

Tenant sharding

Multi-tenant tizimda har tenant bitta shardga biriktiriladi.

Afzalliklari:

tenant data’si bir joyda;
migration;
backup;
noisy tenantni ajratish;
compliance.

Juda katta tenant bitta shard capacity’sidan oshib ketishi mumkin.

Routing

Application yoki proxy requestni kerakli shardga yuboradi.

Routing qatlamiga shard key berilishi kerak.

Shard key yo‘q query:

barcha shardga yuborilishi;
global indexga murojaat qilishi;
rad etilishi

mumkin.

Scatter-gather

Query barcha shardlarga yuborilib, natijalar markazda birlashtiriladi.

Masalan, global top 100 order.

Bu:

ko‘p network;
har shardda sort;
timeout;
partial failure;
katta memory

xarajatini yaratadi.

Global querylar alohida analytics tizimiga ko‘chirilishi mumkin.

Distributed join

Join qilinadigan table’lar bir xil shard key bilan joylashtirilsa local join bajarilishi mumkin.

Bu co-location.

Turli shardlarda bo‘lsa data ko‘chirish yoki barcha shardlarga query talab qilinadi.

Schema sharding access patternga mos tuziladi.

Distributed transaction

Bitta transaction bir nechta shardni o‘zgartirsa coordination kerak.

Usullar:

two-phase commit;
saga;
application compensation;
transaction coordinator.

Cross-shard transaction local transactiondan sekinroq va failure holati murakkabroq.

Global unique ID

Har shard mustaqil ID yaratsa collision yuz berishi mumkin.

Yondashuvlar:

shard ID qo‘shilgan sequence;
UUID;
vaqtga asoslangan distributed ID;
markaziy ID service;
alohida range.

ID generation availability va ordering talabiga mos tanlanadi.

Unique constraint

Email global unique bo‘lishi kerak, ammo userlar turli shardlarda bo‘lsa lokal unique index yetarli emas.

Yechimlar:

global directory;
alohida uniqueness service;
shard keyga uniquenessni qo‘shish;
reserve table;
eventual conflict resolution.

Bu shardingdagi asosiy murakkabliklardan biri.

Rebalancing

Shardlar notekis bo‘lsa data boshqa node’ga ko‘chiriladi.

Jarayon:

yangi shard tayyorlash;
tarixiy data nusxalash;
yangi write’larni sinxronlash;
routingni almashtirish;
eski nusxani tozalash.

Rebalancing production traffic bilan bir xil network va diskdan foydalanadi.

Hot shard

Bitta shard boshqalardan ko‘proq load oladi.

Sabablar:

mashhur tenant;
monoton key;
vaqt range’i;
noto‘g‘ri hash;
skewed business data.

Virtual shard, key salting yoki tenant migration bilan kamaytirilishi mumkin.

Resharding

Shard soni yoki shard key strategiyasi o‘zgartiriladi.

Bu katta migration bo‘lishi mumkin.

Dual write, change capture va verification orqali downtime kamaytiriladi.

Oldindan virtual partition ishlatish physical shard sonini keyin osonroq o‘zgartiradi.

Shard failure

Har shard o‘z ichida replicationga ega bo‘lishi mumkin.

Bitta shard ishlamasa umumiy tizim qisman ishlashi mumkin.

API partial failure’ni aniq boshqaradi: ayrim tenantlar ishlaydi, boshqalari vaqtincha unavailable.

Monitoring

Shard bo‘yicha kuzatiladi:

row va byte;
request rate;
latency;
CPU;
disk;
replica lag;
hot key;
cross-shard query;
rebalancing holati.

Faqat cluster bo‘yicha o‘rtacha qiymat hot shardni yashiradi.

Metadata boshqaruvi

Har shardning manzili, holati, primary’i va key diapazoni metadata’da saqlanadi.

Routing qatlami bu ma’lumotni cache qilishi mumkin, ammo topology o‘zgarganda tez yangilanishi kerak.

Eski metadata requestni noto‘g‘ri shardga yuborishi mumkin.

Backup

Har shard alohida backup qilinsa umumiy snapshot vaqti farq qilishi mumkin.

Cross-shard consistent recovery uchun global checkpoint yoki transaction watermark kerak bo‘ladi.

Faqat bitta shardni tiklash global index va routing bilan muvofiqlashtiriladi.

Shard map versiyasi

Routing metadata versiyalanadi. Request eski shard map bilan yuborilsa target node yangi manzilni qaytarishi yoki proxy qilib, client cache’ini yangilashga yordam beradi.

Bog‘liq tushunchalar

Shard, Shard key, Hash sharding, Range sharding, Consistent hashing, Routing, Scatter-gather, Distributed transaction, Rebalancing, Hot shard