Юрий Ярош

Я бы даже лучше уехал в сторону scylladb - более толковая штука чем Cassandra / Hbase.

Нужно отрефакторить схему, привести всё в божеский вид к 5-6 нормальной форме.
80% всех проектов с которыми приходилось иметь дело "аля магазин на РНР" индексирует varchar и еже с ним. Из-за этого "выборка 2К товаров" - просто непосильная задача. Стоит почитать книжку SQL Antipatterns и High Performance MySQL. Разобраться как работает InnoDB, и как вообще происходит оптимизация.

Пример "говно-схемы"
Table products
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL
group varchar(255) NOT NULL
oneAttr varchar(255)
otherAttr varchar(255)
anotherAttr varchar(255)
description varchar(255)
dateCreated DATETIME

Нужно разбить минимум на 4 таблички
Table products
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL
group_id unsigned int NOT NULL (FK)
description varchar(255)
dateCreated DATETIME

Table product_groups
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL

Table products_attrs
id unsigned int autoincrement (PK)
name varchar(255) NOT NULL

Table product_attrs_values
product_id unsigned int (PK <- FK)
attr_id unsigned int (PK <- FK)
attr_value varchar(255) NOT NULL

Ну и т.п.

Это второй курс универа :)
И очень много обывателей даже до него не дотягивает, что меня довольно таки печалит.
И, конечно-же, нужно уметь использовать EXPLAIN.

Прежде чем холиварить нужно разъяснить 3 вещи
1. Модель БД в 6ой нормальной форме могут проектировать единицы
2. Понимать как все эти схемы, каталоги, представления и материализованные представления вписываются в SOA, как производить тестирование, какие функции где хранить, как проставлять тригеры, как подчищать журналы, как разделить представления чтения/записи в рамках CQRS - знают единицы, а использует на практике и того меньше.
3. PostgreSQL можно сделать быстрее и эффективнее чем MySQL / MongoDB / Oracle, но не наоборот, хотя косячить можно везде :), и там много чёрной магии которая простым смертным просто недоступна. PostgreSQL слишком просто кастомизируется, и этим можно получить просто дикие приросты производительности, особенно если речь идёт о внедрении каких-то кастомных типов данных, индексов и функций агрегации. В остальных решениях "шаг вправо, шаг влево - расстрел". Если вам нужно простое решение которое "лишь бы работало с коробки" - вам точно не стоит использовать PostgreSQL.

Можно почитать/посмотреть записи с различных конференций, посмотреть как шардят большие конторы.
1. Аутентификация != Авторизация
2. Нужно понимать что при горизонтальном масштабировании сервер не должен хранить состояний - обычно люди хранят данные сессии в просоленной куке, а не в базе.
3. Распределять нагрузку нужно в зависимости от текущей, соответственно должен производится мониторинг, и запросы должны отправляться на наименее нагруженный сервер
4. В куке сессии должен записываться IP cервера который обрабатывает запросы от текущего пользователя, а DNS в свою очередь должен отдавать адрес сервера который работает с данной сессией. Таким образом с одним пользователем может работать только один сервер, и между ними не нужно гонять никаких редиректов, но на первое время можно просто редиректить.
5. В случае с push-нотификациями, и кэшированием там вообще всё очень сложно и нужно крутить CQRS-ES, иногда нужно решать задачу консенсуса Raft'ом.