CSV по сравнению с производительностью MySQL
Старайтесь избегать исторической изменчивости DSL API , поскольку она может измениться в следующем основном выпуске . Вместо этого используйте DSLContext.batchInsert(Collection) :
List list = new ArrayList<>(vars.size());
for (Var var : vars) {
VarsRecord rec = new VarsRecord();
rec.from(var);
list.add(rec);
}
create.batchInsert(list).execute();
7 ответов
CSV не позволит Вам создать индексы для быстрого поиска.
Если Вам всегда нужны все данные из единственной таблицы (как для application settings), CSV быстрее, иначе нет.
Я даже не рассматриваю SQL queries, transactions, data manipulation или concurrent access здесь, как CSV конечно, не для этих вещей.
Как человек, происходящий из промышленности данных, я имел дело с точно этой ситуацией.
Вообще говоря, MySQL будет быстрее.
Однако Вы не заявляете тип приложения, которое Вы разрабатываете. Вы разрабатываете приложение хранилищ данных, которое главным образом используется для поиска и извлечения записей? Сколько полей обычно присутствует в Ваших записях? Сколько записей обычно присутствует в Ваших файлах данных? Эти файлы имеют какие-либо реляционные свойства друг другу, т.е. у Вас есть файл клиентов и файл потребительских заказов? Сколько времени необходимо разработать систему?
Ответ будет зависеть от ответа на вопросы, перечисленные ранее. Однако можно обычно использовать следующее в качестве инструкции:
При создании приложения хранилищ данных с записями, превышающими один миллион можно хотеть считать отказ от обоих и перемещение в Столбец Ориентированной Базой данных.
CSV, вероятно, будет быстрее для меньших наборов данных. Однако прокрутка Ваших собственных стандартных программ вставки в CSV могла быть болезненной, и Вы теряете преимущества индексации базы данных.
Моя общая рекомендация состояла бы в том, чтобы просто использовать MySql, как я сказал ранее, в большинстве случаев это будет быстрее.
Нет, MySQL, вероятно, будет медленнее для вставки (добавляющий к CSV, очень быстро), и сканирование таблицы (базирующийся неиндекс) поиски.
Обновление или удаление из CSV нетривиальны - я оставляю это как осуществление для читателя.
При использовании CSV необходимо действительно стараться обработать несколько потоков / процессы правильно, иначе Вы получите неправильные данные или повредите Ваш файл.
Однако также существуют другие преимущества. Хотите разработать, как Вы делаете ALTER TABLE на CSV?
Используя CSV очень плохая идея, если Вам когда-нибудь нужны ОБНОВЛЕНИЯ, УДАЛЯЕТ, ALTER TABLE или получить доступ к файлу больше чем от одного процесса сразу.
Зависит от использования. Например, для конфигурации или файлов языка CSV мог бы добиться большего успеха. Так или иначе при использовании PHP5 у Вас есть 3-я опция - SQLite, который прибывает встроенный в PHP. Это дает Вам простоту использования как регулярные файлы, но устойчивость RDBMS.
Базы данных для того, чтобы сохранить и получить данные. Если Вам нужны что-то большее чем простое дополнение строки/записи или объемный список, почему бы не пойти для базы данных путем? Иначе необходимо было бы в основном кодировать функциональность (включая удаление, сортируя и т.д.) сами.
С точки зрения чистой производительности это полностью зависит от операции, которую Вы делаете, как говорит @MarkR. Добавление к плоскому файлу очень быстро. Как читает во всем файле (для неиндексируемого поиска или других целей).
Единственный способ знать наверняка, что будет работать лучше на Ваши варианты использования на Вашей платформе, состоит в том, чтобы сделать фактическое профилирование. Я могу гарантировать Вам, что выполнение полного сканирования таблицы на миллионе баз данных строки будет медленнее, чем grep на миллионе файлов CSV строки. Но это - вероятно, не реалистический пример Вашего использования. "Точки останова" будут варьироваться дико в зависимости от Вашего конкретного соединения, получают, индексированный поиск, неиндексированный поиск, обновление, добавляют.
Мне это не проблема производительности. Ваши данные звучат ориентированными на запись, и MySQL значительно выше (в общих чертах) к контакту с такими данными. Если Ваши варианты использования являются даже немного сложными к тому времени, когда Ваши данные становятся большими, имение дело с 100k файлом CSV строки будет ужасающим по сравнению с таблицей базы данных записи 100k, даже если производительность незначительно лучше (который ни в коем случае не гарантируется).
CSV является невероятно хрупким форматом и требует, чтобы Ваше приложение сделало все форматирование и calcuations. Если необходимо обновить определенную запись в csv, необходимо будет сначала прочитать весь файл CSV, найти, что запись в памяти должна была бы измениться, то выписать целый файл снова. Это становится очень медленным очень быстро. CSV только полезен для записи однажды, повторно добавьте однажды приложения типа.