информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаSpanning Tree Protocol: недокументированное применениеПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ну тогда такие соображения... 07.08.08 08:25  Число просмотров: 2120
Автор: 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 тоже весьма отказоустойчива -)
<programming> Поиск 






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


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