Как ускорить?

Гость

День добрый.

Вот и я решил задать вопрос про ускорение работы

C55, ШВС, TPS, W2K, файлы открываются в shared-режиме, обсчет на локальной машине, но в процессе файлы могут пользовать другие программы.

Схема базы:

Цена ->> Кросс-файл <<- Прайс <<- Производитель
Артикул ->> Кросс-файл

Необходимо посчитать, сколько Прайсов по каждой строчке Цены для конкретного Производителя.

Проблема в том, что объем базы сейчас 600Мб и будет расти. Количество записей - миллионы. Время построения - часы.

Как ускорить процесс без денормализации Кросс-файла?
Закачать Прайс в очередь? Пробовал сделать View из Кросса и Прайса и зафильтровать его - скорее ухудшение, чем ускорение. Может, я чего-то не помню и есть радикальные решения?

С такими большими объемами мне пока работать не приходилось, закачивать в SQL пока не получается по ТЗ.

С уважением,
В.Смелик

(Добавление)

Судя по структуре можно сделать промежуточный файл (динамически обновляемый в процессе работы) и свести это к такому

ЦенаПрайс (со значением цены прайса и идентификатором строчки файлов цены и прайса) <<-Производитель

Да, это потребует КОЛОССАЛЬНЫХ счетных ресурсов для РАЗОВОЙ генерации на уже существующей базе и будет несколько замедлять ввод и изменение. Но в результате отчет будет практически мгновенным.

Igor Gubin <igor@quantor.com>

(Добавление)

Здравствуйте, Владимир!

Хотя я не совсем "въехал" в описанную схему (в частности, что есть цена и зачем оно так), пару мыслей возникло.
1. Можно попробовать в старшие разряды ID прайса (или специального поля) прицепить ID производителя. Селектор по ключу ID прайса+Цена, в очередь и сортировка по цене.
2. Технически если не SQL, то хорошее решение для такой базы - терминальный сервер.

С уважением,
Вячеслав Черников Support@finsoft.ryazan.ru
Написал: ClaList(2)

Гость · Сообщение **Гость** » 06 Март 2004, 9:20

По роду деятельности мне постоянно приходится пользовать свои и чужие базы вышеназванных объемов, при этом нужные ключи не всегда есть. В этом случае всегда руководствуюсь одним правилом - минимизировать количество передвижений головок винчестера. Для этого стараюсь всю работу вынести в ОП, т.е. создаю удобную Queue (или несколько) затем пишу в нее фильтруя нужные записи основного файла. читая его по удобному ключу. а зачастую без ключа. идя по физическим записям. Основное условие при этом не дергать другие связанные с этим файлом данные (хотя такой соблазн при этом есть). Добавление в Queue идет естественно без сортировок. Необходимые дополнительные данные из других файлов добираю уже пробегая по Queue столько раз сколько таких файлов имею. После этого делаю необходимые сортировки Queue и готовлю нужные отчеты. Укладываюсь максимум в 5 - 7 минут в самых тяжелых случаях. (CW5.5, файлы Btrieve + Dbf + Tps, сеть Nowell, в сети постоянно от 150 до 300 пользователей). Заранее извиняюсь. если ответ не в струю
Написал: Anatoly(38)

Гость

1. Можно попробовать в старшие разряды ID прайса (или специального поля) прицепить ID производителя. Селектор по ключу ID прайса+Цена, в очередь и сортировка по цене.

Цена отдельно - для экономии места. Ибо само поле цены - строка.
В Прайсе есть ключ КодПрайса-КодПроизводителя. Впрочем,
нет проблем считать Прайсы в очередь - их мало.

Основная задача базы - найти Цены для заданного Артикула.
С этой задачей система справляется легко. А вот глобальный анализ данных - плохо

2. Технически если не SQL, то хорошее решение для такой базы - терминальный сервер.

Мы не можем идти по пути наращивания мощностей. Проект, невзирая на объемы, малобюджетный. Пока не ясен вопрос даже с самоокупаемостью работ, не то, что улучшение техники.
Т.е. хотелось бы получить максимально возможную скорость на обычной машине.

С уважением,
Владимир Смелик

Основная идея предложенного варианта - возможность сделать выборку из кросс-файла по ключу за один set. Вроде должно существенно ускорить, а модфикация кода для поддержки, думается, невелика.

Т.е. хотелось бы получить максимально возможную скорость на обычной машине.

У нас на одном заводе терминал поставили на селерон 800МГц, ОЗУ 128МБ.
Работали с 6-7 станций, правда не очень интенсивно. Недавно вроде увеличили ОЗУ до 256, числ рабочих станций в районе 10. Жалоб нет.
Недавно один знакомый устроился админом в контору, где интенсивно юзают терминал. Сказал так: если бы сам не увидел, не поверил бы, что без проблем можно интенсивно работать с 30 рабочих станций. Объем базы около 3ГБ, dbf.
Характеристик сервера не скажу, но что-то серьезное.
Думаю, что для контор с 2-20 рабочими местами терминальный сервер неплохой вариант.
Поставить можно практически на любую машину "современной" конфигурации.
Достоинства следующие.
1. Не нужно переписывать программу под SQL.
2. Надежно. Сетевые глюки не критичны. У меня, например, большинство клиентов под терминалом и проблем со сбоями в базах нет в природе. Т.е. низкие затраты на сопровождение.
3. Можно испоьзовать слабые компьютеры под рабочие станции. Это тоже весомый фактор для "малобюджетных" организаций.

Если же контора совсем малобюджетная, то не понял, что ты там делаешь

С уважением,
Вячеслав Черников

Все, понял, что ты предлагаешь. Просто сразу не въехал.

У нас на одном заводе терминал поставили на селерон 800МГц, ОЗУ 128МБ.

Но чем лучше будет терминал в моей ситуации? Когда я считаю не по сети, а локально? По сети изредка могут цепляться клиенты, интересующиеся только одной позицией. Да и то, пока такой клиент висит на той же машине.

Если же контора совсем малобюджетная, то не понял, что ты там делаешь

Не контора малобюджетная, а проект малобюджетный. Товарищ принес идею, данные и взял на себя большую половину кодирования. Я даю казенную технику, изголяюсь с отчетами по всей базе и оказываю "консалтинговые услуги" (т.е. выдвигаю идеи и пытаюсь применить на практике знания по проектированию систем). В общем, если заработает и начнет приносить деньги, то можно будет уже думать про технику. А если провалится, то останется опыт работы с большими базами.

По поводу ускорения. Если лень не замучает, то опишу результаты подробнее.
Пока получается, что гистограмму по ценам проще и быстрее строить для всех производителей за один проход, чем делать выборку для отдельного производителя. Впрочем, есть еще одна идея - потрошить базу с другого конца. Не со стороны цены, а со стороны прайсов. Буду экспериментировать.

С уважением,
Владимир Смелик
Написал: ClaList(2)

Гость

Hi!

Видел краем глаза один проект с терминалом (tps) - работал очень быстро, а по отзывам
очень надёжно, держал большие базы.
По поводу гистограммы - если список будет очень большим, то тормозить будет по памяти (будет своп). Возможно, что надо делать два варианта - один для небольшого списка (в памяти), другой для большого, с закачкой во временный файл.

С уважением, Рокотов Андрей.
mailto: andrey_rokotov@mail.ru
Написал: ClaList(2)