Правильное добавление/обновление таблиц в базах данных?
Если с выборкой все в принципе понятно, вытащили данные и храним их в кеше периодически сбрасывая на файл чтобы не терять разогретый кеш, но как быть в случае часто изменяющихся данных? Redis и подобное не подходит, эти данные нужно хранить постоянно. Например взять лайк в любой соц. сети, ведь при любом лайке нет автоматического запроса к бд на добавление/обновление? Единственное что смог придумать - записывать изменения/новые данные в кэш и обновлять их в бд пачками по шедулеру.
Можно в Memcached выполнять агрегацию лайков пачками по 10k плюс ограничением по времени до 5 сек. и затем обновлять агрегированные значения в БД. Напрямую или через очередь.
Для начала хотя бы так.
Кроме этого, на клиенте можно оттягивать отправку после 1-го клика при помощи техники debounce. Также по теме https://levelup.gitconnected.com/debounce-in-javas...
Хорошая идея, кстати, жаль только при масштабировании. Больно будет) ну и для всяких проектов где жесткие требования к безопасности не прокатит, но это я уже загоняюсь)
Emily_Ravenhold, в том что мемкэш не поддерживает шифрование по причине того что он in-Memory. Почти для любой сертификации, требующей шифрование тенантов это сразу неприемлемо
Во-первых есть запросы, а во-вторых есть разные виды кэширования: Read-Through, Write-Through и другие. У всех есть свои минусы и недостатки. Кроме того под капотом в таких системах чаще всего внутри все работает на очередях или стриминге
Есть запросы когда? Меня интересует больше техническая часть, т.е. правильная реализация. Очереди - понятно, класть в очередь запросы много ума не надо, но насколько это эффективно? Я имею ввиду кэшерование данных ПЕРЕД записью, а не данных которые нам потребуются позже после запроса на выборку. Допустим стабильно каждую секунду меняется какая-то величина, это происходит у 10000 пользователей, каким образом организовывать обновление данных в самой базе данных чтобы не было больших задержек в работе?
Emily_Ravenhold, говорить об эффективности не корректно без требований к системе (как функциональных так и не функциональных). Каждое решение строится на основании кучи факторов. "Не было больших задержек" это очень абстрактно без конечных цифр и в первую очередь относит нас к распределенным системам и не реляционным базам данных. Так же очень важно понимать где мы строим решение - в облаке или свой ДЦ.
Для примера: я прямо сейчас могу пойти и за вечер сделать решение для лайков на serverless и оно будет держать условно бесконечное число нагрузки с временем обновления до 200мс. Стоить будет как космос, но сделаю за вечер)
Иван Шумов, хорошо, допустим у нас имеется MySQL база данных с одной таблицей в 50 колонок. Все это стоит на удаленном сервере. Каждую секунду пользователь меняет содержимое 5-6 колонок (все - обычный integer), таких пользователей может быть в районе 10000 человек. Сразу отправлять запрос в базу данных на обновление таблицы - звучит как дикость. Какие методы можно применить для уменьшения итоговой нагрузки на базу данных? Цифры интересуют меньше всего, нужны лишь практики/названия практик чтобы по ним дальше самостоятельно искать какую-либо информацию.
Emily_Ravenhold, в таком ключе самое простое - докинуть read replicas, выделить правильное число ресурсов под базу данных, не индексировать изменяемые поля.
Правильный способ - выбрать key-value или не реляционную базу данных с горизонтальным масштабированием и acid через кворум.
Если первые два варианта не сработали то вы - Netflix и вам пора писать свои базы данных и языки программирования
Иван Шумов, по-сути получается что все практики сводятся в два варианта: горизонтальное/вертикальное расширение и соответственное ускорение работы БД и кеширование для отправления транзакциями?
Emily_Ravenhold, в большинстве случаев да, но надо не забывать ещё про паттерны обращения к данным - сегодня бд проектируется исходя из этого. И важно понимать что сегодня самый серьёзный перформанс можно получить только в облаках - они предоставляют уникальные решения, которые нереально дорого повторять
Средний
Сложный
Простой
Средний
