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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Удачи в вашем приложении.

С уважением,

Дэйв

Answer 2

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

• LevelDB
• Киото TreeDB
• SQLite3
• MDB
• BerkeleyDB

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

. Здесь приведена запись в блоге для сравненияRedis и Memcached.