Зачем использовать MySQL поверх плоских файлов?
Мы с другом спорили о том, должен ли он использовать MySQL или базу данных плоских файлов для бэкэнда своего сайта. Я сказал ему пойти с MySQL, потому что он был структурирован, хорошо держал записи и был последовательным. Он, с другой стороны, сказал, что скорее пойдет на скорость. Чтение файлов намного быстрее, чем подключение к MySQL, и это заставляет меня задуматься, был ли он прав. Например, почему бы просто не создать папку для каждой таблицы, например так: users/groups/posts/внутри папок есть файлы с именами по ID (1, 2, 3), а затем для данных используйте такой формат: username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: example@example.com?
Другими словами, каковы преимущества MySQL перед плоскими файлами?
9 ответов
Другими словами, каковы преимущества MySQL перед плоскими файлами?
MySQL предлагает индексы и объединения (для производительности выполнения), транзакции (для целостности данных) и SQL (для разработки производительности).
Если ваш проект включает в себя только 3-линейный самодостаточный текстовый файл, вам не нужно MySQL,
Чтение файлов намного быстрее, чем подключение к MySQL, и это заставляет меня задуматься, был ли он прав.
Hobcobbles. База данных, подобная mySQL, также хранит свои данные в файлах, но имеет множество оптимизаций, наиболее очевидно, их возможности индексации, что позволяет значительно увеличить производительность по сравнению с чтением (или записью) большого плоского файла.
Плоские файлы могут быть быстрее в некоторых очень ограниченных случаях, но ядро базы данных использует опыт поколений разработчиков, работающих над тем, чтобы сделать доступ к данным более быстрым и надежным. Просто подумайте об условиях гонки и блокировке, когда два экземпляра вашего скрипта пытаются, например, записать данные в базу данных.
Если объем используемых данных превышает несколько строк в CSV-файле - или им не удается легко управлять в таких файлах, как, например, страницы вики - используйте базу данных. Это добавляет слой усложнения, но избавляет вас от головной боли.
Просто подумай о SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10" на плоский файл быстро и что нужно написать с нуля, чтобы достичь этого.
Что такое "база данных плоских файлов"? Плоский файл - это плоский файл - назовите его так. Если вы говорите, что это база данных с плоскими файлами, вы думаете, что она волшебным образом обладает некоторыми функциями базы данных, которых у плоских файлов по определению нет.
Каковы преимущества MySQL над плоскими файлами?
Пропустите MySQL здесь - основной вопрос, который вы задаете: "зачем вообще использовать базу данных".
Я предлагаю вам взглянуть на производительность (операции sewarch - у индексов есть причина) и поискать термин "условия ACID", чтобы получить хотя бы смутное представление о том, что на самом деле делает база данных.
Плоские файлы не дают вам никакой гарантии, и десятилетия разработчиков доказывали все проблемы, которые у них возникали, снова и снова.
Просто пример: рассмотрим, что у вас есть 1 000 000 клиентов с адресной информацией, и вам нужно искать и набор клиентов, которые живут в Нью-Йорке. Если вы храните каждого клиента в отдельном файле, вам нужно будет прочитать все 1 000 000 файлов и посмотреть, принадлежит ли клиент государству. Если вы храните все записи в одном огромном файле - вам нужно будет прочитать весь файл и выполнить итерацию, чтобы найти всех клиентов из Нью-Йорка.
В обоих случаях вы проиграли.
В случае СУБД, подобной MySql - вы бы использовали так называемую операцию "set" или оператор SELECT, с добавлением индексов, механизм, вероятно, считывал бы только на 10/20% больше данных, чем необходимо для поиска всех клиентов из Нью-Йорка.
Надеюсь это поможет
Нам нужно немного больше контекста.
Если ваш друг читает полные страницы (хранит рекламные "капли" в БД), тогда да, использование MySql не сильно поможет. Если у него есть детальные данные (включая, я не знаю, сообщения в блогах, новостные элементы, изображения с метаданными, детали заказа), то, если сайт не очень скудный и очень статичный, подход на основе файлов скоро станет слишком ограниченным.
У предложенного вами решения есть два больших недостатка:
Использование папок / имен файлов аналогично наличию только одного индекса в каждой таблице (в данном случае, имени файла), поэтому поиск любых других критериев займет много времени. Не говоря уже о том факте, что наличие большого количества файлов в одном каталоге начнет облагать налогом ОС.
Кроме того, защита по имени файла представляет собой небольшую угрозу безопасности, даже если вы используете хешированный pwd как часть URL.
В прошлом я делал несколько приложений среднего размера на файловой системе (из-за неадекватных требований мы не могли использовать БД), и это забавно, но на самом деле очень ограниченно, когда вы просматриваете несколько сотен файлов. И даже с небольшими цифрами, вы должны начинать использовать трюки с самого начала, чтобы иметь хоть какую-то надежду на продолжение работы.
Существует также вопрос безопасности. Если вы не защитите плоские файлы должным образом, их будет гораздо легче обнаружить. Особенно, если вы храните информацию о пользователях, нет препятствий для доступа к плоским файлам.
Предполагая, что ваш веб-сайт или приложение растут вертикально, плоские файлы также не масштабируются, потому что чем больше плоские файлы, тем дольше они читают.
И, наконец, использование плоских файлов, когда базы данных уже настолько просты, - просто хак. Это не делает "правильный путь" в том, что КАЖДЫЙ ЕЩЕ использует базы данных, поэтому я бы сказал, наоборот: зачем использовать плоские файлы поверх MySQL? Придет ли кто-то еще, чтобы поддержать ваше заявление после того, как тот поймет или согласится с вашим решением использовать плоские файлы?
Избыточность данных и отсутствие атомарности являются большими проблемами в базах данных плоских файлов, которые проявляются в геометрической прогрессии, чем больше данных требуется для хранения, и вносят задержку в запросы и другие проблемы, такие как аномалии обновления / удаления / вставки.
Реляционная модель данных с нормализацией помогает устранить эти проблемы, обеспечивая атомарность и уникальность каждой записи (первая нормальная форма), то, что каждое поле в таблице функционально зависит от первичного ключа (вторая нормальная форма) и что ключевые поля не разделяют транзитивные зависимости от других полей в таблице (третья нормальная форма).
Модель реляционных данных ни в коем случае не является единственным способом сделать это, возможно, даже не лучшим, но она, безусловно, пытается решить проблемы задержки запросов и аномалий, присущих плоским файлам.
Mysql имеет некоторые преимущества по сравнению с flatfile, файловая структура плоха для запросов, но CRUD в файле быстрее, чем mysql, вы можете использовать базы данных no-sql, такие как mongo db, чтобы иметь лучшую структуру и большую скорость, есть некоторая разница между sql и Базы данных no-sql, но я думаю, что лучше использовать no-sql db вместо flatfile, также имейте в виду, что если вы работаете с большими данными, no-sql db наверняка лучше, чем sql..
Кроме того, не сохраняя всю информацию пользователя внутри Posts/ папка, как вы получаете все сообщения, написанные Джоном Доу (например)? В SQL это просто объединенный оператор выбора. Для плоских файлов вы должны либо хранить информацию внутри фактического файла постов, либо написать код для самостоятельного выполнения операций объединения и поиска.