А что нибудь посоветуйте по оптимизации запрос на ORACLE почитать? Или обычно это происходит добавлением индексов и изменение плана запроса?
раскрыть ветку (8)
Если говорить о связке back-end - DB, то можно еще кэшировать результаты в какой-нть штуке типа memcached, redis, ignite, coherence, и так далее. Дата гриды (ignite и coherence) поддерживают довольно прикольные режимы сквозной записи и чтения, что бывает очень приятно с точки зрения консистентности и актуальности закэшированных данных, но там и минусы есть.
раскрыть ветку (6)
а потом приходит девопс и начинает пиздить всех налево и направо с вопросами какого хера 1 микросервис жрет 1 тб оперативки)))))
раскрыть ветку (5)
Дык надож настраивать экспирейшены и эвикшены при превышении лимита расхода памяти и вообще аккуратно следить за состоянием кэша, а то будет больно. Еще и способы сериализации очень сильно по эффективности отличаются.
раскрыть ветку (4)
раскрыть ветку (3)
Так кэши и созданы под задачу, а не на пустом месте. Тот же мемкэшед Фицпатрик создал чтоб уменьшить количество запросов к бд от ливжорнала
раскрыть ветку (2)
ну это не значит, что на оптимизации запросов, индексы, партиции, реплики нужно класть хер))) точнее я больше скажу, на них ты вообще не сможешь положить хер в высоконагруженном сервисе) а кеши как доп прокладка, но никак не полноценная замена всему этому
раскрыть ветку (1)
Кэши, конечно, образуют свой лейер, но вот так пренебрежительно "доп прокладкой" я бы их не называл. Все же если вы вдруг хотите разработать распределенное горизонтально масштабируемое приложение, то вот я вас уверяю, вы не хотите сами реализовывать формирование кластера, ноуд дискавери, лизинги, перебалансировку, стики роутинг, консенсусы и прочее, т.е. надо взять какую-то либу которая будет базисом горизонтально масштабируемого приложения и кэши это и есть та самая основа.
Для оптимизации 90% запросов достаточно выбрать правильные индексы. Посмотрите какие индексы уже есть.
Иногда помогает уничтожение статистики. Сама СУБД собирает информацию о планах предыдущих запросов. По мере роста БД может получиться так, что статистика уже не соответствует текущему состоянию БД. Первое время будет снижение производительности, но со временем наберётся новая статистика и всё будет работать как раньше. Если повезёт - то даже лучше.
Ещё для 9% достаточно изучить план запроса и переделать запрос. Особое внимание стоит уделить группировкам и фильтрам.
В оставшемся 1% - чистая жесть, которая требует создания временных таблиц и всяческих других извращений.
Помощники
243 поста785 подписчиков
Правила сообщества
Нельзя обсуждать Политику.
Ругаться и оскорблять.