Зачем использовать MySQL поверх плоских файлов?

Question

Мы с другом спорили о том, должен ли он использовать MySQL или базу данных плоских файлов для серверной части своего веб-сайта. Я сказал ему пойти с MySQL, потому что он был структурирован, хорошо держал записи и был последовательным. Он, с другой стороны, сказал, что скорее пойдет на скорость. Чтение файлов намного быстрее, чем подключение к MySQL, и это заставляет меня задуматься, был ли он прав. Например, почему бы просто не создать папку для каждой таблицы, например так: users/ groups/ posts/, в папках есть файлы с именами по идентификатору (1, 2, 3), а затем для данных используйте такой формат: username: John\npassword: e2fc714c4727ee9395f324cd2e7f331f\nemail: example@example.com?

Другими словами, каковы преимущества MySQL перед плоскими файлами?

Answer 1

Другими словами, каковы преимущества MySQL перед плоскими файлами?

MySQL предлагает индексы и объединения (для производительности выполнения), транзакции (для целостности данных) и SQL (для производительности разработки).

Если ваш проект содержит 3 -строчный самодостаточный текстовый файл, вам не нужно MySQL.

Answer 2

Чтение файлов намного быстрее, чем подключение к MySQL, и это заставило меня задуматься, был ли он прав.

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

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

Если объем используемых данных превышает несколько строк в CSV-файле или если им не удается легко управлять в таких файлах, как, например, страницы вики-сайта, - используйте базу данных. Это добавляет слой усложнения, но избавляет вас от головной боли.

Просто подумайте о том, чтобы SELECT * FROM posts WHERE MONTH(post_date) = "2010-03-10" быстро создать простой файл быстро и что необходимо написать с нуля, чтобы достичь этого.

Answer 3

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

Какие преимущества MySQL перед flatfiles

Пропустите MySQL здесь - главный вопрос, который вы задаете: «зачем вообще использовать базу данных».

Я предлагаю вам взглянуть на производительность (операции sewarch - у индексов есть причина) и поискать термин «условия ACID», чтобы получить хотя бы смутное представление о том, что на самом деле делает база данных.

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

Answer 4

Нам нужно немного больше контекста.

Если ваш друг читает полные страницы (хранит рекламные «капли» в БД), тогда да, использование MySql не сильно поможет. Если у него есть детальные данные (включая, я не знаю, сообщения в блогах, новостные элементы, изображения с метаданными, детали заказа), то, если сайт не очень скудный и очень статичный, подход на основе файлов скоро станет слишком ограниченным.

У предложенного вами решения есть два больших недостатка:

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

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

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

Answer 5

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

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

И, наконец, использование плоских файлов, когда базы данных уже настолько просты, - это просто взлом. Это не делает "правильный путь" в том, что КАЖДЫЙ ЕЩЕ использует базы данных, поэтому я бы сказал, наоборот: зачем использовать плоские файлы поверх MySQL? Кто-то еще придет, чтобы поддержать ваше заявление после того, как тот поймет или согласится с вашим решением использовать плоские файлы?

Answer 6

Mysql имеет некоторые преимущества по сравнению с flatfile, структура файла плоха для запроса, но CRUD в файле быстрее, чем mysql, вы можете использовать базы данных no-sql, такие как mongo db, чтобы иметь лучшую структуру и большую скорость, Есть некоторые различия между базами данных sql и no-sql, но я думаю, что лучше использовать no-sql db вместо flatfile, также следует помнить, что если вы работаете с bigdata, no-sql db наверняка лучше, чем sql ..

Answer 7

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

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

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

Answer 8

Просто пример: рассмотрим, что у вас есть 1 000 000 клиентов с адресной информацией, и вам нужно искать и набор клиентов, которые живут в Нью-Йорке.Если вы храните каждого клиента в отдельном файле, вам нужно будет прочитать все 1 000 000 файлов и посмотреть, принадлежит ли клиент государству.Если вы храните все записи в одном огромном файле - вам нужно будет прочитать весь файл и выполнить итерацию, чтобы найти всех клиентов из Нью-Йорка.

В обоих случаях вы проиграли.

В случае СУБД, такой как MySql- вы бы использовали так называемую операцию «set» или оператор SELECT, с добавлением индексов механизм, вероятно, будет считывать только на 10/20% больше данных, чем необходимо, чтобы найти всех клиентов из Нью-Йорка.

Надеюсь, это поможет

Answer 9

Кроме того, не храня всю информацию пользователя в папке Posts/, как вы получаете все сообщения, написанные Джоном Доу (например)? В SQL это просто объединенный оператор выбора. Для плоских файлов вы должны либо хранить информацию внутри фактического файла записи, либо написать код для самостоятельного выполнения операций объединения и поиска.