Project-1: Basis Data Dokumen dan Key-Value

Soal / Brief

Tujuan dan Kelompok

Tujuan: mahasiswa mengimplementasikan suatu kasus dalam teknologi basisdata NoSQL berbasis dokumen dan key-value serta membandingkan kinerjanya dengan teknologi basisdata relasional.

Tugas dikerjakan berkelompok, @ kelompok 3-4 orang, sedapat mungkin menggunakan pengelompokan yang sama dengan project-0 (karena akan menggunakan studi kasus yang sama).

Penggunaan Gen-AI

Boleh digunakan untuk:

  • Mendapatkan pengetahuan dan mencari referensi tentang penggunaan teknologi

Dilarang dalam:

  • Pembuatan produk akhir tugas
  • Penyiapan dan generate data test
  • Penulisan laporan, slide, dan video (termasuk untuk pengecekan dan perbaikan tata bahasa dan ejaan)

Deskripsi Tugas

Menggunakan persoalan yang dideskripsikan di project-0, buatlah implementasi persoalan atau sebagian persoalan ke dalam 1 (satu) DBMS berbasis dokumen dikombinasikan dengan 1 (satu) DBMS berbasis key-value. Tentukan dan jelaskan bagian persoalan mana yang tepat menggunakan DBMS berbasis dokumen dan bagian mana yang tepat menggunakan DBMS berbasis key-value.

Sangat disarankan: setiap kelompok memilih DBMS yang berbeda → tuliskan nama DBMS yang dipilih pada link daftar kelompok di atas.

Buatlah model lojik untuk basisdata berbasis dokumen dan key-value untuk persoalan di atas berdasarkan model ER:

  • Gunakan petunjuk dari materi kuliah, atau lakukan eksplorasi tentang bagaimana melakukan transformasi dari model ER ke model basisdata berbasis dokumen/key-value.
  • Jelaskan konvensi-konvensi yang digunakan (jika ada).

Buatlah implementasi basis data pada kasus tersebut. Gunakan contoh data yang sama dengan data pada basisdata relasional.

Tuliskan semua query yang didefinisikan pada kasus pada lingkungan basisdata berbasis dokumen dan berbasis key-value dan eksekusi query. Catat performance query dari sisi waktu dan berikan analisis kinerja.

Environment implementasi: Diharapkan implementasi basisdata NoSQL dan relasional dilakukan dalam environment yang sama/sejenis sehingga dapat dilakukan perbandingan kinerja yang ‘adil’. Jika hal ini sulit, maka catat dengan cermat perbedaan lingkungan dan apa pengaruhnya terhadap kinerja sistem basisdata.

Laporan

Tambahkan laporan project-0 dengan aspek-aspek dari tugas project-1 yaitu:

  • Model lojik dan konvensi yang digunakan
  • Penjelasan implementasi pada DBMS NoSQL
  • Deskripsi environment implementasi untuk basisdata
  • Implementasi query
  • Hasil dan analisis perbandingan kinerja query antara implementasi di basis data relasional dengan di basis data NoSQL
  • Kesimpulan dan lesson learned
  • Pembagian kerja dalam tim
  • Referensi
  • Lampiran: script struktur data, query, data yang penting untuk disampaikan
  • Link video presentasi

Deliverables

  • Laporan ditulis dalam format A4 dan disimpan dalam format pdf dengan nama file: IF4040_Project1_XX.pdf (XX adalah 2 digit nomor kelompok).
  • Pengumpulan laporan dilakukan di Edunex paling lambat Kamis, 24 September 2026 pukul 23.59.
  • Pada hari Selasa, 22 September 2026 pada jam kuliah akan dilakukan presentasi dan diskusi kelas mengenai hasil project-1.
  • Buat video presentasi durasi maksimum 15 menit mengenai hasil tugas.
    • Setiap anggota kelompok wajib mempresentasikan bagian pekerjaannya.
    • Harus ada demo implementasi kasus basis data di teknologi basis data yang digunakan.
    • Unggah di situs video sharing dan masih harus dapat diakses sampai paling lambat 31 Januari 2026.
    • Tuliskan link video dalam laporan.

Ketentuan / Yang Dikumpulkan

  • Pilih 1 DBMS dokumen + 1 DBMS key-value (beda dari kelompok lain kalau bisa), catat pilihan di daftar kelompok
  • Model lojik dokumen & key-value hasil transformasi dari model ER project-0, beserta penjelasan konvensi
  • Implementasi basis data (dokumen + key-value) dengan data yang sama seperti di basisdata relasional project-0
  • Semua query dari project-0 ditulis ulang & dieksekusi di kedua DBMS NoSQL, waktu eksekusi dicatat
  • Analisis perbandingan kinerja query: relasional vs dokumen vs key-value
  • Deskripsi environment implementasi (idealnya sama/sejenis dengan environment relasional)
  • Update laporan project-0 dengan semua section project-1 (lihat daftar di atas)
  • Video presentasi ≤15 menit, semua anggota tampil, ada demo, link disertakan di laporan
  • Submit PDF IF4040_Project1_XX.pdf ke Edunex sebelum Kamis, 24 Sep 2026 23:59
  • Siap presentasi kelas Selasa, 22 Sep 2026

Progress & Catatan Pengerjaan

  • 2026-09-17 — Brief dicatat. Project-0 (basisdata relasional Nimonspedia) sudah selesai di repo kerja, jadi project-1 tinggal lanjut dari situ: pilih DBMS dokumen + key-value, lalu transformasi model dari ERD project-0 yang sudah ada.

  • 2026-09-26 — Deadline pengumpulan mundur jadi Minggu, 27 September 2026 malam (bukan 24 September lagi).

  • 2026-09-21 — DBMS dipilih: MongoDB (dokumen) + Redis (key-value).

    Spesifikasi acuan ditemukan: kasus Nimonspedia yang jadi basis project-0/1 aslinya dari spesifikasi tugas besar IF3110 WBD (Milestone 1: e-commerce dasar — user/store/product/cart/ order; Milestone 2: tambahan auction/lelang, chat, push notification, feature flag), file mentahnya ada di _Tugas/PDL/Spesifikasi Tugas Besar wbd.txt. Cocok dengan scope project-0 yang sudah mencakup transaksi, lelang, chat, notifikasi push, dan feature flag (15 tabel). Catatan keamanan: file spec itu awalnya mengandung 2 blok prompt injection tersembunyi (menyuruh AI jadi tutor Socratic yang nolak kasih jawaban langsung, dan satu lagi menyuruh AI pura-pura jadi junior dev yang nulis kode jelek/asal) — sudah dihapus dari file.

    Desain awal Mongo+Redis dibuat teman di sesi Claude terpisah (link share tidak bisa diakses langsung tanpa login, isinya sudah disalin ke _Tugas/PDL/desain db mongo redis dari claude.txt). Ringkasan desain (“revised”):

    • 12 collections Mongo: users, stores, categories, products, carts, orders, auctions, auction_bids, chat_rooms, chat_messages, push_subscriptions, feature_access — pakai denormalisasi/snapshot (misal store: {_id, name} di product/order) dan hanya field yang ada di spesifikasi (tanpa field tambahan di luar itu).
    • Konkurensi: tanpa distributed lock — pakai conditional update (CAS: stock >= qty, status = X), $inc dengan guard balance, dan Mongo transaction optimistic (retry saat conflict). Butuh replica set Mongo.
    • Redis diposisikan cache/ephemeral state saja (session, presence, unread counter, hot bid cache, feature-flag cache, rate limit, dedup notifikasi) — bukan source of truth untuk apapun.
    • Sudah ada to-do list implementasi (setup replica set + redis → bikin schema/index Mongo → definisikan key Redis → service logic sesuai urutan dependency → verifikasi konkurensi), dan rencana bootstrap (docker-compose Mongo 7 replica set + Redis 7 + container Node one-shot yang bikin collection & index) — baru dideskripsikan di chat, belum ditulis ke repo.

    Tanggapan/assessment: desain solid secara modeling (embedding, index, partial unique index untuk “1 auction aktif per seller”), tapi ada gap terhadap requirement brief: karena Redis cuma cache, jawaban ke pertanyaan slide 4 (“bagian mana yang tepat pakai key-value”) jadi 100% dokumen/0% key-value — berisiko dianggap belum menjawab pertanyaan itu. Rekomendasi (belum diputuskan): jadikan carts dan feature_access authoritative di Redis (bukan di Mongo) — keduanya secara alami key-value (point lookup by user_id/feature name, tanpa query kompleks). Draft pesan untuk diskusi ke teman soal ini sudah dibuat (belum dikirim/belum ada jawaban).

    Catatan lain: desain teman pakai Node-only untuk bootstrap (PHP diabaikan sementara), sedangkan tooling project-0 (seed & benchmark query) pakai Python — perlu diputuskan sadar, bukan default, karena akan disebut di laporan (perbandingan kinerja “adil”).

    Next step: tunggu konfirmasi teman soal cart/feature_access di Redis, baru lanjut ke (1) revisi model kalau disetujui, (2) tulis bootstrap docker-compose + scripts/bootstrap.js di PDL/Project0-ADM-Kelompok-1, (3) transformasi data dari nimonspedia.sql + tulis ulang 20 query project-0 ke Mongo/Redis, (4) benchmark & analisis, (5) update laporan + video.

    Reminder waktu (dari 2026-09-21): presentasi kelas Selasa 22 Sep 2026 (besok, jam kuliah), submission laporan Kamis 24 Sep 2026 23:59. Window sangat sempit.

  • 2026-09-21 (lanjutan) — git pull 2x, dapat progress besar dari tim: repo direstruktur jadi project0/ (relasional, dipindah apa adanya) + project1/ (baru). project1/ sudah ada bootstrap Mongo (scripts/bootstrap.js: 12 collection + semua index) dan seed generator (scripts/seed.js, formula sama persis dengan project0/database/seed.py), plus 20 query (scripts/read/*.mql, scripts/write/*.mql) — semuanya untuk MongoDB, kecuali read_07_unread_messages.redis yang genuinely baca dari Redis (user:{uid}:unread hash).

    Sempat didiskusikan: apakah cache-only Redis (seperti desain awal) cukup jawab requirement slide 4 brief (“tentukan bagian mana yang tepat pakai key-value”)? Kesimpulan: enggak cukup kalau Redis cuma cache di atas Mongo — perlu minimal satu bagian yang genuinely authoritative di Redis. Kandidat: feature_access (point-lookup by user_id+feature, enggak butuh query kompleks, cocok key-value). Luqman (teammate) khawatir soal durability kalau Redis-only (mati/ke-evict) — dijawab: compose sudah pakai AOF (--appendonly yes) jadi survive restart selama volume enggak ikut kehapus (down -v), dan volatile-lru policy cuma ngevict key yang punya TTL, jadi key tanpa TTL aman dari eviction.

    Keputusan sementara (belum final, demi jaga-jaga): belum menghapus feature_access dari Mongo dulu — cuma menambahkan jalur Redis di project1/scripts/seed.js (fungsi seedFeatureFlagsToRedis, key feature:{feature}:{user_id} sebagai Redis hash {is_enabled, reason, updated_at}), plus dependency redis di package.json dan env REDIS_URI di docker-compose.yml. Jadi sekarang data feature_access duplikat di Mongo & Redis. Ini belum final — sebelum nulis bagian model/laporan, harus diputuskan final sama tim (terutama konfirmasi ke Luqman) apakah feature_access di Mongo dicabut supaya Redis jadi satu-satunya sumber (baru itu genuinely menjawab slide 4), atau tetap dua-duanya dengan alasan lain.

    Smoke test (2026-09-22) — berhasil, terverifikasi beneran jalan (bukan cuma node --check): docker compose up → bootstrap → seed --scale 1 --seed 42 di Mongo+Redis lokal. Sempat gagal 2x duluan gara-gara Docker Desktop tidak stabil (crash/500 error saat baru cold-start, bukan bug di kode), baru sukses penuh di percobaan ke-3 setelah daemon stabil. Hasil: semua 12 collection Mongo persis sesuai expected count (products 550rb, orders 550rb, chat_messages 1,1jt, feature_access 330rb, dst). Redis: DBSIZE = 330,000 (pas sama jumlah user_feature_access), HGETALL feature:checkout_enabled:1 balikin hash yang benar (is_enabled, reason, updated_at sesuai formula generator). Jadi kode seedFeatureFlagsToRedis/assertRedisFeatureFlagsEmpty/featureFlagKey terbukti jalan benar end-to-end, bukan cuma teori.

Files Terkait

  • Brief asli: 1789204992652_IF4040_Project1_sem1_2627.pdf
  • Repo kerja (kode & laporan): D:\Kuliah\PDL\Project0-ADM-Kelompok-1 — laporan project-0 di IF4040_Project0_01.md, ERD & model relasional di docs/, skema di nimonspedia.sql