Comments 3
Эту по-настоящему крупную сумму вы платите людям за то, чтобы они просто присматривали за вашим программным обеспечением.
То есть, ДБА — это те, кто делает бэкапы?
Каким образом автономная СУБД будет исправлять плохое проектирование и запросы — основной источник головной боли?
Простите TL;DR, мог пропустить ответ где-то в тексте.
У меня вопрос. Когда у вас в базе 5 таблиц — всё понятно. Но когда их 500 и нагрузка абсолютно разная по характеру (OLAP\OLTP), как ваша автономная СУБД (или не ваша, а от Oracle) поймёт какие запросы должны работать быстрее, а какие не так важны? У такой системы по умолчанию нет полной информации об архитектуре, ближайших и не очень планах, и что самое важное о требованиях к системе. Как она может делать мудрые решения будучи фактически слепой?
У меня вопрос. Когда у вас в базе 5 таблиц — всё понятно. Но когда их 500 и нагрузка абсолютно разная по характеру (OLAP\OLTP), как ваша автономная СУБД (или не ваша, а от Oracle) поймёт какие запросы должны работать быстрее, а какие не так важны? У такой системы по умолчанию нет полной информации об архитектуре, ближайших и не очень планах, и что самое важное о требованиях к системе. Как она может делать мудрые решения будучи фактически слепой?
Не знаю, как ответил бы автор, но можно сделать ряд предположнений
1) Как правило занчимые изменения в архитектуре серьезных систем на 500 таблиц не выкатывают в прод сразу (а те, кто выкатывают, полагаю, имеют проблемы посерьезнее автонастройки СУБД). Проходит ряд стадий — интеграционное тестирование, нагрузочное тестирование, пилотная эксплуатация. То есть, собрать информацию, теоретически, при правильном подходе к разработке, можно. Правда, есть другие нюансы — к примеру, на пилоте систему используют 20 операторов, а в проде 2000. Соответственно, оптимальная конфигурация для 20-ти может привести к дедлоку в первые 5 минут прода. Но если наращивать нагрузку постепенно, или написать грамотный стресс-тест (например, сгенерировав скрипт стресс-теста с логов старой продакшн системы, собранных на условную черную пятницу), то можно ожидать, что система сможет настроиться корректно.
2)
3)
И еще: тут все сводится к регуляторам, но, думаю, радикально больший прирост можно получить за счет скрытой денормализации, дублирования структур, автоподсчету олапов. Условно, если постоянно идут запросы на 20 джойнов, то создать скрытую таблицу на все необходимые столбцы, апдейтить ее при каждом изменении данных в любой из 20-ти таблиц (причем, делать это весьма хитрым алгоритмом, чтобы не повесить все на сутки при апдейтте справочника), и потом на селект определенного паттерна поднимать только ее. Если кто-то постоянно долбит group by date, то создать скрытый гибридный олап, и тоже в него ходить, и так далее…
1) Как правило занчимые изменения в архитектуре серьезных систем на 500 таблиц не выкатывают в прод сразу (а те, кто выкатывают, полагаю, имеют проблемы посерьезнее автонастройки СУБД). Проходит ряд стадий — интеграционное тестирование, нагрузочное тестирование, пилотная эксплуатация. То есть, собрать информацию, теоретически, при правильном подходе к разработке, можно. Правда, есть другие нюансы — к примеру, на пилоте систему используют 20 операторов, а в проде 2000. Соответственно, оптимальная конфигурация для 20-ти может привести к дедлоку в первые 5 минут прода. Но если наращивать нагрузку постепенно, или написать грамотный стресс-тест (например, сгенерировав скрипт стресс-теста с логов старой продакшн системы, собранных на условную черную пятницу), то можно ожидать, что система сможет настроиться корректно.
2)
абсолютно разная по характеру (OLAP\OLTP)тут некоторые используют модное слово HTAP) На практике это конкретный зашквар. Видел не раз такие системы, и каждый раз понимал, что поддерживать две СУБД с разным способом хранения было бы дешевле, безгеморнее, и продуктивнее. Ну, как минимум, разводить по схемам и таблицам. И тут, как раз, можно предположить, что хороший ИИ поймет, что надо данные дублировать, и ходить к разным таблицам в зависимости от характеристик запроса.
3)
У такой системы по умолчанию нет полной информации об архитектуре, ближайших и не очень планах, и что самое важное о требованиях к системе.если предположить, что все пишут прям с нуля (и желательно на чем-то низкоуровневом), то да. По факту, уверен, что многие конкретные инсталяции СУБД обслуживают либо одинаковый софт (одну и ту же CRM/ERP/CMS), либо софт, обильно использующий что-то вроде (Django ORM/Entity Framework). В первом случае достаточно просто по профилю нагрузки понять, что это «оно», и подставить настройку, взятую с системы, годами отработавшей с связке с данным софтом (предполагаем, что сбор данных анонимен, и даже нельзя сметчить имена таблиц). Во втором можно иметь готовые рецепты на ряд мерзких запросов.
И еще: тут все сводится к регуляторам, но, думаю, радикально больший прирост можно получить за счет скрытой денормализации, дублирования структур, автоподсчету олапов. Условно, если постоянно идут запросы на 20 джойнов, то создать скрытую таблицу на все необходимые столбцы, апдейтить ее при каждом изменении данных в любой из 20-ти таблиц (причем, делать это весьма хитрым алгоритмом, чтобы не повесить все на сутки при апдейтте справочника), и потом на селект определенного паттерна поднимать только ее. Если кто-то постоянно долбит group by date, то создать скрытый гибридный олап, и тоже в него ходить, и так далее…
Sign up to leave a comment.
Автономное будущее СУБД