Hot shard — sharded tizimda bir shard boshqalarga qaraganda ancha ko‘p request, write, storage yoki CPU yukini oladigan holat. Clusterning umumiy capacitysi bo‘sh ko‘rinsa ham shu shard bottleneck bo‘lib, latency, timeout va throttling keltiradi. Muammo node sonini shunchaki oshirish bilan yo‘qolmasligi mumkin, chunki mashhur key yana bitta shardga route qilinadi.
Kelib chiqish sabablari
Past cardinalityli shard key ko‘p yozuvni oz shardga yig‘adi. Range shardingda monoton timestamp barcha yangi write’larni oxirgi intervalga yuboradi. Tenant bo‘yicha shardingda bitta juda katta mijoz “elephant tenant” bo‘lib qoladi. Celebrity post, mashhur product yoki global counter kabi bitta key read hotspot yaratadi.
Data hajmi teng bo‘lsa ham traffic teng bo‘lmasligi mumkin. Rebalancer faqat bytesga qarasa QPS skewini ko‘rmaydi. Aksincha, cold archive katta joy egallab, kam request olishi mumkin.
Belgilar
Shard bo‘yicha p95/p99 latency, QPS, CPU, disk queue, throttled request va storage growth taqqoslanadi. Cluster average muammoni yashiradi. Key frequency histogrami yoki sampled trace qaysi tenant va operation yukni yaratganini ko‘rsatadi.
Hot shardga tegishli replica ham read trafficni tarqatishi mumkin, ammo write leader baribir bitta nuqta bo‘lib qoladi. Replica lag oshishi apply capacity yetishmasligini ko‘rsatadi.
Kamaytirish usullari
Mashhur read uchun cache, request coalescing va CDN backend yukini kamaytiradi. Counter sharded counterlarga bo‘linib, keyin yig‘iladi. Write keyga random salt yoki time bucket qo‘shish oqimni bir necha shardga tarqatadi, evaziga read bir nechta bucketni gather qilishi kerak.
Range split issiq intervalni maydaroq qiladi. Directory mapping katta tenantni dedicated shardga ko‘chirishi mumkin. Adaptive sharding traffic oshganda virtual shardlarni qayta joylashtiradi, lekin migration paytida dual write va ordering ehtiyotkor boshqariladi.
Rate limit noisy tenantni boshqalardan izolyatsiya qiladi. Queue write burstni tekislaydi, ammo backlog va end-to-end latencyni oshiradi. Faqat hardware scale-up tez yordam beradi, ildizdagi key skew qoladi.
Oldindan loyihalash
Shard key tanlashda o‘rtacha emas, eng katta tenant, eng mashhur obyekt va vaqt bo‘yicha write pattern sinovdan o‘tadi. Virtual shardlar physical node sonidan ko‘proq yaratilsa keyin remapping osonlashadi. Resharding runbook va progress monitoring tizim ishga tushishidan oldin tayyor bo‘lishi kerak.
Migratsiya xavflari
Issiq shardni ko‘chirishning o‘zi qo‘shimcha read va network yukini aynan qiynalayotgan sourcega beradi. Snapshot copy rate limit qilinadi, keyin change log orqali delta yetkaziladi. Cutoverda router mapping versiyasi yangilanadi; eski router requestni sourcega yuborsa source targetga redirect yoki forward qiladi. Ikki tomonda mustaqil write qabul qilish conflict yaratadi.
Emergency splitdan keyin cache key va secondary index mappingi ham yangi shardlarni bilishi kerak. Observability shard ID bilan birga logical key range va tenantni saqlaydi, chunki physical ID migrationda o‘zgaradi. Hotspot yo‘qolgach vaqtinchalik overprovisioningni birdan olib tashlash backlog catch-upni sekinlashtirishi mumkin; capacity metriclar barqarorlashgach bosqichma-bosqich qisqartiriladi.
Hot shard alerti faqat fixed QPSga emas, cluster medianiga nisbatan skew ratio va saturationga qaraydi. Tabiiy ravishda katta shardni keraksiz ko‘chirishdan ko‘ra latency va queue ta’sirini baholash aniqroq.
Bog‘liq tushunchalar
Sharding, Shard key, Data skew, Consistent hashing, Resharding, Cache, Noisy neighbor, Scatter-gather