16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв

Когда надо изобретать свой велосипед?
Строим NoSQL хранилище в приемлемые
сроки
Календарев Александр
Программист РБК-Медиа
akalend@mail.ru

2013

dev.it-portfolio.net

О чём доклад
-

о велосипедах
NoSQL
key/value хранилищах
это очень просто
Сделай сам


2

О велосипедах


3



4



5

- Под конкретные условия местности свой
велосипед
- Велосипеды эволюционирует, как впрочем и
все на свете, в том числе системы хранения
данных
- Следовательно, всегда полезно думать над их
улучшением
- Значить, и стоит пытаться изобрести что-то
новое

6

- Под конкретные условия местности свой
велосипед
- Велосипеды эволюционирует, как впрочем и
все на свете, в том числе системы хранения
данных
- Следовательно, всегда полезно думать над их
улучшением
- Значить, и стоит пытаться изобрести что-то
новое
- Или украсть идею и приспособить под свои
нужды

7

- Может получиться


8

- А может и нет


9

- Это как повезет


10

- Но в любом случае Вы
всегда останетесь в
плюсе:
- получите новый опыт и
знание


11

-

NoSQL
Сделай сам


12

NoSQL
- Термин озвучен 1991 Carlo Strozzi
- Carlo Strozzi 1998 представил ”NoSQL
RDBMS, Copyright (C)”, язык запросов 4GL
- 2009 на “Open Source” Конференции
применили этот термин ко всем
хранилищам, не относящимся к RDBMS


13

-

Документно-ориентированные БД
Key/value хранилища
Поколоночные БД
Графовые БД

Подробнее

http://nosql-database.org/


14

Документно-ориентированные
- Данные представлены в виде документов
- Форматы документы:
- XML: BerkeleyXML (XQuery), Sedna, Tamino (XQL)
- JSON/BSON: MondoDb(BSON), CoachDb(JSON)
- msgpack: Kumofs, tarantool 2.0

Рекомендуется использовать для слабо
структурированной информации


15

Key/value хранилища
Key-value хранилища запоминают и
извлекают документы по ключу.
Распределенные хеш-таблицы (DHT)
Пример: Riak, Voldemort, aerospike
Key/value хранилищa
Пример: Redis, Tokyo/Kyoto Tyrant , tarantool
1.5, MemcacheDb

16

- Данные собраны в колонки и представляют
собой хеш таблицы.


17

Преимущества:
- быстрая вставка,
- где документ представляем много колонок
- агрегирующие запросы в разы выше
Примеры: MonetDb, Accumulo, Vertica, Teradata
Недостаток: сложность загрузки данных
Cassandra, Hbase – не имеют поколоночную
модель данных (технология SSTAble)

18

Графовые БД
Данные в виде сетевой модели

Пример: Neo4, InfoGrid, GraphBase, DEX

19

NoSQL сравнение моделей хранения
key/value

RDBMS

документно-ориентированные

поколоночно-ориентированные


20

-

NoSQL
Сделай сам


21

Key/Value Хранилище
- Index и Массива данных (bucket)
- Сетевой части
- Вспомогательных Tools :
- Конфигурация
- Репликация
- Мониторинг


22

Index + Bucket


23

Index
- Hash (хеш)
- Теоретически доступ/вставка за пост время: O(a)
- Поиск строго по ключу (операция равно).

- BTree (двоичное дерево)
- Поиск по диапазону
- Теоретически доступ за O(log2(n) ÷ n) или O(h)
- Удаление – очень дорого O(l *log2(n) )
Недостаток: разбалансировка
Разновидности: Btree+, AVL-Tree, RB-tree, 2-3-tree …

24

Hash таблица
f = crc32(key) % n

Хеш-функция:
crc32/64, md5, Jenkins,
Murmur

Масив данных [bucket]
для хранения


25

Hash таблица

Так как объем Банк
данных конечный, то
возможна коллизия:
Sabdra Dee & John
Smeet


26

Hash
Хеш таблицу характеризуют
– Ёмкость bucket
– Разреженность массива
– Длинна элемента массива
f = key % n

коллизия
Key 1

Хеш функция

Длинные
данные

Данные

Key 51

Данные

Key 2

Длинные данные . . . . . .
Длинные Данные часть II


27

-

NoSQL
это очень просто , cделай сам


28

Что надо сделать?
- Понять требования
- Изучить существующие решения
- Найти подходящее API:
-

BerkeleyDb
dict, qhash,
Tokyo Cabinet
LevelDb
Sophia

29

-

Понять требования
Изучить существующие решения
Найти подходящее API
Сделать тесты
Выбрать сетевую модель:
-

Однотредовая (corotine)/многотредовая модель
block/nonblock: select, poll, epoll, kqueue
libevent, libev (взять существующие библ.)
Найти готовый кусок кода

30

-

Понять требования
Изучить существующие решения
Найти подходящее API
Сделать тесты
Выбрать сетевую часть
Определиться с протоколом.


31

О проекте
-

Служба знакомств
50 млн. анкет
25 млн. активных
25-90 тыс. сессий


32

О проекте (функциональная часть)
-

Просмотр и поиск анкет
Система сообщений
Голосовалки
Симпатии, Лайки
Сбор статистики
Геосервис : кто рядом.


33

Что хотелось хранить?
-

Результаты голосований
Лайки
Информация о просмотрах (счетчики)
Геоданные


34

Лайки, голосовалки, просмотры
Counter: 1

Alice

Кто : 01

Bob: 01


35

Counter: 2

Alice

Кто : 01, 02

Bob: 01
Carol : 02


36

Counter: 3

Alice

Кто : 01, 02, 05

Bob: 01
Carol : 02
Carlos : 05

37

Что хотелось?
- Простую функциональность:
- get(key)
- set(key)
- increment ( key )
- Кандидаты:
redis – можно использовать через Хеши
tarantool – удобный встроенный API (Lua)


38

- Простую функциональность;
get/set, Increment ( key1 , key2 )
- Персистентность
если упало, то данные не потерялись


39

- Простую функциональность
- Персистентность
- Что-то не сложное и быстрое
- не занимающее много места
- MongoDb такое же сложное, как MySQL


40

-

Простую функциональность:
Персистентность
Что-то не сложное
Не memory-only
- вдруг не хватит места:
- redis, tarantool не подходят
- Tokyo Tyrant – сложно реализовать лайки


41

Протокол
- Разработать свой
Преимущества: учтены все особенности

- Взять существующий
Преимущества: не нужно разрабатывать клиенты
Недостатки: необходимо расширение, доработка под
свои особенности


42

Протокол взять существующий
- Бинарный: protobuf, msgpack, memcached-bin,
Apache-thrift, Apache-Avro, BSON,…
компактнее, быстрее, сложнее отладка

- Текстовый: XML, JSON, memcached, redis, …
Проще отладка

Есть утилиты: telnet, nc, memget, redis-cli


43

Протокол memcached
-

GET ˽ [key] rn
SET ˽ [key] ˽ [flag] ˽ [expire] ˽ [bytes] rn
INCR ˽ [key] ˽ [value] ˽ [NOREPLAY] rn
DELETE ˽ [key] ˽ [NOREPLAY] rn
STATS rn
FLUSH_ALLrn


44

Расширяем протокол
- Добавляем новые служебные команды:
- FLUSH ˽ 1rn
- SHOW INIrn
- STAT CLEAR rn

- Расширяем существующие команды через
ключ:
- key: prefix.key[.subkey]
- Вводим понятие относительная адресация /
- Вводим понятие символьный вид #

45

Философия построения хранилища
- Используем понятие «Банк данных»
Банк данных – обособленный массив
данных, место для хранения (bucket)
- Разбиваем данные по функциональности:
лайки, голосования, просмотры
- Каждой сущности по своему банку.
- Номер банка определен префиксом ключа


46

Принцип построения хранилища
Номер банка определен префиксом ключа
Key prefix
32 bit

``

key
32 bit
Банк 1

GET 1.23456

Банк 2

GET 3.23456
GET 2.23456

Банк 3


47

Принцип построения хранилища
Номер банка определен префиксом ключа
Несколько банков могут быть объединены в
одну физическую хеш таблицу
(определяется конфигом)
Достоинство такого распределения:
• уменьшаем нагрузку на каждую хеш таблицу
• Шаг к масштабированию
• Распределение по типу использования


48

Типы банков
-

Бинарные данные
Символьные данные
Счетчики [4 байта]
«Индексные данные» на базе RB-tree
Индексные данные могут быть привязаны к
счетчикам
Привязка осуществляется в конфиге.


49

Реализация счетчика просмотров

Счетчики просмотров:
INCR ˽ 1.5 ˽ 1 rn
ключ анкеты = 5
SET˽ 1.5 ˽ 0 ˽ 0 ˽ 1 rn 0 rn
сброс
50

Реализация лайка
Alice
Bob:01

- Увеличение счетчика Алисы :
INCR ˽ 1.5 ˽ 1 rn
ключ Алисы = 5
- Добавляем в хеш Алисы ключ Боба:
SET ˽ 2.5.1 ˽0˽0˽1rn1rn ключ Боба = 1

51

Alice
Bob:01

Однако если расширить протокол:
INCR ˽ 2.5.1/1 ˽ 1 rn
key

Вместо двух обращений – одно.

52

- Вариант 1, как сортированный массив.
- Доступ за ln(n), n = 100 – 4 000 ( 7-14 шагов )
- Трудности с алгоритмом Garbage Collector.

- Вариант 2, используем Tree индекс
- Индекс составной 64 bit: key1 `` key2
32 bit

32 bit

- Выборка диапазона Key1 0x00 - Key1 0xFFFFFFFF


53

Расширяем протокол
Вводим понятие символьный вид #
Запомнили в символьном виде:
SET ˽ #1.5 ˽0˽0˽1rn1rn
GET ˽ #1.5 rn вернет символ “1” – 1 байт
GET ˽ 1.5 rn вернет int32: 0x1 – 4 байта
SET ˽ 1.5 ˽0˽0˽1rn1rn
GET ˽ 1.5 rn вернет int32: 0x31

Пригодится в отладке типа index

54

чистка мусора (garbage collector)
Удаленные профили
нужно удалять из хранилища
Требуется перебор всех данных
Делается, блоками, когда
процессор наименее загружен
Вычисляем загрузку сервиса,
Подбираем опытным путем.

55

Проблемы
- Удаленные профили надо чистить
- Постоянно растет память, нужно
сбрасывать кеш, переоткрывать таблицы
- Вывод: Необходим мониторинг


56

Мониторинг
- Команда stats
- Настраиваем rdd
- Рисуем графики


57

- Память из /proc/self/mstat
- Производительность: кол-во запросов в сек
- Загрузка: отношение времени исполнения к
циклу измерения
- Размер корзины
- Общее кол-во ключей


58



59

Тестирование
API покрыли тестами Схх http://cxxtest.com
Тестирование производительности:
aналог Apache ab, протокол memcached
https://github.com/akalend/mcstrass


60

Используемые Библиотеки
libev – сетевая однотредовая модель
libtokyocabinet – hashdb & treedb
tcmalloc - Memory pool allocator


61

Рекомендуемые Библиотеки
Сетевые:
libevent2 http://libevent.org/
libev
http://software.schmorp.de/pkg/libev.html

Коротины:
libcoro http://software.schmorp.de/pkg/libcoro.html
pcl
http://xmailserver.org/libpcl.html
libtask http://swtch.com/libtask/


62

Рекомендуемые Библиотеки
Хештаблицы:
Tokyo/Kyoto http://fallabs.com/ [cabinet]
libdict
https://github.com/fmela/libdic
strmap
http://pokristensson.com/strmap.html
sglib
http://sglib.sourceforge.net/
Judy
http://judy.sourceforge.net/
levelDb
http://code.google.com/p/leveldb/
Sophia
http://sphia.org/
uthash http://troydhanson.github.io/uthash/index.html
sunriseDb http://www.sunrisetel.net/software/devtools/sunrise-datadictionary.shtml

63

Рекомендуем почитать
Блог о высоких нагрузках
http://highloadblog.ru/
http://ru.wikipedia.org/wiki/Хеш-таблица
http://ru.wikipedia.org/wiki/B-дерево
Алгоритмы и структуры http://algolist.ru/
Опыт создания key/value хранилищ
СА сент,окт,нояб,дек 2012, март 2013.


64

Вопросы
Q:

Open Source ?

A:

в полной версии нет, не вижу смысла
есть прототип, который можно заточить под
любые нужды вашего проекта
https://github.com/akalend/mymc


65

16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Semelhante a 16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв

Semelhante a 16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв (20)

Mais de IT-Portfolio

Mais de IT-Portfolio (9)

16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв