Використання плоских файлів проти бази даних / API як транспорту між фронтом і резервним

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

В основному, він розділений на веб-шар і резервний шар. Веб-шар збирає інформацію за допомогою простої веб-форми, зберігає ці дані у вигляді документа JSON (буквально .json-файл) у папку годинника, використовувану заднім кінцем. Задній кінець оглядає цю папку кожні кілька секунд, підбирає файл і виконує його функції.

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

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

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

Аргументи, які я чув, розбиваються наступним чином

На користь плоских файлів:

• Плоскі файли надійніші, ніж будь-яке інше рішення, оскільки файл переміщується лише з папки "спостерігати", до папки "обробка" після її завантаження, і, нарешті, у папку "зроблено" після її закінчення. Існує нульовий ризик зникнення повідомлень, забороняючи помилки дуже низького рівня, які в будь-якому разі можуть порушити інші речі.

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

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

• Принцип YAGNI зазначає, що плоскі файли працюють зараз добре, немає необхідності переходити на більш складне рішення, тому залиште це.

На користь бази даних:

• Масштабування бази даних простіше, ніж каталог, наповнений файлами

• Плоскі файли мають ризик того, що хтось скопіює файл "готовий" назад у каталог "watch". Через характер цієї програми (управління віртуальною машиною) це може призвести до катастрофічних втрат даних.

• Вимагаючи додаткової технічної вдосконалення для T / S, додаток означає, що неосвічений персонал має меншу ймовірність щось викрутити, просто поцупивши речі.

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

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

Як я бачу, обидва розробники мають чимало дійсних балів.

Отже, про цих двох людей, про-файли розробника або розробники баз даних, який більше відповідає найкращій практиці інженерії програмного забезпечення, і чому?

Перехід на рішення, що включає бази даних або системи очередей, згадані Ewan

• створити залежність від нової складної системи як в резервному, так і в інтернеті
• ввести непотрібну складність і велику кількість нових пунктів відмови
• збільшити вартість (включаючи вартість власності)

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

У нашій компанії ми використовували подібні файлові інтерфейси протягом десятиліть з великим успіхом. Багато інших речей прийшло і пішло, але ці інтерфейси залишилися через їхню максимальну простоту, надійність та мінімальну взаємодію / залежність.

Я не думаю, що обидва рішення не є вродженою поганою практикою, тому відповісти, яка найкраща практика може бути складною.

Я не вірю, що принцип YAGNI застосовується тут, якщо ви маєте справу зі масштабом. "Робота" є відносною, якщо ви маєте сильний потенціал для катастрофічних втрат даних і мало можливостей для масштабування, я б не вважав, що це працює. Я не точно впевнений у масштабі, з яким ви маєте справу, але якщо у вас є велика кількість цих записів, з кожним із них лише важче перейти на нову систему. Отже, якщо це так, я б сказав, що база даних є найкращою практикою.

MongoDB або redis (я не маю досвіду роботи з redis, читайте лише хороші речі) повинен робити добре, оскільки ваші дані вже повинні добре вміщуватись у нього (документи json часто тривіально змінюються на документи BSON для MongoDB). Це також має додаткову перевагу - зберігати багато даних у пам'яті замість того, щоб постійно постійно читати / записувати на диск. Це також гарантує, що одночасне читання / запис не призводить до пошкодження чи блокування.

Якщо керівник YAGNI тут застосовується і файли не є вузьким місцем, вони масштабуються в межах сфери, і не мають катастрофічних проблем, я б сказав, що дотримуватися файлів - це "найкраща практика". Немає причин нічого змінювати, якщо проблем немає, можливо, напишіть кілька тестів, підкресліть його і подивіться, де ваші обмеження та вузькі місця.

Я не впевнений, чи база даних є рішенням у цьому контексті. Якщо ви спілкуєтеся з речами на одному сервері, то якась IPC може бути зроблена, ні?

Хоча хороший файл збереже і скопіює його у виконаний файл, є основним елементом багатьох шарів зв'язку esp. зі старими основними каркасними системами тощо. У хлопців "анти" є крапка; в тому, що у нього багато проблем і кращих справ. З якими важко впоратися, якщо вам потрібен 100% надійність, і трапляються частіше, коли ви збільшуєте частоту та обсяг файлів.

Якщо ви керуєте обома сторонами транзакції, я б запропонував вам переглянути деякі з багатьох доступних простих систем черги. ZeroMQ, RabbitMQ, MSMQ тощо, а не база даних. Але як ви розумієте, якщо це не зламалося ...

Рішення бази даних є правильним. Він вирішує велику залежність від конкретного вузла або граничних умов.

Обидва є подібними рішеннями, за винятком того, що база даних не розміщується в конкретному хості. Це позбавляється від брандмауера / проблем з доступом до системи Unix. У нас були випадки "випадкового" видалення у файлових системах, і ніхто їх не звинувачував.

З базою даних у вас може бути та сама проблема, але ви можете поставити аудит або вставити лише логіку для позбавлення від видалених файлів.

Також у файловій системі, якщо вам потрібно поставити додаток у назві файлу, наприклад, OASIS, вам потрібно буде створити файли OASIS.john_doe.system1.20160202. Це стає стомлюючим і їх можна легше представити в базі даних. Ви можете навіть мати нульові поля в базі даних та логіці на основі цього

Також легко оновлювати бази даних, а не цілий каталог файлів у випадку будь-яких патчів або виправлень, які ви могли б зробити в таблицях. Звичайно, ви можете зробити це у файловій системі, але оновлення бази даних - більш інтуїтональне.

Наприклад, ви хочете, щоб повтор, але з іншою системою, ніж OASIS, скажімо, DESERT та john_doe для doe_smith і датується з 20160101 по 20151231

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

Тож з точки зору читабельності краще розв’язати базу даних розширень.