Будь у меня основная БД монга (а это так и есть), я бы использовал монгу. Я бы не делал лог общения в одной записи - делал бы каждый месседж отдельной записью (как собственно и делаю). Я бы уж точно не трогал бы _id - можно добавить к полю login уникальный индекс, или вязать пользователей по _id прям (как я и сделал). И я бы сделал очередь, в которую бы буферизировал ввод (потому что очередь тупо быстрее работает, чем мускуль или монга), c тем, чтобы улучшить отзывчивость приложения (ведь для чата эта запись вовсе не нужна, лучше делать ее асинхронно, возможно даже - вообще на другом сервере).
Тем, что вы написали ранее, что основная база у вас MySQL, а к монге вы явно не c той стороны подходите. Лягнет. Лучше использовать привычные интерфейсы. Прям сейчас я помогаю одному студенту проектировать курсовик про масс-чат. И так выходит, что БД нужна по сути только для хранения логов. Вы напишите сначала чат, а потом уж допишете хранение логов, это будет правильным решением. И тогда, поверьте, вам будет совершенно по барабану, в какой БД хранить эти логи. И даже больше скажу - монга не покажется вам наилучшей БД для этого.
Равносильно "написать c нуля, используя некоторые вызовы битрикса". Учитывая стоимость разработки и сопровождения проекта, лучше от данной мысли отказаться и делать на чем-то посовершеннее.
Лонг поллинг это не websocket - принимается один месседж и отсоединяется. Нужно заворачивать присоединение сразу после приема месседжа. Так работает. Могли бы догадаться по "клинической картине" самостоятельно.
Очередь не должна переполняться. Очередь - это труба.
C одной стороны туда наливают фронтальные сервера. Делают они это очень быстро (потому что очередь - быстрая штука, в принципе). Тут можно и про ноду подумать, чтобы соединение к очереди было поднято постоянно.
С другой стороны вычерпывают из этой трубы данные скрипты, которые работают в фоне. Их тоже может быть много (очередь гарантирует атомарность, то есть, что два скрипта не получат один и тот же пакет). Эти скрипты делают следующее: вытаскивают из очереди пакеты данных и формируют запрос к БД на вставку. Например, если делать вставку миллиона строк по одной, БД будет такую вставку обрабатывать существенно дольше, чем если делать ее одним махом (формировать один инсерт для всего миллиона записей и сразу отправлять в БД). Плюс, так же соединение c БД у этих скриптов будет постоянное.
При таком подходе вам будет просто масштабировать решение в любой пропорции. Стали подтормаживать фронты - добавили еще фронтов. Стала тормозить очередь - добавили еще один сервер очереди. Стала тормозить БД - добавили сервер в кластер БД (тут конечно монга сделает sql по простоте кластеризации).
Плюс, чтобы не тормозило формирование запросов, надо озаботиться каким-то префетчем данных в фоне. То есть, помимо сырых данных, собранных из очереди, хранить так же некие дополнительно обработанные данные, собранные как надо. Но тут уже я вам точно подсказать не смогу, не зная всех подробностей структуры отчетов.
Это вопрос кеширования, можно держать все ehks в БД и при запросе сохранять в файл c массивом, если его нет. В БД проще управлять, проще приделать к этому админку.
Ну, гит справится c этим, если все сделать, как я написал.
Главное, при переключении веток вам надо делать коммит. Не забывайте об этом, и все будет отлично. Но, да, если файлы бинарные, разрастаться это будет изрядно при каждом коммите, ибо фактически при этом делается копия измененного файла.
Под каждый год СРАЗУ делаете ветку, в начале года, из empty. И работаете там.
Можно конечно и в master вести текущий год, но лучше не надо.
И да, перед переключением в другую ветку всегда надо сделать коммит, чтобы файлы, которые не в репе, не побили файлы в другой ветке.
Вы совсем немного рассказали, что вам конкретно надо, но есть ощущение, что гит действительно не очень подходит для этого.