информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
DB->set_pagesize мало что даёт. Я тестировал page_size =... 07.08.08 07:19  Число просмотров: 2701
Автор: 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 значеними этой мапы. Гарантий для сохранности актуальных данных гораздо меньше - но это лучше чем ничего.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach