Иван Шумов, по-сути получается что все практики сводятся в два варианта: горизонтальное/вертикальное расширение и соответственное ускорение работы БД и кеширование для отправления транзакциями?
Иван Шумов, хорошо, допустим у нас имеется MySQL база данных с одной таблицей в 50 колонок. Все это стоит на удаленном сервере. Каждую секунду пользователь меняет содержимое 5-6 колонок (все - обычный integer), таких пользователей может быть в районе 10000 человек. Сразу отправлять запрос в базу данных на обновление таблицы - звучит как дикость. Какие методы можно применить для уменьшения итоговой нагрузки на базу данных? Цифры интересуют меньше всего, нужны лишь практики/названия практик чтобы по ним дальше самостоятельно искать какую-либо информацию.
Есть запросы когда? Меня интересует больше техническая часть, т.е. правильная реализация. Очереди - понятно, класть в очередь запросы много ума не надо, но насколько это эффективно? Я имею ввиду кэшерование данных ПЕРЕД записью, а не данных которые нам потребуются позже после запроса на выборку. Допустим стабильно каждую секунду меняется какая-то величина, это происходит у 10000 пользователей, каким образом организовывать обновление данных в самой базе данных чтобы не было больших задержек в работе?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
