terrier

онлайн 500-1000 человек

300-400 запросов в секунду к mysql

На сколько либо нормальном железе 1 mysql-сервера хватит за глаза, redis точно излишний. Могу смело предположить, что у вас там характер нагрузки - короткие более-менее одинаковые запросы и все горячие данные быстро поднимутся в кэш базы ( у вас же не 100 гигабайт горячих данных, правда? ).
Переход на постгрес на таких масштабах заметного прироста именно в производительности скорее всего не даст, тем более понятно, что это затраты. Хотя помним, что у постгреса много других преимуществ.

Выглядит как PubSub-задача. Допустим у нас есть карта "Король гоблинов" 5/5 таунт, класс - гоблины.
Когда мы кладем ее на стол она ( в смысле соответствующий объект ) отписывается от канала "для тех, кто лежит в руке" и подписывается на каналы "Лежим на столе", "Класс - гоблины", "Карты с таунтом" и тэ дэ.
И посылает в соответствующие каналы сообщение - "Я 5/5 гоблин пришел на стол на такую-то позицию".

Таким образом мы можем баффать гоблинов, уничтожать вражеские таунты или баффать соседей по столу без перебора всех карт. Ну и добавление новых эффектов тоже с меньшей болью происходит

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

Пункт номер 0 - не сомневайтесь, С++ - один из основных языков в гейм-индустрии.
1. Гейм-индустрия сильно разная. Лабать инди-игру на кухне - это одно, фигачить очередную часть AAA-тайтла - это другое, делать веселую ферму с енотиками для вконташи - это третье
2. Соответственно, если фирма еще не вышла из стадии "Вася и Петя решили сделать новый фэллаут и уже даже наняли одного программиста Толяна", то условия очевидны - Толян фигачит пока не упадет за копейки.
3. А вот если фирма уже перешла на более индустриальный уровень, то тут обыкновенная IT-разработка, с некоторыми особенностями:
- В индустрии вполне встречаются энтузиасты и кто-то в компании будет работать с восьми до восьми ( хорошо, если это продюсер ), но это совсем не обязательно должны быть вы.
- В целом в управлении как правило бардак, для того чтобы рулить одновременно и художниками и программистами и геймдизаннерами нужны очень классные менеджеры, а таких в индустрии нет
- Уровень технической организации ( CI, vcs, code-review, внятные стандарты кодирования ) колеблется от "стихийного" до весьма высокого, есть суперкрутые специалисты, работать с ними - большая удача, особенно для новичка.
- Однако если вас интересует конкретно стек технологий с C++ - там крутых спецов вымывают яндекс/мэйл, они способны предложить условия получше
- Переработки случаются, поскольку планирование как правило весьма "креативное". По идее разработчки должны с этим бороться, насколько успешно - другой вопрос
- По деньгам - средне, вот тут сильно зависит от заказчика/проекта
- Есть ли улучшение со временем? Ну, вот недавно тем, кто работает на западного заказчика одномоментно стало резко лучше, гггг))) Но в целом, вы правильно поняли, в плане условий труда индустрия эволюционировала от "Полный треш, подойдет только для долбанутых подростков" к "Можно рассматривать, если есть толерантность к некоторому творческому беспорядку"

Ну, тут, есть несколько моментов
- Сама по себе скорость 1k инсертов в секунду не является запредельной ни для какого хранилища на нормальном железе.
Ну вот, например, постгрес.
- Вопрос: что вы с этими данными потом делаете?
Судя по десяти индексам вы одновременно из этой же таблицы активно читаете и это, наверное, не совсем разумно.
Если у вас куча инсертов приходят всплесками, то проще сначала вставить данные в таблицу без индексов ( prepared statements, по X строк в стейтменте, Y стейтментов в транзакции, где X и Y надо твикать в зависимости от железа ), а потом уже построить индексы. Если возможно, может быть вообще сделать "COPY ... BINARY " вместо инсертов.

Можно также копировать в UNLOGGED таблицу без индексов, а потом либо сделать ее LOGGED, либо спокойненько скопировать уже в нормальные таблицы из которых уже читать.

>> Потом она падает в ноль

Чекпоинт видимо пришел. Его можно отложить в настройках

pg_dump -t table_name

Ваш триггер на инсерт вызывает инсерт ( который вызывает инсерт ).
Вам нужно во-первых объявить его FOR EACH ROW,
во-вторых можифицировать new
new.guid = < ваше выражение>

Выглядит как задача для Logstash

Postgres:

Вопрос в том, будет ли эксклюзивно заблокирована строка из post на время выполнения всех этих операций

Собственно, да, всегда берется FOR UPDATE row-level lock, когда на строку делают delete, reference не влияет на это.
Посмотреть на локи можно примерно так.
Из одной консольки psql делаем

BEGIN;
delete from post where id = 1;

- в одной транзакции делаем delete ( понимаем, что он хватает лок на все, что удаляет )
Из другой консольки

BEGIN;
select * from post where id = 1 for update;

- эта транзакция пытается схватить лок на ту же строку, не может и ждет.

А вот что произойдет при роллбеке/коммите - это зависит от уровня изоляции транзакций.

проверять TG_OP или делать дополнительный триггер

Да, в общем-то и так и так нормально, смотрите как будет более читаемо

если триггер выполняется на большем кол-ве строк операция now() будет вызываться на каждой из них?

Да, собственно, как и написано в объявлении триггера "FOR EACH ROW", то бишь для каждой измененной строки. Ну, конкретно по поводу now() я бы сильно не волновался, это же время на начало транзакции, оно не меняется, то есть, скорее всего просто достается число из ближнего кэша. А вот если бы там была длительная операция вместо now(), вы бы ее в триггер не засунули бы, верно?

Впрочем, если вам принципиально проставлять время один раз для одного SQL-запроса, то можно объявить триггер "FOR EACH STATEMENT", он будет выполняться один раз для каждого запроса. Но в нем, понятное дело недоступны таблицы OLD и NEW, то есть каким-то отдельным запросом надо время проставлять

Так, возможно, следует создать соответствующий индекс для текстового поиска? Пример для одной из конкретных СУБД.
Если же враги запретили вам создавать индексы в базе, то быстрее всего было бы выгрузить значения в кэш - префиксное дерево в памяти и дальше запрашивать уже по нему