Ну как минимум за $table->string('color', 18); надо руки сразу отрывать
То есть на координатах наэкономили, 4 байта в сумме, а потом хоба - в 4 раза больше на несчастный цвет. при том что цветов там явно не больше десятка. И это не говоря уже про нормализацию.
По уму надо придумать простой бинарный протокол, который получает поток байт выравненными кусками
2 байта х
2 байта у
1 байт цвет
4 байта юзер (и нечего жадничать, никаких BigInteger. половины населения земного шара вполне хватит)
то есть всего 9 байт.
а не под сотню, как сейчас - ещё и завернутое в скобочки/кавычечки джейсона
Если подумать, то можно юзера сразу не передавать. Всех юзеров никто смотреть не будет, а при наведении можно и отдельный запрос послать. Тогда можно и BigInteger оставить.
Получится всего 5 байт на пиксель, то есть 10 метров на всю карту. Дофига, но подъемно.
По пагинации это дурь какая-то. Зачем "офсет-лимиты" если уже есть четкая разбивка.
Кто мешает запрашивать тупо построчно? Скажем, по 100 строк картинки? 10 запросов по мегабайту.
id в этой таблице по сути вообще не нужно, только если лара без него не сможет. Но по уму первичный ключ - это ху.
Из БД получать 2 лимона строк конечно тоже не сахар
Но можно наверное увеличить строки, хотя бы виртуально.
Вью или процедура, которая комбинирует скажем сто строк в одну
Насчет других хранилищ я не уверен. Там же наверняка нужна будет выборка обновлений, по таймстампу.
Но в целом с Редисом поэкспериментировать можно.