Возвращаясь к вечному вопросу "Хранить ли картинки в базе или в файловой системе?".
Команда SQLite провела небольшое исследование, сравнив производительность работы с небольшими (8-12 Кб) блобами, размещенными в базе SQLite и в файловой системе. Результаты, конечно, варьируются в зависимости от ОС, железа и настроек SQLite, но выигрыш SQLite достигал 35%. Основная причина, по мнению авторов — накладные расходы на открытие/закрытие файлов. В случае файловой системы они имеют место при каждой операции.
Пара графиков:
Chart 1: SQLite read latency relative to direct filesystem reads.
100K blobs, avg 10KB each, random order using SQL
Chart 4: SQLite write latency relative to direct filesystem writes.
10K blobs, avg size 10KB, random order,
WAL mode with synchronous NORMAL,
exclusive of checkpoint time
Здравствуйте, wildwind, Вы писали:
W>Возвращаясь к вечному вопросу "Хранить ли картинки в базе или в файловой системе?".
W>Команда SQLite провела небольшое исследование, сравнив производительность работы с небольшими (8-12 Кб) блобами, размещенными в базе SQLite и в файловой системе. Результаты, конечно, варьируются в зависимости от ОС, железа и настроек SQLite, но выигрыш SQLite достигал 35%.Основная причина, по мнению авторов — накладные расходы на открытие/закрытие файлов. В случае файловой системы они имеют место при каждой операции.
Поэтому картинки хранят в одном большом файле, который постоянно открыт, а базе только индекс начала файла картинки и его длинна. Вроде бы яндекс так и поступает.
Программа – это мысли спрессованные в код
Re: Чтение небольших блобов из SQLite на 35% быстрее, чем из фай
Для постгреса бы кто потестил. Я когда-то делал, что картинки лежат в файле причем отдаёт их nginx, вроде как у него какой-то свой кеш ещё есть помимо стандартного файлового. Вроде быстро работало.
Re[2]: Чтение небольших блобов из SQLite на 35% быстрее, чем из фай
Здравствуйте, Qulac, Вы писали:
Q>Поэтому картинки хранят в одном большом файле, который постоянно открыт, а базе только индекс начала файла картинки и его длинна. Вроде бы яндекс так и поступает.
Ну да. Осталось только разобраться с обновлениями, фрагментацией, согласованностью с основной базой и т.п. И получится практически тот же SQLite, только слепленный на коленке.
Re[3]: Чтение небольших блобов из SQLite на 35% быстрее, чем из фай
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Qulac, Вы писали:
Q>>Поэтому картинки хранят в одном большом файле, который постоянно открыт, а базе только индекс начала файла картинки и его длинна. Вроде бы яндекс так и поступает.
W>Ну да. Осталось только разобраться с обновлениями, фрагментацией, согласованностью с основной базой и т.п. И получится практически тот же SQLite, только слепленный на коленке.
По скорости для классического HDD диска это самый быстрый способ. Если пользователь удалил данные, то обновляется только бд. Файл остается неизменным, так что с дефрагментацией проблем нет. При условии, что лишь небольшая часть данных будет удалена — это вполне приемлемое решение.
Программа – это мысли спрессованные в код
Re[4]: Чтение небольших блобов из SQLite на 35% быстрее, чем из фай
Здравствуйте, Qulac, Вы писали:
Q> W>Ну да. Осталось только разобраться с обновлениями, фрагментацией, согласованностью с основной базой и т.п. И получится практически тот же SQLite, только слепленный на коленке.
Q> По скорости для классического HDD диска это самый быстрый способ. Если пользователь удалил данные, то обновляется только бд. Файл остается неизменным, так что с дефрагментацией проблем нет. При условии, что лишь небольшая часть данных будет удалена — это вполне приемлемое решение.
Тавтология какая-то. "При условии, что неиспользованных фрагментов мало, с дефрагментацией проблем нет". Гхм, ну да.
Древнее исследование от Microsoft на эту тему: To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?
Ответ на этот вопрос зависит от среднего размера файла. Т.е. если файлы большие, то лучше их хранить как файлы. Мелкие в базе. После этого исследования в Sql Server появились файлстримы, так что можно их использовать и быть довольным
Re: Чтение небольших блобов из SQLite на 35% быстрее, чем из фай
Здравствуйте, wildwind, Вы писали:
W>... Основная причина, по мнению авторов — накладные расходы на открытие/закрытие файлов. В случае файловой системы они имеют место при каждой операции ...
Естественно база sqlite использовалась в однопользовательском и скорее всего однопоточном режиме. В то время файловая система многопользовательская и многопоточная. Странно было бы, если sqlite был медленнее.
