Архитектура РСУБД — различия между версиями
м (rollbackEdits.php mass rollback) |
|||
(не показаны 3 промежуточные версии 2 участников) | |||
Строка 1: | Строка 1: | ||
+ | {{Определение | ||
+ | |definition = | ||
+ | '''Реляционная система управления базами данных''' (сокр. РСУБД, англ. Relational Database Management System, сокр. RDBMS) - СУБД, управляющая реляционными базами данных.}} | ||
+ | |||
== Общий план == | == Общий план == | ||
− | Верхнеуровнево, система управления баз данных состоит из ''' хранилища данных ''' и ''' программы''', которая к этим данным обращается. | + | Верхнеуровнево, система управления баз данных состоит из ''' хранилища данных ''' и ''' программы''', которая к этим данным обращается. |
+ | |||
+ | ''Замечание'', программа и данные могут быть на разных компьютерах. | ||
[[Файл:intro_arch_mini.png|400px|Общий план]] | [[Файл:intro_arch_mini.png|400px|Общий план]] | ||
== Взаимодействие с СУБД == | == Взаимодействие с СУБД == | ||
− | Под вопросом из первой картинки скрывается несколько компонент, один из них - ''' протокол ''' взаимодействия программы и СУБД. Этот протокол реализуется '' драйверами'' : с одного конца есть программа, взаимодействующая с драйвером, и, аналогично, с другого конца есть СУБД и также драйвер. | + | Под вопросом из первой картинки скрывается несколько компонент, один из них - ''' протокол ''' взаимодействия программы и СУБД. Этот протокол реализуется '' драйверами'' : с одного конца есть программа, взаимодействующая с драйвером, и, аналогично, с другого конца есть СУБД (которое обращается в хранилище) и также драйвер. |
− | + | ''Замечание'', на этой картинке СУБД и данные располагаются на одном компьютере, что позволяет не ходить по сети между СУБД и хранилищем, если БД распределённая и хранилище это несколько компьютеров, то ходить оп сети всё же придётся. | |
+ | |||
+ | ''Замечание'', традиционно, у каждого СУБД есть свой протокол, по которому происходит взаимодействие. | ||
[[Файл:intro_arch_drivers.png|400px|Протокол взаимодействия]] | [[Файл:intro_arch_drivers.png|400px|Протокол взаимодействия]] | ||
Строка 26: | Строка 34: | ||
Улучшения '' исполнителя запроса '': | Улучшения '' исполнителя запроса '': | ||
* добавление модуля ''' управление памятью ''' - так как эффективность исполнение запроса может зависеть от кол-ва используемых данных, а именно - поместятся они все в память или нет, это стоит учитывать при выборе того как запрос будет исполнен | * добавление модуля ''' управление памятью ''' - так как эффективность исполнение запроса может зависеть от кол-ва используемых данных, а именно - поместятся они все в память или нет, это стоит учитывать при выборе того как запрос будет исполнен | ||
− | * использование '' статистики '' - в зависимости от того, какие данные конкретно хранятся, оптимизатор может принимать разные решения об используемых алгоритмах | + | * использование '' статистики '' - в зависимости от того, какие данные конкретно хранятся, оптимизатор может принимать разные решения об используемых алгоритмах, например, если из бд нужно обработать информацию которая занимает бОльшую её часть, то выгоднее прочитать все данные подряд (из-за кэш линий) и обработать их, если наоборот, нужно обработать порядка 10% бд, то если есть способ быстро итерироваться по этой части данных, то вполне разумно обрабатывать этот запрос прочитав только нужные данные. |
[[Файл:intro_arch_complete.png|400px|Эффективная обработка запроса]] | [[Файл:intro_arch_complete.png|400px|Эффективная обработка запроса]] |
Текущая версия на 19:22, 4 сентября 2022
Определение: |
Реляционная система управления базами данных (сокр. РСУБД, англ. Relational Database Management System, сокр. RDBMS) - СУБД, управляющая реляционными базами данных. |
Общий план
Верхнеуровнево, система управления баз данных состоит из хранилища данных и программы, которая к этим данным обращается.
Замечание, программа и данные могут быть на разных компьютерах.
Взаимодействие с СУБД
Под вопросом из первой картинки скрывается несколько компонент, один из них - протокол взаимодействия программы и СУБД. Этот протокол реализуется драйверами : с одного конца есть программа, взаимодействующая с драйвером, и, аналогично, с другого конца есть СУБД (которое обращается в хранилище) и также драйвер.
Замечание, на этой картинке СУБД и данные располагаются на одном компьютере, что позволяет не ходить по сети между СУБД и хранилищем, если БД распределённая и хранилище это несколько компьютеров, то ходить оп сети всё же придётся.
Замечание, традиционно, у каждого СУБД есть свой протокол, по которому происходит взаимодействие.
Обработка запроса
В программе есть sql запросы, которые требуется разобрать, этим занимается модуль разборщик запроса , который является парсером.
После разбора есть запрос, который нужно исполнить, этим занимается исполнитель запроса , который в отличие от разборщика взаимодействует с реальными данными. Но если исполнить запрос ровно так, как он написан, скорее всего это будет весьма не эффективно.
Эффективная обработка запроса
Чтобы запрос исполнялся более эффективно, есть построитель плана исполнения (также называется оптимизатором), который получает на вход разобранный запрос и решает как конкретно он будет исполнен, а именно:
- какие, откуда и в каком порядке будут загружаться данные
- какие индексы будут использованы
Улучшения исполнителя запроса :
- добавление модуля управление памятью - так как эффективность исполнение запроса может зависеть от кол-ва используемых данных, а именно - поместятся они все в память или нет, это стоит учитывать при выборе того как запрос будет исполнен
- использование статистики - в зависимости от того, какие данные конкретно хранятся, оптимизатор может принимать разные решения об используемых алгоритмах, например, если из бд нужно обработать информацию которая занимает бОльшую её часть, то выгоднее прочитать все данные подряд (из-за кэш линий) и обработать их, если наоборот, нужно обработать порядка 10% бд, то если есть способ быстро итерироваться по этой части данных, то вполне разумно обрабатывать этот запрос прочитав только нужные данные.