Итак, есть задача реализовать чат с применением связки php+ajax. Есть несколько вопросов, даже скорее не вопросов, а желание услышать советы.

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

Отсюда вытекают следующие вопросы:

1. Допустим, реализовать в виде: каждый день создается новый файл. В него при постинге сообщения в определенном структурированном виде запишется айди юзера, оставившего сообщение, само сообщение, номер  другого юзера (в случае привата, либо 0) и, возможно какое-то техническое поле. Соот-но каждые несколько секунд аяксом будет забираться из этого файла последние несколько строк, начиная с той, на которой юзер закончил чтение (номер строки будет где-то храниться).
Насколько рентабелен такой вариант? И каким образом логичнее в техническом плане выдавать юзеру сообщения при наступлении нового для и соот-но создании нового файла с логом чата.

2. Проблема безопасности. Допустим, при логине и сверкой с базой в сессию будет добавляться id и username юзера и соот-но он и будет использоваться при чаттинге. Насколько безопасно хранить это в сессиях с точки зрения какой-либо подмены? Каким образом при бане кикать юзера из чата, ведь бан будет содержаться в базе, а каждый N секунд лишние запросы для таких проверок в базу делать не хочется.

3. Нагрузка на сам сервер. Я так понимаю что при кол-ве юзеров менее 500 нагрузка при таком варианте исполнения не будет столь значительна?

И вообще, целесообразна ли такая идея организации чата?

лучше уж для каждой комнаты

Добавлено через 58 секунд

может стоит задуматься над своим сервером?

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

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

По поводу пункта 1 - без комментариев.



Делать стандартными средствами. У вас чат, а не банк-клиент. Чем проще система, тем быстрее и стабильнее работает. Храните ID пользователя в сессии + можно туда записать определенный набор данных, что бы в базу не лазить каждый раз.



Комбинируйте варианты. Забан по куке, по ип, по логину и т.п. Я бы предусмотрел все варианты (все вместе или по отдельности).




У нас стоят сервера по 18Gb оперативки 4-х процессорные по 8 ядер в каждом. Думаю для него нагрузка в 10000 чатеров-онлайн не проблема. Такие вопросы задавать глупо. Для каждой системы, тем более под дополнительной нагрузкой, измеряют производительность в процессе эксплуатации.

Спасибо за комментарии и советы.

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

IZ@TOP, про удобство связывания данных - бесспорно база выигрывает. Проблема в том, что выбор сервера зависит далеко не от меня,   и я мало чем могу на это повлиять. Все организовано на не очень мощном ВДС. Чат-демон для меня не вариант.
 Мне просто не верится, что при одновременном онлнайне даже пусть в 100-200 человек, на базу не создастся какой-никакой нагрузки под влиянием количества запросов. Поэтому, собственно и задумался о файлах.
А про баны и тому подобное: единственный вариант, который мне пока что пришел в голову, чтобы не делать запросы в базу, так это вместе с контентом отдавать какой-либо флаг, отвечающий за бан и силами ajax'a при получении этого флага инициировать выход из чата.

Это не так уж и плохо.


Почему?


Это мизерная нагрузка. 100-200 человек онлайн генерят 100qps отсилы.

По поводу банов, данных пользователей и прочих настроек, которыми Вы, якобы, нагрузите СУБД, могу посоветовать хранение в Memcached. В принципе, при грамотном подходе к реализации, можно частично ч чат там держать.


Это уже вопрос реализации. Формируйте JSON/XML ответы, в которых будут сервисные секции. С ответом трете куки, JS-ом выдаете сообщение о бане и выкидываете из чата. Тут просто немного подумать нужно.