Это сайт — моя персональная записная книжка. Интересна мне, по большей части, история, своя жизнь и немного программирование.

SELECT [DEFER] * FROM…

Я тут подумал, что было бы очень круто как помечать запросы флагом, который бы говорил СУБД «если такой же запрос уже выполняется, то меня устроят его результаты, новый запускать не надо». Было бы очень полезно для запросов, в которых не нужна оперативность и которые заказываются большим числом пользователей.

Конечно такое можно кешировать со стороны приложения (что у нас и делается в продукте), но встают вопросы инвалидации кеша, предотвращения одновременного выполнения одного и того же запроса несколько раз, если в кеше что-то не нашлось, обработки ошибок от базы и так далее.

Со стороны СУБД было бы интереснее такое увидеть.

9 комментариев
PastorGL 2017

Materialized view.

lazarevmax 2017

Поддерживаю, отличная идея!

Евгений Степанищев (bolknote.ru) 2017

Комментарий для PastorGL:

Materialized view.

Нет.

Алексей Шамрин 2017

Да, materialized view требуется вручную обновлять. По крайней мере в Postgres. Инвалидации кеша и другие проблемы остаются.

SELECT DEFER — интересный предложение. Но было бы ещё лучше, если бы база данных умела эффективно реагировать на произвольные изменения во входных данных запроса. Предположим, есть периодический запрос SELECT SUM(amount) FROM transfer. В таблице transfer сто миллионов строк. За один час в таблице изменяется/добавляется десять тысяч строк. Свежий результат запроса этого запроса современные БД будут вычислять за время порядка размера всей таблицы. Но очевидно, что в БД есть вся информация, чтобы делать это за время порядка скорости изменений в таблице. Было бы круто, если БД научились так делать. И не только в тривиальных случаях вроде суммы, а *для произвольных запросов*.

Исследование на эту тему: https://github.com/frankmcsherry/differential-dataflow

Евгений Степанищев (bolknote.ru) 2017

Комментарий для Алексей Шамрин:

SUM(amount) умеют хорошо колоночные СУБД. Кроме того, если в Оракле навесить пересчёт MV (быстрым методом, то есть с логами по таблице) на триггер — то вот оно решение. В Постгресе, увы «быстрых» MV не вовсе.

Алексей Шамрин 2017

Комментарий для Евгения Степанищева:

если в Оракле навесить пересчёт MV (быстрым методом, то есть с логами по таблице) на триггер

Не очень понятно, что значит «быстрый метод». Можно чуть подробней?

Евгений Степанищев (bolknote.ru) 2017

Комментарий для Алексей Шамрин:

Ну он так и называется «быстрый метод» (fast method or fast refresh), можно погуглить. Это не полный пересчёт MV с нуля, а добавление данными (на основе логов по полям, задействованным в запросе). У метода масса ограничений, которые тоже гуглятся. Я на этих вьюхах счётчики документов делал в нашем СЭДе.

xyz 2017

Oracle: result cache

Евгений Степанищев (bolknote.ru) 2017

Комментарий для xyz:

Я не про кеш, прочитайте внимательно, пожалуйста.