Pendahuluan: Mengapa index dan pagination penting untuk catatan ink reMarkable?

Database Catatan Ink reMarkable harus menangani ribuan catatan tinta digital yang terus bertambah di perangkat dan cloud. Tanpa struktur index dan pagination yang tepat, pengalaman menyimpan atau menampilkan halaman menjadi lambat dan menyulitkan sinkronisasi. Artikel ini langsung menjawab: desain schema yang terdistribusi, strategi index terbaca dari repo MaximeRivest/riddle, pagination efisien, serta diagnosa slow query untuk menjaga responsivitas backend.

Kita akan membahas kenyataan teknis dengan contoh nyata bagaimana schema disusun, index dikunci, dan pagination dijalankan untuk koleksi besar.

Desain schema untuk catatan tinta yang bisa diskalakan

Repo riddle mengadvokasi model data yang memisahkan metadata catatan, versi halaman, dan hubungan terhadap pengguna. Struktur minimal berbentuk:

notes (note_id PK, user_id, title, updated_at, status)
pages (page_id PK, note_id FK, sequence, blob_ref, checksum, updated_at)
user_note_access (user_id, note_id, access_level, last_seen)

Memisahkan header catatan (notes) dari isi tiap halaman (pages) memungkinkan cache yang lebih mudah dan penalti penulisan terbatas pada table yang relevan. Foreign key dan constraint tetap penting agar konsistensi terjaga, namun saat scale-up, perhatian utama adalah kolom yang sering digunakan dalam filter atau join dibatasi kebutuhan indexnya.

Strategi indexing untuk query responsif

Ketika query utama adalah “tampilkan semua catatan aktif user X” atau “ambil halaman berikutnya dari note Y”, index harus mendukung filter dan ordering.

Contoh index yang umum:

  • CREATE INDEX idx_notes_user_updated_at ON notes (user_id, status, updated_at DESC); mengeksekusi query daftar catatan aktif per user dengan pengurutan terbaru.
  • CREATE INDEX idx_pages_note_sequence ON pages (note_id, sequence); mempercepat pengambilan halaman berdasarkan urutan dokumentasi catatan.
  • CREATE INDEX idx_user_note_access_user ON user_note_access (user_id, note_id); untuk mengecek hak akses.

Index composite lebih efisien ketimbang beberapa index tunggal karena mencakup kebutuhan filter dan sort sekaligus. Namun, trade-offnya adalah penambahan biaya saat insert/update; gunakan partial index ketika status aktif lebih sering diakses, seperti:

CREATE INDEX idx_active_notes ON notes (user_id, updated_at DESC) WHERE status = 'active';

Partial index menjaga ukuran index tetap kecil dengan fokus pada subset data yang sering di-query.

Pagination dan arsitektur page-aware

Backend serupa reMarkable biasanya memberikan daftar halaman dengan pagination yang konsisten walaupun ada penambahan/ penghapusan. Dua pendekatan utama:

Offset pagination

Metode offset tradisional cocok untuk dataset kecil tapi buruk skala besar karena penyortiran ulang. Untuk catatan tinta, offset bisa menyebabkan klausa LIMIT 100 OFFSET 900 tetap membaca banyak baris. Baiknya diganti dengan keyset pagination:

Keyset pagination (cursor)

Gunakan kolom timestamp atau sequence sebagai cursor untuk paging yang stabil. Contoh query:

SELECT page_id, sequence FROM pages WHERE note_id = $1 AND sequence > $2 ORDER BY sequence ASC LIMIT 25

Dengan sequence sebagai cursor, database tidak perlu melewati baris yang sudah ditampilkan, sehingga latensi tetap rendah walau tabel tumbuh.

Tip arsitektur: simpan cursor terakhir dari halaman yang ditampilkan di layer API agar client dapat mengirim kembali untuk halaman berikutnya tanpa mereset urutan.

Archive dan dasbor catatan matang

Ketika catatan berusia lama, pertimbangkan memindahkannya ke archive table dengan schema serupa tapi terpisah. Hal ini mencegah table utama menjadi terlalu besar dan menjaga index tetap ramping. Arsitektur yang digunakan repositori reMarkable menggabungkan materialized view untuk statistik user yang hanya di-refresh saat diperlukan, bukan setiap insert.

Diagnosa bottleneck SQL dan perbaikan

Ketika query menua, gunakan EXPLAIN ANALYZE untuk melihat apakah index digunakan. Contoh slow query:

EXPLAIN ANALYZE SELECT * FROM notes WHERE user_id = $1 ORDER BY updated_at DESC LIMIT 50;

Hasil menunjukkan Seq Scan karena index tidak mencakup ORDER BY. Solusi:

CREATE INDEX idx_notes_user_updated ON notes (user_id, updated_at DESC); Setelah index dibuat, query memakai index scan, mengurangi waktu dari detik ke milidetik.

Penting juga memonitor buffer cache hit ratio dan IO wait. Join besar antara notes dan pages bisa dipecah dengan batching atau materialized views untuk menghindari hundreds-of-milliseconds spike.

Penerapan praktis dan pengecekan rutin

Tim backend sebaiknya menetapkan profiling rutin dan tes beban pada skenario utamanya: membuka daftar catatan, menambah halaman, dan sinkronisasi. Langkah recommended:

  1. Gunakan pg_stat_statements atau setara untuk mendeteksi query lambat.
  2. Periksa cardinality index dengan EXPLAIN (ANALYZE, BUFFERS).
  3. Evaluasi apakah partial index, index covering, atau rewrite query bisa mengurangi hitungan disk.
  4. Implementasikan metrics (latensi query, cache hit) agar regresi dapat terdeteksi sebelum user menyinggung.

Selain itu, kode ingestion catatan harus memisahkan write-heavy path (simpan halaman) dari read-heavy path (tampil daftar) agar blocking minim.

Kesimpulan

Maintaining responsiveness pada Database Catatan Ink reMarkable berarti menyelaraskan schema, index, dan pagination dengan pola akses data. Dengan mengambil inspirasi dari MaximeRivest/riddle—schema modular, index yang tepat, keyset pagination, archive strategy, serta diagnosa slow query—tim backend bisa meminimalkan bottleneck SQL sebelum berdampak ke pengguna. Fokus pada pengukuran nyata dan iterasi per query akan mencegah pertumbuhan data mengorbankan performa.