Sorting key — jadval, fayl yoki indeks ichida recordlarning fizik yoki mantiqiy tartibini belgilash uchun tanlangan bir yoki bir nechta ustundir. U query natijasining avtomatik tartibini kafolatlamaydi; ORDER BY baribir kerak. Asosiy foyda ma’lumotni access pattern bo‘yicha yaqin joylashtirish, min–max pruning, compression va merge operatsiyalarini tezlashtirishdir.
Ustunli saqlash
Analitik jadval event_date, tenant_id bo‘yicha saralansa, bir kun va tenant recordlari yaqin turadi. Row group statistikasi tor min–max diapazonga ega bo‘lib, filter mos kelmagan guruhlarni tashlaydi. Bir xil qiymatlar ketma-ketligi run-length va dictionary encodingni yaxshilashi mumkin.
Sorting keyning chapdagi ustunlari eng katta clustering ta’siriga ega. tenant_id, event_time tartibi tenant ichidagi vaqt so‘roviga yaxshi; faqat global vaqt oralig‘i barcha tenant diapazoniga tegishi mumkin. event_time, tenant_id buning teskarisi. Compound key real query predikatlari va cardinalityga asoslanadi.
Database implementatsiyasi
Ba’zi columnar warehouselarda sort key yuklash paytida ma’lumot segmentlarini tartiblaydi. Yangi batchlar to‘liq global tartibda bo‘lmasligi mumkin; background merge yoki vacuum ularni qayta tashkil etadi. Unsorted region ko‘payganda pruning yomonlashadi.
ClickHouse kabi MergeTree oilasida ORDER BY sorting key va sparse primary index bilan bog‘liq. Primary key alohida prefix bo‘lishi mumkin. Relatsion B-tree clustered index ham satrlarni keyga yaqin fizik joylashtiradi, ammo termin va kafolat databasega qarab farq qiladi.
Yozish xarajati
Random kirishdagi recordlarni to‘liq saralash CPU, xotira va spill disk talab qiladi. LSM yoki immutable fayl tizimida har batch ichida sort qilinadi, keyin compaction tartiblangan runlarni merge qiladi. Tez-tez yangilanadigan key recordni boshqa joyga ko‘chirishga olib keladi.
Monoton timestamp key barcha yangi yozuvni bir oxirga to‘plab, ayrim distributed tizimda hot partition yaratishi mumkin. Hash partition ustida har partition ichida vaqt bo‘yicha sort muvozanat va lokalitetni birlashtiradi. Salting pruningni yomonlashtirishi mumkin.
Tanlash va o‘zgartirish
Query history filtrlarda tez-tez ishlatiladigan, selektiv va korrelyatsiyalangan ustunlarni ko‘rsatadi. Juda yuqori cardinality doim yomon emas, ammo birinchi key har row groupda keng diapazon qilsa foyda kamayadi. Null va default qiymat ko‘p bo‘lsa ularning joylashuvi alohida hot segment hosil qilishi mumkin.
Sorting keyni o‘zgartirish odatda existing data ni rewrite qiladi. Storage vaqtincha ikki nusxa, compaction I/O va query latencyni hisobga oladi. Migratsiya canary tableda real workload bilan sinovdan o‘tadi. Faqat kompressiya nisbatini emas, scanned bytes, skipped granule, ingest throughput va p99 query vaqtini solishtirish kerak.
Sorting key va partition
Partition yirik bo‘limlarni tanlab tashlaydi va lifecycle boshqaradi; sorting key bo‘lim ichidagi data ni tartiblaydi. Har kun uchun millionlab kichik partition yaratish o‘rniga oy bo‘yicha partition, uning ichida kun va tenant bo‘yicha sort samarali bo‘lishi mumkin. Ikkala dizayn birga metadata, file size va access patternni muvozanatlashtiradi.
Z-order va ko‘p o‘lchamli clustering
Bitta leksik compound key chapdagi ustunga kuchli ustuvorlik beradi. Z-order yoki space-filling curve bir nechta ustun bitlarini aralashtirib, turli kombinatsiyadagi filtrlar uchun ma’lumotni yaqinlashtirishga urinadi. U barcha so‘rovga optimal emas va reclustering write amplification yaratadi. Ustunlar soni ko‘paygan sari lokalitet foydasi suyuladi; amaliy query historydan eng muhim ikki-uch o‘lcham tanlanadi.
Null va kollatsiya
Null birinchi yoki oxirgi joylashishi, matn esa binary yoki til kollatsiyasida tartiblanishi mumkin. Writer va reader boshqa qoida ishlatsa min–max pruning xavfsiz bo‘lmaydi. Table format sort orderni metadata da aniq versiyalaydi.
Bog‘liq tushunchalar
Clustering key, Partition key, ORDER BY, Columnar storage, Data skipping, MergeTree, B-tree