СУБД как управляемая система
На прошедшей вчера онлайн конференции OSACON профессор Энди Павло из CMU попробовал спрогнозировать развитие СУБД лет на 20 вперед. Вернее, не столько спрогнозировать, сколько обозначить тренд исследований, который может привести к ощутимому результату. Основной посыл -- это необходимость перехода к автономным СУБД, которые сами себя оптимизируют и настраивают.
Нельзя сказать, что идея новая. Последние лет 10-15 разработки в этой области велись и в Микрософте, и в IBM, но до чего-то серьезного дело пока не дошло. Сложность здесь та же, что и в случае с автономным транспортом: для автономного управления программе необходимо "моделировать реальность", предсказывать изменения в окружении и результат управления. Для сложных нелинейных систем это более-менее научились делать только недавно при помощи алгоритмов машинного обучения. Почему бы не перенести наработки в сферу СУБД? Некоторые инженерные идеи изложены в этой статье, но я зайду немного с другой стороны.
В чем состоит задача управления? Перевести систему из состояния X в состояние Y при помощи функции управления f. В математической теории управления требуется уравнение или система уравнений, которые описывают эволюцию системы, что-то типа M(X, f, t). В задаче оптимального управления также добавляется некоторый функционал качества (за минимальное время, с минимальным расходом топлива и т.д.). В более сложных задачах добавляется неопределенность, вводится помеха и т.д. В применении к СУБД это означает следующее.
Во-первых, необходимо прогнозировать эволюцию системы при нулевом управлении, т.е. M(X, t). Для прогнозирования можно использовать историю мониторинга основных параметров. Самый простой пример -- свободное место на диске. Более сложные примеры -- суточные колебания нагрузки, "мины" в схеме данных и др. Здесь можно использовать какие-то регрессионные модели или ML.
Во-вторых, и это гораздо сложнее, необходимо прогнозировать, как управляющее воздействие влияет на состояние системы. Почему это сложно? Потому что за пределами элементарных вещей, типа объема памяти или количества ядер процессора, готовых формул нет, есть только некоторые эвристики, вырабатываемые у людей годами. Этим эвристикам можно научить и компьютер, но потребуется "натренировать" его на чем-то настоящем, и при этом обеспечить переносимость модели между разными окружениями.
В-третьих, сделать СУБД управляемыми. У современных СУБД сотни настроечных параметров, и еще больше, если смотреть на схему данных, индексы и прочее. Пространство возможных управлений огромно, и никакой Монте-Карло или ML не сможет его надежно изучить за доступное время. В приведенной выше статье описываются некоторые требования к СУБД, чтобы было ей проще управлять. Один из способов -- это деление СУБД на модули, или деление процесса выполнения запроса на независимые фазы, и выделение управлений, которые воздействуют на эти части системы или процесс. Это безусловно имеет смысл, но большие трудности здесь не методолгические, а технические. Сильным аргументом кажется развитие автономного транспорта -- но, честно говоря, научить человека управлять СУБД на реальных системах будет посложнее, чем водить автомобиль.
А что же человек? А человек останется отвечать за "функцию качества", которая, если решена задача управления, превращается в многокритериальную оптимизацию: СУБД может подсказать Парето-границу возможного, а человеку уже выбирать, что ему важнее, скорость там или стоимость.
Нельзя сказать, что идея новая. Последние лет 10-15 разработки в этой области велись и в Микрософте, и в IBM, но до чего-то серьезного дело пока не дошло. Сложность здесь та же, что и в случае с автономным транспортом: для автономного управления программе необходимо "моделировать реальность", предсказывать изменения в окружении и результат управления. Для сложных нелинейных систем это более-менее научились делать только недавно при помощи алгоритмов машинного обучения. Почему бы не перенести наработки в сферу СУБД? Некоторые инженерные идеи изложены в этой статье, но я зайду немного с другой стороны.
В чем состоит задача управления? Перевести систему из состояния X в состояние Y при помощи функции управления f. В математической теории управления требуется уравнение или система уравнений, которые описывают эволюцию системы, что-то типа M(X, f, t). В задаче оптимального управления также добавляется некоторый функционал качества (за минимальное время, с минимальным расходом топлива и т.д.). В более сложных задачах добавляется неопределенность, вводится помеха и т.д. В применении к СУБД это означает следующее.
Во-первых, необходимо прогнозировать эволюцию системы при нулевом управлении, т.е. M(X, t). Для прогнозирования можно использовать историю мониторинга основных параметров. Самый простой пример -- свободное место на диске. Более сложные примеры -- суточные колебания нагрузки, "мины" в схеме данных и др. Здесь можно использовать какие-то регрессионные модели или ML.
Во-вторых, и это гораздо сложнее, необходимо прогнозировать, как управляющее воздействие влияет на состояние системы. Почему это сложно? Потому что за пределами элементарных вещей, типа объема памяти или количества ядер процессора, готовых формул нет, есть только некоторые эвристики, вырабатываемые у людей годами. Этим эвристикам можно научить и компьютер, но потребуется "натренировать" его на чем-то настоящем, и при этом обеспечить переносимость модели между разными окружениями.
В-третьих, сделать СУБД управляемыми. У современных СУБД сотни настроечных параметров, и еще больше, если смотреть на схему данных, индексы и прочее. Пространство возможных управлений огромно, и никакой Монте-Карло или ML не сможет его надежно изучить за доступное время. В приведенной выше статье описываются некоторые требования к СУБД, чтобы было ей проще управлять. Один из способов -- это деление СУБД на модули, или деление процесса выполнения запроса на независимые фазы, и выделение управлений, которые воздействуют на эти части системы или процесс. Это безусловно имеет смысл, но большие трудности здесь не методолгические, а технические. Сильным аргументом кажется развитие автономного транспорта -- но, честно говоря, научить человека управлять СУБД на реальных системах будет посложнее, чем водить автомобиль.
А что же человек? А человек останется отвечать за "функцию качества", которая, если решена задача управления, превращается в многокритериальную оптимизацию: СУБД может подсказать Парето-границу возможного, а человеку уже выбирать, что ему важнее, скорость там или стоимость.