Отправлено: 04.04.15 02:22. Заголовок: Нужен реально компактный индекс

Добрый день.

Есть большая таблица (под 100 мегов) - выборка по товару за пару лет с такой структурой:
--
code C10 - код товара
stock I2 - код склада хранения, 32бита
date D3 - дата (компактная форма)
remain I4 - остаток товара на эту дату, 64бита
sales I4 - продано в этот день, 64 бита
--
Чтобы правильно заполнить эту таблицу на основании данных приходов/перемещений/продаж, нужно иметь индекс по "код товара+код склада+дата". Если делать "классически": INDEX ON table->code+STR(table->stock,5)+DTOS(table->date) TO... - получаем:

1) размер индексного файла становится много больше самой таблицы (23 байта индексное выражение против 15 байт одна строка таблицы)

2) после увеличения самой таблицы свыше 20 мегов - скорость добавления в нее падает очень и очень заметно. Таблица и индекс локальны и открыты монопольно.

-----

Что я подумал: а существует ли какой-то способ создания индекса на основе имеющихся, "компактных" форм хранения данных? По сути, выражение DTOS() и "приклеенный" STR() дают избыточную сортировку по дате и номеру склада, которые в момент создания этой таблицы не нужны. Нужен быстрый поиск записи по трем полям и корректировка значений.

Т.е. нужно "бинарное" значение даты и 32-битного числа.

PS: про I2BIN() и BIN2I() знаю с времен Клиппера. Вопрос - что делать с датой в данном случае и с разными "интересными" и "компактными" форматами данных, например, "@", "+" итп... - в общем ?

PPS: dbfntx

Спасибо.

 Отправлено: 04.04.15 19:49. Заголовок: Sergy пишет: Если о..

Sergy пишет:

цитата:

Если он "компактный" на диске - это не значит, что он "компактный" в памяти

И что? Он работает. У меня есть таблицы весом около 200Mb (добавлено: записей около 900000). На размер индекса я не смотрел. Работает с такой же скоростью, как и когда таблицы были пустыми. Надо логику менять. Размер в нынешних условиях не имеет значения.

 Отправлено: 04.04.15 19:51. Заголовок: Sergy пишет: Разобр..

Sergy пишет:

цитата:

Разобрался. Если он "компактный" на диске - это не значит, что он "компактный" в памяти

Намекаешь что NTX vs CDX это примерно тоже что EXE vs EXE пожатый UPX ?
Тут тестить надо на самом деле.
У меня размер одной базы 250 метров , индексы IDX , работает в сети и примерно 25 юзеров ,
на тормоза ни кто не жалуется. Кол-во записей ~ чуть больше 2 лимонов.

 Отправлено: 04.04.15 20:41. Заголовок: SergKis пишет:str(cr..

SergKis пишет:

цитата:

str(crc32(cKey), 8) или str(crc16(cKey, 5)

немного наврал (по памяти), нашел у себя место где применял. надо:
str(hb_crc32(cKey), 10) или str(hb_crc16(cKey, 5)
использовал в похожей ситуации: запись в инд.поле
KY := str(hb_crc32(R_6+R_7+R_2+Dtos(R_4)+R_13+str(R_46)),10)
это код, склад, операция, дата, докум., id

 Отправлено: 08.04.15 22:56. Заголовок: Dima пишет: Намекае..

Dima пишет:

цитата:

Намекаешь что NTX vs CDX это примерно тоже что EXE vs EXE пожатый UPX ? Тут тестить надо на самом деле.

Przemek пишет, что "не все так однозначно": _https://groups.google.com/forum/#!topic/harbour-users/EB-eDbnEDMA
Различия во внутренней структуре индекса есть.
Но DBFNTX можно заставить работать по аналогии с CDX. Будет время - потестю.

цитата:

У меня размер одной базы 250 метров , индексы IDX , работает в сети и примерно 25 юзеров , на тормоза ни кто не жалуется. Кол-во записей ~ чуть больше 2 лимонов.

У меня аналогично, рабочая таблица продаж, под 100..200 мегов - никто не жалуется. Интенсивность разная. Во время работы юзера прошла выборка по индексу, десяток-другой записей - мгновение и ждем реакции пользователя... Во время активного заполнения справочника с активным поиском по таблице с ~5 млн значений ощущаются тормоза.

Пример: прогресс дошел до середины за минуту, таблица разрослась до 100 мегов. Еще две минуты она доходит до 75%. Еще через три - до 100%. Итоговый размер - под 200 мег.
Итого получается, что работа с первой сотней мегов прошла за минуту, со второй - за пять. Итого шесть минут.

Но нужно будет потестить с CDX.