Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Данные длиною в три байта. [D7, Win2k]

Страницы: 1 2 >
KilkennyCat © (2005-05-10 12:49:00)
Можно ли такое реализовать?
Предположим, что куча записей базы данных имеют ссылку на другую базу. В этой другой базе записей не более $ffffff, то есть, в первой базе достаточно хранить ссылку размером в три байта. При миллионе записей в первой базе отсутствие одного байта - почти мегабайт экономии.

KilkennyCat (2005-05-10 17:36:00) [1]
Кстати, связи имеют четкую древовидную структуру. Это позволяет опять их оптимизировать по объему и значительно по скорости работы, так как на поиск подчиненых объектов уже не требуется полный перебор.
Да здравствует мой вариант КЛАДРа! :)

KilkennyCat (2005-05-10 17:33:00) [2]

> nikkie © (10.05.05 16:50) [21]

гм...

ну вот, к примеру имеем таблицу. Стандартно, как в книжке :) - три отдела сотрудников, фио сотрудников, номер телефона сотрудников. Но телефон на всю контору - один единственный и фио1 работает сразу в двух...
Так вот кладр был бы так:

отдел1 фио1 телефон1
отдел1 фио2 телефон1
отдел2 фио1 телефон1

у меня же было бы так:

файл с пятью записями отдел1, отдел2 , фио1 , фио2, телефон1
и файл связей, реализовавший бы первоначальную таблицу.

ну вот опять из статистики: почтовый индекс в кладре реализован как строка из 6 байтов и пишется в каждой записи, которых более миллиона. Но на самом деле почтовый индекс можно выразить всего тремя байтами, и всех вариантов индекса будет 999999*3 = 2,8 метра. Однако, так как вместо индекса мы вынуждены поставить идентификатор, то выигрыша никакого. Но! всего вариантов индекса 40227, т.е максимальный объем около 300 килобайт, и тогда мы получаем уменьшение объема индексов в таблице в два раза + 300 кил. Фактически с 5.7 метров до 3 метров.

nikkie (2005-05-10 16:50:00) [3]
если кто-нибудь понял, объясните мне.

KilkennyCat (2005-05-10 16:34:00) [4]

> nikkie © (10.05.05 16:23) [19]

остальные - это структура dbf и многократно, сверхмногократно повторяющиеся значения.

nikkie (2005-05-10 16:23:00) [5]
>объем базы около 50 метров
>все файлы в несжатом виде имеют размер около 11 метров
если честно, то я не понимаю.

>итого, мой CODE имеет размер 14 байт.
>число записей файла связей около 600 тысяч.
видимо один файл CODE весил 11Mb? его удалось сократить на 1/8 (2 байта из 16). ок. а что с остальными 40Mb?

KilkennyCat (2005-05-10 14:52:00) [6]
Согласитесь, отобрать у 11 метров еще полтора - это неплохо.
Но это еще не конец: файл связей вполне поддается алгоритмизации, а не тупой прописи. Ща еще уменьшу вполовину.

KilkennyCat (2005-05-10 14:50:00) [7]

> nikkie © (10.05.05 14:11) [15]

Да есть.

Ну раз уж заговорили оффтопом, давайте тогда расскажу вкратце структуру. Может, придем к выводу, что я фигню наворотил.
Итак, популярный KLADR имеет три основных файла:
KLADR.DBF, где находятся следующие мне интересные поля:
наименования городов, районов и пр. (string), код субъекта(byte), почтовый индекс (string[6]), окато(string[11]), код налоговой (string[4]), сокращенное наименование (string[1-10])
STREET.DBF c аналогичной структурой, DOMA.DBF, SOCR.DBF

В каждом есть еще громадное поле CODE (11, 15 и 23 байтов), которое все связывает.

Что сделал я - выдрал все поля и уничтожил дубликаты.
Получил в итоге семь файликов: файл связей, индексы, окато, гни, наименования, сокращенные наименования, расшифровка наименований.
Всего в дбэфах около миллиона записей (а ведь в каждой записи еще кучка полей...), объем базы около 50 метров (изначально было почти 70, но я выкинул ненужных полей немного :) ).

У меня:

файл - число записей - необходимый размер ссылки
DOMA - 23911 - 2byte
INDEX - 40227 - 2byte
NAME - 152028 - 3byte
SOCR - 81 - byte
SSOCR - 81 - ненужно
OKATO - 129128 - 3byte
Region - 99 - byte
GNI - 2493 - 2byte

итого, мой CODE имеет размер 14 байт.

число записей файла связей около 600 тысяч.

все файлы в несжатом виде имеют размер около 11 метров

Сделав NАМЕ и ОКАТО на один байт меньше, я выиграл чуть больше мегабайта. Заменив $0D0A на $00 я выиграю еще почти 0,4 метра

Проигрыш в работе только лишь при первоначальной загрузке. И вполне терпимый, по крайней мере, я это торможение (4 секунды) заметил лишь на Pentium-II-300

GreatMaster (2005-05-10 14:33:00) [8]
голое поле номеров никому не нужно, тогда бы как Anatoly Podgoretsky сказал и всё.
ясный перец есть чёто ещё. это или такие же 3х байтовые поля-обрезки на другие/этуже таблицы, тогда изврат с 3мя байтами канает. Или просто обычные данные, тогда замутка ваще не в тему и выигрыш --> 0

nikkie (2005-05-10 14:11:00) [9]
>Это не единственная оптимизация.
вооот. осталось теперь оценить вклад именно этого момента в общий результат. сдается мне, что в этой базе есть также и текстовые данные, а потому вряд ли экономия одного байта даст более 1% выигрыша.

GreatMaster (2005-05-10 13:54:00) [10]
Держи SmallInt + Byte
ещё и за счёт служебных данных пару бит выиграешь :)

KilkennyCat (2005-05-10 13:43:00) [11]

> Anatoly Podgoretsky © (10.05.05 13:32) [11]

Нет, при объединении я буду вынужден вместо трех байтов добавить намного больше.

> nikkie © (10.05.05 13:38) [12]

Это не единственная оптимизация.

nikkie (2005-05-10 13:38:00) [12]
>с 7,72 М в архиве уменьшить до 2,5 М в архиве
в 3 раза за счет удаления 1 байта из 4-х?
даже если других данных в базе нет - выигрыш только 25% будет, а не 66%.
что-то мне с трудом верится.

Anatoly Podgoretsky (2005-05-10 13:32:00) [13]
KilkennyCat © (10.05.05 12:49)
Ты гораздо больше выиграешь если объединишь эти две базы.

GreatMaster (2005-05-10 13:23:00) [14]
Marser, [2] даст не верный результат, если твои переменные байтовые! (firstbyte, secondbyte, thirdbyte : byte;)
надо по очереди сдвигать:
a:=1;
a:=a shl 8;
a:=a + 2;
a:=a shl 8;
a:=a + 3;

KilkennyCat (2005-05-10 13:20:00) [15]

> [6] nikkie © (10.05.05 13:12)

Как сказать... Переделка KLADR таким макаром позволила с 7,72 М в архиве уменьшить до 2,5 М в архиве. Что уже существенно при скачивании в интернете.

> [7] kai © (10.05.05 13:13)

Быстрее, чем через BDE

KilkennyCat (2005-05-10 13:17:00) [16]

> [5] Marser © (10.05.05 13:08)

ага, это я понял из [2], спасибо.

kai (2005-05-10 13:13:00) [17]
KilkennyCat © (10.05.05 13:05) [4] Спасибо.
Сейчас еще 0D0A выкину, и моя база будет самая малюсенькая! :)
и самая медленная -)

nikkie (2005-05-10 13:12:00) [18]
мегабайт экономии, говоришь? на гигабайтной базе вряд ли заметишь. надо считать относительный выигрыш, а не абсолютный.

Marser (2005-05-10 13:08:00) [19]
Это пример приведения трёх байт к LongWord. Ну а считывать можено обратной операцией.
firstbyte:=lo(longwordvar);
secondbyte:=hi(longwordvar);
thirdbyte:=longwordvar shr 16

KilkennyCat (2005-05-10 13:05:00) [20]
Спасибо.
Сейчас еще 0D0A выкину, и моя база будет самая малюсенькая! :)

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »