Что такое блокирующий фактор в СУБД,
Бит, на который я смотрел, сказал, что это полное значение блоков на запись (так B/R floor), где B - размер блока, а R - записи. Мне просто интересно, может ли кто-нибудь рассказать мне основную причину его использования, а также, действительно ли это ПОЛНОСТЬЮ?
Мое понимание FLOORED - 1.5, доходит до 1.0, для тех, кому интересно.
Да, это означает, сколько целых записей вписывается в блок.
(Блок представляет собой наименьшую единицу данных, к которой желательна базовая система хранения (hdd, san fs и т.д.). Обычно этот размер составляет 512 байт для жестких дисков.)
Он выровнен, потому что, если будет соответствовать 100 с половиной записи, в одном будет сохранено только 100 записей на блок.
Коэффициент блокировки довольно сильно используется во многих вычислениях, связанных с dbms.
Например:
У нас есть 10 000 000 записей. Каждая запись имеет длину 80 байтов. Каждая запись содержит уникальный ключ (скажем, номера социального страхования). Мы хотим найти кого-то по номеру социального обеспечения, чтобы быть быстрым.
Нам нужно что-то, чтобы измерить производительность. Вещь, которая занимает больше всего времени, запрашивает блок из жесткого диска. Вы знаете, это механическое устройство. Он должен переместить свою голову, и blabla, так что это действительно медленная работа по сравнению с тем, насколько быстрым является процессор, или по сравнению с тем, насколько быстрый доступ к оперативной памяти (ОЗУ). Хорошо, давайте скажем, что мы измеряем производительность операции по количеству обращений к диску. Мы хотим минимизировать количество обращений к диску. Хорошо, теперь мы знаем, как сказать, что что-то медленное или быстрое.
Многие обращения к диску → плохие
Очень немногие обращения к диску → хорошие
Давайте скажем, что на нашем мнимом hw каждый блок равен 5000 байт. Мы хотим рассчитать, сколько блоков нам нужно. Во-первых, нам нужно знать, сколько записей вписывается в один блок:
Blocking factor= floored((Block size)/(Record size))= floored(5000/80)= floored(62.5)= 62 record/block
И у нас есть 10000000 записей, поэтому нам нужны ceiled(10000000/62)=ceiled(161290.32)=161291 блоки для хранения всех этих данных.
Если кто-то должен был прочитать все блоки, чтобы найти одну запись по ключу (номер социального страхования), тогда это займет 161291 доступ к диску. Нехорошо.
Мы можем сделать лучше. Давайте создадим индексный файл. Мы построим разреженный индекс.
Редкий индекс в базах данных - это файл с парами ключей и указателей для каждого блока в файле данных. Каждый ключ в этом файле связан с определенным указателем на блок в отсортированном файле данных. В кластеризованные индексы с дублирующимися ключами, разреженный индекс указывает на самый низкий ключ поиска в каждом блоке.
Хорошо, поэтому у нас будет указатель и ключ в нашем индексном файле для каждого блока. Допустим, что на нашем мнимом hw указатель имеет длину 4 байта, а в нашем воображаемом мире номер социального обеспечения (ключ) занимает 6 байтов.
Итак, мы собираемся хранить одну 10-байтовую пару ключей-указателей для каждого блока в нашем индексе. Сколько из этих пар вписывается в один блок?
Blocking factor of the index file = floored(5000/10) = 500
... так что это означает, что 500 пар клавиш-указателей вписываются в один блок. И нам нужно сохранить 161291 из них, поэтому индексный файл займет ceiled(161291/500)=323 blocks
Индексный файл упорядочивается по ключу, поэтому мы можем выполнить двоичный поиск в нем, чтобы найти указатель на блок, который содержит запись. Выполнение двоичного поиска в индексном файле стоит не более ceiled(log2(323))=9 дисков acceses. Нам также нужен +1 доступ к диску для фактического чтения блока данных, на который указывает индексная запись.
Вау, мы получили наш поиск для работы в 10 дисковых достуках. Это довольно удивительно. Мы могли бы даже сделать лучше.:)
Хорошо, так что вы можете видеть, что фактор блокировки используется, например, в этом расчете.
Прочитайте мое последнее видео о факторе блокировки самым простым способом https://www.youtube.com/watch?v=dZbks-wnIWs