நூறு மில்லியன் கணக்கான accounts-க்கு transaction history-ஐச் சேமித்து query செய்யவும்

Question

IT Interview Practice · Accepted Answer

**ledger-ஐ account மற்றும் time-ஆல் partition செய்யுங்கள், சமீபத்திய data-ஐ hot-ஆகவும் பழைய data-ஐ cold-ஆகவும் வைத்திருங்கள், மேலும் rows-ஐ ஒரு append-only immutable ledger ஆகக் கருதுங்கள் — இதனால் ஒரு single account-இன் history ஒரு சிறிய, indexed slice, ஒருபோதும் பில்லியன் கணக்கான rows-இன் scan அல்ல.** access pattern எப்போதும் "ஒரு account, ஒரு date range", எனவே அதற்குப் பொருந்த partition செய்யுங்கள்.

## கட்டமைப்பு

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## எப்படி வேலை செய்கிறது

- **account + time-ஆல் Partition செய்.** account id-ஐ N buckets-ஆக hash செய்து, பிறகு month-ஆல் range-partition செய்யுங்கள். ஒரு account/month-க்கான query சரியாக ஒரு partition-ஐ அடைகிறது — DB மீதத்தை prune செய்கிறது. இது மொத்த அளவைப் பொருட்படுத்தாமல் ஒவ்வொரு read-ஐயும் bound செய்கிறது.
- **Immutable ledger.** ஒரு transaction-ஐ ஒருபோதும் `UPDATE` செய்யாதீர்கள்; திருத்தங்கள் புதிய reversing rows. இது ஒரு audit trail, safe replication தருகிறது, மேலும் aggressively cache செய்ய அனுமதிக்கிறது (rows ஒருபோதும் மாறாது).
- **Hot/cold tiering.** கடைசி ~3 மாதங்களை low-latency reads-க்கு fast SSD/Postgres-இல் வைத்திருங்கள்; பழைய partitions-ஐ **S3/Parquet** (Athena/Trino மூலம் query செய்யப்படுகிறது) அல்லது Glacier-க்கு roll செய்யுங்கள். 95% queries சமீபத்திய data-ஐ அடைகின்றன, எனவே பெரும்பாலான storage மலிவாக இருக்கலாம்.
- **Keyset pagination.** `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50`-உடன் page செய்யுங்கள் — `OFFSET` அல்ல. Offset skip செய்யப்பட்ட rows-ஐ scan செய்து நிராகரிக்கிறது; keyset index-ஐ நேரடியாக seek செய்கிறது, ஒரு page-க்கு O(1).

## நேர்காணல் கண்ணோட்டம்

நேர்காணல் செய்பவர் **partition-key தேர்வு** மற்றும் **pagination**-ஐ ஆராய்கிறார். நல்ல பதில்கள் "account மூலம் partition செய்" என்கின்றன; சிறந்த பதில்கள் deep pages-இல் **keyset ஏன் OFFSET-ஐ வெல்கிறது** என்பதையும், **ledger ஏன் immutable** (auditability, lock contention இல்லை) என்பதையும், **tiering** எப்படி cost-ஐக் குறைக்கிறது என்பதையும் விளக்குகின்றன. ஒரு பொறி ஒரு composite index கொண்ட ஒரே பெரிய table — index இனி RAM-இல் பொருந்தாத வரை வேலை செய்கிறது, பிறகு ஒவ்வொரு read-ம் disk-bound ஆகிறது.

## சமரசங்களும் பிழைகளும்

- **Partition key மாற்ற கடினம்.** account+time-ஐ முன்கூட்டியே தேர்ந்தெடுங்கள்; பின்னர் நூறு மில்லியன் கணக்கான rows-ஐ re-partition செய்வது ஒரு migration project.
- **Cross-account queries பாதிக்கப்படுகின்றன.** "எல்லா accounts முழுவதும் மொத்த volume" இப்போது partitions முழுவதும் fan out செய்கிறது — அவற்றை ஒரு OLAP rollup-க்குத் தள்ளுங்கள்.
- **Cold reads மெதுவானவை.** Glacier-இலிருந்து 3 ஆண்டு பழைய statement-ஐ எடுப்பது நிமிடங்கள் எடுக்கிறது; பயனர் எதிர்பார்ப்புகளை அமைக்கவும் அல்லது request-இல் pre-warm செய்யவும்.
- **Hot partitions.** ஒரு whale account அல்லது தற்போதைய மாதம் ஒரு hotspot ஆகலாம்; sub-partition அல்லது cache செய்யுங்கள்.
- **எப்போது இல்லை:** மில்லியன் கணக்கான rows (நூறு மில்லியன் அல்ல) ஒரே indexed Postgres table-இல் பொருந்துகின்றன — தேவையில்லாத tiering கட்டாதீர்கள். ஒரே table-இன் index memory-இல் பொருந்துவதை நிறுத்தும் அளவில் இதை நோக்குங்கள்.

கட்டமைப்பு

எப்படி வேலை செய்கிறது

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் பிழைகளும்

தொடர்புடைய கேள்விகள்