TokuMX

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:34, 25 ноября 2017.
TokuMX
fraimed
Разработчики: Tokutek
Написана на: C++
Операционная система: Linux
Платформа: x32, x64
Локализация: Английский
Тип ПО: База данных
Лицензия: GNU AGPL[1]
Веб-сайт официальный сайт

TokuMX - высокопроизводительная замена MongoDB с открытым исходным кодом, которая значительно улучшает производительность и эффективность работы. За счёт использования продвинутых методов сжатия данных и технологии Fractal Tree Indexing, Percona TokuMX улучшает производительность приложений MongoDB, одновременно значительно сокращая расход свободного места.

Однако по заявлению производителя рекомендуется переход на обновленное решения Percona Server for MongoDB от этого же производителя.

TokuMX - ветвь (форк) MongoDB версии 2.2 со многими возможностями версии 2.4. Tokutek утверждают, что их БД-сервер сжимает обычную MongoDB базу данных в 4 и более раз. Он также поддерживает кластерные индексы для минимизации количества операций ввода-вывода при сканировании через связанные документы.[2]

Большинство файлов исходного кода TokuMX доступны под GNU Affero General Public License (AGPL). Библиотека TokuKV Fractal Tree Indexing доступна под GNU General Public License (GPL) версии 2, с дополнительной выдачей патента.[3]

Fractal Tree Indexing

Одним из нововведений TokuMX является то, что она отменяет давнее правило баз данных: чтобы добиться хорошей производительности записи, рабочий набор индексов должен помещаться в памяти[4]. Основная идея этого правила: если рабочий набор ваших индексов не умещается в памяти, то запись будет вызывать операции ввода-вывода, что скажется на производительности. Так что либо убедитесь, что ваши индексы умещаются в памяти, либо убедитесь, что способ вставки ваших индексов сохраняет малым рабочий набор.

В TokuMX это просто не так. Новшество индексов на фрактальных деревьях заключается в том, что по мере того, как ваш рабочий набор превышает основную память, производительность записи остаётся неизменной. По этой причине фрактальные деревья так хорошо себя проявляют в тестовых условиях большого объёма записи (как для MongoDB, так и для MySQL).

Так как же TokuMX достигает такой производительности по записи там, где это не удаётся другим БД? Это происходит за счёт замены B-деревьев, основной структуры данных во многих БД (MongoDB, MySQL, BerkeleyDB, и тд…) на фрактальные деревья, структуру данных, оптимальную по записи.

Что мы имеем в виду под оптимальной по записи структурой данных?

Для начала необходимо понять, почему B-деревья сдают позиции, когда индексы перестают помещаться в памяти. Ниже приведена картинка B-дерева.

B-дерево

TokuMX.B-Tree.png

B-дерево - простая (и элегантная) структура данных. Внутренние вершины содержат много опорных точек и указатель, а листья хранят все данные. Для вставки в B-дерево необходимо пройти в листовую вершину, хранящую данные и поместить в неё новые данные. Если все данные помещаются в память, это работает быстро. Однако если большинство данных не вмещается (как, например, на картинке выше, где только внутренние вершины и лишь пара листовых вмещаются), тогда достижение этих листьев требует выполнения ввода-вывода. По факту, практически все вставки будут инициировать ввод-вывод. Из-за этого и страдает производительность. Если ваш жёсткий диск может выполнять около ста операций ввода-вывода в секунду, тогда ваше B-дерево может обработать не более ста вставок в секунду. Вот поэтому MongoDB и MySQL проигрывают iiBench, и пользователей справедливо просят "держать рабочий набор индексов в памяти".

Чем же фрактальные деревья настолько лучше? Если кратко, то они уменьшают количество операций ввода-вывода. И вот, как.

Фрактальное дерево

Обратите внимание на серые буферы для во внутренних вершинах.

Ключевое различие между индексами на фрактальных деревьях и B-деревьях, объясняющее различие в производительности записи, заключается во внутренних вершинах:

  • в B-деревьях, внутренние вершины содержат только ключевые точки и указатели для каждого ребёнка.
  • во фрактальных деревьях внутренние вершины содержат ключевые точки, указатели и буферы для каждого ребёнка.

Обратите внимание на серые буферы для во внутренних вершинах на картинке выше.

Вот как работает операция записи с применением буферов:

  • найти в корневой вершине, в какого ребёнка должна произойти запись
  • сериализовать ожидающую операцию в буфер
  • если в буфере, связанном с этим ребёнком есть место, возврат. Если нет - сбросить ожидающие операции в буфер на уровень ниже, освобождая место для будущих записей.

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

Почему же этот алгоритм показывает такую хорошую производительность? Если кратко, он уменьшает количество операций ввода-вывода (всё действительно связано только с вводом-выводом). Операции ввода-вывода очень медленные, поэтому если нам необходимо прибегать к ним, хочется использовать их с максимальной эффективностью. С B-деревьями при записи мы инициируем операцию ввода-вывода для вставки одного документа, или строки, или пары "ключ-значение". При использовании фрактальных деревьев, полагая, что корневая вершина всегда находится в памяти, мы знаем, что выполняя операцию ввода-вывода при записи, мы делаем это для записи полного буфера данных, который может включать очень много документов (или строк и тд). За счёт того, что каждая операция ввода-вывода выполняет сразу много записей, индексы на фрактальных деревьях значительно уменьшают количество операций ввода-вывода, избавляясь от серьёзного недостатка B-деревьев.

За счёт этого индексы на фрактальных деревьях не обязаны полностью помещаться в памяти, и TokuMX позволяет достигать такой высокой производительности по записи.

Если же данные полностью помещаются в памяти, то фрактальные деревья не дают алгоритмических преимуществ над B-деревьями по скорости записи - обе структуры данных работают быстро.

Сравнение с MongoDB

У TokuMX есть несколько недостатков по сравнению с MongoDB[5]:

  • Отсутствуют 2d/2dsphere индексы. Они не были реализованы, потому что разработчики не считают их часто используемыми. Впрочем, они не отрицают возможности добавления их в будущих версиях.
  • Отсутствуют текстовые индексы по той же причине.
  • Более медленные запросы count() Проблема в том, что, поскольку MongoDB производит все изменения во время блокировки записи, она может просто поддерживать счётчики во внутренних вершинах. TokuMX поддерживает одновременную запись и использует MVCC, чтобы предоставлять читателям снимки данных. Это значит, что запрос count должен просмотреть каждый документ, чтобы определить, согласно алгоритму MVCC, должен ли он учитывать его при подсчёте.
  • Дополнительные возможности. Всегда есть вероятность, что разработчики добавят в MongoDB возможность, которая не будет реализована в TokuMX. Это маловероятно, но всё же возможно.

Если вам не нужны 2d, 2dsphere или текстовые индексы и если вы не слишком часто используете count(), TokuMX для вас будет быстрее, меньше и надёжнее, чем MongoDB.

Установка

TokuMX на данный момент доступны для Debian 7 and Ubuntu 12.04, 12.10, 13.04, 13.10, and 14.04, а так де OS X. Однако для последней операционной системы рекомендуется использовать TokuMX только в целях разработки. Прежде чем приступить к непосредственно самой установки необходимо добавит ключ подписи

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 505A7412

Далее необходимо добавить репозиторий:

$ echo "deb [arch=amd64] http://s3.amazonaws.com/tokumx-debs $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/tokumx.list

И наконец, можно приступить к установке:

$ sudo apt-get update
$ sudo apt-get install tokumx

Управление TokuMX можно производить следующим образом:

$ sudo service tokumx start
$ sudo service tokumx restart
$ sudo service tokumx stop

Тесты производительности

Импорт больших коллекций

Миграция данных за счёт экспорта и импорта коллекций между набором реплик может часто пригождаться [6]. К сожалению, зачастую скорость миграции оказывается смехотворно низкой, особенно для коллекций, содержащих большое количество небольших записей и/или сложных индексов. Для тестирования импорта и экспорта был выполнен импорт/экспорт двух больших коллекций с разным количеством объектов.

  • Collection1: 143 GB коллекция с ~300 миллионами маленьких объектов
  • Collection2: 147 GB коллекция с ~500 тысячами больших объектов

Обе коллекции были экспортированы из существующих коллекций MongoDB. Первой потребовалось 6 дней, второй - 6 часов. Для импорта коллекций в MongoDB и TokuMX была использована команда mongoimport. Согласно результатам теста, TokuMX справилась с Collection1 в 3 раза быстрее.

# Collection1: exported from MongoDB for 6 days

Database         Import Time
---------------------------------------------------------------------
MongoDB           58 hours 37 minutes
TokuMX            14 hours 28 minutes

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

# Collection2: exported from MongoDB for 6 hours

Database         Import Time
---------------------------------------------------------------------
MongoDB           48 minutes
TokuMX            53 minutes

Обработка большого количества запросов на запись

Было использовано приложение, инициирующее большое количество запросов "update" с объектами большого размера. Было записано 10 часов пробного трафика, который затем воспроизвели для обеих БД. По результатам теста, TokuMX работает с этим приложением в 3 раза быстрее, с меньшими задержками по всем параметрам.

# MongoDB Benchmark Results
- Ops/sec: 1695.81
- Update Latencies:
    P50: 5.96ms
    P70: 6.59ms
    P90: 11.57ms
    P95: 18.40ms
    P99: 44.37ms
    Max: 102.52ms
# TokuMX Benchmark Results
- Ops/sec: 4590.97
- Update Latencies:
    P50: 3.98ms
    P70: 4.49ms
    P90: 6.33ms
    P95: 7.61ms
    P99: 12.04ms
    Max: 16.63ms

Эффективность использования дискового пространства

Эффективность использования диска - ещё одна подкупающая особенность TokuMX. Как много места может TokuMX сэкономить в плане использования диска? Для проверки был экспортирован большой объём данных с набора реплик (2.4Т данных), а затем импортирован в TokuMX. Результат был ошеломляющий: TokuMX использовала всего 379 ГБ дискового пространства - около 15% оригинального размера.

Примечания

Источники