CSV против производительности MySQL - PullRequest
5 голосов
/ 18 февраля 2009

Предположим, что PHP5 работает с MySQL5 и CSV-файлами одинаково. MySQL находится на том же хосте, что и размещенные скрипты.

Будет ли MySQL всегда быстрее, чем извлекать, искать, изменять, добавлять / удалять записи в CSV?

Или есть некоторый объем данных, ниже которого производительность PHP + CSV лучше, чем при использовании сервера базы данных?

Ответы [ 7 ]

7 голосов
/ 18 февраля 2009

CSV не позволит вам создавать индексы для быстрого поиска.

Если вам всегда нужны все данные из одной таблицы (например, для application settings), CSV быстрее, в противном случае - нет.

Я даже не рассматриваю SQL queries, transactions, data manipulation или concurrent access здесь, поскольку CSV определенно не для этих вещей.

4 голосов
/ 18 февраля 2009

Нет, MySQL, вероятно, будет медленнее для вставки (добавление в CSV выполняется очень быстро) и поиска по таблице (не на основе индекса).

Обновление или удаление из CSV нетривиально - я оставляю это как упражнение для читателя.

Если вы используете CSV, вам нужно быть очень осторожным, чтобы правильно обрабатывать несколько потоков / процессов, иначе вы получите неверные данные или испортите ваш файл.

Однако есть и другие преимущества. Хотите узнать, как вы делаете ALTER TABLE на CSV?

Использование CSV - очень плохая идея, если вам когда-либо понадобятся ОБНОВЛЕНИЯ, УДАЛЕНИЯ, ALTER TABLE или для доступа к файлу сразу из нескольких процессов.

3 голосов
/ 18 февраля 2009

Как человек из индустрии данных, я имел дело именно с этой ситуацией.

Вообще говоря, MySQL будет быстрее.

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

Ответ будет зависеть от ответа на вопросы, перечисленные ранее. Тем не менее, вы можете использовать следующие рекомендации:

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

CSV, вероятно, будет быстрее для небольших наборов данных. Однако развертывание собственных подпрограмм вставки в CSV может быть болезненным, и вы теряете преимущества индексации базы данных.

Моя общая рекомендация - просто использовать MySql, как я уже говорил ранее, в большинстве случаев это будет быстрее.

1 голос
/ 19 февраля 2009

Зависит от использования. Например, для конфигурационных или языковых файлов CSV может быть лучше. В любом случае, если вы используете PHP5, у вас есть третий вариант - SQLite, который встроен в PHP. Это дает вам простоту использования, как обычные файлы, но надежность СУБД.

1 голос
/ 18 февраля 2009

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

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

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

0 голосов
/ 18 февраля 2009

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

0 голосов
/ 18 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...