Разработка и реализация алгоритма отложенного обновления вторичных индексов
на LSM-деревьях в базах данных

Научный руководитель:

Волканов Дмитрий Юрьевич

Научный консультант:

Осипов Константин Аркадьевич

Выполнил:

Шпилевой Владислав Дмитриевич

План доклада

  1. Постановка задачи
  2. Базы данных и Б-деревья
  3. LSM-деревья и SSD
  4. Обновление индексов
  5. Проблема нескольких LSM-индексов
  6. Цель работы
  7. Предложенный алгоритм
  8. Выводы
  9. Результаты
  10. Планы

Постановка задачи

Разработать алгоритм обновления вторичных индексов на LSM-деревьев с отложенным удалением старых данных

LSM-дерево

Б-дерево

Память

Диск

Базы данных и Б-деревья

id name email salary
... ... ... ...

Таблица

name id
... ...
email id
... ...

Индекс 1

Индекс 2

SELECT WHERE name = ...

SELECT WHERE email = ...

UPDATE WHERE name = ...

Индексы - для быстрого поиска, удаления, обновления данных.

Это способ хранения и сортировки. Одни данные - много индексов, вариантов сортировок.

Вариант 1 - Б-дерево

Read/Write

balance

HDD

SSD

Баланс скорости случайных чтения/записи

Дисбаланс скорости последовательных

чтения/записи

"Бесплатные" чтения

 > 100х скорость HDD 

"Write amplification"

LSM-деревья

Память

Диск

Уровень 0

Уровень 1

Уровень N

  • Версионность записей
  • Горячие данные в памяти
  • Запись на диск всегда последовательна
  • Удаление старых версий всегда последовательно

LevelDB, RocksDB, Cassandra, Tarantool, Google BigTable, PNUTS, Riak

Обновление индексов

Б-дерево

LSM-дерево

INSERT OR REPLACE

DELETE

INSERT OR REPLACE

DELETE

Индекс

Индекс

Найти старую запись 

Вставить новую запись

Заменить старую запись

Запись на диск

Найти старую запись

Удалить

старую запись

Чтение диска

Вставить в нулевой уровень:

{данные, INSERT, версия}

Вставить в нулевой уровень:

{ключ, DELETE, версия}

Нет обращений к диску. Последовательная запись при сбросе уровня 0 на диск.

Проблема нескольких LSM-индексов: пример

a

b

c

d

Таблица

Вторичный индекс

Первичный индекс

INSERT (1,2,3,4)

{a=1, b=2, c=3, d=4, version=1}

{b=2, c=3, a=1, version=1}

REPLACE (1,5,6,7)

{a=1, b=2, c=3, d=4, version=1}

{a=1, b=5, c=6, d=7, version=2}

{b=2, c=3, a=1, version=1}

{b=5, c=6, a=1, version=2}

Удаление старых версий

{a=1, b=5, c=6, d=7, version=2}

{b=2, c=3, a=1, version=1}

{b=5, c=6, a=1, version=2}

Так как version 1 и 2 равны по ключу индекса:

{a=1} == {a=1}

{b=2, c=3} != {b=5, c=6}

!!!

Ошибка! Количество записей не одинаково

Проблема нескольких LSM-индексов: итог

Версионность вторичных индексов не работает

Больше индексов - медленнее обновления

...

Найти старое, вставить новое

Старые версии данных нужно удалять из вторичных индексов сразу, из-за чего:

Цель работы

Разработать алгоритм обновления LSM-деревьев с отложенным удалением старых данных

Версионность во вторичных индексах

Запись в дисковую БД без обращений к диску

Скорость записи не зависит от количества индексов

Предложенный алгоритм обновления данных

Рассмотрим обновление данных через REPLACE на примере таблицы:

Первичный индекс

Вторичный индекс

{1,2,3,4, version=1}

{1,5,6,7, version=2}
{1,8,9,10, version=3}

a

b

c

d

{2,3,1, version=1}

{5,6,1, version=2}

{8,9,1, version=3}

Первичный индекс объединяет LSM-уровни

Первичный индекс

{1,8,9,10, version=3}

Удаленные из первичного индекса записи можно использовать:

{1,2,3,4, version=1} и {1,5,6,7, version=2}

DELETE {2,3,1 version=1}

DELETE {5,6,1 version=2}

Вторичный индекс

{2,3,1, version=1}

{5,6,1, version=2}

{8,9,1, version=3}

Вторичный индекс объединяет LSM-уровни

Вторичный индекс

{8,9,1, version=3}

Старые версии удалены из обоих индексов без чтений диска!

Предложенный алгоритм удаления данных

Рассмотрим удаление данных на той же таблице

Первичный индекс

Вторичный индекс

{1,2,3,4, version=1}

{delete 1, version=2}

a

b

c

d

{2,3,1, version=1}

Первичный индекс объединяет LSM-уровни

Первичный индекс

{empty}

Удаленные из первичного индекса записи по dry delete можно использовать:

{1,2,3,4, version=1}

DELETE {2,3,1 version=1}

Вторичный индекс

{2,3,1, version=1}

{delete 2,3,1, version=1}

Вторичный индекс объединяет LSM-уровни

Вторичный индекс

Старые версии удалены из обоих индексов без чтений диска!

{empty}

Выводы

  • Неприменимо при наличии уникальных вторичных индексов
  • Неприменимо для UPDATE, INSERT
  • Может замедлить чтения ключей, имеющих не удаленные старые версии
  • Нет чтений диска на REPLACE и DELETE. Реально, это основная часть запросов;
  • Независимость от количества вторичных индексов

Полученные результаты

  • Разработан алгоритм отложенного обновления вторичных индексов на LSM-деревьев в базах данных;
  • Написана часть текста дипломной работы.

Планы

  • Реализовать алгоритм отложенного обновления вторичных индексов на LSM-деревьев в базах данных;
  • Получить математические оценки ускорения записи;
  • Провести апробацию реализации;
  • Дописать текст дипломной работы.

Разработка и реализация алгоритма отложенного обновления вторичных индексовна LSM-деревьях в базах данных

By Vladislav Shpilevoy

Разработка и реализация алгоритма отложенного обновления вторичных индексовна LSM-деревьях в базах данных

  • 1,550

More from Vladislav Shpilevoy