Про сообщение по теме тулинга я не забыл. Однако оно требует примеров и иллюстраций, поэтому затянулось — но будет, просто позднее.
А пока выдам небольшую тележку про RDBMS. В последнее время распространилось большое веяние, что RDBMS это зло, и вообще всем пора переползать на NoSQL. Только случится это нескоро, а кормит нас всех часто всё-таки легаси и энтерпрайз. Кроме того, моё личное мнение, что про NoSQL обычно говорят в таком акцепте:
- Do you know SQL Databases?
- No
- Ok, I see you're master at NoSQL Database.
Между тем, знание хотя бы поверхностное устройства RDBMS сильно упрощает жизнь и повышает качество всей той бороды, которую вы зачем-то называете SQL Data Access Layer. А может, вам и самим придётся писать storage, принципы устройства никуда не меняются.
Итак, из чего состоит типовая RDBMS. Из 4х частей:
1. Обработчик запросов на подключение от клиента. Назовём этот модуль Request Servant. Это он отвечает за то, чтобы клиентская библиотека успешно преодолела все трудности, связанные с удалённым доступом, получила соединение к БД, далее её запрос был принят "в руки" и отшедуллен на конкретного исполнителя внутри БД. Объём памяти и воркеров на подключения, пулы запросов, обрабатывать подключения в потоках или процессах, исполнять там же или передавать в отдельные воркеры — это всё настраивается здесь. Ошибки разного сетевого уровня, ошибки аутентификации, порты и соединения, пулы и высокая доступность, репликации и протоколы — всё вопросы сюда.
2. Планировщик запросов (Query planner). Отвечает за то, чтобы странслировать команду, которую вы направили, в набор примитивных операций, которым владеет данная СУБД, и вернуть вам результат. Здесь делается всё для того, чтобы ваш запрос распарсить, составить оптимальнейший план для него (или взять план из кеша), оценить его трудоёмкость десятками методов и обсчитать сотни тысяч вариантов (например, на основании статистики предыдущих запросов) и отправить на исполнение. Хитрые оптимизации, разные баги исполнения запросов — всё таится здесь. Кеш результатов запроса, кеш планов, стоимость операций — всё настраивается тут.
В этом месте фасеточные глаза разработчика открываются на всякие спецэффекты, типа, почему надо использовать именованные параметры СУБД, а не клеить запросы из строк (потому что кеш планов запросов засоряется, например).
3. Сегменты данных (Data segments). Это ваши данные, доступ к которым организует БД. Если брать примитивно, то сегмент данных — это огромный файл со строками, над которым построено некоторое количество деревьев с дублированием данных или без дублирования (т.н. представления и индексы) и гора семафоров/мьютексов, которая позволяет реализовать совместный доступ (да, не всё так уж и параллельно!). Ровно то, как вы себе представляете чтение и редактирование этого файла, так и устроена работа в БД, магии не существует. Тут настраивается объём этого файла, и какую часть надо его читать в память, сразу или по запросу, политику кеширования данных в памяти, расположение данных на носителях и т.п.
Поняли это — можете прикинуть стоимость операций доступа к данным, это 99% времени, которое тратится в запросе. Именно тут становится понятно, почему колоночные СУБД рулят на OLAP-задачах (подсказка: потому что данные по колонкам лежат рядом, поэтому типовая выборка 5 колонок из 50 будет требовать гораздо меньший объём IOPS).
А пока выдам небольшую тележку про RDBMS. В последнее время распространилось большое веяние, что RDBMS это зло, и вообще всем пора переползать на NoSQL. Только случится это нескоро, а кормит нас всех часто всё-таки легаси и энтерпрайз. Кроме того, моё личное мнение, что про NoSQL обычно говорят в таком акцепте:
- Do you know SQL Databases?
- No
- Ok, I see you're master at NoSQL Database.
Между тем, знание хотя бы поверхностное устройства RDBMS сильно упрощает жизнь и повышает качество всей той бороды, которую вы зачем-то называете SQL Data Access Layer. А может, вам и самим придётся писать storage, принципы устройства никуда не меняются.
Итак, из чего состоит типовая RDBMS. Из 4х частей:
1. Обработчик запросов на подключение от клиента. Назовём этот модуль Request Servant. Это он отвечает за то, чтобы клиентская библиотека успешно преодолела все трудности, связанные с удалённым доступом, получила соединение к БД, далее её запрос был принят "в руки" и отшедуллен на конкретного исполнителя внутри БД. Объём памяти и воркеров на подключения, пулы запросов, обрабатывать подключения в потоках или процессах, исполнять там же или передавать в отдельные воркеры — это всё настраивается здесь. Ошибки разного сетевого уровня, ошибки аутентификации, порты и соединения, пулы и высокая доступность, репликации и протоколы — всё вопросы сюда.
2. Планировщик запросов (Query planner). Отвечает за то, чтобы странслировать команду, которую вы направили, в набор примитивных операций, которым владеет данная СУБД, и вернуть вам результат. Здесь делается всё для того, чтобы ваш запрос распарсить, составить оптимальнейший план для него (или взять план из кеша), оценить его трудоёмкость десятками методов и обсчитать сотни тысяч вариантов (например, на основании статистики предыдущих запросов) и отправить на исполнение. Хитрые оптимизации, разные баги исполнения запросов — всё таится здесь. Кеш результатов запроса, кеш планов, стоимость операций — всё настраивается тут.
В этом месте фасеточные глаза разработчика открываются на всякие спецэффекты, типа, почему надо использовать именованные параметры СУБД, а не клеить запросы из строк (потому что кеш планов запросов засоряется, например).
3. Сегменты данных (Data segments). Это ваши данные, доступ к которым организует БД. Если брать примитивно, то сегмент данных — это огромный файл со строками, над которым построено некоторое количество деревьев с дублированием данных или без дублирования (т.н. представления и индексы) и гора семафоров/мьютексов, которая позволяет реализовать совместный доступ (да, не всё так уж и параллельно!). Ровно то, как вы себе представляете чтение и редактирование этого файла, так и устроена работа в БД, магии не существует. Тут настраивается объём этого файла, и какую часть надо его читать в память, сразу или по запросу, политику кеширования данных в памяти, расположение данных на носителях и т.п.
Поняли это — можете прикинуть стоимость операций доступа к данным, это 99% времени, которое тратится в запросе. Именно тут становится понятно, почему колоночные СУБД рулят на OLAP-задачах (подсказка: потому что данные по колонкам лежат рядом, поэтому типовая выборка 5 колонок из 50 будет требовать гораздо меньший объём IOPS).
