Выступление HAMANO Tsukasa (Open Source Solution Technology Corporation) на конференции LDAPCon 2015, Эдинбург, ноябрь 2015 года. Оригинал статьи (PDF) и слайды к этому выступлению (на английском языке).
В этом документе представлен механизм манипуляции данными WiredTiger для OpenLDAP. WiredTiger — это встраиваемая база данных с характеристиками многоядерной масштабируемости и безблокировочных алгоритмов. Мы реализовали новый механизм манипуляции данными для OpenLDAP, названный back-wt, который использует базу данных WiredTiger, а затем измерили производительность.
BerkeleyDB — устаревшая встраиваемая база данных. Производительность операций записи back-bdb (механизма манипуляции данными OpenLDAP, использующего BerkeleyDB) ужасно низкая, также эти операции не поддерживают масштабирования. Если для повышения производительности мы будем синхронизировать содержимое базы данных на диске не сразу после его изменения в памяти, есть риск потерять часть данных. Кроме того, OpenLDAP — мультипоточное приложение, а существующие механизмы манипуляции данными недостаточно хорошо масштабируются по числу процессоров. Механизм манипуляции данными WiredTiger призван обеспечить высокую производительность одновременно выполняемых операций записи.
Для начала нам пришлось определиться со структурой данных, выбирая между плоской структурой, как в back-bdb, и иерархической структурой, как в back-hdb. Если выбрать плоскую структуру, то поиск с диапазоном sub выполняется быстро, но операции modrdn и add требуют дополнительных затрат. Фактически, в back-bdb мы не можем использовать операцию modrdn с подкаталогами. Для плоской структуры требуется множество записей с префиксом @ для выполнения поиска с диапазоном sub, кроме того, для поиска с диапазоном one требуются записи с префиксом %. Если выбрать иерархическую структуру, modrdn выполняется быстро, но поиск с диапазонами one и sub требует дополнительных затрат.
Рисунок 1: Сравнение плоской и иерархаческих структур
В основном мы придерживались плоской структуры данных, но внесли в неё некоторые усовершенствования в плане производительности и представления базы данных. Перед тем как добавить запись, мы переворачиваем DN по составляющим его RDN, а затем добавляем это перевёрнутое DN в качестве ключа в B-Tree таблицу WiredTiger. На этой стадии записи сортируются по перевёрнутому DN, таким образом мы можем быстро выполнять поиск с диапазоном sub с помощью поиска по областям WiredTiger. Поиск по областям — это эффективный метод, которому для этой цели требуется только вызов WT_CURSOR::search_near() и операции инкрементации курсора.
Рисунок 2: Создание перевёрнутого DN
Рисунок 3: Структура данных back-wt
В WiredTiger имеется несколько уровней обеспечения сохранности данных транзакций. Далее приведены настройки back-wt, соответствующие каждому из этих уровней. Для настройки уровня обеспечения сохранности данных в back-wt задаётся параметр wtconfig. Значения этого параметра просто передаются в wiredtiger_open().
1. Журнал транзакций записывается в память. Это самый быстрый вариант, однако сохранность данных обеспечивается только при сбросе в контрольных точках.
wtconfig log=(enabled=false)
Пример 1: slapd.conf для ведения журнала транзакций в памяти
2. Журнал транзакций записывается в файл, но записи журнала сбрасываются туда не при каждой фиксации транзакции. Такое поведение эквивалентно поведению back-bdb при настройке dbnosync.
wtconfig log=(enabled) wtconfig transaction_sync=(enabled=false)
Пример 2: slapd.conf для асинхронной записи журнала транзакций в файл
3. Журнал транзакций записывается в файл, записи журнала сбрасываются туда при каждой фиксации транзакции.
wtconfig log=(enabled) wtconfig transaction_sync=(enabled=true)
Пример 3: slapd.conf для синхронной записи журнала транзакций в файл
Мы измерили контрольные показатели, главным образом касающиеся производительности параллельно выполняемых запросов, с помощью нового аналитического инструмента lb. Данный инструмент может генерировать высокую параллельную нагрузку путём вызова goroutines языка Go. Подробную информацию о нашем тестировании можно посмотреть на wiki-странице git-репозитория механизма back-wt.
Тесты проводились в таком окружении:
Рисунок 4: Скорость операции LDAP ADD (с синхронным сбросом журнала транзакций)
Рисунок 5: Скорость операции LDAP ADD (без синхронного сброса журнала транзакций)
Рисунок 6: Скорость операции LDAP BIND
Рисунок 7: Скорость операции LDAP SEARCH