Все записи

Как использовать файловые хранилища в своих проектах?

Где лучше хранить файлы, когда их становится много: в базе данных или файловом хранилище? И как сделать так, чтобы приложение не упало под нагрузками, а важные файлы не потерялись?

Маша, разработчик Naumen, рассказала о файловых хранилищах. Примеры — в статье на Habr.

Без имени-2 (3).jpg

Когда только пришла в Naumen, я не знала, что такое файловые хранилища и как с ними работать. Однако первые мои задачи были связаны именно с этим, поэтому пришлось разобраться, что это такое, и как файлы хранятся в системе. Благодаря осознанной эволюции хранения файлов, у нас есть решение, где мы не потеряем файлы и не упадем под нагрузками. 

Когда дело касается файлов, первое, что раньше приходило мне в голову — это сохранять их в базе данных. При маленьких размерах файлов и небольшом количестве — это хорошее решение. Однако когда файлы начинают расти, а их количество увеличивается, наша БД начинает разбухать. Возникает три основные проблемы:

  • Занимаем много места на сервере, где находится БД;

  • БД долго обрабатывает запросы;

  • Время создания бэкапа уходит в бесконечность.

На помощь приходят файловые хранилища. Это директория на локальном или сетевом диске, где мы храним и получаем файлы. 

По расположению файловые хранилища могут находиться:

В локальной файловой системе 

Плюсы: легкая реализация, быстрый доступ, независимость от сети.

Минусы: единый критический узел, занимаем дисковое пространство.

В сетевой файловой системе

Плюсы: устранение единого критического узла.

Минусы: сложнее реализация, поддержка уже второго сервера.

Файловые системы могут разделяться и по тому, что лежит в их основе

Использование файловой системы

Плюсы: бесплатный вариант, не грузим базу.

Минусы: реализация с нуля всех методов взаимодействия.

S3 совместимое файловое хранилище (поддержка стандарта Amazon’s S3 API)

Плюсы: легкая реализация, возможность использовать из коробки множество плюшек, наличие бесплатных систем (ceph и MinIO).

Минусы: необходимо первичное изучение библиотеки, поднятие и настройка файлового хранилища.

Хранилище данных поставщика услуг

Плюсы: простая реализация, возможность использовать из коробки множество плюшек, не требуется самостоятельного поднятия и настройки ФХ.

Минусы: необходимо первичное изучение библиотеки, системы платные.


Group 1 (3).jpg

Как обойти пиковые нагрузки и не потерять файлы?

Пользователь скачивает файл → мы размещаем его в БД → переносим в ФХ отдельной задачей, но с уточнением, что перенесется не каждый файл. Мы сначала проверим, можно его перенести или нет.

Бонусы работы с файловыми хранилищами

Обработка тайм-аута

Если нашему ФХ плохо, можно взять перерыв и потом продолжить обращаться к нему.

Поддержка нескольких ФХ

Если ФХ хранит очень много файлов, мы переключаемся на дополнительное и продолжаем работать. А из первого получаем файлы, которые уже сохранены. Либо если одному ФХ стало плохо, мы переключаемся на резервное ФХ и работаем с ним, пока разбираемся с основным.

Похожие новости

Когда задача считается выполненной

В работе для нас важен результат — хорошо сделанная задача и закрытая потребность пользователя. Этого легко достичь, когда команда продумывает план действий, реализует решение и доводит его до результата, который действительно приносит пользу.

При этом у каждого из нас свое понимание того, что значит выполненная задача. Разработчик, тестировщик и аналитик оценивают результат по разным критериям — через свою роль и зону ответственности.

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте в нашем материале.

Разбираем фичи по кусочкам: атомарные коммиты как внутренняя дисциплина

Дима руководит группой прикладной разработки в Naumen и много лет работает с командами, которые делают не одноразовые фичи, а долгоживущие системы — те, что развиваются годами, переживают смену людей, требований и контекста.

В статье он рассказывает о декомпозиции: зачем она на самом деле нужна в разработке и какую неожиданную роль в этом играют атомарные коммиты.

Как развивать документацию и продвигать техписателей

В продуктовой команде документацией пользуются все, но ожидают от нее разного. Аналитику важно одно, разработчику — другое, поддержке — третье. Если не учитывать контекст, можно бесконечно что-то улучшать и все равно не попадать в цель.

Мы поговорили с Дашей, техническим писателем Naumen SMP, о том, как через коммуникацию с командой она разбиралась в реальных ожиданиях от документации и выстраивала направление ее развития.

Все новости