Это не максимально эффективное решение, при том, что в структуре есть данные, которые нужно разделить - их правильнее разделять построчно, если уж их пишете все в один файл и читать так же построчно. Построчное чтение легче, проще, может быть завершено по результату найденного вхождения и не потребует постоянной загрузки всего файла в память с последующим циклом проверки этих данных.
А вообще, про реальную практику на проде я уже написал, поскольку сам уже несколько лет сижу на самописах на файлах, не используя БД в принципе. Понятно, что в БД есть неоспоримые плюсы на соответствующих задачах, но на тех, которые описаны и поднимаются в этой теме - можно легко, безопасно и эффективно обходиться только файлами.
Ps: я уж не говорю о том, что часть задач по работе с данными в файлах можно выполнять более эффективными grep, sed, awk и т.д. и возвращать результат в оболочку сайта.
Я например могу накидать вам кучу трудностей, которые вы даже не отследите. Например, у вас будет бэкапится файл с ошибкой и вы даже не будете понимать что не так: просто он будет исключен их поиска, соответственно результат не нарантирован. А найти ошибку - ну я даже не представляю навскидку как. При правильной организации БД это будет исключено. Роллбэк неправильно транзакции нарантирует что у вас БД будет D- устойчивой. Опять же правильно нстроенный бэкап позволяет хранить кучу версий базы на промежуток времени.
Вы накидали в одну корзину совершенно разные ситуации без особого понимания этих ситуаций. Какое отношение роллбэк имеет к статично размещенному в директории файлу? Почему вдруг при бэкапе может быть ошибка и ее не может быть в базе данных? Не говоря уже о том, что база данных - это те же файлы на диске. Более того, если какой-то файл изменился в процессе создания бэкапа - об этом будет уведомление. Если он по какой-то причине не сохранился - так же.
Ничего не может быть исключено, вообще. Организация правильности БД никаким образом не влияет на отказоустойчивость базы, файлов на сервере и, тем более, на возможное физическое повреждение сервера.
Остальное все вы настолько гипотетически обсуждаете, что даже нет смысла пытаться ответить на ваш вопрос "найти ошибку - ну я даже не представляю навскидку как", по той простой причине, что этих ошибок нет по факту. А все остальное решается правильной структурой, правильной проверкой целостности, правильным резервным копированием и надежностью самого сервера. Но сама логика, что БД надежна, а файлы нет - не выдерживает никакой критики, поскольку БД - это те же файлы, а сколько раз крашились эти самые базы данных на серверах на любых сайтах - считать не пересчитать )
В общем, последний ваш комментарий - это вообще обо всем сразу и ни о чем конкретном и никакого отношения к обсуждаемой теме не имеет.
Про миллион не знаю, но есть у меня один "странный" проект, где файлов больше 400 000 (ну так исторически сложилось), сервер с ним бэкапится примерно за то же время, что и соседний, где файлов в 100 раз меньше, файл бэкапа не раздут.
Высказывались опасения - как себя будет вести файловая система с миллионом файлов, насколько легко это все будет забэкапить. Поделитесь опытом.
На счет миллиона файлов не подскажу, такого объема не было, было в несколько сотен тысяч, где-то до полумиллиона. Причем, по глупости, я в первый раз запулил почти сотню тысяч файлов в один каталог. Этот сайт до сих пор прекрасно себя чувствует и работает без проблем с высокой скоростью. Тут весь смысл в том, что при такой постановке задачи сайту и серверу не требуется делать списки каталога, он обращается напрямую к уже указанному пути файла, т.е. не тратит какие-либо иные ресурсы кроме конкретной задачи чтения данного файла или, если нужно просто проверить наличие файла - то это еще проще и быстрее.
Т.е., если нет задачи найти искомый id в папке, а уже зная этот id проверить его наличие - это быстро. Если же в задаче, по какой-то причине, нужно делать листинг каталога и потом искать подходящие файлы - вот это будет ооооочень медленно на больших объемах файлов.
Чтобы уменьшить нагрузку на поиск и построение дерева каталогов и файлов - оптимально хранить id не в одной папке, а в нескольких, например id "11112222333" хранить в папке 1/11/, а id "222333444" в папке 2/22. Тут вариантов вложений может быть сколь угодно, сильно зависит от того, какие именно id и группы повторов у них есть, чтобы выбрать оптимальный путь каталогов. Тогда и проблем с построением папок будет значительно меньше, поскольку одна папка будет содержать список не в сотни тыс файлов, а в сотни-тысячи, что позволяет работать гораздо быстрее.
С бэкапом так же проблем нет. Основная проблема тут в том, что, конечно, самих файлов много и будет значительно дольше собираться сам архив, но, кроме этого - никаких трудностей.
И такой вопросик: то, что они предлагают - реклама в самом начале, такое разрешено ютубом или за это что-нибудь может прилететь?
Так вроде до сих пор такие попадаются у топовых блогеров. Ролик начинается сразу с рекламной вставки, а уже потом сам контент. Часто приходится пролистывать, ибо эти несколько минут реклы нафиг не впились.
