"Kovalenko Dmitry" ...
>
> Спасибо, пацаны, что не забыли :)
Тебя забудешь ;)
> > > На текущий момент - затык с диском.
> >
> > Я же говорил - пиши последовательно, а не абы как. И как можно
> > бОльшими кусками
> > ...
>
> Видно деваться будет некуда. Щас буду пытаться систематизировать
> сделанные изменения, я же сломал все что только можно сломать.
>
> Потом начну смотреть. "Большими" кусками... У меня в кэше сегменты,
> находящиеся рядом на диске, могут находиться в разных частях кэша. То
> есть нахаляву состыковать их в памяти не удасться.
А в памяти и не надо. См. WriteFileGather API (в posix'е, кстати,
оно на порядок удобнее).
Главное тут - последовательно. Если удастся большими кусками - тем
лучше (ибо они по-определению последовательны), но главное - последовательно.
> Тут выход - либо
> копировать их в линейный буфер (маразм?) либо упорядочивать выдачу
> команд на запись ...
Второе, конечно. У тебя нет наших проблем с precedence, поэтому
ты волен писать страницы в любом удобном для тебя порядке
> Читать-то все равно только по одной странице за раз надо ?
Почему ?
> Опять же - поток который пишет он спит. 3/4 кэша были "чистые" ...
Он и должен почти всегда спать - диск работает ;)
> Текущие траблы из-за того что много промахов мимо кэша. У меня
> писатель на самом низком приоритете работает.
А не нада трогать приоритеты потоков. Пусть писатель просыпается
когда ему есть что делать и делает это частями, но не все сразу.
...
> > > Вторая - Б-деревья.
> >
> > Тут будет не более 4-х на твоих объёмах
>
> При 4 килобайтной странице ... ???? У меня 4-х байтный идентификатор
> страницы. Ключ, считай, 16-байтный. Данные, которые нужно привязаны к
> ключу - 8 байт (это тот же ID, только для пары целиком).
Я вообще-то FB-шные индексы имел в виду и страницу в 8-16К.
> > > Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно
> > > добавлять новые ключи в индексы?
> >
> > Конечно. Но имей в виду - одновременно на одну и ту же страницу
> > конечно же никто не пишет
>
> А разве алгоритм Б-дерева обратно по дереву не поднимается? Если
> поднимается - то может же возникнуть блокировка ...
Кури btr.cpp - как там все сделано в смысле блокировок. При вставке
в индекс никогда не блокируется более одной страницы одновременно, даже
во время расщепления. При удалении блокируется до 4-х страниц, из них на
запись только одна. Всё в строгом порядке, есс-но, так что дедлоков быть
не может
> > Кстати - префиксная компрессия ключей в этом смысле очень даже
> > рулит. Хотя кодировать это - ужас один
>
> Я дальше отбрасывания ведущих нулевых байт для DST не собирался
> "сжимать". Поэтому и говорил про 4 байта (при 8 максимум).
А ты обрати внимание на среднюю длину ключа в индексе FB и на кол-во
занимаемых страниц. Тебе понравится ;)
> ... Значит все таки практикующие акушеры рекомендуют Б-дерево.
Шо знаем, то и рекомендуем :)
--
Хорсун Влад
