পাঠ ২২ · ২৯-এর মধ্যে · মডিউল ৪

Home / AI Courses / Data Engineering / Snowflake

Snowflake পরিচিতি

Snowflake — cloud-native data warehouse

৭ মিনিট পড়া মাঝারি · Intermediate Cloud DW

এই পাঠে যা শিখবেন

Snowflake-এর তিন-স্তরের architecture — storage, compute, services
Virtual Warehouse কীভাবে চালান, বন্ধ করেন, এবং auto-suspend
Micro-partition ও clustering — কেন Snowflake দ্রুত
Time Travel ও Zero-Copy Cloning — production-এ ব্যবহারিক প্যাটার্ন

১ · Snowflake আসল কেন

২০১২-তে Snowflake শুরু হয় একটি প্রশ্ন থেকে — "প্রচলিত data warehouseData Warehouseanalytical query-র জন্য optimized বিশেষ database। OLTP-এর তুলনায় columnar storage, compression ও parallel execution-এ পারদর্শী। উদাহরণ: Teradata, Snowflake, BigQuery, Redshift। (Teradata, Oracle Exadata) cloud-এ এনে আবার ডিজাইন করলে কী দাঁড়ায়?" উত্তর — সম্পূর্ণ নতুন architecture। প্রচলিত warehouse-এ storage ও compute একই node-এ আঁটকানো; Snowflake-এ তিনটি স্বাধীন স্তর।

তিন-স্তরের architecture

১) Storage layer: S3 / Azure Blob / GCS-এ columnar micro-partition হিসেবে data বসে।
২) Compute layer: এক বা একাধিক virtual warehouse — প্রতিটি স্বাধীন cluster।
৩) Cloud Services: metadata, query optimizer, security, transactions।

এই বিচ্ছিন্নতার ফলে — Daraz যদি ১ TB সেলস ডেটা রাখে, কিন্তু রাত ১০টায় হঠাৎ ১০ জন analyst একসাথে ভারী query চালায়, তখন শুধু compute scale করলেই হলো; storage স্পর্শও করতে হয় না।

২ · Virtual Warehouse — compute এর একক

Snowflake-এ "warehouse" মানে storage নয় — virtual warehouseVirtual WarehouseSnowflake-এর compute cluster। T-shirt size-এ আসে: XS, S, M, L, XL, 2XL...6XL। প্রতিটি size আগেরটির দ্বিগুণ resource ও দ্বিগুণ credit/hour খরচ করে। মানে compute cluster। T-shirt size-এ আসে: XS (১ node), S (২), M (৪), L (৮), XL (১৬), 2XL (৩২), পর্যন্ত 6XL (৫১২)।

প্রতি size আগেরটির ঠিক দ্বিগুণ resource ও দ্বিগুণ credit/hour খরচ। ১ XS warehouse-এ একটি ১০ মিনিটের query → ১ M warehouse-এ ~২.৫ মিনিট। কিন্তু খরচ একই (linear scaling)।

ভাবুন — Dhaka-র একটি restaurant। গ্রাহক বেড়ে গেলে — extra chef ভাড়া করেন (compute scale)। কিন্তু freezer (storage) একই থাকে। Snowflake ঠিক সেভাবে — আপনার ডেটার "স্টোর" এক, কিন্তু "রান্নাঘর" যত খুশি বাড়ান।

Auto-suspend ও auto-resume: warehouse ১ মিনিট idle থাকলে suspend হয়ে যায়; নতুন query এলে ১-২ সেকেন্ডে resume হয়। billing হয় শুধু active সময়ের, per-second (১ মিনিট minimum)।

৩ · Micro-partition — কেন এত দ্রুত

Snowflake-এ ডেটা micro-partitionMicro-partitionSnowflake-এর storage একক — ৫০-৫০০ MB compressed columnar block। প্রতিটিতে min/max/null-count metadata রাখা হয়, যা query-time pruning সম্ভব করে। নামে ৫০-৫০০ MB-এর columnar block-এ সংরক্ষিত। প্রতিটি block-এ metadata — column-wise min/max value, distinct count, null count।

Query চালালে optimizer প্রথমেই partition pruning করে — যদি query-তে WHERE order_date = '2025-05-09' থাকে, কেবল সেই date range-যুক্ত micro-partition পড়ে; বাকিগুলো skip হয়। ফলে ১ TB টেবিলে ১% data scan হলেও সম্পূর্ণ result ঠিক।

Clustering Key: বড় টেবিলের জন্য (১ TB+) CLUSTER BY (order_date, customer_id) দেওয়া যায় — Snowflake auto-reclustering করে background-এ।

৪ · Snowflake SQL flavor — কী ভিন্ন

Snowflake ANSI SQL-এর সাথে ৯৫%+ compatible, কিন্তু কিছু বিশেষ feature আছে যা DE-দের জানা উচিত।

VARIANT type: JSON/Avro/Parquet semi-structured data সরাসরি column-এ। data:user.email dot-notation-এ access।
QUALIFY clause: window function-এর result-এ filter — subquery-র দরকার নেই।
FLATTEN: nested array/object explode করে rows-এ পরিণত করে।
COPY INTO: S3/Azure/GCS থেকে bulk load — gzip/snappy auto-decompress।
Tasks & Streams: built-in CDC ও scheduled job (Airflow ছাড়াই)।

৫ · Time Travel ও Fail-safe

Time TravelTime TravelSnowflake-এ DELETE/UPDATE/DROP-এর পরও পুরনো version কিছু সময় retain — Standard tier-এ ১ দিন, Enterprise+-এ ৯০ দিন। AT/BEFORE clause দিয়ে পুরনো অবস্থা পড়া যায়। — Snowflake-এর সবচেয়ে life-saving feature। DELETE বা DROP-এর পরও ডেটা retain থাকে নির্দিষ্ট সময় (Standard: ১ দিন; Enterprise: ৯০ দিন)।

উদাহরণ — bKash-এর একজন junior engineer ভুলে UPDATE transactions SET amount = 0 চালালেন (WHERE clause মিস)। সাধারণ DB-তে — restoring backup, hours of downtime। Snowflake-এ:

$$\text{Recovery time} = O(\text{seconds}), \quad \text{not } O(\text{hours})$$

Time Travel-এর পর আরও ৭ দিন Fail-safe period — শুধু Snowflake support পুনরুদ্ধার করতে পারে। এটি disaster recovery-র শেষ স্তর।

৬ · Zero-Copy Cloning — পরীক্ষা ছাড়া খরচ

একটি ১০ TB production টেবিলের clone — Snowflake-এ ১ সেকেন্ডে, খরচ ০। শুধু metadata pointer copy হয়; data physically copy হয় না। Clone-এ লেখা শুরু করলে — শুধু changed micro-partitions নতুন হয় (copy-on-write)।

Daraz-এ একজন analyst যদি বলেন — "production-এর ঠিক copy চাই, একটা experiment-এর জন্য" — DBA এক command-এ সম্ভব করেন:

SQL · Snowflake

-- Production থেকে dev-এ instant clone (০ খরচ)
CREATE DATABASE daraz_dev CLONE daraz_prod;

-- নির্দিষ্ট টেবিল clone
CREATE TABLE orders_test CLONE daraz_prod.public.orders;

-- পুরনো অবস্থায় clone (Time Travel + Clone)
CREATE TABLE orders_yesterday CLONE daraz_prod.public.orders
  AT (OFFSET => -86400);  -- ২৪ ঘণ্টা আগের

প্রতিটি clone instant — কারণ Snowflake শুধু metadata-তে pointer তৈরি করে। ১০ TB clone-এ ১ MB-ও storage খরচ হয় না (যতক্ষণ লেখা শুরু না হয়)।

তিনটি স্তর সম্পূর্ণ স্বাধীন। Compute scale করলে storage অপরিবর্তিত; storage বাড়লে compute-এ প্রভাব নেই।

৭ · বাংলাদেশের প্রসঙ্গ — region, খরচ, সার্বভৌমত্ব

Snowflake-এর কাছাকাছি region: AWS Singapore (ap-southeast-1) ও AWS Mumbai (ap-south-1)। ঢাকা থেকে latency ~৪০-৬০ ms (Singapore), ~৫০-৭০ ms (Mumbai)।

খরচ (২০২৫ approx): Standard tier — Singapore-এ ~$৩.০০/credit। ১ XS warehouse ১ ঘণ্টা = ১ credit = ~৩৩০ BDT।
Storage: ~$২৩/TB/month (compressed)। Daraz-এর ৫০ TB raw events ~১০ TB compressed → মাসে ~২৫,০০০ BDT।
Data sovereignty: Bangladesh Bank-এর CIRC guidelines অনুসারে banking sensitive data বিদেশী region-এ রাখার আগে regulatory approval দরকার। অনেক BD bank এজন্য এখনো on-prem Teradata ধরে আছেন।
BD region নেই: Snowflake-এর Bangladesh-এ data center নেই। সবচেয়ে কাছে India। এটি health/banking-এ বাধা।

৮ · একটি সাধারণ ETL pattern

SQL · Snowflake

-- ১. S3 stage তৈরি
CREATE OR REPLACE STAGE daraz_stage
  URL = 's3://daraz-events/orders/'
  CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...')
  FILE_FORMAT = (TYPE = PARQUET);

-- ২. Raw landing table
CREATE OR REPLACE TABLE raw_orders (
  order_id     VARCHAR,
  customer_id  VARCHAR,
  amount_bdt   NUMBER(12,2),
  order_ts     TIMESTAMP_NTZ,
  payload      VARIANT          -- semi-structured backup
)
CLUSTER BY (order_ts);

-- ৩. COPY থেকে load (gzip/snappy auto-decompress)
COPY INTO raw_orders
FROM @daraz_stage
PATTERN = '.*orders_2025_05_.*[.]parquet'
ON_ERROR = 'CONTINUE';

-- ৪. Curated layer — transformation
CREATE OR REPLACE TABLE orders_curated AS
SELECT
  order_id,
  customer_id,
  amount_bdt,
  DATE_TRUNC('day', order_ts) AS order_date,
  EXTRACT(HOUR FROM order_ts) AS order_hour
FROM raw_orders
WHERE amount_bdt > 0
  AND customer_id IS NOT NULL
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY order_id ORDER BY order_ts DESC
) = 1;  -- dedupe

QUALIFY Snowflake-এর বিশেষ — window function-এর result-এ সরাসরি filter। এতে subquery ছাড়াই deduplication হয়। VARIANT column raw payload backup — schema evolve করলে পুরনো ডেটা হারায় না।

Warehouse AUTO_SUSPEND always set করুন (default ৬০s)। ভুলে গেলে — একটি XL warehouse ২৪ ঘণ্টা চললে ১৬ credit/hour × ২৪ × $৩ = $১,১৫২ (~১,২৬,০০০ BDT) এক রাতে চলে যাবে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ bKash বা Nagad কেন এখনো Snowflake-এ পুরোপুরি move হয়নি, যদিও global fintech-এ এটি বহুল ব্যবহৃত? কী regulatory ও technical বাধা আছে?

বাংলাদেশের mobile financial services (MFS) — bKash, Nagad, Rocket — Bangladesh Bank-এর তত্ত্বাবধানে। Snowflake adoption-এর পথে কয়েকটি স্তরের বাধা।

(১) Regulatory — Bangladesh Bank ও NTMC:

BB-এর Cyber Incident Response (CIRC) ও DOS Circular অনুযায়ী — banking ও MFS-এর "core transactional data" দেশের বাইরে রাখার আগে BB থেকে explicit approval দরকার।
Customer KYC, NID, transaction PII — sovereign data হিসাবে গণ্য।
Snowflake-এর Bangladesh region নেই; সবচেয়ে কাছে Singapore বা Mumbai। তাই data physically দেশের বাইরে।

(২) Latency ও fraud detection:

bKash দিনে ১২+ কোটি transaction process করে। Real-time fraud check-এ ১০-৫০ ms latency budget।
Singapore-এ round-trip ~৪০-৬০ ms — fraud detection-এ unacceptable।
সমাধান: hot path on-prem (Oracle/Teradata), warm/cold path Snowflake-এ। কিন্তু dual stack maintain করা ব্যয়বহুল।

(৩) খরচ — BDT context:

একটি large bank-এর ~৫০০ TB historical data + daily ৫ TB ingestion।
Snowflake credit + storage ~$৫০,০০০-১,০০,০০০/মাস (~৬০-১২০ লাখ BDT)।
একই workload on-prem capex amortized — ৩০-৫০% সস্তা ৫-বছরের TCO-তে। কিন্তু flexibility কম।

(৪) Talent — local skill scarcity:

Snowflake SnowPro certified DE Bangladesh-এ ১০০-এর কম।
প্রচলিত Oracle DBA অনেক বেশি — migration team গঠন কঠিন।

(৫) যেদিকে যাচ্ছে: Eastern Bank, BRAC Bank, Robi-র মতো প্রতিষ্ঠান marketing analytics ও non-PCI data Snowflake-এ আনছে। Core banking এখনো on-prem; analytics layer cloud-এ — এটাই BD-এর pragmatic pattern ২০২৫-এ।

মূল উপলব্ধি: Snowflake adoption শুধু technical decision নয় — regulatory, latency, খরচ ও talent-এর সমন্বয়। BD-এর বাস্তবতায় hybrid architecture সবচেয়ে practical।

প্র ০২ Daraz Bangladesh-এর ১০ TB historical orders টেবিল। Analyst-রা প্রতিদিন WHERE order_date, WHERE district, ও WHERE customer_segment দিয়ে query করেন। Clustering key কী দেবেন এবং কেন?

এটি classic Snowflake design problem। উত্তর — CLUSTER BY (order_date, district)। কারণটি বুঝতে micro-partition pruning-এর mechanics দরকার।

(১) Cluster key কীভাবে কাজ করে:

Snowflake automatically table-কে micro-partition-এ ভাঙে — কিন্তু ordering data-এর insertion order অনুসরণ করে।
CLUSTER BY দিলে — Snowflake background-এ data physically reorganize করে যাতে একই key-র rows কাছাকাছি micro-partition-এ থাকে।
Result — query-time-এ irrelevant micro-partition skip হয় (pruning)।

(২) প্রস্তাবিত key-এর reasoning:

order_date প্রথমে: সবচেয়ে সাধারণ filter — প্রতিদিন ও weekly/monthly report। High cardinality, time-ordered।
district দ্বিতীয়: ৬৪টি district — moderate cardinality। Same date-এর মধ্যে district-wise locality।
customer_segment নয়: কম cardinality (৪-৫ segment) — pruning value সীমিত। এটিকে cluster-এ যোগ করলে maintenance খরচ বাড়ে কিন্তু benefit কম।

(৩) High vs low cardinality trade-off:

Low cardinality (gender, status: ৩-৫ value) — অলরেডি প্রতিটি partition-এ সব value আসবে। Cluster অপ্রয়োজনীয়।
High cardinality (customer_id: ১ কোটি unique) — random distribution; cluster-এ বসালে pruning benefit সামান্য, কিন্তু reclustering cost বিশাল।
"Sweet spot" — moderate cardinality, time-ordered, সাধারণ filter-এ ব্যবহৃত column।

(৪) Reclustering খরচ:

Snowflake auto-clustering — background credit খরচ করে। ১০ TB টেবিলে monthly ~১০-২০% data churn হলে ~৫০-১০০ credit/মাস।
BDT-তে: ~১৬,৫০০-৩৩,০০০ BDT/মাস extra।

(৫) যাচাইয়ের উপায়:

SYSTEM$CLUSTERING_INFORMATION('orders', '(order_date, district)') — clustering quality দেখায়।
Query plan-এ "partitions scanned / partitions total" — ratio ১০% বা কম হলে pruning ভাল।

মূল উপলব্ধি: Cluster key — যা সবচেয়ে বেশি filter হয় ও high-enough cardinality আছে। Low cardinality column ভুল choice; cluster যোগ করার আগে query log analyze করুন।

প্র ০৩ Robi Axiata-র DE team-এ ৫টি virtual warehouse আছে — ETL, BI, AdHoc, ML, FraudDetection। প্রতিটির sizing ও schedule কীভাবে design করবেন? কোনটি multi-cluster (auto-scale) করবেন?

Multi-warehouse design — Snowflake-এর সবচেয়ে গুরুত্বপূর্ণ skill। Workload আলাদা করলেই খরচ ও performance optimal।

(১) WH_ETL — predictable, batch:

Size: L (৮ nodes) — রাত ১২-৬টা daily। ভারী transformation।
Multi-cluster: না — single workload, sequential job।
Auto-suspend: ৬০s। Schedule: Airflow trigger।
খরচ: ৬h × ৮ credit × ৩০ days × $৩ = $৪,৩২০/মাস (~৪.৭ লাখ BDT)।

(২) WH_BI — concurrent BI users:

Size: M (৪ nodes)। Tableau dashboard ৫০+ user।
Multi-cluster: হ্যাঁ — min ১, max ৪। Concurrent query queue হলে auto-scale।
SCALING_POLICY = 'STANDARD' — দ্রুত scale up, ধীরে scale down।
Auto-suspend: ১২০s (frequent re-use)।

(৩) WH_AdHoc — analyst exploration:

Size: S (২ nodes) default; analyst চাইলে session-এ USE WAREHOUSE WH_AdHoc_L করতে পারে।
Multi-cluster: না, কিন্তু resource monitor দিয়ে monthly cap ($৫০০)।
Auto-suspend: ৩০s (most aggressive)।

(৪) WH_ML — bursty, large:

Size: XL (১৬ nodes) — feature engineering ও training data prep।
Multi-cluster: না — single big job।
Schedule: Airflow on-demand (training pipeline trigger)।
STATEMENT_TIMEOUT_IN_SECONDS = ৩৬০০ (১ ঘণ্টা cap)।

(৫) WH_FraudDetection — low-latency, always-on:

Size: S (২ nodes)।
Multi-cluster: হ্যাঁ — min ১, max ৩, MAXIMIZED policy (instant scale)।
Auto-suspend: NEVER বা খুব বড় সংখ্যা — cold start unacceptable।
খরচ বেশি কিন্তু SLA critical।

(৬) Resource Monitor সবার উপর:

Account-wide monthly limit (যেমন ১,০০০ credit) → ৮০%-এ alert, ১০০%-এ suspend।
WH-wise monitor — runaway query থেকে রক্ষা।

(৭) চূড়ান্ত প্রিন্সিপল:

Workload আলাদা = খরচ predictable।
Multi-cluster শুধু concurrent (BI, fraud) — sequential (ETL, ML) নয়।
Auto-suspend aggressive — credit save।
Resource monitor essential — junior engineer-এর "select * from huge_table" রাতারাতি $১০,০০০ burn করতে পারে।

মূল উপলব্ধি: Snowflake-এর "১ warehouse for all" anti-pattern। প্রতি workload class-এর আলাদা warehouse — finance team-এর কাছে predictable invoice দেওয়ার একমাত্র পথ।

প্র ০৪ Eastern Bank-এর একজন DE Time Travel ব্যবহার করে production থেকে ১০ TB টেবিল clone করে dev environment-এ analytics করছেন। ৩০ দিন পর হঠাৎ storage bill ১০x বেড়ে গেল — কী হয়েছিল?

এটি Snowflake adoption-এর সবচেয়ে দামি ভুলগুলোর একটি। Zero-copy clone "free" বলে নয় — copy-on-write semantics আছে।

(১) যা সম্ভবত ঘটেছিল:

DE clone-এ UPDATE/DELETE/INSERT করেছেন। প্রতিটি change-এ — affected micro-partition নতুনভাবে লিখতে হয়।
Original ১০ TB clone "free" — শুধু metadata pointer। কিন্তু clone-এ ৫০% rows update করলে → ৫ TB নতুন physical data।
একই সাথে — original prod-এ Time Travel retention (90 days) চলছে; প্রতিদিন ETL micro-partition rewrite করছে; পুরনোগুলো ৯০ দিন retain।
Fail-safe — Time Travel-এর পরে আরও ৭ দিন।

(২) Storage বিস্ফোরণের গাণিতিক রূপ:

Active storage: ১০ TB।
Time Travel storage: প্রতি দিন ৩০০ GB churn × ৯০ দিন = ২৭ TB।
Fail-safe storage: ৩০০ GB × ৭ = ২.১ TB।
Clone-এ writes: ৫ TB।
Total billable: ~৪৪ TB — ৪.৪x বৃদ্ধি। সাথে অন্য টেবিলের churn → ১০x সম্ভব।

(৩) BDT-তে cost impact:

$২৩/TB/month × ৪৪ TB = $১,০১২/মাস (~১.১ লাখ BDT)।
Original প্রত্যাশা ছিল $২৩০ × ১০ = $২৩০।
Surprise factor — Time Travel + Fail-safe storage দেখা যায় না সহজে।

(৪) প্রতিরোধের উপায়:

DATA_RETENTION_TIME_IN_DAYS: dev/clone টেবিলে ০ বা ১ সেট করুন (default ১, max Enterprise-এ ৯০)।
Transient table: dev-এ CREATE TRANSIENT TABLE — Fail-safe স্বাভাবিক ভাবে নেই।
Account-level monitor: SHOW STORAGE USAGE — daily check।
Database-level limit: Resource monitor + Information Schema query-তে storage trend।
Clone lifecycle: ৭ দিনের বেশি dev clone রাখবেন না; কাজ শেষে DROP।

(৫) চিকিৎসা — যদি ইতিমধ্যে ঘটে:

ALTER TABLE x SET DATA_RETENTION_TIME_IN_DAYS = 1 — পুরনো Time Travel গুলিয়ে যাবে ১ দিন পর।
Fail-safe কমানো যায় না — ৭ দিন অপেক্ষা।
Unused clone DROP করুন।
ACCOUNT_USAGE.TABLE_STORAGE_METRICS থেকে top consumers identify।

(৬) Bangladesh-এ এই pattern বিশেষ ঝুঁকিপূর্ণ: ছোট DE team, কম monitoring maturity, USD billing — finance team এক মাস পরে দেখে CFO ক্ষুব্ধ। প্রথম clone-এর আগেই lifecycle policy + alert সেট আপ করুন।

মূল উপলব্ধি: "Zero-copy" শুধু creation-এ। Modification + Time Travel + Fail-safe storage একত্রে invisible cost তৈরি করে। Production discipline ও lifecycle policy ছাড়া Snowflake-এ surprise bill অনিবার্য।

অনুশীলন

Warehouse design: আপনি একটি BD ecommerce startup-এর DE। দিনে ৫০ GB orders + nightly ETL + ১০ analyst Tableau ব্যবহার করেন। কোন ২টি warehouse, কোন size, কোন auto-suspend? মাসিক approximate credit কত?
- WH_ETL (S, ২ node): nightly ৩ ঘণ্টা × ২ credit = ৬ credit × ৩০ = ১৮০। Auto-suspend ৬০s।
- WH_BI (XS, ১ node, multi-cluster ১-২): office hours ১০h × ১ × ২২ workdays = ২২০ credit। Auto-suspend ১২০s।
- মোট: ~৪০০ credit/মাস × $৩ = $১,২০০ (~১.৩ লাখ BDT) compute। Storage extra।
- Resource monitor account-wide ৬০০ credit cap সেট করুন।

Time Travel ব্যবহার: ভুলে DELETE FROM customers চালিয়েছেন (WHERE মিস)। ১ ঘণ্টা আগে অবস্থায় পুনরুদ্ধার করুন (Standard tier)।

-- উপায় ১: পুরনো version দেখা
SELECT * FROM customers AT (OFFSET => -3600);  -- ১ ঘণ্টা আগে

-- উপায় ২: পুনরুদ্ধার (recreate)
CREATE OR REPLACE TABLE customers_restore CLONE customers
  AT (OFFSET => -3600);

-- উপায় ৩: যদি table-ই DROP হয়
UNDROP TABLE customers;

Standard tier-এ retention ১ দিন; এই হঠাৎ DELETE ১ ঘণ্টা আগের — সহজে recoverable।

Cluster key বাছুন: একটি BD telecom call-detail-record (CDR) টেবিল — ৫০ TB, columns: call_ts, caller_msisdn, callee_msisdn, duration_sec, cell_id, region। সবচেয়ে সাধারণ query — last 7 days, region-ভিত্তিক aggregate। Cluster key কী দেবেন?
```
ALTER TABLE cdr CLUSTER BY (
  DATE_TRUNC('day', call_ts),
  region
);
```
- call_ts (truncated): primary filter। Truncate করায় same-day rows একসাথে।
- region: ৮টি BD division — moderate cardinality, সাধারণ filter।
- caller_msisdn cluster-এ নয়: ১৫ কোটি unique — কোনো pruning value কম, reclustering খরচ বিপুল।
- verify: SYSTEM$CLUSTERING_DEPTH < ৫ ভাল।