Anda benar memperhatikan bahwa dokumen akan memiliki ukuran yang berbeda. Jadi Anda akan menghemat setidaknya 15 bytes per dokumen (60% untuk dokumen serupa) jika Anda memutuskan untuk mengadopsi skema kedua. Ini akan berakhir seperti 140MB untuk 10 million your catatan. Ini akan memberi Anda keuntungan berikut:
- Penghematan HDD. Satu-satunya masalah adalah melihat harga HDD saat ini sebagian besar tidak berguna.
- Penghematan RAM. Dibandingkan dengan hard disk, ini dapat berguna untuk pengindeksan. Dalam set kerja mongodb dari indeks harus sesuai dengan RAM untuk mencapai hasil yang baik kinerja
. Jadi jika Anda akan memiliki indeks pada dua bidang ini, Anda tidak hanya akan menghemat
140MBruang HDD tetapi juga140MBruang RAM potensial (yang sebenarnya terlihat). - I/O . Banyak kemacetan terjadi karena keterbatasan sistem input/output (kecepatan membaca/menulis dari disk terbatas). Untuk dokumen Anda, ini berarti bahwa dengan skema 2 Anda berpotensi dapat membaca/menulis
twice as many documentsper 1 detik. - jaringan . Dalam banyak situasi jaringan bahkan jauh lebih lambat dari IO, dan jika server DB Anda berada di mesin yang berbeda maka server aplikasi Anda, data harus dikirim melalui kabel. Dan Anda juga dapat mengirim data dua kali lebih banyak.
Setelah menceritakan tentang kelebihannya, saya harus memberi tahu Anda kerugian untuk kunci kecil:
- keterbacaan database. Ketika Anda melakukan
db.coll.findOne()dan melihat{_id: 1, t: 13423, a: 3, b:0.2}cukup sulit untuk memahami apa yang sebenarnya disimpan di sini. - keterbacaan aplikasi mirip dengan database, tetapi setidaknya di sini Anda dapat memiliki solusi. Dengan logika pemetaan, yang mengubah
currentDatekecdanpricekepAnda dapat menulis kode bersih dan memiliki skema pendek.
