Скорость доступа к файлу по сравнению со скоростью доступа к базе данных
Функция datediff() возвращает количество границ части даты между двумя датами.
Итак, datediff(year, '2018-12-31', '2020-01-01') вернет «2», потому что есть двухлетние границы.
Границы недели происходят в субботу вечером / в воскресенье утром. Есть два субботних вечера, так что вы получите две недели.
Если вы хотите приблизить приблизительное количество недель, используйте day и разделите на 7.
4 ответа
Если вы выполняете доступ с интенсивным чтением (поиск имен файлов и т. Д.), Вам может пригодиться memcached . Вы можете хранить «самые горячие» (последние созданные, недавно использованные, в зависимости от вашего приложения) данные в памяти, а затем запрашивать только БД (и, возможно, файлы), когда кеш не работает. Доступ к памяти намного быстрее, чем к базе данных или файлам.
Если вам нужен доступ с большим объемом записи, база данных - это то, что вам нужно. Если вы используете MySQL, используйте таблицы InnoDB или другой движок, поддерживающий блокировку на уровне строк. Это позволит избежать блокировки людей, пока кто-то другой пишет (или, что еще хуже, пишет).
Но в конечном итоге это зависит от данных.
Это зависит от того, как структурированы данные, сколько их и как часто они меняются.
Если у вас относительно небольшие объемы относительно статичных данных с относительно простыми отношениями - тогда плоские файлы являются правильным инструментом для этой работы.
Реляционные базы данных становятся самостоятельными, когда связи между данными становятся более сложными. Для базовых «таблиц поиска» они могут быть немного излишними.
Но, если данные постоянно меняются, тогда может быть проще просто использовать базу данных, чем управлять конфигурацией вручную - и для больших объемов data, с плоскими файлами у вас возникает дополнительная проблема: как эффективно найти тот бит, который вам нужен.
Это действительно зависит от многих факторов. Если у вас быстрая база данных с большим количеством данных, кэшированных в ОЗУ, или быстрая система RAID, шансы, что вы много выиграете от простого кэширования файловой системы на веб-сервере, малы. Также подумайте о масштабируемости. При высокой рабочей нагрузке простой механизм кэширования может легко стать узким местом, в то время как база данных хорошо спроектирована для обработки высоких рабочих нагрузок.
Если запросов не так много и вы (или операционная система) можете хранить кеш в ОЗУ, вы можете повысить производительность. Но теперь возникает вопрос, действительно ли нужно выполнять кеширование при низкой рабочей нагрузке.
С точки зрения производительности, разумнее настроить сервер базы данных и не усложнять логику доступа к данным с помощью промежуточных файловых кешей. Хороший сервер базы данных будет выполнять кеширование самостоятельно, если результаты можно кэшировать. (Я не уверен, что происходит с mysql.)
Если у вас есть проблемы с производительностью, вы должны профилировать страницы, чтобы увидеть реальные узкие места. Даже если вы, как и я, являетесь поклонником оптимизированных кодов, включение более мощного / большего количества оборудования в уравнение будет дешевле в долгосрочной перспективе.
Если вам все еще нужно использовать кеши, подумайте об использовании существующего решения, такого как memcached .