Лучшая база данных ключей/значений языка C для огромных количеств записей

Я пытаюсь создать базу данных key/value с 300 000 000 пар ключ/значение по 8 байт (как для ключа, так и для значения). Требование состоит в том, чтобы иметь очень быстрый механизм key/value, который может запрашивать около 500 000 записей в секунду.

Я попробовал BDB, Tokyo DB, Kyoto DB и levelDB, и все они очень плохо работают, когда дело доходит до баз данных такого размера. (Их производительность даже не приближается к их контрольной ставке в 1 000 000 записей).

Я не могу хранить свою базу данных в памяти из-за аппаратных ограничений (32-битное программное обеспечение), поэтому memcached не может быть и речи.

Я не могу использовать внешнее серверное программное обеспечение (только модуль базы данных), и нет необходимости в многопользовательской поддержке вообще. Конечно, серверное программное обеспечение не может выдерживать 500 000 запросов в секунду от одной конечной точки в любом случае, так что это исключает Redis, тиранский тиран и т.д.

Ответ 1

Дэвид Сеглау, здесь. Менеджер продуктов для Berkeley DB.

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

Из вашего описания я не уверен, что вы столкнулись с этими распространенными проблемами или, возможно, во что-то еще. В любом случае наш опыт состоит в том, что Berkeley DB имеет тенденцию проявлять и масштабироваться очень хорошо. Мы будем рады помочь вам выявить любые узкие места и улучшить пропускную способность приложений BDB. Лучшее место для получения помощи в этом отношении будет на форумах BDB по адресу: http://forums.oracle.com/forums/forum.jspa?forumID=271. Когда вы отправляете сообщение на форум, было бы полезно показать критические сегменты запросов вашего кода приложения и вывод db_stat, показывающий производительность среды базы данных.

Вероятно, вы захотите использовать BDB HA/Replication, чтобы загрузить баланс запросов на нескольких серверах. 500K запросов/секунду, вероятно, потребует большего многоядерного сервера или серии меньших реплицированных серверов. Мы часто видели приложения BDB со 100-200 Кбайтами в секунду на товарном оборудовании, но 500 тыс. Запросов в секунду на 300 М записей в 32-битном приложении, вероятно, потребует некоторой тщательной настройки. Я бы предложил сосредоточиться на оптимизации производительности запросов в приложении BDB, работающих на одном node, а затем использовать HA для распределения этой нагрузки через несколько систем, чтобы масштабировать вашу запрос/вторую пропускную способность.

Надеюсь, это поможет.

Удачи вам в вашей заявке.

Привет,

Dave

Ответ 2

Я нашел хорошую сравнительную веб-страницу сравнения, которая в основном сравнивает 5 известных баз данных:

LevelDB
Киото TreeDB
SQLite3
MDB
BerkeleyDB

Вы должны проверить это, прежде чем делать свой выбор: http://symas.com/mdb/microbench/.

P.S - Я знаю, что вы уже протестировали их, но вы также должны учитывать, что ваша конфигурация для каждого из этих тестов не была оптимизирована, поскольку в противном случае будет показано, что эталон показывает.

Ответ 3

Попробуйте ZooLib.

Он предоставляет базу данных с С++ API, который был первоначально написан для высокопроизводительной мультимедийной базы данных для образовательных учреждений под названием Knowledge Forum. Он может обрабатывать 3000 одновременных клиентов Mac и Windows (также написанные в ZooLib - это кросс-платформенная платформа приложений), все они передают аудио, видео и работают с графически богатыми документами, созданными преподавателями и студентами.

Он имеет два низкоуровневых API для фактической записи ваших байтов на диск. Один очень быстрый, но не отказоустойчивый. Другой отказоустойчив, но не так быстро.

Я один из разработчиков ZooLib, но у меня нет большого опыта работы с компонентом базы данных ZooLib. Также нет документации - вам нужно будет прочитать источник, чтобы выяснить, как он работает. Это моя собственная проклятая ошибка, поскольку я взял на себя работу по написанию руководства ZooLib более десяти лет назад, но только начал его.

ZooLib в первую очередь разработчик Энди Грин отличный парень и всегда рад ответить на вопросы. Я предлагаю вам подписаться на список разработчиков ZooLib в SourceForge, а затем спросить о том, как использовать базу данных. Скорее всего, Энди ответит вам сам, но, возможно, один из наших других разработчиков.

ZooLib - это Open Source в соответствии с лицензией MIT и действительно высококачественный зрелый код. Он находится в непрерывном развитии с 1990 года или около того и был помещен в Open Source в 2000 году.

Не беспокойтесь, что с 2003 года мы не выпустили tarball. Мы, вероятно, должны это сделать, поскольку это приводит к тому, что многие потенциальные пользователи могут подумать, что они были оставлены, но очень активно используются и поддерживаются. Просто получите источник из Subversion.

Энди - консультант по найму. Если у вас нет времени, но у вас есть бюджет, он будет очень хорошо писать собственный, поддерживающий высококачественный код на С++ в соответствии с вашими потребностями.

Я тоже, если бы это была какая-то часть ZooLib, кроме базы данных, которая, как я уже сказал, мне незнакома. Я провел большую часть своей собственной консалтинговой работы с интерфейсом UI ZooLib.

Ответ 4

300 М * 8 байтов = 2,4 ГБ. Это, вероятно, поместится в память (если ОС не ограничивает адресное пространство 31 битом) Так как вам также потребуется обработать переполнение (либо с помощью схемы перефразирования, либо с помощью цепочки), память становится еще более жесткой, для линейного зондирования вам, вероятно, понадобится > 400 М слотов, цепочка увеличит размер элемента до 12 байтов (бит-игра может получить вас несколько бит). Это увеличило бы общую площадь до 3,6 ГБ.

В любом случае вам понадобится специально созданное ядро, которое ограничивает его собственное "зарезервированное" адресное пространство до нескольких сотен МБ. Не невозможно, а крупная операция. Во всех случаях переход на диск основанное было бы слишком медленным. (PAE может спасти вас, но это сложно)

ИМХО, лучшим выбором будет переход на 64-битную платформу.

Ответ 5

500 000 записей в секунду без сохранения рабочего набора в памяти? Ничего себе.

В общем случае это невозможно с использованием жестких дисков и даже сложных SSD.

Есть ли у вас какие-либо свойства локальности, которые могли бы облегчить задачу? Какие у вас есть вопросы?

Ответ 6

Мы используем Redis. Написанный на C, его только немного сложнее, чем memcached по дизайну. Никогда не пытались использовать много строк, но для нас очень важна латентность, и она хорошо справляется с этими задержками и позволяет хранить данные на диске

Вот запись блога сравнивая redis и memcached.

Ответ 7

Berkely DB может сделать это за вас. Я получил 50000 вложений в секунду около 8 лет назад и окончательную базу данных из 70 миллиардов записей.