Добрых времен, специалисты! Нужен совет по логике? (пните куда рыть)

Дано: Delphi 2007, FireBird 2.1 (+EhLib, +Fib, + сторонние компоненты)

Все было разработано, все работало как надо, но в один миг СИЛЬНО увеличилась нагрузка (в сотни раз, фирма развивается и на такие нагрузки, я просто не расчитывал)

Логика значит сейчас такая:
Коннект к сторонней базе. Получаю в клиента ~3000 записи. Беру первую запись.
Делаю Select к своей базе проверяю по 3 значениям (индексы, план все вроде в порядке, запрос летит шустро, НО ИХ МНОГО). Если есть такая запись - забыли. Иначе полез по таблицам, добавляю в справочники инфу. Добавляю новую запись. Записал. Следующую запись... и по кругу, и так до конца... (ну там за одно еще справочники проверяются, но это не критично.) Естественно на сервере вскипает процессор под 100% пиком.

Все хорошо пока сторонних баз было 3-5. Но когда их стало под 200. Из каждой выдернуть все записи и на каждую запись кинуть Select в мою базу. Тут процессор чето приуныл. Тяну данные из 10 баз одновременно. Процессор в шоке. Полный цикл проходит за 40 минут, без ошибок и т.п.. Но процессор в это время "жужжит" и не дает работать бухгалтерии, от слова совсем.
Такой импорт делается 4-5 раз в день, сами понимаете, бухгалтерии времени на работу не остается.

Лирика кончилась. Проект буду переделывать.

Теперь вопрос: Вот чтоб не убивать сервер тупыми запросами select, можно ли как-то выдернуть кусок таблицы "от даты, до даты(которые известны при старте импорта" в память клиента и уже у него проводить сверку по конкретным параметрам?
Куда копать MemtableEh?

Желательно у клиента в памяти создать "нечто" к чему можно обращаться Query, т.е. виртуальную (БД) табличку. Куда рыть?

(Если вариант совсем глупый, пинайте ногами. За сумбурность извините, не спал, проект горит. Побеспокоил, потому, что времени на переработку НЕТ. Все перечитать не могу... пните что читать, куда думать? )

Симонов Денисdgdog,

сначала объясни откуда взялись 200 БД и почему их нельзя слить в одну.

1. БД разные. 1С. Самописные Firebird. Текстовые файлы банковских выписок.
Вот так вот, а сливаются в одну УЖЕ в моей базе. Собственно она для этого и нужна.

2. Почему приходится перепроверять фигову тучу записей? Потому, что какой-нибудь бухгалтер нафигачит проводок задним числом... и пипец... какой-то оператор, перебьет к чертям вчерашнюю проводку. Поэтому каждую запись получил и лезу в свою базу проверять есть такая или подобная? (если есть подобная, то еще алгоритм "а не измененная ли это?")

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

rdb_devdgdog, что мешает импортировать записи только от штампа времени последнего импорта?

Старые записи могут добавиться, измениться (бухгалтерии косячят. 1С откатывается в БэкАп...) Из вводных данных имею только конкретные даты "от... и до..." Остальное я и разбираю. Но слишком много обращений к бд. Они плевые, но их много. Мнеб вот это "От... и до..." как-то на клиента утянуть и там уже крутить - вертеть и к базе лишний раз не лезть.

Симонов ДенисArioch,

я так понял что он сначала текстовые файлы в отдельные БД на firebird сливает, а потом из этих БД в центральную ещё.

Нет. Цепляюсь например (клиентом) к 10 1С ком соединением. Получаю из каждой кусок данных от ДАТЫ до ДАТЫ. Потом клиент берет каждую запись и лезет в мою базу с проверкой есть такая или нет? Если есть - забыли. Если нет - добавить. (Это грубо там логика в клиенте сверка всяких параметров полученной записи и записей в БД... я такую логику в самом Firebird не осилю.)

(Базы разные от 1С и до папки с файлами платежных поручейний из банков.)

Пусть на каждой из "200 БД" запускается служба подготовки к выгрузке.

(базы разные от 1С, Firebird, ... и до простых текстовых файлов экспорта из клиентбанков)

Симонов ДенисArioch,

с трудом представляю сервак который потянет 200 БД одновременно. Ну 10 ещё куда ни шло.

Сервак тянет 1 БД Firebird Остальные базы лежат где-как и в локальной сети и на удаленках... я из них только данные тяну на клиента, а уже потом фигачу в БД

(плохо я задачу объясняю, завтра высплюсь мож легче будет )

[quot Dimitry Sibiryakov]
dgdogДелаю Select к своей базе проверяю по 3 значениям (индексы, план все вроде в порядке,
запрос летит шустро, НО ИХ МНОГО).

Покажи код, которым это делаешь и план запроса.
Клиент формирует



отсылает
авторPlan
PLAN (SDELKA INDEX (SDELKA_IDX2))

Adapted Plan
PLAN (SDELKA INDEX (SDELKA_IDX2))

------ Performance info ------
Prepare time = 15ms
Execute time = 0ms
Current memory = 1 846 464
Max memory = 3 084 544
Memory buffers = 75
Reads from disk to cache = 3
Writes from cache to disk = 0
Fetches from cache = 15

Dimitry SibiryakovСимонов Денися как бы склонен к тому что ТС не идиот чтобы использовать супер в 2.1

Я практически уверен в обратном.

Классик

AriochdgdogПусть на каждой из "200 БД" запускается служба подготовки к выгрузке.

(базы разные от 1С, Firebird, ... и до простых текстовых файлов экспорта из клиентбанков)

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

грубо говоря, берешь своего клиента, вырезаешь из него все источники, кроме одного нужного на конкретном месте, и делешь программу выгрузки данных для Ивановой Марьи Владимировны....

Практически так оно и есть. Запускается десять разных клиентов которые тащат конкретные данные из конкретных источников. Но мне каждую строчку надо сверить с моей базой. Они наваливаются разом ... и привет ЦП.

Логика проверки вся на клиенте. В Firebird у меня мозгов не хватит все перетянуть.

ЦП кстати гавно I5. Лучше ближайшие три месяца не будет. ВотТакВота

AriochНадеюсь, запросы не текстом каждый раз наново формируются, а используют параметры и prepare ?


группируй свои запросы, хотя бы по дате




Пробовал и собирать строку и через параметры. А смысл? Нагрузка то на сервер не уменьшается. Сейчас параметрами шьет. Но один фик, там математика сначала обрабатывает ибо надо обрезать пробелы, проверить формат прилетевший из 1С по COM. Еще этот долбаный NULL ))) Чего и как нафигачили в назначении платежа и т.п. Но это отлаженная логика. Дело только в забое ЦП кучей запросов. Которые я хочу свести к одному запросу. Вытянуть данные по Клиенту от даты, до даты на клиента и там в памяти разобрать. Подготовить файл-табличку и её залить в БД.

Di_LInedgdogЦП кстати гавно I5. Лучше ближайшие три месяца не будет.
- Сам ты такое слово. (падобраму канешна) :-)
Потому как нефег сваливать на ЦП свое не знание и не понимание, прикрываясь "Он железный, вот пусть и пашет..."

А кто? Я за него, чтоли буду считать и тригерры с процедурами на логарифмической линейке высчитывать

Dimitry SibiryakovdgdogКлиент формирует
За использование непрепарированных запросов в таких условиях надо отрывать руки. Используй
параметры и получишь нужное ускорение.


Ускорение чего? Как быстро запрос долетит до сервера???? Так в этом нет беды... Сервак, что так, что эдак переварить не успевает.

AriochdgdogНагрузка то на сервер не уменьшается. Сейчас параметрами шьет.

...

либо решай радикально - избавляй сервер от этой работы вообще
....

Ну а я в чем и прошу помощи))) Как бы одним запросом свалить нужную выборку ИЗ МОЕЙ БАЗЫ на клиента. Там разобрать и слить обратно только нужное. ВОт вопрос то ВО ЧТО слить? Ну не в текстовый же файл. Куда в память это можно засунуть... в какой компанент? Вообще в идеале чтоб до этого компанента можно было QUERY добраться (тогда вообще все в шоколаде)

Dimitry SibiryakovdgdogПробовал и собирать строку и через параметры. А смысл? Нагрузка то на сервер не уменьшается.

Значит плохо пробовал. Потому что от применения препарированных запросов нагрузка должна
уменьшаться. В твоём случае - в 15 раз. Код показывай.