Форум » [x]Harbour » Нужен реально компактный индекс » Ответить
Нужен реально компактный индекс
Sergy: Добрый день. Есть большая таблица (под 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 Спасибо.
Ответов - 24, стр:
1 2 All
PSP: Sergy пишет: Если он "компактный" на диске - это не значит, что он "компактный" в памяти И что? Он работает. У меня есть таблицы весом около 200Mb (добавлено: записей около 900000). На размер индекса я не смотрел. Работает с такой же скоростью, как и когда таблицы были пустыми. Надо логику менять. Размер в нынешних условиях не имеет значения.
Dima: Sergy пишет: Разобрался. Если он "компактный" на диске - это не значит, что он "компактный" в памяти Намекаешь что NTX vs CDX это примерно тоже что EXE vs EXE пожатый UPX ? Тут тестить надо на самом деле. У меня размер одной базы 250 метров , индексы IDX , работает в сети и примерно 25 юзеров , на тормоза ни кто не жалуется. Кол-во записей ~ чуть больше 2 лимонов.
SergKis: 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
Sergy: 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.
полная версия страницы