Я розробляю новий веб-сайт, і я хочу використовувати GridFS як сховище для всіх завантажених користувачем файлів, оскільки він пропонує масу переваг у порівнянні зі звичайним сховищем файлової системи.
Тести з GridFS, що обслуговуються nginx, вказують, що це не так швидко, як звичайна файлова система, що обслуговується nginx.
Хтось із тих, хто використовує GridFS вже у виробничому середовищі, або використовував би його для нового проекту?
Відповіді:
Я використовую gridfs під час роботи на одному з наших серверів, який є частиною веб-сайту, що порівнює ціни, з почесною статистикою трафіку (близько 25 тис. Відвідувачів на день). На сервері мало оперативної пам'яті, 2 гігабайт, і навіть процесор не дуже швидкий (Core 2 duo 1,8 ГГц), але сервер має достатньо місця для зберігання: 10 Тб (sata) у конфігурації raid 0. Робота, яку виконує сервер, дуже проста:
Кожен продукт на нашому порівняльнику цін має зображення (налічується близько 10 мільйонів товарів відповідно до нашого продукту db), а завдання серверів - завантажити зображення, змінити його розмір, зберегти в сітках та доставити в браузер відвідувачів. .. якщо він відсутній у сітці ... або ... доставити його до браузера відвідувачів, якщо він уже збережений у сітці. Отже, це можна назвати "традиційною схемою CDN".
Ми зберегли та обробили 4 мільйони зображень на цьому сервері, оскільки він працює і працює. Змінення розміру та збереження матеріалів здійснюється простим php-скриптом ... але, безсумнівно, скрипт python або щось на зразок Java може бути швидшим.
Поточний розмір даних: 11,23г
Поточний розмір сховища: 12,5 г
Індекси: 5
Розмір індексу: 849,65м
Про надійність: Це дуже надійно. Сервер не завантажується, розмір індексу нормальний, запити швидкі
Про швидкість: Звичайно, це не так швидко, як локальне зберігання файлів, можливо на 10% повільніше, але досить швидко, щоб використовувати його в режимі реального часу, навіть коли зображення потрібно обробити, що в нашому випадку дуже залежить від php. Також скорочено час обслуговування та розробки: видалити одне або кілька зображень стало настільки просто: просто запитайте db за допомогою простої команди видалення. Ще одна цікава річ: коли ми перезавантажили наш старий сервер із локальним сховищем файлів (тобто мільйон файлів у тисячах папок), він іноді зависає годинами, оскільки система виконувала перевірку цілісності файлів (це дійсно зайняло години ...). Ми більше не маємо цієї проблеми з сітками, наші зображення тепер зберігаються великими шматками mongodb (файли 2 Гб)
Отже ... на мій погляд ... Так, gridfs досить швидкий і надійний, щоб використовувати його для виробництва.
Як уже згадувалося, це може бути не так швидко, як звичайна файлова система, але тоді вона надає вам переваги перед звичайними файловими системами, для яких, на мою думку, варто трохи відмовитися.
Зрештою, за допомогою шардінгу ви можете досягти точки, коли сховище GridFS насправді стає швидшим варіантом на відміну від звичайної файлової системи та одного вузла.
Однак оголення щодо ремонту великих БД - нова система, яку ми розробляємо, mongo не вийшов чисто, і ремонт 7TB GridFS, схоже, займе 130 годин.
Через це, я думаю, я розгляну перехід на OpenStack Swift або Ceph. Все-таки до того часу це було добре. І модуль nginx-gridfs приємний.
Я не рекомендую використовувати сітки, якщо ви не знаєте, що робите. GridFS - це просто абстракційний шар, який розділяє файли на фрагменти та зберігає файли у двох колекціях. Більше файлів - більше накладних витрат. Якщо ви очікуєте, що файли будуть однакового розміру, не перевищуючи 32 млн. Або близько того, - ви в правильному напрямку. Не намагайтеся зберігати великі файли у сітках. Чому?
Якщо ви думаєте про завантажений проект, розгляньте можливість завантаження файлів у документи безпосередньо (якщо розмір не перевищує 16 мільйонів) або виберіть інший кластер, а також прив’яжіть ім’я файлу / inode до вашої логіки.
Сподіваюся, це допомагає.