Файлы или СУБД

Задача: в каких случаях использовать СУБД, а в каких файлы для работы с данными.

Краткое сравнение

Золотым стандартом хранения данных в архитектуре современных программ является хранение в базе данных. Не сильно ошибусь, если скажу, что в произвольном проекте сложнее Hello World на этапе проектирования будет заложена СУБД.

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

Преимущество СУБД с позиции архитектора:

- унифицированный способ хранения и обработки (стандартизация CRUD);
- быстрый поиск, агрегация и извлечение данных;
- логика обработки может быть объединена с данными;
- возможность проверить ограничения на уровне СУБД;
- стандартны API для работы с СУБД, что позволяет подключать разные приложения;
- безопасность и резервное копирование делаются по готовым шаблонам;
- большой запас прочности для роста проекта;
- унификация описания структур и связей между данными.

Недостатки:

- дополнительная сложность на этапе сопровождения;
- недостатки "черного ящика" - не всегда возможно понять причину проблем, так как разработчик СУБД, как правило, стороннее лицо;
- производительность и масштабирование требует дополнительной квалификации, не всегда делается правильно;
- привязка к вендору (вендорлок);
- усложнение за счет дополнительных абстракции ну уровне БЛ (например, ORM).

Вместо СУБД можно использовать другой способ: хранение данных в файлах. Такое решение имеет следующие преимущества:

- хранение неизменяемых данных (или в случае изменения части данных полностью перезаписывается весь набор);
- быстрый инкремент данных;
- простой способ хранения данных;
- не требует повышения уровня абстракции (нет дополнительных слоев в архитектуре, в существующей архитектуре добавляется модуль для работы с данными);
- низкое зацепление данных (каждый файл - собственный неймспейс, который не обязан быть связан с другими файлами);
- свобода в выборе структуры данных и способах их обработки;
- простой способ интеграции приложений, не требует доп. драйверов и протоколов;
- легко передавать, хранить, архивировать, шифровать данные;
- возможность использовать текстовые и бинарные форматы;

Недостатки:

- медленная вставка "в середину" данных;
- логика отделена от самих данных, каждое приложение должно реализовывать свой парсинг и обработку данных;
- ограничения на размеры файлов и их количество со стороны файловых систем;
- контроль за схемами данных и их связями лежит на приложении;
- приходится "велосипедить" для обычных CRUD задач, обычно с просадкой по скорости.

Вывод

Рассматривать файлы в качестве основного способа хранения и обработки данных смысла не имеет, лучше сразу заложить СУБД, однако файлы отлично подходят в качестве вспомогательного инструмента для решения следующих задач:

- промежуточное накопление сырых данных для последующей обработки;
- ведения различных текстовых или бинарных логов (как текстовых, так и лога изменений данных, например, может использоваться в Event Sourcing);
- ведения журналов аудита (в отличие от лога имеет дополнительные требования, исключающие подмену данных, что потребует дополнительных тех. решений);
- экспорт/импорт данных (файлы замечательно подходят для промежуточного хранения и конвертирования);
- как элемент распределенных транзакций.

Реакции влияют на темы постов:

100 x 💡 - пост по архитектуре
100 х 🥷 - пост про код
100 х 👑 - пост про профессиональный рост



#архитектура #знания

SOER | PRO | Boosty