Павел: то есть, если таблицу не разбивать, но при первом запросе брать лишь мета-данные всех комментариев к статье для сортировки, исключив из выборки text-содержимое, скорость выборки и затраты ресурсов будут такие же, как если бы в этой таблице были лишь мета-данные без содержимого? В принципе, суть моего вопроса именно вокруг этого момента.
Под индексированием я всё же имел в виду поля, участвующие в фильтрации (where).
Я предположил, что выборка будет быстрее, если таблица будет содержать только поля, по которым будет производиться фильтрация where, а затем уже добавляться через left join нужные поля с текстовым содержимым.
К примеру, двухуровневые (с возможностью отвечать) комментарии я сделал так:
1) Запрашиваются все комментарии с ключом post_id
2) Они сортируются так, что на выходе остаются 15 комментариев верхнего уровня (последние добавленные, либо с наибольшим рейтингом), а также до 5 комментариев-ответов на каждый из них.
3) Отдельным запросом из второй таблицы загружается остальное содержимое отобранных ранее комментариев.
В проведённом тесте for in для объекта показал значительно более быстрые результаты, чем перебор массива. Не знаю, насколько универсальны эти результаты. Советуете использовать {}?
1) Хорошая идея — полагаю, можно хранить время последнего хода игрока и, зная скорость восстановления его шкалы хода, при запросе от него высчитывать, может ли он ходить или ещё нет. Или в момент завершения его хода сразу высчитывать допустимое время следующего. Спасибо, как-то не додумался до этого. В этом случае основной game loop не нужен в принципе.
@alexclear то есть, воркеры должны быть спроектированы таким образом, чтобы они могли время от времени перезапускаться без пагубного влияния на игровой процесс? Кажется, у меня совсем нет понимания того, какого рода задания в принципе делегировать им от главного процесса игры. В случае с моим предположением вешать на воркеры tcp-сервера для соединения игроков, при перезапуске воркера части игроков грозит дисконнект. Других предположений, какого рода задачи отдавать воркерам, я пока не выработал.
Для централизованного хранения информации о текущих боях, например. По-моему, это лучше, чем хранить их в redis и запрашивать при каждом шаге в бою. Или не лучше?
“Делать по потоку на коннект - худшая идея.”
Тут имел в виду коннектить игроков к воркерам, а число самих воркеров делать равным числу ядер процессора. Как в сэмплах кода по cluster — require('os').cpus().length.
Значит, вы рекомендуете tcp-сервер делать на главном потоке? Я просто не знаю, насколько ресурсоёмкой является работа с соединениями игроков.
