bitcask — это механизм хранения ключей и значений, написанный на Erlang. Происхождение Bitcask тесно связано с Riak, распределенной базой данных «ключ-значение». В кластере Riak каждый узел использует подключаемый механизм хранения, и почти все механизмы хранения ключей-значений можно использовать в качестве механизма хранения одного узла. Подробное знакомство с Riak я расскажу позже, когда у меня будет возможность.

концепт дизайна

В MySQL и postgresql помимо реальных данных базы данных, хранящихся на диске, есть дополнительные лог-файлы, binlog в MySQL и wal-файлы в pg. Эти файлы журналов очень полезны при резервном копировании, восстановлении и создании подчиненных библиотек.

В дизайне bitcask все относительно просто, лог-файл сам по себе является базой данных. Резервное копирование тоже достаточно простое, достаточно скопировать все файлы в директорию данных и перестроить индекс на другом сервере. Кратко, есть следующие моменты:

Используйте ОЗУ (память) для хранения хэш-таблицы, значение в хэш-таблице указывает на файл в файловой системе и конкретное расположение значения, соответствующего ключу в файле.
Будь то вставка, обновление или удаление, запись добавляется в файл специального формата.
После каждой записи добавления обновляйте хэш-таблицу в памяти.
У каждого файла есть максимальное пространство.После того, как файл будет заполнен, напишите следующий, и он никогда не изменится после того, как он будет записан.
Существует процесс слияния для слияниястарые данные, чтобы предотвратить бесконечное накопление размера файла.
Кэш чтения: другие системы баз данных, такие как MySQL, PostgreSql, имеют довольно сложную конструкцию, bitcask не имеет родственной конструкции, но полагается на кеш файловой системы ядра операционной системы.

Преимущество

Операция записи: поскольку все операции являются присоединяемыми, скорость чрезвычайно высока, потому что не используется поиск (я не знаю, как выразить это по-китайски, закрой лицо вручную).
Операция чтения: O(1) дисковый запрос, потому что хеш-таблица в памяти уже знает, где находится значение имени таблицы.
Дизайн простой и понятный, что тоже является преимуществом

объяснить подробно

Следующее содержимое почти полностью взято из статьи bitcask, которая легко читается, а адрес:Basho.com/Боюсь-контент/…

Экземпляр bitcask — это каталог. Он предназначен для того, чтобы в любое время только один процесс операционной системы мог открыть bitcask для операций записи. Этот процесс можно рассматривать как службу bitcask. В любой момент активен только один файл в этом каталоге, и только этот файл можно записать. Когда размер активного файла достигает критического значения, bitcask создаст новый файл для замены текущего активного файла. Заменяемый файл называется старым файлом, и он неизменяем навсегда, и ни один процесс не будет записывать в него данные.

Все записи активных файлов являются добавлениями, что означает, что последовательные записи не требуют поиска на диске. Формат каждой записи следующий:

crc: контрольное значение, которое здесь можно игнорировать
tstamp: метка времени
ksz: размер ключа
value_sz : размер значения.

Следует отметить, что операция удаления просто вставляет запись, значение которой является специальным значением.

Вместе эти записи образуют файл bitcask:

Когда операция добавления завершается, структура данных в памяти, называемая keydir, обновляется. Keydir — это простая хеш-таблица, ключ — это ключ вставленных данных, а значение указывает на конкретное расположение вставленного значения данных в файловой системе.

file_id : как упоминалось ранее, у bitcask есть активные файлы и старые файлы данных, этот file_id указывает на один из файлов.
value_pos : начальная позиция значения в файле.
value_sz : размер значения

Когда происходит запись, исходные старые данные все еще хранятся на диске, но новые запросы на чтение ключа будут использовать самые последние данные в keydir. Как будет упомянуто позже, существует процесс слияния, который в конечном итоге удалит старые данные, которые больше не будут использоваться.

Операция чтения очень проста, и нет необходимости выполнять поиск по диску вообще. Запросите ключ из keydir в памяти и узнайте здесь file_id, местоположение и размер значения, а затем просто вызовите системный интерфейс чтения. Как правило, операционная система также имеет собственный независимый кэш чтения с диска, поэтому эта операция может выполняться быстрее.

Теперь давайте поговорим об операции слияния, упомянутой ранее. На самом деле это очень просто: процесс слияния ** просматривает все старые файлы и создает файл, который содержит только текущую последнюю версию данных. ** Когда эта часть будет завершена, будет создан файл подсказки, который по сути такой же, как файл данных, за исключением того, что они сохраняют позицию в файле, где находится значение, а не само значение. Этот файл может ускорить процесс восстановления каталога ключей из файлов каталогов.

Когда биткаск открывается процессом Erlang, он проверяет, не использует ли другой процесс Эрланга биткаск в той же виртуальной машине, и если да, то использует тот же каталог ключей с этим процессом. Если это не так, он сканирует все файлы данных и создает новый каталог ключей, что значительно улучшает процесс сборки для тех, у кого есть файлы подсказок.

Суммировать

Первый механизм хранения ключей и значений, с которым я столкнулся, был Redis. Все данные Redis устанавливаются в памяти (данные будут время от времени сохраняться на диске), что означает, что Redis очень быстро читает и записывает. Но у этого есть ограничение, то есть данные, хранящиеся одномашинным redis, не могут быть больше, чем сама память. Самое большое ограничение bitcask заключается в том, что в памяти должны храниться все ключи, потому что значение bitcask хранится на диске. Таким образом, по сравнению с Redis смысл биткаска не в том, чтобы сравнивать скорость с редисом, но когда ваши данные не могут быть сохранены в редисе, вы можете немного потерять скорость и попробовать биткаск.

Следите за моей публичной учетной записью WeChat