Если твой чат подразумевает работу в режиме:
1. Грузим статику.
2. Обновляем окно с сообщениями по принципу стека.
То от файлового кеша толку мало, количество попаданий в кеш будет минимально, т.е данные из кеша будут браться только в том случае если пользователь грузит страницу с чатом с нуля. Такие ситуации редкие, либо возникают во время злонамеренных запросов, чтобы сломать чат
Если твой чат обновляется по принципу:
1. Грузим страницу с нуля.
2. Обновляем страницу, новые сообщения обновляются (принцип форума)
То в данном случае файловый кеш имеет место быть, но не при 9000 каналов, где идет обширный флуд каждую секунду.
Есть еще гибридный режим.
1. Грузим страницу с нуля.
2. Обновляем страницу, новые сообщения обновляются (принцип форума)
3. Если пользователь не обновляет страницу, делаем это сами через ajax, но в данном случае обновляем только сам чат. В файле кешируем готовый json с сообщениями.
Вопрос в другом зачем вообще использовать базу данных? Только если нужно логи вести или еще что-то делать в дальнейшем.
Самый быстрый метод с большим количеством коннектов это первый, только на сокетах а не ajax, тут уже событийная модель может работать, а значит меньше трафика и использование проца, хотя чат проц почти не использует, но если 90к коннектов через прослойку апача будут стучать в итерации php скриптов, то проц нагрузят и памяти отожрут нормуль, а так можно держать 1 инстанс и удобно управлять потоками инфы в пределах 1 процесса.
Так, что нужно определиться какой тип чата будет, делать 9000 комнат с кешем на файлах микроскопических не выгодно, а вот если комнат немного например 10 то вполне прокатит. субд для чата не вижу особого смысла делать, ну если только хранить информацию о юзерах, а вот месаджи там держать и дергать их от туда как по мне не рационально, если только не нужно эти сообщения еще гдето обрабатывать или использовать, например транслировать чат на 5 сайтах на разных серваках, но опять таки можно кешем обойтись