Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
Алгоритмы и структуры
данных для СУБД
в оперативной памяти
Konstantin
Osipov
Software
engineer
http://try.tarantool.org
Содержание
It's time for a complete
rewrite!..
или почему сегодня можно и
нужно создавать новые
СУБД
Database people are
logicians..
или почему инженерия ПО
не менее важна чем
красивые теории
First time is the best time!..
смотрим на аллокаторы
памяти
Deep dive...
специализированные
структуры данных для
оперативной памяти.
Архитектура СУБД
Постановка задачи - ACID
● ATOMICITY – транзакции работают по принципу “всё или
ничего” - ошибка в середине приводит к откату всех
действий транзакции
● CONSISTENCY – транзакции при модификации данных
сохраняют их консистентность
● ISOLATION - выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● DURABILTY – эффекты завершённых транзакций не
теряются даже в случае программного сбоя или выхода из
строя оборудования
● Isolation — выполнение параллельных транзакций имеет
тот же эффект что и их последовательное применение
● Consistency без isolation не достижим
● Пусть есть x, y, z – данные к которым осуществляется
совместный доступ
● Расписание (schedule) — возможная история
выполнения транзакций, конкретный порядок операций
чтения и записи относительно друг друга
E = r1[x] w1[x] w2[y] r2[z]
Isolation
● Если t1 транзакция использует X не допустить
модификацию X в других транзакциях до завершения t1
➔ Конкурентные транзакции работают с разными
поднаборами данных
➔ Порядок модификаций одних и тех же данных
фиксирован
● Блокировка (лок) — механизм обеспечения
эксклюзивного доступа
Isolation: классическое решение
● Таким образом, без 2PL история выполнения может
оказаться несериализуемой
● Достаточно ли 2PL? Да:
Two-Phase Locking Theorem: If all transactions in an
execution are two-phase locked, then the execution is
serializable.
2PL
● Много пользователей = много потоков, требуется
latching, т.е. разграничение доступа к ресурсам
● Внешнее хранение = два представления данных, в
памяти и на диске
Другие проблемы
Другие проблемы (2)
page header
modification log
page trailer
page directory
compressed
data
BLOB pointers
empty space
page header
page trailer
row offset array
row rowrow
Row
row
row
row rowrow
trx id
field 1
roll pointer
field pointers
field 2 field n
Константин Осипов
Решение
● храним 100% данных в RAM
● транзакции выполняются строго последовательно в
одном потоке
● получаем настоящий serial execution без блокировок!
● Шардировать всё равно придётся, поэтому бьём на
шарды сразу, с первой машины.
● t1 записала X и завершилась
● выполняется успешно t2, которая читает X
● запись t1 в журнал привела к ошибке
→ нужно уметь делать откат при ошибке записи в
журнал
Работа с журналом
Константин Осипов
Аспекты инженерии
Latency vs. throughput
Concurrency – сойство систем,
глобальное состояние которых
изменяется чередующимся
выполнением независимых или
частично-независимых функций
или компонент
Parallelism – система
конкурентна, но один или
несколько блоков могут
выполняться параллельно
Insight: concurrency != parallelism
With shared state:
- locking ← not composable
- wait-free algorithms – parallelism
- hardware transactional memory
Without shared state:
- functional programming
- actor model
Подходы к concurrency
● нет глобального состояния
● порядок выполнения не задаётся явно, зависит от
данных
● функциональные зависимости просты для
распараллеливания
→ composable
- нет языков достаточно эффективных для системного
программирования
Functional programming
+ портабельны, просты в использовании
+ низкие издержки
- не интегрируются в poll() event loop
- могут стать hot spot
Locking
● Дедлоки
● Конвоирование, хотспоты
● Лайвлоки
● Голодание
● Не универсальны – гранулярность статична, возможна
инверсия приоритетов
Locks are not composable!
+ ещё более низкие издержки
- сложно реализовать и тестировать
- не интегрируются в event loop
- могут стать hot spot
Wait-free algorithms
● Actors
– посылают, получают,
обрабатывают сообщения
– создают новых actors
● нет глобального состояния
- unbounded non-determinism
+ composable!
Actor model
Intel Xeon E5 микроархитектура
Intel Xeon E5 чип
● кооперативная
многозадачность внутри
потока
● обмен сообщениями
между потоками и узлами
→ Erlang “на коленке”
Выводы: actor model в Tarantool
Память, память, память
void *malloc(size_t size); 
void free(void *);
● работает в любом потоке
● для любого размера (совсем любого)
● “средние по больнице” требования к фрагментации
Классический менеджер памяти
● не нужна синхронизация
● нужна поддержка квот
● нужна поддержка консистентных снимков памяти
→ специализированные аллокаторы памяти
Аллокация в одном потоке
Аллокаторы Tarantool
● http://github.com/tarantool/small
● quota, slab_arena – аллоцирует данные выровненными 4МБ блоков,
поддерживает квоты, multi-threaded
● slab_cache – buddy system для выровненных блоков от 4КБ до 4МБ
● mempool - позволяет аллоцировать и освободждать участки одинакового
размера
● region_alloc – позволяет аллоцировать память, но не позволяет её
освобождать :)
● small – колллекция pool allocators для разных типоразмеров
● matras – аллокатор для выровненных блоков, работающий в 32 битном
адресном пространстве
Матрас
Extent size: 16 kB Block size: 16 B
Block id: 32 bit 0 0 0 0 0 0 0 0 1 0 1
0 0 0 0 0 0 0 0 1 0 1
id0 : high 11 bit
id1 : middle 11 bit
id2 : low 10 bit
0 0 0 0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
Матрас id2 : low 10 bit
L0 extent: array of 2048
pointers to L1 extents
Use id0 as index to find
pointer to L1 extent
L1 extents:
arrays of
2048
pointers to
L2 extents
L2 extents:
arrays of
1024 blocks
Use id1 as index to find
pointer to L2 extent
Use id2 as index to the block
Log-structured memory
Структуры данных
● b+*-tree: compact, cache-
oblivious, transactional
● worst case about 12 bytes per
tuple (4 bytes overhead),
average is 10
● worst case about 1.1 log(N)
comparisons per search
(AVL-tree about 1.45 log(N),
RB-tree about 2 log(N)
Хэши и деревья
● hash: linear hashing for
secondary storage
● bucket size is 5 slots
● transactional
The daily latency spike
● СУБД в оперативной памяти – отдельный вид технологии
● На создание такой технологии требуются десятки
человеко-лет R&D
● В результате имеем честный выигрыш по
производительности в 10 раз и больше
● Результат доступен по адресу
http://download.tarantool.org
Главное
@kostja_osipov
Konstantin
Osipov
Software
engineer
Tarantool
Вопросы?
fb.com/TarantoolDatabase
www.tarantool.orgkostja@tarantool.org

More Related Content

Константин Осипов

  • 1. Алгоритмы и структуры данных для СУБД в оперативной памяти Konstantin Osipov Software engineer http://try.tarantool.org
  • 2. Содержание It's time for a complete rewrite!.. или почему сегодня можно и нужно создавать новые СУБД Database people are logicians.. или почему инженерия ПО не менее важна чем красивые теории First time is the best time!.. смотрим на аллокаторы памяти Deep dive... специализированные структуры данных для оперативной памяти.
  • 4. Постановка задачи - ACID ● ATOMICITY – транзакции работают по принципу “всё или ничего” - ошибка в середине приводит к откату всех действий транзакции ● CONSISTENCY – транзакции при модификации данных сохраняют их консистентность ● ISOLATION - выполнение параллельных транзакций имеет тот же эффект что и их последовательное применение ● DURABILTY – эффекты завершённых транзакций не теряются даже в случае программного сбоя или выхода из строя оборудования
  • 5. ● Isolation — выполнение параллельных транзакций имеет тот же эффект что и их последовательное применение ● Consistency без isolation не достижим ● Пусть есть x, y, z – данные к которым осуществляется совместный доступ ● Расписание (schedule) — возможная история выполнения транзакций, конкретный порядок операций чтения и записи относительно друг друга E = r1[x] w1[x] w2[y] r2[z] Isolation
  • 6. ● Если t1 транзакция использует X не допустить модификацию X в других транзакциях до завершения t1 ➔ Конкурентные транзакции работают с разными поднаборами данных ➔ Порядок модификаций одних и тех же данных фиксирован ● Блокировка (лок) — механизм обеспечения эксклюзивного доступа Isolation: классическое решение
  • 7. ● Таким образом, без 2PL история выполнения может оказаться несериализуемой ● Достаточно ли 2PL? Да: Two-Phase Locking Theorem: If all transactions in an execution are two-phase locked, then the execution is serializable. 2PL
  • 8. ● Много пользователей = много потоков, требуется latching, т.е. разграничение доступа к ресурсам ● Внешнее хранение = два представления данных, в памяти и на диске Другие проблемы
  • 9. Другие проблемы (2) page header modification log page trailer page directory compressed data BLOB pointers empty space page header page trailer row offset array row rowrow Row row row row rowrow trx id field 1 roll pointer field pointers field 2 field n
  • 11. Решение ● храним 100% данных в RAM ● транзакции выполняются строго последовательно в одном потоке ● получаем настоящий serial execution без блокировок! ● Шардировать всё равно придётся, поэтому бьём на шарды сразу, с первой машины.
  • 12. ● t1 записала X и завершилась ● выполняется успешно t2, которая читает X ● запись t1 в журнал привела к ошибке → нужно уметь делать откат при ошибке записи в журнал Работа с журналом
  • 16. Concurrency – сойство систем, глобальное состояние которых изменяется чередующимся выполнением независимых или частично-независимых функций или компонент Parallelism – система конкурентна, но один или несколько блоков могут выполняться параллельно Insight: concurrency != parallelism
  • 17. With shared state: - locking ← not composable - wait-free algorithms – parallelism - hardware transactional memory Without shared state: - functional programming - actor model Подходы к concurrency
  • 18. ● нет глобального состояния ● порядок выполнения не задаётся явно, зависит от данных ● функциональные зависимости просты для распараллеливания → composable - нет языков достаточно эффективных для системного программирования Functional programming
  • 19. + портабельны, просты в использовании + низкие издержки - не интегрируются в poll() event loop - могут стать hot spot Locking
  • 20. ● Дедлоки ● Конвоирование, хотспоты ● Лайвлоки ● Голодание ● Не универсальны – гранулярность статична, возможна инверсия приоритетов Locks are not composable!
  • 21. + ещё более низкие издержки - сложно реализовать и тестировать - не интегрируются в event loop - могут стать hot spot Wait-free algorithms
  • 22. ● Actors – посылают, получают, обрабатывают сообщения – создают новых actors ● нет глобального состояния - unbounded non-determinism + composable! Actor model
  • 23. Intel Xeon E5 микроархитектура
  • 24. Intel Xeon E5 чип
  • 25. ● кооперативная многозадачность внутри потока ● обмен сообщениями между потоками и узлами → Erlang “на коленке” Выводы: actor model в Tarantool
  • 27. void *malloc(size_t size);  void free(void *); ● работает в любом потоке ● для любого размера (совсем любого) ● “средние по больнице” требования к фрагментации Классический менеджер памяти
  • 28. ● не нужна синхронизация ● нужна поддержка квот ● нужна поддержка консистентных снимков памяти → специализированные аллокаторы памяти Аллокация в одном потоке
  • 29. Аллокаторы Tarantool ● http://github.com/tarantool/small ● quota, slab_arena – аллоцирует данные выровненными 4МБ блоков, поддерживает квоты, multi-threaded ● slab_cache – buddy system для выровненных блоков от 4КБ до 4МБ ● mempool - позволяет аллоцировать и освободждать участки одинакового размера ● region_alloc – позволяет аллоцировать память, но не позволяет её освобождать :) ● small – колллекция pool allocators для разных типоразмеров ● matras – аллокатор для выровненных блоков, работающий в 32 битном адресном пространстве
  • 30. Матрас Extent size: 16 kB Block size: 16 B Block id: 32 bit 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 0 1 id0 : high 11 bit id1 : middle 11 bit id2 : low 10 bit 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
  • 31. Матрас id2 : low 10 bit L0 extent: array of 2048 pointers to L1 extents Use id0 as index to find pointer to L1 extent L1 extents: arrays of 2048 pointers to L2 extents L2 extents: arrays of 1024 blocks Use id1 as index to find pointer to L2 extent Use id2 as index to the block
  • 34. ● b+*-tree: compact, cache- oblivious, transactional ● worst case about 12 bytes per tuple (4 bytes overhead), average is 10 ● worst case about 1.1 log(N) comparisons per search (AVL-tree about 1.45 log(N), RB-tree about 2 log(N) Хэши и деревья ● hash: linear hashing for secondary storage ● bucket size is 5 slots ● transactional
  • 36. ● СУБД в оперативной памяти – отдельный вид технологии ● На создание такой технологии требуются десятки человеко-лет R&D ● В результате имеем честный выигрыш по производительности в 10 раз и больше ● Результат доступен по адресу http://download.tarantool.org Главное