мои действия: после создания метода в репозитории, который создает этот запрос, я напишу тест. Изучу план выполнения запроса в этом тесте. Пойму, что Seq Scan более предпочтительный и поставлю соответствующий assert.
Тем самым покажу результат проделанной работы для других разработчиков, чтобы они потом не повторяли эти действия и сразу увидели, что я проверил план.
Смысл статьи не в том, что лучше или хуже, а в том, что я призывал проверять execution plan до выкадки на прод. Инструмент, который я предложил, всего лишь призван помочь в этом вопросе.
Парсинг все равно нужен, чтобы разложить в объектную модель и дальше удобно с ней работать, делая проверки.
Вы правы, распарсить JSON намного проще, чем TEXT)). Я как-то это упустил. Спасибо за подсказку! Добавлю в план написать другую реализацию query & parser.
Если я, например, добиваюсь идеального плана выполнения в тесте, например на 10К-20К записей. Потом на проде планировщик за счет статистики, по моему опыту, может сделать запрос только лучше, но я не припомню, чтобы он его прибил в ноль.
Например, если планировщик увидит, что в результате фильтрации позвращается больше определенного процента записей, он может посчитать, что использовать seq scan оправданно. При этом время запроса только улучшится (в большенстве случаев).
Мне же как разработчику важно изначально «подстелить соломку» и провести некую работу над запросом, убедившись, что планировщик вообще в состоянии его выполнить оптимально.
Может я, конечно, не встречался еще с такими кейсами. Буду рад примеру.
100% на каждый чих этого делать не нужно. В разработке вообще все нужно делать осознанно, такая у нас профессия). Но я бы проверял все «чихи» (изменение запроса, добавление нового), если в таблице записи исчисляются в миллионах.
Не исключаю, что где то они необходимы, но я успешно избегаю их использование уже на протяжении нескольких лет). На сколько мне известно, EXPLAIN не работает с инструкцией CALL, поэтому текущий ExecutionPlanQuery не сможет получить план.
Я стараюсь всю логику держать в приложении, а БД использовать только в качестве хранилища. Так легче масштабироваться: накидал пару дополнительных нод и готово. С БД все не так просто, реплики и тд гораздо сложнее. Прибегаю к этому в последнюю очередь имхо.
Не совсем. Да, то что вы предлагаете действительно подойдет многим, но не всем. Есть сценарии, когда нужен мой подход. Покрайней мере, я не нашел как сделать это просто, готовыми решениями.
Объясню на примере: вы разрабатываете сервис, который получает из другого целевого сервиса информацию о погоде и возвращает пользователям, добавляя к ней веселые картинки. Например, зонтики, если дождь.
Вот сценарий: пользователь, например, в 10:00 запрашивает с вашего сервиса погоду, вы за ней идете в целевой сервис. Получаете, например +15, кладете в кеш и возвращаете пользователю. В документации к целевому сервису сказано, что погода может измениться каждые 10 минут. Соответственно, вы ставите TTL в кеше 10 минут, желая отдавать пользователям актуальную информацию.
Пользователь, приходит в 10:11. Ваш кеш протух, и предположим что целевой сервис не отвечает. Вы его пушите retry`ем, но он все равно не отвечает. Hystrix «размыкает цепь» и отдает вам значение по умолчанию, то что я описывал в DisasterStrategy. Какое значение по умолчанию вы можете отдать?..
Я же предлагал поставить TTL кеша, например, на 2-3 часа. А так называемый CRP = 10 минут. Тогда если пользователь пришел бы в 10:11 и целевой сервис был бы недоступен, я бы вернул ему значение из кеша +15 градусов. Да, возможно на улице было бы +16 или +14, но ведь это лучше, чем что то типа «погода уточняется, зайдите позже»?..
При этом, если бы в 10:11 целевой сервис ответил, я бы обновил CRT на значение CRP ((CRT)10:10 + (CRP)10 минут) и обновил бы значение в кеше. Поставив, например, +16.
Такая, собственно, у меня была идея, которой я хотел поделиться.
Тем самым покажу результат проделанной работы для других разработчиков, чтобы они потом не повторяли эти действия и сразу увидели, что я проверил план.
Смысл статьи не в том, что лучше или хуже, а в том, что я призывал проверять execution plan до выкадки на прод. Инструмент, который я предложил, всего лишь призван помочь в этом вопросе.
Вы правы, распарсить JSON намного проще, чем TEXT)). Я как-то это упустил. Спасибо за подсказку! Добавлю в план написать другую реализацию query & parser.
Например, если планировщик увидит, что в результате фильтрации позвращается больше определенного процента записей, он может посчитать, что использовать seq scan оправданно. При этом время запроса только улучшится (в большенстве случаев).
Мне же как разработчику важно изначально «подстелить соломку» и провести некую работу над запросом, убедившись, что планировщик вообще в состоянии его выполнить оптимально.
Может я, конечно, не встречался еще с такими кейсами. Буду рад примеру.
но даже в таком виде какие то явные косяки (например, забыл что-то) мне помогло устранить.
Я стараюсь всю логику держать в приложении, а БД использовать только в качестве хранилища. Так легче масштабироваться: накидал пару дополнительных нод и готово. С БД все не так просто, реплики и тд гораздо сложнее. Прибегаю к этому в последнюю очередь имхо.
До текущего момента не думал), я ведь этим решал свою проблему. Нужно подумать, но кроме портации, например, на .net ничего в голову не приходит.
Объясню на примере: вы разрабатываете сервис, который получает из другого целевого сервиса информацию о погоде и возвращает пользователям, добавляя к ней веселые картинки. Например, зонтики, если дождь.
Вот сценарий: пользователь, например, в 10:00 запрашивает с вашего сервиса погоду, вы за ней идете в целевой сервис. Получаете, например +15, кладете в кеш и возвращаете пользователю. В документации к целевому сервису сказано, что погода может измениться каждые 10 минут. Соответственно, вы ставите TTL в кеше 10 минут, желая отдавать пользователям актуальную информацию.
Пользователь, приходит в 10:11. Ваш кеш протух, и предположим что целевой сервис не отвечает. Вы его пушите retry`ем, но он все равно не отвечает. Hystrix «размыкает цепь» и отдает вам значение по умолчанию, то что я описывал в DisasterStrategy. Какое значение по умолчанию вы можете отдать?..
Я же предлагал поставить TTL кеша, например, на 2-3 часа. А так называемый CRP = 10 минут. Тогда если пользователь пришел бы в 10:11 и целевой сервис был бы недоступен, я бы вернул ему значение из кеша +15 градусов. Да, возможно на улице было бы +16 или +14, но ведь это лучше, чем что то типа «погода уточняется, зайдите позже»?..
При этом, если бы в 10:11 целевой сервис ответил, я бы обновил CRT на значение CRP ((CRT)10:10 + (CRP)10 минут) и обновил бы значение в кеше. Поставив, например, +16.
Такая, собственно, у меня была идея, которой я хотел поделиться.