Кэширование - очень большая база

#php #кэширование #mysql

Гугл выдает результат по одному из разделов сайта -
14 600 000.
База данных MySQL кряхтит, запрос выполняет от 5 до 30 сек.
Сделал кэширование с сохранением кэшированных файлов в папку,
причем для поисков один кэш, для юзеров - совсем другой.
Получилось:
  /cache/1.txt - это для юзеров
  /cache/1r.txt - это для поисковиков
  /cache/2.txt
  /cache/2r.txt
  /cache/3.txt
  /cache/3r.txt
  /cache/4.txt
  /cache/4r.txt
  и т.д.

Естественно вообще можно так делать то?
Со временем в папке появится 14 600 000 * 2 = 29 200 000 файлов.
Все это дело займет 2 - 3 месяца.
Файл занимает 17 кб в среднем.
Отсюда считаем.
17 * 14 600 000 = 248 200 000 кб / 1024 = 242 383 мб / 1024 = 237 гб * 2 = 474 гб
Получается, что в папке будет лежать 474 гб файлов, общее количество которых будет
составлять 29 200 000 файлов.
Не загнется все это дело?
Что посоветуете?
И не забывайте - это всего один раздел сайта, а таких несколько.
С кэшированием страницы загружаются мгновенно.    

Ответы

Ответ 1

Файловый кэш, как вы описали, можно разнести по (бинарному?) дереву подпапок. 14600000
это 23 бита. Например, вариант раскидать по папкам соотв. старшим N битам: cache/1/0/0/1/0/1/0/1/65535.txt
БД кряхтит, выполняя один запрос, без других параллельно? Пересмотрите запросы и
индексы в таблицах — возможно, только с помощью этой меры удастся сделать, чтобы запросы
летали. 14 600 000 страниц это не так много.
Часты ли повторяющиеся 1:1 запросы/ответы? Статистика запросов - ровное горизонтальное
поле или "колокол"? Кэширование имеет смысл если повторов много.
Может, пора расти: поднимать кластер, или хотя бы еще один сервер с MySQL? Сделать
его slave'ом, на котором работает копия бд и обрабатывает ровно половину всех запросов.
У них может быть общий кэш, напр. на memcached - доступный для всех серверов, чтобы
часто повторяющиеся запросы не грузили БД.

Upd. 
 5. Роботов можно попридержать, настроив robots.txt - например, пусть заходят не
чаще раза в неделю.
Для понимания того, как в данном случае оптимизировать сайт, надо подробно видеть,
что именно там происходит. Как устроена база, какие запросы, персонифицированы ли страницы
под посетителей. 
Инуитивно подозреваю, что длинные запросы вызваны банальным отсутствием нужных индексов
в БД. Если же БД уже никак не оптимизировать индексами и изменением запросов, а дышит
она тяжело именно от обилия данных, можно разнести разросшиеся таблицы по партициям
. Напр. строки с индексом от 1 по N хранятся на одном сервере, от N+1 по M — на другом.
Ещё варианты для размышления:

страничный кэш типа Varnish;
nginx proxy, установив разумный срок дискового кэширования страниц.