Исходное сообщение
"Результаты измерения производительности BerkeleyDB" Отправлено parad, 14-Апр-09 17:25
>Что мешает прочитать мануал по BerkeleyDB и перестать фантазировать? > >Для btree и hash там используется постраничная блокировка. Ни о каком блокировании >всей базы речи нет. Постраничная блокировка - это не атомарная операция и в больших БД страница может стать о(sizeof(DB)) - 'о'-малое от размера бд, те фактические своим количеством сэмитировать блокировку ячейки. Если даже поставить лимит кол-ва страниц, то на тех-же больших бд возникнет эффект схожий с блокировкой все БД. Предлагаю не выпендриваться и перестать перефразировать мои слова. + мозг подключять при чтении документации. >Кстати, там же речь идет о сравнении производительности hash и btree. Резюме >такое, что в зависимости от размера базы это немонотонная функция. Вначале >(пока база влезает в оперативную память) - без разницы, потом узким >местом становится IO и hash сливает, а потом начинает сказываться размер >метаданных, который больше у btree, и в итоге на самых больших >базах выигрывает hash. Разумеется, если locality не важна, а нужен только >точный поиск по ключу и важна производительность. Твою ###########! Хеш будет сливать только при малом размере БД (очень малом). При всех остальных, даже если он целиком будет храниться на диске - он будет впереди. Другое дело реализация - можно обосраться и сделать даже самый быстрый алгоритм медленее банального перебора. Если берклидб в документации пишет, то, что ты выше рассказал - то это явно у них проблемы с реализацией.