Cardinality — to‘plamdagi noyob qiymatlar yoki noyob kombinatsiyalar sonidir. Database ustunida distinct qiymatlar soni, monitoring tizimida esa metric nomi va barcha label qiymatlarining noyob kombinatsiyalari cardinalityni ifodalaydi. Bir tushuncha turli tizimlarda ishlatilsa-da, umumiy ma’no qidiruv va saqlash kerak bo‘lgan alohida identifikatorlar miqdoridir.
Monitoringdagi cardinality
Prometheusda har bir noyob label set alohida time series yaratadi. service va method kabi cheklangan labelar odatda boshqariladi. User ID, request ID, to‘liq URL yoki timestamp labelga qo‘yilsa qiymatlar deyarli cheksiz bo‘lib, series soni tez o‘sadi.
Masalan, 20 service, 5 region, 4 method va 10 status kombinatsiyasi nazariy jihatdan 4 000 series beradi. Har o‘lcham ko‘paytma sifatida ta’sir qiladi. Barcha kombinatsiyalar amalda paydo bo‘lmasligi mumkin, lekin worst-case capacity hisobida bu model foydali.
Yuqori cardinality head block xotirasi, index, query rejalashtirish va remote write trafikini oshiradi. Yangi podlar eski pod labelini almashtirgani uchun churn ham muhim: bir vaqtdagi series soni barqaror ko‘rinsa-da, vaqt davomida juda ko‘p yangi series yaratilishi mumkin.
Ma’lumotlar bazasida
Query optimizer ustun cardinalitysi va qiymatlar taqsimotidan selectivityni baholashda foydalanadi. Primary key cardinalitysi odatda qatorlar soniga teng. Boolean ustunda esa atigi ikki qiymat bo‘lishi mumkin. Past cardinalityli ustunga alohida B-tree index har doim foydali emas, chunki query baribir jadvalning katta qismini o‘qishi mumkin.
Cardinality faqat distinct count emas, distribution bilan birga talqin qilinadi. Country ustunida yuzlab qiymat bo‘lsa ham yozuvlarning katta qismi bitta davlatga tegishli bo‘lishi mumkin. Eskirgan statistics optimizerga noto‘g‘ri row count taxmini berib, samarasiz join tartibini tanlatadi.
Nazorat usullari
Monitoring labeli agregatsiya va alertda haqiqatan kerak bo‘lsa ishlatiladi. Cheksiz identifikator log yoki tracega ko‘chiriladi; metricda esa endpoint template, status class yoki xizmat darajasidagi kategoriya saqlanadi. /users/123 o‘rniga /users/:id labeli cardinalityni cheklaydi.
Relabeling keraksiz labelni ingestdan oldin olib tashlashi yoki butun metricni drop qilishi mumkin. Bu yo‘qotilgan o‘lchamni keyin tiklamaydi, shuning uchun qoidalar ta’siri o‘lchanadi. Series soni metric nomi, label nomi va qiymat bo‘yicha tahlil qilinib, budget belgilanadi.
Hisoblash xususiyatlari
Juda katta oqimda aniq distinct count ko‘p xotira talab qiladi. HyperLogLog kabi probabilistic tuzilma kichik xotira evaziga taxminiy cardinality beradi. Database COUNT DISTINCT aniq natija talab qilsa sort yoki hash set ishlatishi mumkin. Qaysi usul tanlanishi xato chegarasi, data hajmi va javob vaqtiga bog‘liq.
Cardinality budgeti
Metric dizaynida har label uchun kutilgan qiymatlar soni va umumiy ko‘paytma oldindan yoziladi. Budget faqat bugungi instance soniga emas, autoscaling, region va statusning maksimal holatiga qaraydi. CI test sample metriclardan label nomlarini tekshirishi, production esa active series va series creation ratega alert qo‘yishi mumkin. Limit oshsa qaysi yangi deployment yoki label qiymati sabab bo‘lganini build metadata bilan bog‘lash kerak.
Cardinalityni kamaytirish uchun labelni olib tashlash tarixiy querylarni o‘zgartiradi. Avval yangi metric nomi chiqarilib, dashboard va alertlar ko‘chiriladi, so‘ng eski series retention muddati tugagach olib tashlanadi.
Bog‘liq tushunchalar
Distinct value, Label, Time series, Selectivity, Database index, HyperLogLog, Metric churn