Skip to main content

Глоссарий

Общее​

Определение квантиля​

Квантиль в математической статистике — значение, которое заданная случайная величина не превышает с фиксированной вероятностью. Если вероятность задана в процентах, то квантиль называется процентилем или перцентилем.
Например, фраза «90-й процентиль массы получаемых после обработки изделий составляет 4 кг» означает, что 90 % изделий после обработки имеют вес меньше либо равный 4 кг, а 10 % изделий после обработки имеют вес, больший 4 кг.
Значение, которое делит сортированное множество значений пополам называется медианой и является 50-м процентилем заданного множества. Получение процентилей для множества позволяет отбросить граничные аномальные значения, оценить распределение значений или найти медиану, которая может использоваться аналогично среднему арифметическому, моде и другим мерам центральной тенденции.

Данные и индексы​

Таблица​

Таблица в базе данных - логическая сущность для организации записи, изменения и удаления данных. Понятие таблицы используется во многих СУБД и в целом очень схоже. Физическая же структура хранения данных может очень сильно отличаться между разными системами управления БД.

Куча (Heap)​

Куча - вариант организации данных в таблице базы данных, при котором данные хранятся без упорядочивания. Зачастую "кучей" называют саму таблицу с таким вариантом хранения. Хранение данных в куче эффективно с точки зрения скорости вставки новых записей. Однако выборка и изменение данных будет требовать сканирования таблицы (перебора всех записей), что является крайне ресурсоёмкой операцией. Вычислительная сложность поиска в куче описывается как O(n), где n - количество записей в таблице. Таким образом, существует линейная зависимость между количеством элементов в таблице и скоростью выполнения поиска.
Для ускорения поиска и выборки данных используются индексы.

Индекс​

Индекс - дополнительная структура данных в виде сбалансированного дерева (B-Tree), построенная по данным таблицы. Индекс позволяет существенно повысить скорость поиска данных в таблице. Так, сложность поиска в индексе описывается как O(log n), т.е. зависимость скорости поиска от количества записей в таблице - логарифмическая.
Индекс строится по выбранным полям таблицы. Эти поля являются ключами индекса. Для того чтобы индекс использовался, условия выборки, описанные в запросе, должны совпадать с ключами индекса.
Индекс всегда поддерживается в актуальном состоянии: новые записи размещаются в индексе с учетом ключей и настроек сортировки индекса непосредственно в момент добавления в таблицу. Таким образом, наличие индекса влияет на время вставки и изменения записей. Излишнее количество индексов может пагубно сказываться на производительности. На одной таблице может быть создано неограниченное количество некластерных индексов и только один кластерный.

Кластерные индексы​

Индекс является кластерным, если фактическая структура хранения данных в таблице соответствует структуре дерева индекса. Можно сказать, что таблица, на которой построен кластерный индекс, представляет собой дерево, на листовых узлах которого хранятся сами данные таблицы. Это объясняет, почему кластерный индекс может быть только один - невозможно хранить одни и те же данные с разной сортировкой. Использование кластерного индекса может давать выигрыш за счёт того, что после выполнения поиска не нужно обращаться к данным таблицы для получения данных, не входящих в ключ индекса - все данные есть в листовом узле. Т.е. кластерный индекс всегда является покрывающим. Если на таблице построен кластерный индекс, то связь некластерного индекса с данными таблицы будет организована по ключу кластерного индекса. Т.е. в листовых узлах некластерных индексов будут значения ключа связанного кластерного индекса. Эту особенность важно учитывать при проектировании структуры таблицы, т.к. большой ключ кластерного индекса приведёт увеличению размеров всех некластерных индексов и, как следствие, к замедлению всех операций с ними.

Некластерные индексы​

Индекс является некластерным, если он не влияет на структуру хранения данных таблицы. Некластерных индексов может быть создано неограниченное количество. Некластерный индекс содержит только ключи индекса и поля ключа кластерного индекса (если он есть). Это значит, что поиск по некластерному индексу как правило потребует обращения к данным таблицы, для получения недостающих полей.

Покрывающий индекс​

Если индекс содержит все поля, необходимые для выполнения запроса, он является покрывающим. Является индекс покрывающим или нет, определяется для каждого конкретного запроса - один и тот же индекс может быть покрывающим для одного запроса, и не покрывающим для другого.
Поиск по покрывающему индексу - наиболее быстрый способ поиска и выборки данных.

Фрагментация индекса​

Операции вставки, изменения и удаления данных в таблицах и связанных индексах приводят к тому, что логический порядок сортировки данных индекса перестаёт совпадать с фактическим расположением данных на накопителе. Это приводит к увеличению количества операций чтения.
Высокая фрагментация часто используемых индексов очень сильно влияет на производительность баз данных, расположенных на шпиндельных дисках. Для базах на современных дисках - практически не оказывает влияния.
Фрагментация устраняется при помощи операций перестроения или реорганизации индекса.

Страница данных​

Данные в таблицах и индексах организованы в логические блоки фиксированного размера. Эти блоки данных называются страницами данных и по умолчанию имеют размер 8Кб. При работе с данными СУБД считывает и записывает данные постранично. Это значит, что даже если размер требуемой строки 10 байт, с диска будет прочитана страница целиком - 8Кб. Многие инструменты для анализа объёма считанных и записанных данных в СУБД возвращают информацию именно в разрезе количества прочитанных/измененных страниц. Изменение размера страниц возможно, но не рекомендуется и в инстялляциях 1С не встречается. Поэтому, чтобы получить фактический объём данных в килобайтах, количество страниц надо умножить на 8.

Блок данных​

В СУБД Postgres вместо термина "страница данных" используется "блок данных". Используемые в Алькир средства мониторинга обращений к диску позволяют разделять прочитанные блоки на 3 группы: shared, local и temp. В блоках shared хранятся данные обычных таблиц и их индексы, в блоках local - данные временных таблиц и их индексы, в блоках temp - служебные данные, необходимые для выполнения некоторых запросов и операций.

Логические и физические чтения​

Для выполнения любой операции с данными, страница, содержащая эти данные, помещается СУБД в оперативную память. Операция чтения данных с физического диска называется физическим чтением. Область оперативной памяти, содержащая прочитанные страницы, называется буферный кэш. Страница, помещенная в буферный кэш, не удаляется из него сразу же после выполнения операции и может быть использована другими запросами, таким образом повышая производительность работы с данными. Операция получения страницы из оперативной памяти называется логическим чтением. Физические чтения намного менее производительны чем логические, даже при использовании современных дисков. Большое количество физических чтений в системе может говорить о недостатке оперативной памяти (буферный кэш не может вместить всех необходимых страниц и часть страниц из него удаляется). Большое количество физических чтений для одного запроса может говорить о выборке данных с нетипичными отборами (например, за прошлые периоды). Большое количество логических и/или физических чтений может говорить о неэффективности используемых отборов и индексов.

B-Tree​

B-дерево – это сбалансированное дерево, предназначенное для ускорения операций выборки, изменения и удаления данных. Операция поиска по дереву имеет нюансы и может быть реализована по-разному в разных СУБД.

Более подробно можно прочитать в Википедии.

Page life expectancy​

Page life expectancy - счетчик реализованный в MS SQL и показывающий оценочное время жизни страниц данных в буферном кэше в секундах. Чем ниже это значение, тем чаще СУБД приходится обращаться к диску для получения данных. Низкое время жизни страниц в памяти может говорит о том, что объёма оперативной памяти, выделенной под буферный кэш, недостаточно для хранения обрабатываемых страниц. Решением может быть как увеличение объёма объёма памяти доступного СУБД, так и сокращение количества считываемых данных путём добавления индексов и оптимизации запросов. Для данного счетчика нет каких-то общепризнанных референсных значений. В общем случае, внимание ему стоит уделить при средних значениях ниже 600, либо при наличии периодов, когда значение падает до 0.