Αποθήκευση & query ιστορικού συναλλαγών για εκατοντάδες εκατομμύρια λογαριασμούς

Question

IT Interview Practice · Accepted Answer

**Κάντε partition το ledger κατά λογαριασμό και χρόνο, κρατήστε τα πρόσφατα δεδομένα hot και τα παλιά cold, και αντιμετωπίστε τα rows ως ένα append-only immutable ledger — ώστε το ιστορικό ενός μεμονωμένου λογαριασμού να είναι ένα μικρό, indexed κομμάτι, ποτέ ένα scan δισεκατομμυρίων rows.** Το access pattern είναι πάντα "ένας λογαριασμός, ένα 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)
```

## Πώς λειτουργεί

- **Partition κατά λογαριασμό + χρόνο.** Κάντε hash το account id σε N buckets, μετά range-partition κατά μήνα. Ένα query για έναν λογαριασμό/μήνα χτυπάει ακριβώς ένα partition — η βάση κλαδεύει τα υπόλοιπα. Αυτό φράζει κάθε read ανεξάρτητα από το συνολικό μέγεθος.
- **Immutable ledger.** Ποτέ μην κάνετε `UPDATE` μια συναλλαγή· οι διορθώσεις είναι νέες reversing rows. Αυτό δίνει audit trail, ασφαλές replication, και σας αφήνει να κάνετε cache επιθετικά (τα rows δεν αλλάζουν ποτέ).
- **Hot/cold tiering.** Κρατήστε τους τελευταίους ~3 μήνες σε γρήγορο SSD/Postgres για low-latency reads· κυλήστε τα παλαιότερα partitions σε **S3/Parquet** (queried μέσω Athena/Trino) ή Glacier. Το 95% των queries χτυπάει πρόσφατα δεδομένα, οπότε το μεγαλύτερο μέρος του storage μπορεί να είναι φθηνό.
- **Keyset pagination.** Σελιδοποιήστε με `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — όχι `OFFSET`. Το offset κάνει scan και πετάει τα skipped rows· το keyset κάνει seek το index απευθείας, O(1) ανά σελίδα.

## Οπτική συνέντευξης

Ο συνεντευκτής διερευνά την **επιλογή partition-key** και το **pagination**. Καλές απαντήσεις λένε "partition κατά λογαριασμό"· εξαιρετικές απαντήσεις εξηγούν **γιατί το keyset κερδίζει το OFFSET** σε βαθιές σελίδες, γιατί το **ledger είναι immutable** (auditability, όχι lock contention), και πώς το **tiering** μειώνει το κόστος. Μια παγίδα είναι ένας μοναδικός γιγαντιαίος πίνακας με ένα composite index — δουλεύει μέχρι το index να μη χωράει πλέον στη RAM και κάθε read να γίνεται disk-bound.

## Trade-offs & αποτυχία

- **Το partition key είναι δύσκολο να αλλάξει.** Επιλέξτε account+time εξαρχής· το re-partitioning εκατοντάδων εκατομμυρίων rows αργότερα είναι έργο migration.
- **Τα cross-account queries υποφέρουν.** Το "συνολικός όγκος σε όλους τους λογαριασμούς" τώρα κάνει fan out πέρα από partitions — σπρώξτε τα σε ένα OLAP rollup αντ' αυτού.
- **Τα cold reads είναι αργά.** Η ανάκτηση ενός statement 3 ετών από το Glacier παίρνει λεπτά· ρυθμίστε τις προσδοκίες του χρήστη ή κάντε pre-warm on request.
- **Hot partitions.** Ένας whale λογαριασμός ή ο τρέχων μήνας μπορεί να είναι hotspot· κάντε sub-partition ή cache το.
- **Πότε όχι:** εκατομμύρια rows (όχι εκατοντάδες εκατομμύρια) χωράνε σε έναν indexed Postgres πίνακα — μην χτίζετε tiering που δεν θα χρειαστείτε. Καταφύγετε σε αυτό στην κλίμακα όπου το index ενός μοναδικού πίνακα σταματά να χωράει στη μνήμη.

Αρχιτεκτονική

Πώς λειτουργεί

Οπτική συνέντευξης

Trade-offs & αποτυχία

Σχετικές ερωτήσεις