LTAP dengan PostgreSQL, Parquet, dan S3: Arsitektur, Trade-off, dan Biaya

LTAP dengan PostgreSQL, Parquet, dan S3 mencoba menjalankan transaksi berlatensi rendah sekaligus analitik berskala besar tanpa memelihara salinan data terpisah melalui pipeline ETL tradisional. Compute transaksional menyediakan antarmuka dan semantik bergaya PostgreSQL, sedangkan data historis atau hasil materialisasi disimpan sebagai Parquet di object storage dan dibaca melalui snapshot yang konsisten.

Pola ini dapat mengurangi duplikasi storage dan mempercepat freshness analitik, tetapi bukan sekadar memasang PostgreSQL di atas bucket S3. Sistem membutuhkan durable log, cache, layanan metadata transaksional, compaction, pengelolaan snapshot, garbage collection, serta mekanisme recovery yang dirancang sebagai satu kesatuan.

Artikel Lakebase LTAP: Rethinking Database Storage dari Databricks menjadi konteks utama pembahasan. Arsitektur di bawah ini merupakan model LTAP generik, bukan dokumentasi internal atau jaminan perilaku produk tertentu. Semantik durability, isolasi, freshness, dan recovery harus diverifikasi pada implementasi yang dipilih.

Apa yang membedakan LTAP dari PostgreSQL standar?

LTAP, atau lakehouse transactional and analytical processing, menggabungkan jalur transaksi dengan penyimpanan dan eksekusi analitik bergaya lakehouse. Tujuannya adalah memberikan satu garis keturunan data dari perubahan transaksional hingga snapshot kolumnar yang dapat dipindai secara efisien.

PostgreSQL standar menggunakan storage dengan semantik block device atau filesystem yang sesuai dengan kebutuhannya. PostgreSQL mengelola heap, indeks, buffer cache, WAL, checkpoint, vacuum, dan katalognya sendiri. S3 tidak dapat menggantikan direktori data PostgreSQL secara langsung karena object storage tidak menyediakan semantik random-write dan filesystem yang dibutuhkan PostgreSQL.

Ekstensi seperti foreign data wrapper dapat membantu PostgreSQL mengakses sumber eksternal, tetapi tidak otomatis menghasilkan arsitektur LTAP. Demikian pula, kompatibilitas wire protocol PostgreSQL tidak berarti implementasinya memiliki storage engine, dukungan ekstensi, perilaku locking, atau karakteristik recovery yang identik dengan PostgreSQL komunitas.

• PostgreSQL standar: database mengendalikan format halaman, WAL, buffer, vacuum, dan storage lokal atau block storage.
• LTAP: compute transaksi, durable log, metadata, object storage, dan compute analitik dapat dipisahkan serta diskalakan secara independen.
• Parquet: cocok untuk scan kolumnar, kompresi, statistik file, dan predicate pruning; tidak cocok untuk memperbarui satu baris secara langsung.
• S3: murah dan durable untuk objek immutable, tetapi aksesnya memiliki latensi lebih tinggi daripada RAM, NVMe, atau block storage.

Karena itu, jalur transaksi tidak boleh menunggu pembacaan dan penulisan objek Parquet untuk setiap query. Sistem memakai cache dan log untuk jalur cepat, kemudian mematerialisasikan perubahan menjadi file kolumnar secara asinkron.

Alur write, cache, metadata, compaction, dan snapshot

Diagram arsitektur LTAP

                    JALUR TRANSAKSI
Aplikasi
   | SQL / protokol kompatibel PostgreSQL
   v
+-----------------------+
| Transaction Compute   |
| parser, planner, MVCC  |
+-----------+-----------+
            |
            +---- baca/tulis ----> +------------------+
            |                      | Row/Page Cache   |
            |                      | RAM / SSD lokal  |
            |                      +------------------+
            |
            +---- append commit --> +------------------+
                                     | Durable Log      |
                                     | WAL / change log |
                                     +--------+---------+
                                              |
                                              v
                                   +---------------------+
                                   | Flush/Materializer  |
                                   +----------+----------+
                                              |
                                              v
                                   +---------------------+
                                   | Parquet di S3       |
                                   | data + delete files |
                                   +----------+----------+
                                              |
                     +------------------------+-------------------+
                     |                                            |
                     v                                            v
            +-------------------+                       +------------------+
            | Metadata/Catalog  |<---- commit atomik ---| Compaction      |
            | snapshot, schema, |                       | merge/rewrite    |
            | statistik, files  |                       | file kecil       |
            +---------+---------+                       +------------------+
                      |
                      | snapshot ID / read timestamp
                      v
            +---------------------+
            | Analytical Compute  |
            | pruning, scan, join |
            +---------------------+

1. Write dan pengakuan commit

Aplikasi mengirim INSERT, UPDATE, atau DELETE ke compute transaksional. Engine memeriksa constraint, mengatur concurrency, memperbarui representasi mutable di cache, lalu merekam perubahan ke log yang durable.

Commit semestinya baru diakui setelah memenuhi kontrak durability implementasi, misalnya setelah log tersimpan pada media atau replika yang disyaratkan. Commit tidak harus menunggu perubahan dikonversi menjadi Parquet. Pemisahan ini menjaga latensi transaksi agar tidak mengikuti latensi object storage dan compaction.

Pertanyaan penting saat mengevaluasi platform adalah: di mana commit dianggap durable, berapa banyak replika yang diperlukan, dan apa RPO ketika seluruh compute atau satu region gagal? Jawaban tersebut tidak dapat disimpulkan hanya dari keberadaan Parquet di S3.

2. Cache sebagai jalur cepat, bukan sumber kebenaran tunggal

Cache menyimpan halaman, baris, indeks, atau delta yang sering diakses. Cache memungkinkan point lookup dan update tanpa mengambil file Parquet dari S3 pada setiap transaksi. Compute yang baru dinyalakan dapat menghangatkan cache dari snapshot dasar dan memainkan ulang log setelah snapshot tersebut.

Cache harus dapat hilang tanpa kehilangan transaksi yang sudah diakui. Jika node mati dan data hanya berada di cache lokal, sistem melanggar durability. Sebaliknya, cache yang terlalu kecil meningkatkan cache miss, pembacaan jarak jauh, dan latensi ekor.

3. Materialisasi dan metadata

Proses latar belakang mengubah rentang perubahan yang telah committed menjadi objek immutable, biasanya file Parquet dan representasi delete atau delta. Layanan metadata mencatat file yang aktif, versi schema, rentang transaksi, statistik kolom, partitioning, dan snapshot yang mengacu pada file tersebut.

S3 memiliki konsistensi kuat untuk operasi objek, tetapi perubahan beberapa objek tetap bukan transaksi multi-object. Karena itu, pembaca tidak boleh menyimpulkan snapshot hanya dengan melakukan listing prefix. Metadata atau transaction log harus memublikasikan kumpulan file baru secara atomik dari sudut pandang pembaca.

4. Compaction dan garbage collection

Write kecil yang terus-menerus akan menghasilkan banyak delta atau file kecil. Compaction menggabungkan file, menerapkan delete, mengurutkan data bila perlu, dan memperbarui statistik. Hasilnya meningkatkan scan throughput dan mengurangi jumlah request ke S3.

Compaction menyebabkan write amplification: data dibaca dan ditulis ulang walaupun nilai bisnisnya tidak berubah. File lama juga tidak boleh langsung dihapus karena mungkin masih dipakai query atau snapshot aktif. Garbage collection baru aman setelah periode retensi dan referensi snapshot berakhir.

5. Snapshot dan query analitik

Query analitik meminta snapshot ID atau read timestamp dari katalog. Planner memilih file yang valid pada snapshot tersebut, memakai statistik untuk melewati file yang tidak relevan, lalu menjalankan scan dan join pada compute analitik yang terpisah.

Freshness bergantung pada desain sistem. Jika analitik hanya membaca Parquet yang sudah dimaterialisasi, keterlambatannya mengikuti antrean flush dan commit metadata. Beberapa implementasi dapat menggabungkan snapshot Parquet dengan delta terbaru dari log atau cache, tetapi jalur ini menambah kompleksitas, biaya compute, dan kemungkinan perbedaan kemampuan query.

Trade-off dibandingkan alternatif

Latensi, konsistensi, dan freshness

LTAP tidak menghapus teorema dasar sistem terdistribusi. Semakin kuat persyaratan sinkronisasi antara commit transaksi dan visibilitas analitik, semakin besar koordinasi yang dibutuhkan. Tentukan service-level objective secara terpisah:

• Commit latency: waktu dari permintaan commit sampai aplikasi menerima sukses.
• Read-after-write: apakah sesi transaksi langsung melihat tulisannya sendiri.
• Analytical freshness: selisih antara commit terbaru dan snapshot yang dapat dipindai.
• Snapshot consistency: apakah seluruh tabel atau beberapa tabel dibaca pada timestamp yang kompatibel.

Kesalahan umum adalah menyebut analitik “real-time” tanpa mendefinisikan percentile, kondisi overload, atau perilaku ketika materializer tertinggal.

Compute-storage, egress, dan vendor lock-in

Pemisahan compute dan storage memungkinkan cluster analitik dimatikan ketika tidak digunakan, sementara data tetap berada di object storage. Namun, biaya total tidak hanya berasal dari kapasitas Parquet. Durable log, metadata, cache SSD, request object storage, compaction, snapshot lama, dan observability juga harus dihitung.

Egress dapat mendominasi jika compute, katalog, dan S3 berada di region atau cloud berbeda. Penempatan lintas availability zone juga dapat memiliki biaya transfer sesuai kebijakan penyedia. Tempatkan jalur data ber-volume besar sedekat mungkin dan ukur byte aktual, bukan hanya ukuran tabel terkompresi.

Parquet adalah format terbuka, tetapi keterbukaan file tidak menjamin portabilitas sistem. Transaction log, protokol metadata, delete semantics, catalog API, branching, dan prosedur recovery dapat bersifat vendor-specific. Demikian pula, kompatibilitas SQL PostgreSQL mungkin tidak mencakup seluruh ekstensi, trigger, logical replication, tipe data, atau perilaku administrasi.

Model biaya dan contoh estimasi

Gunakan formula bulanan yang memisahkan setiap komponen berikut:

total = compute_transaksi
      + compute_analitik
      + storage_objek
      + storage_log_dan_cache
      + request_S3
      + compute_compaction
      + metadata_dan_catalog
      + observability
      + transfer_data
      + lisensi_atau_biaya_layanan

Contoh berikut hanya model ilustratif, bukan harga Databricks, AWS, atau vendor tertentu. Misalkan tim memakai asumsi internal berikut:

• Dua unit compute transaksi aktif 730 jam per bulan dengan tarif asumsi USD 0,60 per unit-jam.
• Tiga unit compute analitik aktif 120 jam per bulan dengan tarif asumsi USD 1,20 per unit-jam.
• Parquet dan snapshot memakai 2.048 GB dengan tarif asumsi USD 0,023 per GB-bulan.
• Request object storage diperkirakan USD 100, compaction USD 80, serta metadata dan observability USD 150.
• Transfer keluar 500 GB dengan tarif asumsi USD 0,09 per GB.

compute transaksi = 2 × 730 × $0,60       = $876,00
compute analitik  = 3 × 120 × $1,20       = $432,00
storage Parquet   = 2.048 × $0,023        =  $47,10
request + compact + metadata/observability = $330,00
egress            = 500 × $0,09           =  $45,00
------------------------------------------------------
total ilustratif                             $1.730,10/bulan

Angka ini menunjukkan bahwa storage objek belum tentu menjadi komponen terbesar. Compute transaksi yang selalu aktif dapat mendominasi, sementara query tidak efisien, compaction agresif, atau egress dapat menghapus penghematan dari Parquet.

Bandingkan biaya tersebut dengan alternatif secara setara. Pada CDC ke warehouse, masukkan biaya PostgreSQL, konektor, message broker, warehouse, staging storage, duplikasi data, dan tenaga operasi. Pada PostgreSQL tunggal, masukkan kebutuhan instance puncak, replica, backup, IOPS, dan risiko gangguan OLTP akibat analitik.

Risiko kegagalan, recovery, dan observability

Mode kegagalan yang perlu diuji

Recovery bukan hanya memulihkan file Parquet

Recovery umumnya memerlukan snapshot dasar yang valid, metadata yang cocok, serta replay log sampai titik tertentu. Point-in-time recovery membutuhkan retensi log yang cukup dan hubungan yang dapat diverifikasi antara posisi log dan snapshot. Backup katalog tanpa data, atau data tanpa katalog dan log, belum tentu dapat menghasilkan database konsisten.

Uji pemulihan pada lingkungan terisolasi. Ukur RTO ketika cache kosong, karena sistem yang berhasil dipulihkan secara logis belum tentu memenuhi target latensi setelah menerima traffic produksi.

Metrik minimum

• Commit latency dan error rate per percentile, bukan hanya rata-rata.
• Cache hit ratio, cache eviction, remote-read bytes, serta waktu prewarming.
• Durable-log lag, ukuran backlog, dan umur transaksi tertua yang belum dimaterialisasi.
• Commit-to-snapshot lag dan snapshot publish failure.
• Jumlah file, distribusi ukuran file, delete ratio, serta antrean compaction.
• Byte yang dipindai per query, pruning ratio, spill, concurrency, dan queue time.
• Storage growth per kategori: data aktif, log, file lama, snapshot, dan temporary output.
• Egress per region, availability zone, layanan, dan tenant.

Log harus membawa transaction ID, snapshot ID, query ID, dan identitas job compaction agar satu perubahan dapat ditelusuri dari commit hingga query analitik.

Matriks keputusan dan strategi migrasi

Matriks pemilihan arsitektur

Migrasi bertahap yang dapat dibatalkan

1. Profilkan workload. Kelompokkan point lookup, write, transaksi panjang, join, scan, concurrency, ukuran working set, serta pertumbuhan data. Tetapkan SLO commit dan freshness sebelum memilih produk.
2. Audit kompatibilitas PostgreSQL. Inventarisasi ekstensi, trigger, sequence, isolation level, advisory lock, tipe data, logical replication, fungsi, dan alat backup yang digunakan.
3. Mulai dari salinan analitik. Backfill snapshot PostgreSQL ke Parquet, lalu teruskan perubahan melalui CDC atau mekanisme ingest yang didukung. Simpan watermark atau posisi log yang menghubungkan backfill dengan perubahan inkremental.
4. Validasi data. Bandingkan jumlah baris, agregat per partisi, null distribution, primary key duplicate, dan checksum pada subset deterministik. Jangan hanya membandingkan total baris.
5. Jalankan shadow query. Eksekusi query produksi terpilih pada sistem lama dan LTAP. Bandingkan hasil, freshness, byte scan, latency percentile, dan biaya.
6. Canary untuk transaksi. Pindahkan tenant atau workload berisiko rendah jika platform LTAP akan menjadi system of record. Hindari dual-write aplikasi tanpa idempotency karena kegagalan parsial mudah menghasilkan divergensi.
7. Siapkan rollback. Pertahankan sumber lama dan log perubahan selama periode yang disepakati. Dokumentasikan titik ketika rollback tidak lagi sederhana.
8. Optimalkan setelah benar. Tuning partitioning, clustering, ukuran file, cache, dan jadwal compaction dilakukan setelah konsistensi serta recovery terbukti.

Jika memakai logical decoding PostgreSQL selama migrasi, monitor retensi WAL dan kesehatan replication slot. Konsumen yang berhenti dapat menahan WAL dan memenuhi disk primary. Snapshot awal dan stream perubahan juga harus disambungkan pada posisi log yang benar agar tidak ada gap atau duplikasi tanpa penanganan.

Kapan LTAP tidak layak?

• PostgreSQL tunggal sudah memenuhi kapasitas, availability, dan biaya dengan margin yang sehat.
• Analitik sedikit atau dapat dijalankan pada replica tanpa mengganggu transaksi.
• Bisnis membutuhkan setiap commit langsung terlihat oleh seluruh query lintas tabel, tetapi implementasi LTAP hanya menyediakan materialisasi asinkron.
• Aplikasi bergantung pada ekstensi atau perilaku administrasi PostgreSQL yang tidak didukung.
• Workload didominasi update kecil dengan volume analitik rendah sehingga compaction hanya menambah biaya.
• Data dan compute harus berada di cloud atau region berbeda sehingga egress mendominasi.
• Tim belum siap mengoperasikan log, metadata, snapshot, compaction, dan recovery, sementara layanan terkelola tidak memenuhi kebutuhan.
• Persyaratan portabilitas melarang ketergantungan pada protokol metadata atau control plane vendor.

LTAP paling masuk akal ketika ada tekanan nyata dari dua arah: transaksi memerlukan pengalaman bergaya PostgreSQL, sementara analitik membutuhkan scan kolumnar yang segar dan elastis. Keputusan sebaiknya didasarkan pada SLO, uji kegagalan, kompatibilitas, dan biaya total—bukan hanya karena Parquet lebih murah daripada storage database atau karena endpoint menerima SQL PostgreSQL.