Ada arsitektur terbukti yang telah saya lihat berkali-kali untuk mendukung layanan dan aplikasi web Anda:
- PostgreSQL untuk penyimpanan data
- Redis untuk mengoordinasikan antrian pekerjaan latar belakang (dan beberapa operasi atom terbatas)
Redis luar biasa, tetapi bagaimana jika saya memberi tahu Anda bahwa kasus penggunaan yang paling umum untuk tumpukan ini sebenarnya dapat dicapai hanya dengan menggunakan PostgreSQL?
Skenario 1: antrian pekerjaan
Mungkin penggunaan Redis yang paling umum yang pernah saya lihat adalah mengoordinasikan pengiriman pekerjaan dari layanan web Anda ke kumpulan pekerja latar belakang. Idenya adalah Anda ingin merekam keinginan untuk melakukan semacam pekerjaan latar belakang (mungkin dengan beberapa masukan) dan memastikan bahwa hanya satu dari banyak pekerja latar belakang Anda yang akan menjalankannya. Redis membantu dalam hal ini karena ia menyediakan serangkaian operasi atom yang kaya untuk struktur datanya.
Namun sejak rilis versi 9.5, PostgreSQL memiliki fungsi SKIP
LOCKED untuk pernyataan SELECT… FOR… ( dokumentasi di sini ). Ketika opsi ini ditentukan, PostgreSQL hanya akan mengabaikan setiap baris yang memerlukan penguncian rilis menunggu.
Mari kita lihat contoh ini dari perspektif pekerja latar belakang:
BEGIN;
WITH job AS (
SELECT
id
FROM
jobs
WHERE
status = 'pending'
LIMIT 1
FOR UPDATE SKIP LOCKED
)
UPDATE
jobs
SET
status = 'running'
WHERE
jobs.id = job.id
RETURNING
jobs.*;
COMMIT;
Ketika FOR UPDATE SKIP LOCKED ditentukan, penguncian tingkat baris secara implisit diatur pada setiap baris yang dikembalikan dari SELECT. Juga, karena Anda menentukan SKIP LOCKED, pernyataan ini tidak akan diblokir untuk transaksi lain. Jika ada job lain yang siap untuk diproses, maka akan dikembalikan. Tidak ada kekhawatiran bahwa beberapa proses pekerja yang menjalankan perintah ini akan menerima baris yang sama karena pemblokiran tingkat baris.
Peringatan terbesar untuk metode ini adalah bahwa jika Anda memiliki banyak pekerja yang mencoba menjalankan antrian ini, dan sejumlah besar pekerjaan memasok mereka, mereka mungkin menghabiskan beberapa waktu untuk melompat di antara pekerjaan dan mencoba mendapatkan kunci. Dalam praktiknya, sebagian besar aplikasi yang saya kerjakan memiliki kurang dari selusin pekerja latar belakang, dan biayanya tidak mungkin signifikan.
Skenario 2: Blok Aplikasi
Mari kita bayangkan bahwa Anda memiliki rutinitas sinkronisasi dengan layanan pihak ketiga, dan Anda hanya memerlukan satu instance, bekerja untuk setiap pengguna tertentu di semua proses server. Aplikasi Redis umum lainnya yang pernah saya lihat adalah penguncian terdistribusi.
PostgreSQL juga dapat mencapai ini menggunakan kunci rekomendasi (kunci penasihat). kunci penasehat memungkinkan Anda untuk menggunakan mekanisme penguncian yang sama yang digunakan PostgreSQL secara internal, untuk tujuan yang ditentukan aplikasi Anda sendiri.
Skenario 3: Pub / Sub
Saya meninggalkan contoh paling keren untuk yang terakhir: mengirim acara ke klien aktif Anda. Misalnya, Anda perlu memberi tahu pengguna bahwa mereka memiliki pesan baru yang tersedia untuk dibaca. Atau mungkin Anda ingin mentransfer data ke klien saat tersedia. Biasanya soket web adalah lapisan transport untuk acara ini, sementara Redis berfungsi sebagai mesin Pub / Sub.
Namun, mulai dari versi 9, PostgreSQL juga menyediakan fungsionalitas ini dengan operator LISTEN dan NOTIFY... Setiap klien PostgreSQL dapat berlangganan (DENGARKAN) ke saluran pesan tertentu, yang hanya berupa string arbitrer. Ketika klien lain mengirim pesan NOTIFY melalui saluran ini, semua klien berlangganan lainnya akan diberitahu. Secara opsional, Anda dapat melampirkan pesan kecil.
Jika Anda menggunakan Rails dan ActionCable, menggunakan PostgreSQL bahkan didukung di luar kotak.
Mengambil keuntungan penuh dari PostgreSQL
Redis pada dasarnya menempati ceruk yang berbeda dari PostgreSQL, dan unggul dalam apa yang PostgreSQL tidak perjuangkan. Contohnya termasuk data caching dengan TTL, dan menyimpan dan memproses data sementara.
Namun, PostgreSQL memiliki lebih banyak kekuatan daripada yang Anda harapkan ketika Anda mendekatinya hanya dalam hal database SQL lain atau entitas misterius yang hidup di belakang ORM Anda.
Ada kemungkinan besar bahwa hal-hal yang Anda gunakan untuk Redis mungkin berubah menjadi hal yang baik untuk PostgreSQL juga. Mungkin ada baiknya membuang Redis dan menghemat biaya operasional dan kompleksitas pengembangan dengan mengandalkan beberapa layanan data.