Использование плоских файлов против базы данных / API в качестве транспорта между внешним и внутренним интерфейсом

У меня есть приложение, которое вызвало довольно жаркую дискуссию между парой разработчиков.

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

Сами файлы очень просты (т. Е. Все строковые данные, без вложенности), и их размер составляет около 1-2 тыс., При этом система большую часть времени простаивает (но в каждый момент времени может обрабатываться до 100 сообщений). Шаг обработки бэкэнда занимает около 10 минут для каждого сообщения.

Аргумент приходит, когда один разработчик предполагает, что использование файловой системы в качестве уровня обмена сообщениями является плохим решением, когда вместо этого следует использовать что-то вроде реляционной базы данных (MySQL), базы данных noSQL (Redis) или даже простой вызов REST API.

Следует отметить, что Redis используется в других местах организации для обработки сообщений в очереди.

Аргументы, которые я слышал, распадаются следующим образом

В пользу плоских файлов:

• Плоские файлы более надежны, чем любое другое решение, поскольку файл перемещается только из папки «watch», в папку «processing» после его получения и, наконец, в папку «done» после завершения. Существует нулевой риск исчезновения сообщений, за исключением ошибок очень низкого уровня, которые в любом случае могут сломать другие вещи.

• Плоские файлы требуют меньшей технической сложности, чтобы понять - только catэто. Нет запросов для записи, нет риска случайного удаления сообщения из очереди и его исчезновения навсегда.

• Код управления файлами проще, чем API баз данных с точки зрения программирования, поскольку он является частью стандартной библиотеки каждого языка. Это уменьшает общую сложность кодовой базы и объем стороннего кода, который необходимо ввести.

• Принцип YAGNI гласит, что плоские файлы сейчас работают отлично, нет очевидной необходимости переходить на более сложное решение, поэтому оставьте его.

В пользу базы данных:

• Проще масштабировать базу данных, чем каталог, полный файлов

• Плоские файлы рискуют скопировать «готовый» файл обратно в каталог «watch». Из-за характера этого приложения (управление виртуальной машиной) это может привести к катастрофической потере данных.

• Требуя большей технической сложности для T / S, приложение означает, что необразованный персонал с меньшей вероятностью что-то испортит, просто ткнув в вещи.

• Код подключения к БД, особенно для чего-то вроде Redis, по меньшей мере такой же надежный, как стандартные функции управления файлами библиотеки.

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

Из того, что я вижу, оба разработчика имеют много правильных точек.

Итак, из этих двух людей, разработчика pro-files или разработчика pro-database, какой из них больше соответствует передовой практике разработки программного обеспечения и почему?

Переключение на решение, включающее базы данных или системы очередей, упомянутые Эваном,

• создать зависимость от новой, сложной системы в бэкэнде и во внешнем интерфейсе
• внесите ненужную сложность и множество новых точек отказа
• увеличить стоимость (включая стоимость владения)

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

В нашей компании мы с большим успехом использовали подобные файловые интерфейсы на протяжении десятилетий. Многие другие вещи приходили и уходили, но эти интерфейсы остались из-за их абсолютной простоты, надежности и минимальной связи / зависимости.

Я не думаю, что любое из этих решений по своей природе является плохой практикой, поэтому ответ на этот вопрос может оказаться затруднительным.

Я не верю, что принцип ЯГНИ применим здесь, если вы имеете дело с масштабом. «Работа» относительна, если у вас есть серьезный потенциал для катастрофической потери данных и небольшая способность к масштабированию, я бы не подумал, что это работает. Я не совсем уверен, с какой шкалой вы имеете дело, но если у вас огромное количество этих записей, с каждой из них становится все труднее переключиться на новую систему. Так что, если это так, я бы сказал, что база данных - лучшая практика.

MongoDB или redis (у меня нет опыта работы с redis, я только читаю хорошие вещи) должны работать хорошо, поскольку ваши данные уже должны вписываться в них (документы json часто тривиально меняются на документы BSON для MongoDB). Он также имеет дополнительное преимущество, заключающееся в хранении большого количества данных в памяти, а не в возможности частого чтения / записи на диск все время. Это также гарантирует, что одновременное чтение / запись не приведет к повреждению или блокировке.

Если принцип YAGNI здесь применим, и файлы не являются узким местом, они масштабируются в пределах области и не имеют катастрофических проблем, я бы сказал, что придерживаться этих файлов - «лучшая практика». Нет никаких причин что-либо менять, если проблем нет, возможно, напишите несколько тестов, подчеркните это и посмотрите, где находятся ваши ограничения и узкие места.

Я не уверен, является ли база данных решением в этом контексте в любом случае. Если вы общаетесь с вещами на одном и том же сервере, какой-то IPC мог бы быть, не так ли?

В то время как хороший способ сохранить файл и скопировать его в готовый каталог является основным элементом многих коммуникационных уровней, особенно. со старыми системами основной рамы и тому подобное. «Анти» парни действительно имеют смысл; в этом есть много проблем и крайних случаев. С которыми трудно иметь дело, если вам требуется 100% надежность, и это происходит чаще, когда вы увеличиваете частоту и объем файлов.

Если вы контролируете обе стороны транзакции, я бы посоветовал вам взглянуть на некоторые из множества доступных систем очередей. ZeroMQ, RabbitMQ, MSMQ и т. Д., А не база данных. Но, как вы подразумеваете, если это не сломалось ...

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

Оба являются похожими решениями, за исключением того, что база данных не размещается на конкретном хосте. Это избавляет от проблем брандмауэра / доступа с системой Unix. У нас были случаи «случайного» удаления на файловых системах, и никто не виноват.

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

Также в файловой системе, если вам нужно поместить приложение в имя файла, например, OASIS, то вам нужно будет создать файлы OASIS.john_doe.system1.20160202. Это становится утомительным и может быть легко представлено в базе данных. Вы даже можете иметь нулевые поля в базе данных и логику, основанную на этом

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

Например, вы хотите выполнить повтор, но с системой, отличной от OASIS, скажите DESERT и john_doe для doe_smith и укажите дату с 20160101 по 20151231

Легко генерировать строки для DESERT / doe_smith / 20151231 из исходного набора, а не создавать эти файлы с помощью сценария оболочки.

Таким образом, с точки зрения читаемости, решение с точки зрения расширения базы данных лучше.