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

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

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

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

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

Спасибо

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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