Philipp

Аналогично

Вы неправильно рассматриваете систему чатов.
В чатах есть комнаты, внутри комнат сообщения и участники.
Тет-а-тет это приватная комната с 2-ми участникам.

room 
- id
- name
- private

participant (участник чата)
- id
- name

roster (список участников чата)
- room_id
- participant_id

history (история сообщений)
- id
- room_id
- participant_id
- timestamp
- type (тип сообщения, иногда нужны системные сообщения от ботов)
- text
- deleted

А теперь вперед - учить JOIN'ы!

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

Используйте stream_get_line или fgets для построчного чтения. В мануале к fgets есть хороший пример.

Если файл структурированный (например CSV), то можно использовать LOAD DATA INFILE dev.mysql.com/doc/refman/5.7/en/load-data.html

dev.mysql.com/doc/refman/5.7/en/memory-storage-eng...

BlueGroup должен быть массивом:

{
"Key" : $key,
"BlueGroup" : [
     {
        "1469132000" : {
            "X" : 1.2,
            "Y" : 3.3,
            "Z" : 2.1
        }
     }
],
"ManyGroups" : { * }
}

Называется DHT Protocol.
Начинайте отсюда www.bittorrent.org/beps/bep_0005.html

В мире программирования - это синонимы.

В жизни Request подразумевает формализованный запрос, например официальный запрос информации о каком-то предмете, который подразумевает заполнение некоторой формы (формуляра).

Query - это просто вопрос.

Например, вы приходите в банк, вам нужно открыть кредит. Когда вы спрашиваете, в какое окошко вам обратиться, это query, когда заполняете форму это fill in application, когда отправляете форму на рассмотрение - это и есть request.

https://github.com/Ninjakannon/Cloudgen.js + jsfiddle.net/qfEUt

На мой взгляд здесь Laravel пришит сбоку с припеку. Node.js умеет работать с MySQL.
Я бы подобный сервис реализовал следующим образом:
Node.js в качестве основного сервера с API и траспортом данных через Socket.io.
Redis в качестве шины сообщений между инстансами Node.js сервера.
Веб-сокеты позволяют обмен данными и пересылку файлов. Ajax в целом вам тут и не нужен.

IMHO, отправка сообщения должна выглядеть следующим образом:
Node.js принимает сообщение из сокетов, выдает идентификатор сообщению и далее передает его по шине сообщений (Redis). На шине несколько слушателей, один из которых отвечает за сохранение данных в базе, а другие рассылают сообщения клиентам.

Заявка в друзья выглядит следующим образом:
Node.js принимает сообщение из веб-сокетов, сохраняет в базу, отправляет запрос по шине сообщений получателю.

При загрузке приложения, клиент соединяется с сервером через веб-сокеты, далее регистрируется на шине сообщений.

Хочу добавить пару моментов, которые нужно учитывать при разработке приложения.
1. У вас может быть запущено несколько инстансов приложения как на одном сервере, так и на разных.
2. Нужно контролировать момент, когда система пытается переотправить сообщение в случае потери соединения с инстансом - часто случается при ненадежном соединении с сетью, особенно в мобильных сетях.