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

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

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

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

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

благодаря

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

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

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

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

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

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

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

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

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

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

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