Как эффективно хранить canvas попискельно в БД с последующим отображением?

Question

[hesy]

Стек: PHP (Laravel), JS, MySQL, Nginx, Websockets.



Есть canvas размером 2000х1000 (~2 млн. пикселей суммарно).
На этом полотне в реалтайме рисуют N подключенных клиентов по веб-сокетам.
Данные о пикселях лежат в MySQL.

Таблица

Schema::create('pixels', function (Blueprint $table) {
    $table->id();
    $table->unsignedBigInteger('user_id')->nullable();
    $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
    $table->smallInteger('x');
    $table->smallInteger('y');
    $table->string('color', 18);
    $table->timestamps();
    $table->index('id');
});

При каждом клике на стороне клиента, информация записывается в таблицу и разносится по подключенным клиентам.

Вопрос: как при открытии сайта, быстрее и эффективнее всего отобразить полотно со всеми пикселями из БД?

Как сейчас реализовано

Загрузка по чанкам: при открытии сайта делает N ajax запросов к апи, который возвращает чанк с пикселями. Использовал вариант с offset-limit, с where id > N and where id < N, эффект одинаковый.
Еще проблема в том, что запросы занимают большое кол-во времени, при этом блокируя другие открытые вкладки которые ждут пока завершатся предыдущие запросы с других вкладок (nginx php-fpm, очевидно завершать запросы, чтобы принять следующие плохая идея, т. к. нагрузка на сервер в эти моменты и так растет, а ожидаемое кол-во одновременно подключенных клиентов десятки тысяч (*в моих влажных мечтах)).

Вообще, идея с подобным подходом мне вообще не нравится, и я понимаю что это неправильно.
Может у вас есть идеи как подобное можно реализовать? И годится ли MySQL для таких целей?

Comments

[Сергей Сергей]

Image/png пусть курсирует. Отдельный мазок - отдельное png-изображение, или цельная мазня от каждого клиента.

[smilingcheater]

с реддита r/place идею взяли?

[hesy]

smilingcheater, давно в голове была, только опыта не хватало реализовать, но видимо его и до сих пор не хватает) а так да, после этого эвента решил опять попробовать

[Михаил Братеньков]

Не легче хранить канвас в png? Графические форматы явно лучше адаптированы для хранения изображений чем реляционные базы. А саму базу использовать только для хранения истории.

Answer 1

[FanatPHP]

Ну как минимум за $table->string('color', 18); надо руки сразу отрывать
То есть на координатах наэкономили, 4 байта в сумме, а потом хоба - в 4 раза больше на несчастный цвет. при том что цветов там явно не больше десятка. И это не говоря уже про нормализацию.

По уму надо придумать простой бинарный протокол, который получает поток байт выравненными кусками
2 байта х
2 байта у
1 байт цвет
4 байта юзер (и нечего жадничать, никаких BigInteger. половины населения земного шара вполне хватит)
то есть всего 9 байт.
а не под сотню, как сейчас - ещё и завернутое в скобочки/кавычечки джейсона

Если подумать, то можно юзера сразу не передавать. Всех юзеров никто смотреть не будет, а при наведении можно и отдельный запрос послать. Тогда можно и BigInteger оставить.
Получится всего 5 байт на пиксель, то есть 10 метров на всю карту. Дофига, но подъемно.

По пагинации это дурь какая-то. Зачем "офсет-лимиты" если уже есть четкая разбивка.
Кто мешает запрашивать тупо построчно? Скажем, по 100 строк картинки? 10 запросов по мегабайту.
id в этой таблице по сути вообще не нужно, только если лара без него не сможет. Но по уму первичный ключ - это ху.

Из БД получать 2 лимона строк конечно тоже не сахар
Но можно наверное увеличить строки, хотя бы виртуально.
Вью или процедура, которая комбинирует скажем сто строк в одну

Насчет других хранилищ я не уверен. Там же наверняка нужна будет выборка обновлений, по таймстампу.
Но в целом с Редисом поэкспериментировать можно.

Comments

[hesy]

Благодарю за пищу для размышления, а то вогнал себя в рамки и не могу вылезти из них

Answer 2

[Роман]

Я сделал бы несколько иначе, сохранял в бд примерное следующее:

1. кто, когда и как рисовал
userID - идентификатор пользователя
timeStamp - временная метка
point - координата мышки

2. информация о смене инструмента рисования (кисточки) и настроек инструмента
userID - идентификатор пользователя
timeStamp - временная метка
toolType - тип инструмента (кисточки)
toolSettings - JSON строка с параметрами инструмента(цвет, размер и т.д.) (у разных кисточек могут быть свои, уникальные наборы параметров, поэтому систематизировать не выйдет, и поэтому JSON строка)

Имея такие записи в 2-х таблицах получим:
- в большинстве случаев гораздо меньший объем сохраняемой информации
- возможность undo как для своих действий, так и для действий других пользователей
- возможность в последствии отобразить не только результат совместного творчества, но и сам процесс
- возможность отключать на холсте с результатом как художества отдельных пользователей так и результат применения отдельных инструментов

ЗЫ: от себя добавлю, что для этой задачи в том виде как ее описал я больше подойдут noSQL базы, в которых можно будет обойтись одной коллекцией и несколькими типами записей:

1. запись о смене инструмента

{"action": "changeTool",  userID: "xxxxxxx",  timeStamp: 0000000000000, toolType:"pen"}

2. запись об изменении параметров инструмента

{"action": "changeToolSettings",  userID: "xxxxxxx",  timeStamp: 0000000000000, setings: {
    тут у каждого инструмента что-то свое, общими наверно будут только цвет и размер
}}

3. запись об пути мазюкания инструментом

{"action": "path",  userID: "xxxxxxx", path:[
    {timeStamp: 0000000000000, "x": 0, "y": 0},
    {timeStamp: 0000000000000, "x": 0, "y": 0},
    {timeStamp: 0000000000000, "x": 0, "y": 0},
    {timeStamp: 0000000000000, "x": 0, "y": 0},
    ....
]}

Comments

[hesy]

Единственное я не уточнил (виноват) - это пиксельная рисовалка, там нет инструментов, есть только пиксель и его цвет, но полезное из ответа почерпнул, спасибо)

[FanatPHP]

там нет инструментов и нет undo. by design
но за то есть тыщи хомячков одновременно.

по сути этот ответ рассказывает, как утяжелить систему, а не как её облегчить

если непонятно, о чем речь, то рекомендую погуглить /r/place

[FanatPHP]

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

[Роман]

FanatPHP, ну хоть бы задумался на секунду? Вечно суешь свой нос не разобравшись.

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

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

[FanatPHP]

повторюсь
если непонятно, о чем речь, то рекомендую погуглить /r/place

автору конечно надо было самому это объяснить, что к "средним многопользовательским рисовалкам" его задача вообще никакого отношения не имеет.

Но после того как я ткнул носом, надо было пойти и погуглить, а не выступать с пламенными речами.

[Роман]

FanatPHP, ну вот опять. Просто ответь на 2 вопроса:

1. с чего ты взял, что я не знаю про /r/place?

spoiler

да, не на слуху, потому что меня никак не касается, но после комента автора все встало на свои места, даже плюсик ему воткнул

2. почему ты решил, что без твоих несомненно "ценных" комментариев мы сами не разберемся в чем нестыковка моего ответа и его вопроса?

Писать мне ответы на эти вопросы не нужно, просто сам себе ответь.

[FanatPHP]

потому что /r/place не имеет никакого отношения к
"в среднем, в многопользовательских рисовалках ну от силы 2-10 активных (рисующих) клиента, и сохраненные данные о выборе кистей"

[Роман]

FanatPHP, ну вот именно то о чем я и говорил, дочитывать до конца мы не умеем:

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

[FanatPHP]

если что, в 2017 году в /r/place рисовали больше миллиона пользователей
в 2022 - больше 6 миллионов

это конечно не отличается от вашей оценки "2-10 активных (рисующих) клиента" :)

в общем "не выиграл, а проиграл, и не в лотерею, а в очко, и не машину, а сто рублей. а в остальном всё верно" )))

[Роман]

FanatPHP, упертый , да? Никогда не признаешь свою ошибку? Ну да ладно, мне проще считать тебя глупым, потому процитирую еще раз:

Речь в моем ответе шла о том, что в среднем, в многопользовательских рисовалках ну от силы 2-10 активных

...

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

И переведу для альтернативно одаренных:

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

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

- Специально для альтернативно одаренных фанатов Ovis-ов в приписке в первому комменту уточнил - "мой вариант действительно неприемлем". Но оказалось что для дитя ОГЕ, ЭГЕ и тестов важен формализм, который видимо помножился на детские психологические травмы и вылился в желание везде совать свой нос и нести никому не нужное знамя "правды". Что же, несите, только ко мне свое знамя не суйте, хорошо?

Answer 3

[mayton2019]

Для оптимизации загрузки landing page, можно хранить копии этой картинки в уменьшенном виде. 2000х1000 => 1000x500 => 500x250 e.t.c. Так игроделы делают для быстрого рендеринга текстур. Mip-уровни кажется называется.
Обновлять эти mip уровни можно не спеша. Через минутку.

База mysql вам вобщем-то не нужна. Картинку можно в реальном времени править atomic операциями и хранить в raw формате. Не знаю делают ли такое на PHP. Возможно вам нужен рукастый програмист на C++ или еще на каком-то языке чтобы подружить PHP с С++ и сделать сервис для этой картинки.