Apakah GridFS cukup cepat dan andal untuk produksi?


86

Saya mengembangkan situs web baru dan saya ingin menggunakan GridFS sebagai penyimpanan untuk semua unggahan pengguna, karena ini menawarkan banyak keuntungan dibandingkan dengan penyimpanan sistem file biasa.

Tolok ukur dengan GridFS yang dilayani oleh nginx menunjukkan, bahwa ini tidak secepat sistem file normal yang dilayani oleh nginx.

Tolok ukur dengan nginx

Apakah ada orang di luar sana, yang sudah menggunakan GridFS di lingkungan produksi, atau akan menggunakannya untuk proyek baru?


1
Sebuah posting blog tentang menyimpan gambar di mongodb untuk pencari masa depan yang memiliki niat yang sama dengan saya: menge.io/2015/03/24/storing-small-images-in-mongodb (membandingkan GridFS dengan hanya membuangnya ke dokumen sebagai biner data)

Ada banyak trade-off yang perlu dipertimbangkan ketika memutuskan apakah Anda ingin menyimpan data biner di MongoDB - lihat: alexmarquardt.com/2017/03/02/…
Alexander Marquardt

Jawaban:


119

Saya menggunakan gridfs saat bekerja di salah satu server kami yang merupakan bagian dari situs web pembanding harga dengan statistik lalu lintas yang terhormat (sekitar 25 ribu pengunjung per hari). Server tidak memiliki banyak ram, 2gigs, dan bahkan cpu tidak terlalu cepat (Core 2 duo 1.8Ghz) tetapi server memiliki banyak ruang penyimpanan: 10Tb (sata) dalam konfigurasi raid 0. Pekerjaan yang dilakukan server sangat sederhana:

Setiap produk pada pembanding harga kami memiliki gambar (ada sekitar 10 juta produk menurut db produk kami), dan tugas server adalah mengunduh gambar, mengubah ukurannya, menyimpannya di gridfs, dan mengirimkannya ke browser pengunjung. .. jika tidak ada di grid ... atau ... kirimkan ke browser pengunjung jika sudah disimpan di grid. Jadi, ini bisa disebut sebagai 'skema cdn tradisional'.

Kami telah menyimpan dan memproses 4 juta gambar di server ini sejak aktif dan berjalan. Mengubah ukuran dan menyimpan barang dilakukan dengan skrip php sederhana ... tapi yang pasti, skrip python, atau sesuatu seperti java bisa lebih cepat.

Ukuran data saat ini: 11.23g

Ukuran penyimpanan saat ini: 12.5g

Indeks: 5

Ukuran indeks: 849.65m

Tentang keandalan: Ini sangat andal. Server tidak memuat, ukuran indeks baik-baik saja, kueri cepat

Tentang kecepatan: Yang pasti, tidak secepat penyimpanan file lokal, mungkin 10% lebih lambat, tapi cukup cepat untuk digunakan secara realtime bahkan ketika gambar perlu diproses, yang dalam kasus kami, sangat bergantung pada php. Waktu pemeliharaan dan pengembangan juga telah dikurangi: menghapus satu atau beberapa gambar menjadi sangat mudah: cukup kueri db dengan perintah hapus sederhana. Hal menarik lainnya: ketika kami me-reboot server lama kami, dengan penyimpanan file lokal (jutaan file dalam ribuan folder), terkadang hang berjam-jam karena sistem melakukan pemeriksaan integritas file (ini benar-benar membutuhkan waktu berjam-jam ...). Kami tidak memiliki masalah ini lagi dengan gridfs, gambar kami sekarang disimpan dalam potongan mongodb besar (file 2gb)

Jadi ... dalam pikiran saya ... Ya, gridfs cukup cepat dan dapat diandalkan untuk digunakan dalam produksi.


9
Saya terkejut bahwa siapa pun akan menggunakan serangan 0 karena ada penyimpanan utama di situs web produksi. Bahkan dengan cadangan yang baik, meningkatkan kemungkinan kegagalan penyimpanan adalah harga yang cukup mahal untuk membayar peningkatan kinerja.
mikerobi

67
Kami menggunakan serangan 0 karena dalam kasus khusus kami, data gambar dapat berubah-ubah. Tidak masalah jika gambarnya hilang karena kami akan mendownloadnya lagi dari situs merchant. Secara pragmatis, kami dapat menganggap bahwa server kami adalah server cache gambar sederhana.
Manu Eidenberger

Tapi Anda secara aktif meningkatkan kemungkinan kegagalan (faktor kegagalan drive awal dikalikan dengan jumlah spindel). Raid 10 akan ideal jika Anda membutuhkan lebih banyak menulis daripada membaca atau Raid 5/6 jika Anda membutuhkan lebih banyak membaca daripada menulis.
NeuroScr

9
@ManuEidenberger Mengapa Anda menggunakan GridFS untuk menyimpan gambar yang lebih baik disimpan dalam dokumen MongoDB? Saya kira Anda tidak mencapai batas ukuran dokumen 16 MB. Dan menyimpan gambar sebagai BLOB dalam dokumen MongoDB akan lebih efisien, karena Anda tidak memerlukan lapisan GridFS di atas dokumen MongoDB.
Arnaud Bouchez

1
Saya juga penasaran dengan pertanyaan @ ArnaudBouchez. Apakah ada keuntungan yang membuat Anda memilih GridFS daripada menyimpannya sebagai data biner dalam dokumen, Manu? Terima kasih!

12

Seperti yang disebutkan, ini mungkin tidak secepat filesystem biasa, tetapi ia memberi Anda keuntungan lebih dari filesystem biasa yang menurut saya layak untuk diberikan sedikit kecepatan.

Pada akhirnya, dengan sharding, Anda mungkin mencapai titik di mana penyimpanan GridFS benar-benar menjadi opsi yang lebih cepat dibandingkan dengan sistem file biasa dan satu node.


6

Perhatian pada perbaikan untuk DB yang lebih besar - sistem baru yang kami kembangkan, mongo tidak keluar dengan bersih, dan memperbaiki GridFS 7TB sepertinya akan memakan waktu 130 jam.

Karena itu, saya pikir saya akan beralih ke OpenStack Swift atau Ceph. Tetap saja, sampai saat itu itu bagus. Dan modul nginx-gridfs sangat bagus.


Jadi, bagaimana Anda pergi?
Mukus

5

Modul nginx-gridfs mdirolf sangat bagus dan cukup mudah untuk disiapkan. Kami menggunakannya dalam produksi di paint.ly untuk melayani semua lukisan dan sejauh ini tidak ada masalah.


3
paint.ly tampaknya sudah tidak tersedia lagi. :(
Maria

2

Saya tidak merekomendasikan menggunakan gridfs kecuali Anda tahu apa yang Anda lakukan. GridFS hanyalah lapisan abstraksi yang membagi file menjadi potongan dan menyimpan file dalam dua koleksi. Lebih banyak file - lebih banyak overhead. Jika Anda mengharapkan file berukuran sama, tidak melebihi 32M atau lebih - Anda berada di jalur yang benar. Jangan mencoba menyimpan file besar di gridfs. Mengapa?

  1. Driver pada bahasa yang berbeda dapat membaca seluruh file. (Misalnya potongan) saat membaca bagian kecil dari file tersebut.
  2. Mengubah file dapat mempengaruhi semua potongan dan meningkatkan beban database Jika sistem file Anda berkembang, Anda harus memutuskan untuk memecah gridfs. Hati-hati! Konsistensi tidak dijamin saat sharding dimulai!

Jika Anda berpikir tentang proyek yang dimuat baca - pertimbangkan untuk memuat file ke dalam dokumen secara langsung (jika berukuran 16M atau kurang) atau pilih clusterf lain, dan tautkan nama file / inode ke logika Anda.

Semoga ini membantu.


4
Saya cukup baru mengenal GridFS meskipun dari apa yang saya pahami GridFS lebih dari sekadar lapisan abstraksi yang menggandakan jumlah file. GridFS menyediakan cara sederhana untuk memanfaatkan fitur replikasi dan sharding MongoDB. Saya yakin orang lain juga telah menyebutkan bahwa file disimpan dalam potongan 2GB yang menurut saya akan mengurangi jumlah total file, terutama jika seseorang memiliki gambar kecil dalam jumlah yang sangat besar.

+1 Anda benar. File yang lebih kecil tidak akan menguntungkan untuk disimpan dengan GridFS. Jika file Anda dapat disimpan dalam dokumen MongoDB (yaitu <dari batas ukuran 16 MB), Anda lebih suka menyimpan file tersebut sebagai BLOB dalam dokumen MongoDB. Ini akan melewati overhead penggunaan GridFS di atas penyimpanan MongoDB. Lihat compose.io/articles/gridfs-and-mongodb-pros-and-cons
Arnaud Bouchez
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.