> Есть DB->set_pagesize и DB->set_h_ffactor попробуй с > ними поиграться. Одна записьна страницу... Готично :-)
DB->set_pagesize мало что даёт. Я тестировал page_size = 512 байт, что является минимумом для BDB.
Я бы не стал играть с и density (DB->set_h_ffactor). Это мало относится к числу записей на странице, но скорее влияет на размер bucket-а хеш контейнера. В принципе даже для более простых хэш контейнеров (расштрения stl, stlport и прочее) не рекомендуется этого делать, если нет совершенно ясного понимания к чему это приведёт при разрешении колизий. Для BDB может быть ещё сложнее. Ну и ... это ничего не дало - я всё же протестировал на всякий пожарный влияние DB->set_h_ffactor как ты посоветовал.
> Но вот мне интересно, БД у тебя in-memory, ради одного > хешированного индекса стоит ли городить огород, чего вы там > в С++ используете для словарей std::map вроде, вот его > может и использовать + своя синхронизация?
Использование БД - принципиально важно. В коде, что выше по постингам я намеренно привёлдополнительнуюконфигурацию in-memory, чтобы показать что дисковое IO практически не влияет на перформанс BDB, когда размер DB_BTREE или DB_HASH невелик и полностью помещается в памяти. На самом деле в проекте я хочу использовать именно НЕ in-memory конфинурацию DB (к хорошему привыкаешь быстро;)). Основная идея - приложение может упасть, но после рестарта - всё самозалечится, так как текущие данные будут прочитаны с диска.
Что же до C++ map - здесь может быть не всё так гладко, если использутся тривиальное решение - синхронизация на единственной критической секции, скажем, для 4-5 readers и 1-2 writers и инденсивном обновлении значений мапы.
Скорее, я буду использовать некий симбиоз. Поток данных будет обнослять "быструю" хеш мапу, а отдельный thread будет поддерживать обновленя BDB значеними этой мапы. Гарантий для сохранности актуальных данных гораздо меньше - но это лучше чем ничего.
На одно-процессорном компьютере, тестировалась производительность «map» контейнера на основе Oracle Berkeley DB с доступом DB_BTREE/DB_HASH. Производительность оказалась не очень высокой: для 1 writer и 4 readers производительность в ~30-40 раз ниже чем для обычной std::map с простейшей синхронизацией на критической секции. Кстати, это не плохой результат (~50000 w/r в секунду) для многих практических задач. Но вопрос в том, можно ли повысить скорость DB_BTREE/DB_HASH?
Вероятно, наибольшее влияние оказывает DB_BTREE/DB_HASH страничный механизм блокировок (page-level locking) на замедление скорости w/r. Напротив, для DB_QUEUE (по-элементная блокировка, record-level locking), производительность не намного уступает stl-based queue коgнтейнерам с простейшей синхронизацией на semaphore и критической секции.
Просто ремайндер06.08.08 15:28 Автор: amirul <Serge> Статус: The Elderman
Из других постов я понял, что нужно это тебе для коммерческого проекта. Так вот Oracle BDB ни фига не бесплатная для коммерческих проектов. Там цена такая, что они ее даже в открытую стесняются на сайте выкладывать.
Хм... меня чуть кандратий не схватил. Я быстенько написал в...07.08.08 07:25 Автор: void <Grebnev Valery> Статус: Elderman
> Из других постов я понял, что нужно это тебе для > коммерческого проекта. Так вот Oracle BDB ни фига не > бесплатная для коммерческих проектов. Там цена такая, что > они ее даже в открытую стесняются на сайте выкладывать. Хм... меня чуть кандратий не схватил. Я быстенько написал в Oracle. Прояснилось следующее - мы можем использовать BDB в коммерческих целях фо фри, если не будет передавать ПО третьим лицам. Самое главное, чтобы не было "redistribution":
The following are not redistribution:
Building an application for use internal to your organization, deployed and managed on your company servers.
Off-site backups or other software archival procedures.
> На одно-процессорном компьютере, тестировалась > производительность «map» контейнера на основе Oracle > Berkeley DB с доступом DB_BTREE/DB_HASH. Производительность > оказалась не очень высокой: для 1 writer и 4 readers > производительность в ~30-40 раз ниже чем для обычной > std::map с простейшей синхронизацией на критической секции. > Кстати, это не плохой результат (~50000 w/r в секунду) для > многих практических задач. Но вопрос в том, можно ли > повысить скорость DB_BTREE/DB_HASH? Ценность БДБ не только в скорости, но и в хранении данных (Durability), и в быстром поиске для большого кол-ва данных, и во вторичных индексах, и в транзакциях, и в журналировании ;-) Внутри код достаточно «ветвистый» для поддержки всего этого, хотя бы проверка тех же условий, как в данный момент произвести то или иное действие в зависимости от опций DB_ENV.
В тестах использовалась stand-alone DB или создавалась сперва DB_ENV, а потом уже открывалась DB? Я просто не помню, какие подсистемы юзает stand-alone DB, может она подключает что-то лишнее...
При открытии среды нужно указывать (в твоём случае) только DB_INIT_LOCK | DB_INIT_MPOOL | DB_THREAD флаги.
Если нужна какая-то ультраскорость :) попробуй убрать флаг DB_INIT_LOCK и сам занимайся синхронизацией.
С флагами памяти ещё можно поиграться... Только наврядли это что-то даст.
Больше мыслей нет.
Я не спорю. Но ведь если перформанс был бы выше, так это...06.08.08 04:47 Автор: void <Grebnev Valery> Статус: Elderman
> Ценность БДБ не только в скорости, но и в хранении данных > (Durability), и в быстром поиске для большого кол-ва > данных, и во вторичных индексах, и в транзакциях, и в > журналировании ;-) Внутри код достаточно «ветвистый» для > поддержки всего этого, хотя бы проверка тех же условий, как > в данный момент произвести то или иное действие в > зависимости от опций DB_ENV.
Я не спорю. Но ведь если перформанс был бы выше, так это только лучше. Так ведь?
> В тестах использовалась stand-alone DB или создавалась > сперва DB_ENV, а потом уже открывалась DB? Конечно DB_ENV.
> При открытии среды нужно указывать (в твоём случае) только > DB_INIT_LOCK | DB_INIT_MPOOL | DB_THREAD флаги.
Не уверен, что нужно инициализировать подсистему DB_INIT_LOCK
> Если нужна какая-то ультраскорость :) попробуй убрать флаг > DB_INIT_LOCK и сам занимайся синхронизацией. > С флагами памяти ещё можно поиграться... Только наврядли > это что-то даст. > Больше мыслей нет.
Основная проблема, как мне кажется - блокировка page-level locking. Например, для DB_QUEUE, где этого нет (там record-level locking) - работает просто ультрасаунд. Поетому, если ключи и данные небольшие, так что всё помещается на нескольких страницах, блокировка страницы душит всю DB. Надо б найти способ уменьшить кол-во записей на страницу.
А, у тебя CDB спользована, отлично!06.08.08 09:53 Автор: HandleX <Александр М.> Статус: The Elderman
> В принципе, код инициализации весьма стандартный: > Не уверен, что нужно инициализировать подсистему > DB_INIT_LOCK Ага, я совсем забыл про CDB.
> Основная проблема, как мне кажется - блокировка page-level > locking. Например, для DB_QUEUE, где этого нет (там > record-level locking) - работает просто ультрасаунд. > Поетому, если ключи и данные небольшие, так что всё > помещается на нескольких страницах, блокировка страницы > душит всю DB. Надо б найти способ уменьшить кол-во записей > на страницу. Есть DB->set_pagesize и DB->set_h_ffactor попробуй с ними поиграться. Одна записьна страницу... Готично :-)
Но вот мне интересно, БД у тебя in-memory, ради одного хешированного индекса стоит ли городить огород, чего вы там в С++ используете для словарей std::map вроде, вот его может и использовать + своя синхронизация?
DB->set_pagesize мало что даёт. Я тестировал page_size =...07.08.08 07:19 Автор: void <Grebnev Valery> Статус: Elderman
> Есть DB->set_pagesize и DB->set_h_ffactor попробуй с > ними поиграться. Одна записьна страницу... Готично :-)
DB->set_pagesize мало что даёт. Я тестировал page_size = 512 байт, что является минимумом для BDB.
Я бы не стал играть с и density (DB->set_h_ffactor). Это мало относится к числу записей на странице, но скорее влияет на размер bucket-а хеш контейнера. В принципе даже для более простых хэш контейнеров (расштрения stl, stlport и прочее) не рекомендуется этого делать, если нет совершенно ясного понимания к чему это приведёт при разрешении колизий. Для BDB может быть ещё сложнее. Ну и ... это ничего не дало - я всё же протестировал на всякий пожарный влияние DB->set_h_ffactor как ты посоветовал.
> Но вот мне интересно, БД у тебя in-memory, ради одного > хешированного индекса стоит ли городить огород, чего вы там > в С++ используете для словарей std::map вроде, вот его > может и использовать + своя синхронизация?
Использование БД - принципиально важно. В коде, что выше по постингам я намеренно привёлдополнительнуюконфигурацию in-memory, чтобы показать что дисковое IO практически не влияет на перформанс BDB, когда размер DB_BTREE или DB_HASH невелик и полностью помещается в памяти. На самом деле в проекте я хочу использовать именно НЕ in-memory конфинурацию DB (к хорошему привыкаешь быстро;)). Основная идея - приложение может упасть, но после рестарта - всё самозалечится, так как текущие данные будут прочитаны с диска.
Что же до C++ map - здесь может быть не всё так гладко, если использутся тривиальное решение - синхронизация на единственной критической секции, скажем, для 4-5 readers и 1-2 writers и инденсивном обновлении значений мапы.
Скорее, я буду использовать некий симбиоз. Поток данных будет обнослять "быструю" хеш мапу, а отдельный thread будет поддерживать обновленя BDB значеними этой мапы. Гарантий для сохранности актуальных данных гораздо меньше - но это лучше чем ничего.
Ну тогда такие соображения...07.08.08 08:25 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 07.08.08 08:25 Количество правок: 1
> Использование БД - принципиально важно. В коде, что выше по > постингам я намеренно привёлдополнительнуюконфигурацию > in-memory, чтобы показать что дисковое IO практически не > влияет на перформанс BDB, когда размер DB_BTREE или DB_HASH > невелик и полностью помещается в памяти. На самом деле в > проекте я хочу использовать именно НЕ in-memory > конфинурацию DB (к хорошему привыкаешь быстро;)). Основная > идея - приложение может упасть, но после рестарта - всё > самозалечится, так как текущие данные будут прочитаны с > диска. Это прекрасно! Но вот если тебя не устраивает производительность BDB, как тогда база будет успевать сохранять тот поток данных, что успевает зохавать "быстрый" хешмап? + он тоже ресурсы кушает.
> Скорее, я буду использовать некий симбиоз. Поток данных > будет обнослять "быструю" хеш мапу, а отдельный thread > будет поддерживать обновленя BDB значеними этой мапы. > Гарантий для сохранности актуальных данных гораздо меньше - > но это лучше чем ничего. Для гарантии сохранности актуальных данных не убежать тебе от DB_INIT_LOG ;-)
ИМХО сделать сперва чисто на BDB, если несколько writers — вместо CDB заюзать DB_INIT_LOCK и посмотреть, что получится.
Или, если важно сохранять данные при пиковых нагрузках, использовать QUEUE, и периодически скармливать основной базе. Очередь в BDB тоже весьма отказоустойчива -)
I agree.08.08.08 01:33 Автор: void <Grebnev Valery> Статус: Elderman
> Но вот мне интересно, БД у тебя in-memory, ради одного > хешированного индекса стоит ли городить огород, чего вы там > в С++ используете для словарей std::map вроде, вот его > может и использовать + своя синхронизация?
Хеш-таблица насколько я помню лежит в std::tr1::unordered_map