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

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

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

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

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


person user103219    schedule 11.05.2009    source источник


Ответы (4)


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

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

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

person James Socol    schedule 11.05.2009

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

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

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

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

person Stringent Software    schedule 11.05.2009
comment
Еще одна вещь, которую базы данных предлагают, чего нет у плоских файлов, — это контроль параллелизма. В контексте интенсивной записи многие процессы, записывающие в один плоский файл, могут быть проблематичными. Хорошим компромиссом между пользовательскими плоскими файлами и полноценной СУБД является SQLite — существует более чем несколько сайтов, поддерживаемых SQLite. - person Frank Farmer; 11.05.2009

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

person Daniel Brückner    schedule 11.05.2009

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

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

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

person Csaba Kétszeri    schedule 11.05.2009