Велосипедостраительство в nosql, строим собственное nosql...

Когда надо изобретать свой велосипед? Строим NoSQL хранилище в приемлемые

сроки

Календарев Александр

Программист РБК-Медиа

[email protected]

2013 dev.it-portfolio.net

О чём доклад

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

- NoSQL

- key/value хранилищах

- это очень просто

- Сделай сам

dev.it-portfolio.net 2

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




- Под конкретные условия местности свой велосипед

- Велосипеды эволюционирует, как впрочем и все на свете, в том числе системы хранения данных

- Следовательно, всегда полезно думать над их улучшением

- Значить, и стоит пытаться изобрести что-то новое

-



- Под конкретные условия местности свой велосипед

- Велосипеды эволюционирует, как впрочем и все на свете, в том числе системы хранения данных

- Следовательно, всегда полезно думать над их улучшением

- Значить, и стоит пытаться изобрести что-то новое

- Или украсть идею и приспособить под свои нужды



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




- А может и нет





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





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

- получите новый опыт и знание



- NoSQL





NoSQL

- Термин озвучен 1991 Carlo Strozzi

- Carlo Strozzi 1998 представил ”NoSQL RDBMS, Copyright (C)”, язык запросов 4GL

- 2009 на “Open Source” Конференции применили этот термин ко всем хранилищам, не относящимся к RDBMS


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

- Key/value хранилища

- Поколоночные БД

- Графовые БД

Подробнее http://nosql-database.org/


http://nosql-database.org/





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

- Данные представлены в виде документов

- Форматы документы:

- XML: BerkeleyXML (XQuery), Sedna, Tamino (XQL)

- JSON/BSON: MondoDb(BSON), CoachDb(JSON)

- msgpack: Kumofs, tarantool 2.0

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


Key/value хранилища

Key-value хранилища запоминают и извлекают документы по ключу.

Распределенные хеш-таблицы (DHT) Пример: Riak, Voldemort, aerospike

Key/value хранилищa Пример: Redis, Tokyo/Kyoto Tyrant , tarantool 1.5, MemcacheDb


Поколоночные БД

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


Поколоночные БД

Преимущества:

- быстрая вставка,

- где документ представляем много колонок

- агрегирующие запросы в разы выше

Примеры: MonetDb, Accumulo, Vertica, Teradata

Недостаток: сложность загрузки данных

Cassandra, Hbase – не имеют поколоночную модель данных (технология SSTAble)


Графовые БД

Данные в виде сетевой модели


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

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


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

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



- NoSQL





Key/Value Хранилище

- Index и Массива данных (bucket)

- Сетевой части

- Вспомогательных Tools :

- Конфигурация

- Репликация

- Мониторинг


Index + Bucket


Index

- Hash (хеш) - Теоретически доступ/вставка за пост время: O(a)

- Поиск строго по ключу (операция равно).

- BTree (двоичное дерево) - Поиск по диапазону

- Теоретически доступ за O(log2(n) ÷ n) или O(h)

- Удаление – очень дорого O(l *log2(n) )

Недостаток: разбалансировка

Разновидности: Btree+, AVL-Tree, RB-tree, 2-3-tree …


Hash таблица


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

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

f = crc32(key) % n

Hash таблица


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

Hash


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

Хеш функция

Key 1

Key 51

Данные

Данные

Key 2 Длинные данные . . . . . .

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

коллизия

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

f = key % n



- NoSQL


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


Что надо сделать?

- Понять требования

- Изучить существующие решения

- Найти подходящее API:

- BerkeleyDb

- dict, qhash,

- Tokyo Cabinet

- LevelDb

- Sophia





- Найти подходящее API

- Сделать тесты

- Выбрать сетевую модель: - Однотредовая (corotine)/многотредовая модель

- block/nonblock: select, poll, epoll, kqueue

- libevent, libev (взять существующие библ.)

- Найти готовый кусок кода





- Найти подходящее API

- Сделать тесты

- Выбрать сетевую модель

- Определиться с протоколом.


О проекте

- Служба знакомств

- 50 млн. анкет

- 25 млн. активных

- 25-90 тыс. сессий


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

- Просмотр и поиск анкет

- Система сообщений

- Голосовалки

- Симпатии, Лайки

- Сбор статистики

- Геосервис : кто рядом.


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

- Результаты голосований

- Лайки

- Информация о просмотрах (счетчики)

- Геоданные


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


Bob: 01

Alice Counter: 1 Кто : 01



Bob: 01

Alice Counter: 2 Кто : 01, 02

Carol : 02



Bob: 01

Alice Counter: 3 Кто : 01, 02, 05

Carol : 02

Carlos : 05

Что хотелось?

- Простую функциональность:

- get(key)

- set(key)

- increment ( key )

- Кандидаты:

redis – можно использовать через Хеши

tarantool – удобный встроенный API (Lua)



- Простую функциональность;

get/set, Increment ( key1 , key2 )

- Персистентность

если упало, то данные не потерялись



- Простую функциональность


- Что-то не сложное и быстрое

- не занимающее много места

- MongoDb такое же сложное, как MySQL



- Простую функциональность:


- Что-то не сложное

- Не memory-only

- вдруг не хватит места:

- redis, tarantool не подходят

- Tokyo Tyrant – сложно реализовать лайки


Протокол

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

- Взять существующий

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

Недостатки: необходимо расширение, доработка под свои особенности


Протокол взять существующий

- Бинарный: protobuf, msgpack, memcached-bin, Apache-thrift, Apache-Avro, BSON,…

компактнее, быстрее, сложнее отладка

- Текстовый: XML, JSON, memcached, redis, …

Проще отладка

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


Протокол memcached

- GET ˽ [key] \r\n

- SET ˽ [key] ˽ [flag] ˽ [expire] ˽ [bytes] \r\n

- INCR ˽ [key] ˽ [value] ˽ [NOREPLAY] \r\n

- DELETE ˽ [key] ˽ [NOREPLAY] \r\n

- STATS \r\n

- FLUSH_ALL\r\n


Расширяем протокол

- Добавляем новые служебные команды: - FLUSH ˽ 1\r\n

- SHOW INI\r\n

- STAT CLEAR \r\n

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

- Вводим понятие относительная адресация /

- Вводим понятие символьный вид #


Философия построения хранилища

- Используем понятие «Банк данных»

Банк данных – обособленный массив данных, место для хранения (bucket)

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

- Каждой сущности по своему банку.

- Номер банка определен префиксом ключа


Принцип построения хранилища

Номер банка определен префиксом ключа


GET 1.23456 Банк 1

Банк 2

Банк 3

GET 3.23456

GET 2.23456

Key prefix key 32 bit 32 bit

``

Принцип построения хранилища

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


Типы банков


- Бинарные данные

- Символьные данные

- Счетчики [4 байта]

- «Индексные данные» на базе RB-tree

Индексные данные могут быть привязаны к счетчикам

Привязка осуществляется в конфиге.

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

Счетчики просмотров:

INCR ˽ 1.5 ˽ 1 \r\n ключ анкеты = 5

SET˽ 1.5 ˽ 0 ˽ 0 ˽ 1 \r\n 0 \r\n сброс

50

Реализация лайка

- Увеличение счетчика Алисы :

INCR ˽ 1.5 ˽ 1 \r\n ключ Алисы = 5

- Добавляем в хеш Алисы ключ Боба:

SET ˽ 2.5.1 ˽0˽0˽1\r\n1\r\n ключ Боба = 1


Bob:01

Alice


Однако если расширить протокол:

INCR ˽ 2.5.1/1 ˽ 1 \r\n

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


Bob:01

Alice

key



- Вариант 1, как сортированный массив.

- Доступ за ln(n), n = 100 – 4 000 ( 7-14 шагов )

- Трудности с алгоритмом Garbage Collector.

- Вариант 2, используем Tree индекс

- Индекс составной 64 bit: key1 key2

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

32 bit 32 bit ``

Расширяем протокол

Вводим понятие символьный вид #

Запомнили в символьном виде:

SET ˽ #1.5 ˽0˽0˽1\r\n1\r\n

GET ˽ #1.5 \r\n вернет символ “1” – 1 байт

GET ˽ 1.5 \r\n вернет int32: 0x1 – 4 байта

SET ˽ 1.5 ˽0˽0˽1\r\n1\r\n

GET ˽ 1.5 \r\n вернет int32: 0x31

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


чистка мусора (garbage collector)


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

Проблемы


- Удаленные профили надо чистить

- Постоянно растет память, нужно сбрасывать кеш, переоткрывать таблицы

- Вывод: Необходим мониторинг

Мониторинг

- Настраиваем rdd

- Рисуем графики


- Команда stats



- Память из /proc/self/stat

- Производительность: кол-во запросов в сек

- Загрузка: отношение времени исполнения к циклу измерения

- Размер корзины

- Общее кол-во ключей

Тестирование


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

http://cxxtest.com/

http://cxxtest.com/

http://cxxtest.com/

https://github.com/akalend/mcstrass



Используемые Библиотеки


libev – сетевая однотредовая модель libtokyocabinet – hashdb & treedb tcmalloc - Memory pool allocator

Рекомендуемые Библиотеки


Сетевые: 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/

http://libevent.org/



http://software.schmorp.de/pkg/libev.html



http://software.schmorp.de/pkg/libcoro.html



http://xmailserver.org/libpcl.html



http://swtch.com/libtask/



Рекомендуемые Библиотеки


Хештаблицы: 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-data-

dictionary.shtml

http://fallabs.com/

http://fallabs.com/

http://fallabs.com/

https://github.com/fmela/libdic



http://pokristensson.com/strmap.html

http://sglib.sourceforge.net/



http://judy.sourceforge.net/

http://code.google.com/p/leveldb/

http://code.google.com/p/leveldb/

http://sphia.org/

http://sphia.org/

http://troydhanson.github.io/uthash/index.html

http://troydhanson.github.io/uthash/index.html

http://www.sunrisetel.net/software/devtools/sunrise-data-dictionary.shtml







Рекомендуем почитать


Блог о высоких нагрузках http://highloadblog.ru/

http://ru.wikipedia.org/wiki/Хеш-таблица http://ru.wikipedia.org/wiki/B-дерево

Алгоритмы и структуры http://algolist.ru/

Опыт создания key/value хранилищ СА сент,окт,нояб,дек 2012, март 2013.

http://highloadblog.ru/

http://ru.wikipedia.org/wiki/Хеш-таблица





http://ru.wikipedia.org/wiki/B-дерево





http://algolist.ru/

http://algolist.ru/

http://algolist.ru/

Вопросы


Q: Open Source ?

A: в полной версии нет, не вижу смысла

есть прототип, который можно заточить под

любые нужды вашего проекта

https://github.com/akalend/mymc




Велосипедостраительство в nosql, строим собственное nosql...

Technology