Memilih Tipe Collection

MongoDB memberi kita empat tipe collection dengan karakter yang saling melengkapi: regular untuk data operasional, capped untuk buffer berputar, time series untuk data pengukuran, dan view untuk presentasi read-only. Kesalahan memilih tidak langsung terasa — semuanya bisa menerima insert dan menjawab find — tetapi salah pilih berarti membayar storage, index, atau maintenance yang tidak dibutuhkan. Bab penutup section ini merangkum perilaku keempatnya dalam satu tabel, mengujinya dalam satu database, lalu menutup dengan checklist keputusan yang bisa dipakai sebelum membuat collection baru.

Perilaku Empat Tipe Berdampingan #

Tabel ini merangkum hasil seluruh section — regular, capped, time series, plus view yang sudah kita kenal di Section Data Modeling:

Aspek	Regular	Capped	Time series	View
Ukuran	Tumbuh sesuai data	Tetap (`size`, opsional `max`)	Tumbuh, terkompresi per bucket	Nol (tanpa storage sendiri)
Retensi data	Manual / TTL index	Tertimpa otomatis (FIFO)	`expireAfterSeconds`	Mengikuti collection sumber
Update	Bebas	Diizinkan, hindari yang memperbesar	Hanya `metaField`, wajib `multi`	Tidak bisa (read-only)
Delete	Bebas	Diizinkan di 9.0	Hanya filter `metaField` / `_id`	Tidak bisa
Index `_id`	Otomatis	Otomatis	Tidak ada	Mengikuti sumber
Transaksi write	Ya	Tidak (galat 263)	Tidak	Tidak relevan
Use case utama	Aplikasi CRUD	Log, buffer, antrian sementara	Sensor, metric, keuangan	Proyeksi API, keamanan, kompatibilitas schema

Empat tipe itu bisa hidup berdampingan dalam satu database. Kita buat semuanya sekaligus dan periksa bagaimana server melabelinya:

js
use latihan_timeseries
db.dropDatabase()
db.createCollection("produk")
db.produk.insertMany([
  { sku: "BK-01", nama: "Laut Bercerita", harga: 95000, stok: 12 },
  { sku: "BK-02", nama: "Bumi Mantra", harga: 550000, stok: 5 },
  { sku: "BK-03", nama: "Rumah Kaca", harga: 480000, stok: 8 }
])
db.createCollection("log_aktivitas", { capped: true, size: 4096, max: 3 })
db.createCollection("cuaca", { timeseries: { timeField: "waktu", metaField: "sensor", granularity: "minutes" } })
db.createView("produk_mahal", "produk", [ { $match: { harga: { $gte: 500000 } } } ])
db.getCollectionInfos().map(c => ({ name: c.name, type: c.type, capped: c.options?.capped === true }))

Output yang Dihasilkan:

text
switched to db latihan_timeseries
{ ok: 1, dropped: 'latihan_timeseries' }
{ ok: 1 }
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId('6ad3e1f98d1b68f2476a44c7'),
    '1': ObjectId('6ad3e1f98d1b68f2476a44c8'),
    '2': ObjectId('6ad3e1f98d1b68f2476a44c9')
  }
}
{ ok: 1 }
{ ok: 1 }
{ ok: 1 }
[
  { name: 'log_aktivitas', type: 'collection', capped: true },
  { name: 'system.views', type: 'collection', capped: false },
  { name: 'cuaca', type: 'timeseries', capped: false },
  { name: 'produk', type: 'collection', capped: false },
  { name: 'produk_mahal', type: 'view', capped: false }
]

Label tipe di getCollectionInfos() membedakan collection, timeseries, dan view — sementara status capped tidak punya label tipenya sendiri, melainkan terbaca dari opsi capped (itulah alasan pemetaan di atas memeriksa c.options?.capped). Collection system.views ikut muncul karena MongoDB menyimpan definisi view di sana. Dari sisi aplikasi semuanya di-query dengan cara serupa; perbedaannya muncul pada aturan tulis dan retensi seperti dirangkum tabel di atas.

Perbedaan perilaku itu cepat terasa begitu kita menulis. Regular collection menerima update stok tanpa syarat, capped collection menimbpa data terlama saat penuh, time series menolak perubahan pada field pengukuran, dan view tidak menyimpan apa pun:

js
db.produk.updateOne({ sku: "BK-01" }, { $set: { stok: 10 } })
db.cuaca.insertOne({ waktu: ISODate("2026-12-10T02:00:00Z"), sensor: { sensor_id: "JKT-01", kota: "Jakarta" }, suhu: 27.4 })
db.log_aktivitas.insertMany([ { aksi: "a" }, { aksi: "b" }, { aksi: "c" }, { aksi: "d" } ])
db.log_aktivitas.find({}, { _id: 0 })
db.produk_mahal.find({}, { _id: 0, nama: 1, harga: 1 })

Output yang Dihasilkan:

text
{
  acknowledged: true,
  insertedId: null,
  matchedCount: 1,
  modifiedCount: 1,
  upsertedCount: 0
}
{
  acknowledged: true,
  insertedId: ObjectId('6ad3e1f98d1b68f2476a44ca')
}
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId('6ad3e1f98d1b68f2476a44cb'),
    '1': ObjectId('6ad3e1f98d1b68f2476a44cc'),
    '2': ObjectId('6ad3e1f98d1b68f2476a44cd'),
    '3': ObjectId('6ad3e1f98d1b68f2476a44ce')
  }
}
[
  { aksi: 'b' },
  { aksi: 'c' },
  { aksi: 'd' }
]
[ { nama: 'Bumi Mantra', harga: 550000 } ]

Empat operasi, empat perilaku: update produk diterima bebas; pengukuran cuaca masuk sebagai measurement yang tak akan pernah bisa di-update field suhu-nya; empat log masuk ke collection bermaks 3 sehingga hanya tiga terakhir yang bertahan; dan view produk_mahal menyaring produk di atas Rp500.000 tanpa menyimpan salinan.

Checklist Keputusan #

Sebelum membuat collection baru, jawab pertanyaan berikut secara berurutan:

Apakah datanya murni hasil presentasi dari collection lain? Ya → view: tanpa storage, schema terkonsolidasi, aman karena read-only.
Apakah datanya deret pengukuran bernilai analitik — ditulis terus-menerus, dibaca lewat agregasi waktu? Ya → time series: bucket terkompresi, index meta+time otomatis, retensi via TTL.
Apakah datanya hanya bernilai beberapa saat terakhir dan boleh hilang demi data baru — tanpa perlu analitik? Ya → capped: buffer tetap dengan ketimbangan otomatis; pertimbangkan juga TTL index bila ukuran bukan patokan utama.
Sisanya → regular: update/delete bebas, transaksi, seluruh jenis index, semua fitur CRUD standar.

flowchart TD A{Butuh collection baru} --> B{Presentasi dari data lain?} B -- Ya --> V[View] B -- Tidak --> C{Deret pengukuran + analitik waktu?} C -- Ya --> TS[Time series] C -- Tidak --> D{Boleh tertimpa saat penuh?} D -- Ya --> CP[Capped] D -- Tidak --> R[Regular]

Dua catatan penutup untuk keputusan jangka panjang. Pertama, tipe collection dikunci saat dibuat — time series tidak bisa dikonversi jadi regular atau sebaliknya; migrasi berarti tulis ulang data. Kedua, kombinasi adalah jawaban yang sah: proyek nyata kerap memakai time series untuk data sensor, regular untuk master data, lalu view untuk API publik — persis seperti keempat collection yang baru saja kita buat berdampingan.

Rangkuman #

getCollectionInfos() membedakan tipe collection, timeseries, dan view; status capped terbaca dari opsi capped, bukan label tipe.
Kunci perbedaan: retensi (manual/TTL vs FIFO vs TTL time series), kebebasan update/delete (bebas vs meta-only vs read-only), dan index _id (ada kecuali time series).
Urutan keputusan: view untuk presentasi, time series untuk deret pengukuran, capped untuk buffer pendek, regular untuk sisanya.
Tipe collection tidak bisa dikonversi setelah dibuat — putuskan di awal, dan jangan ragu memakai kombinasi sesuai kebutuhan tiap kelompok data.