Скорость доступа к файлу и скорость доступа к базе данных

Question

Сайт, который я разрабатываю на php, делает много запросов к базе данных MySQL на каждую просмотренную страницу. Хотя многие из них - небольшие запросы с правильно разработанными индексами. Я не знаю, стоит ли разрабатывать кеш-скрипт для этих страниц.

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

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

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

Answer 1

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

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

Но, в конечном итоге, это зависит от данных.

Answer 2

Это зависит от того, как структурированы данные, сколько их существует и как часто они меняются.

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

Реляционные базы данных вступают в свои права, когда соединения между данными становятся более сложными. Для базовых «справочных таблиц» они могут быть немного излишними.

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

Answer 3

Это действительно зависит от многих факторов. Если у вас есть быстрая база данных с большим объемом данных, кэшированных в ОЗУ, или быстрая система RAID, есть вероятность, что вы многое выиграете от простого кэширования файловой системы на веб-сервере. Также подумайте о масштабируемости. При высокой рабочей нагрузке простой механизм кэширования может легко стать узким местом, в то время как база данных хорошо спроектирована для обработки высоких рабочих нагрузок.
Если запросов не так много, и вы (или операционная система) можете сохранить кэш-память в ОЗУ, возможно, вы сможете повысить производительность. Но теперь возникает вопрос, действительно ли необходимо выполнять кэширование при низкой рабочей нагрузке.

Answer 4

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

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

Если вам все еще нужно использовать кэши, рассмотрите возможность использования существующего решения, такого как memcached.