Форум: "Базы";
Поиск по всему сайту: delphimaster.net;
Текущий архив: 2002.01.08;
Скачать: [xml.tar.bz2];




Вниз

Быстрый доступ к БД ORACLE 


Yelchev   (2001-12-03 10:26) [0]

Есть проблема Существует БД вней порядка миллиона записей с блоб полями. Исспользую компонент Oracle Direct Acess. Чтение занимает очень много времени. Как оптимизировать чтение таблицы по времени и какие есть компоненты более быстрого доступа к БД. Для примера скажу чтоб выбрать 25000 записей каждая объемом 20К необходимо 15 мин



Владислав   (2001-12-03 11:22) [1]

Текст запроса в студию.



petr_v_a   (2001-12-03 11:24) [2]

Более быстрые компоненты врядли существуют, если кто-то и быстрее, то не в разы. Встречный вопрос - зачем тащить на клиента 25000 записей? Пользователь не воспримет больше 50-100 записей в гриде, захочет дополнительный "поиск в найденном" и пр. прелести. На уровне базы почитайте про параметры хранения LOB, там страниц 100



Yelchev   (2001-12-03 12:22) [3]

Пользователю вообще ничего не светится происходит следующее с записей выбирается Влоб масивы потом они проходят математические расчеты и в конце сравнения выводится небольшой список. Никакие гриды не используются. Может кто подскажет вообще как решить проблему быстрой работы с такой базой. Ведь при объеме в 1000000 записей вообще процесс чтения займет пол дня! Всем ответившим буду очень благодарен ))



Yuvich   (2001-12-03 12:44) [4]

А-а-а, так значит не выборка длится ~15мин., а обработка блобов длится 15мин. Тут надо посмотреть: что хранится в блобе - структурированная информация или нет. Если структурированная, то надо положить ее в таблицы и обработку делать не на этапе выборки, а на этапе записи в таблицу. Если не структурированная, то все равно попытаться представить информацию в виде структуры. Как сказал один математик: "нет такой предметной области, которую нельзя было бы представить в виде иерархической структуры".



Yelchev   (2001-12-03 12:50) [5]

Да нет совсем не так. Я делал експеременты просто по выборке данных без какой либо обработки. А структурировать данные нельзя связи стем что это массивы которые описывают обработаное изображение и нельзя их разделить! Вообще где можно что то почитать о решении таких проблем связаных с использованием надбольших БД



petr_v_a   (2001-12-03 13:33) [6]

Это уже хуже.Придется внимательно почитать про параметры хранения LOB :). По v$session_wait и v$system_event посмотрите, на что реально тратится время.Если обсчитываются такие объемы BLOB, может, стоит подумать про external procedures.Вообще, по моему впечатлению, Oracle не очень хорошо качает большие объемы на клиента.



Yelchev   (2001-12-03 13:55) [7]

А на сколько я получу выиграш по времени если встраивать сравнение в оболочку оракла (если это возможно и не качать информацию на клиента при условии что сравнение массивов хранящихся в вбоб необходимо переобразование фурье и другие арифметические операции + выделение большого числа памяти (до 29М)



Mick   (2001-12-03 14:05) [8]

Если Oracl на Wintel, то я бы перенес обработку блобов на сервер. То есть обычная трехзвенка.



Yelchev   (2001-12-03 14:11) [9]

"То есть обычная трехзвенка"? Прошу прощения за непонятливость но что это означает?



petr_v_a   (2001-12-03 14:29) [10]

Проще всего оценить выигрыш по времени, написав
begin
for cr in (<ваш запрос>) loop
null;
end;
end;
и посмотрев, сколько выполняется это



Yuvich   (2001-12-03 15:48) [11]

Mike правильно говорит - надо вынести обработку на сервер, тогда скорость обработки будет зависеть от мощности сервера, а не от мощности клиента.

Даже если Oracle не на Wintel, можно написать процедуру PL/SQL и вызывать из нее другую процедуру обозванную внешней и написанной, к примеру на С или Cobol. Другое дело, что надо знать язык операционки, на которой стоит Oracle и поддерживает вызов Ораклом. Чтобы быть точнее - надо почитать документаци.



petr_v_a   (2001-12-03 16:29) [12]

"обозванную внешней" можно написать и на Delphi, и на ассемблере, главное - сишные соглашения о вызовах. Насчет Wintel - в документации есть шикарная фраза, ( перевод мой) - "external procedures поддерживаеюся на любой платформе, поддерживающй DLL, например Solaris" :))



Yuvich   (2001-12-03 17:12) [13]

Я не думаю, что DLL, написанную на Delphi, можно использовать на Solaris, поэтому я и говорю - надо писать, хоть на ассемблере, на том языке, чей компилятор есть в ОС.

По поводу "шикарной фразы" некоторое дополнение: ... поддерживающей DLL или динамически загружаемые, разделяющие доступ, библиотеки ... , например Solaris .so библиотеки.



Yuvich   (2001-12-03 17:15) [14]

Из той же документации фраза:

So, some tasks are more quickly or easily done in a lower-level language such as C, which is more efficient at machine-precision calculations. For example, a Fast Fourier Transform (FFT) routine written in C runs faster than one written in PL/SQL.



petr_v_a   (2001-12-03 17:53) [15]

>Yuvich :) Ну ладно те, не собирался я DLL, написанную на Delphi,использовать на Solaris :) Смысл-то был в том, чо писать можно на чем угодно, лишь бы вызов был сишным. То, оно должно запуститься, понятно :)



Yuvich   (2001-12-03 18:02) [16]

>petr_v_a
Ничего личного. Возможно, я чего-то не понял.



ASV   (2001-12-04 03:11) [17]

А арифметика тут очень простая. Сетка, то у вас, вероятно 10Мб стоит?
Так 25000*20К=500000К что, при средней пропускной способности сети в 600К/сек дает 13,8 минуты.
И ничего тут, кроме как перенести расчет на сервер сделать нельзя.

Александр Свириденков




Форум: "Базы";
Поиск по всему сайту: delphimaster.net;
Текущий архив: 2002.01.08;
Скачать: [xml.tar.bz2];




Наверх





Память: 0.75 MB
Время: 0.049 c
6-22286           ReY                   2001-10-08 18:07  2002.01.08  
Пиплы!!! Нужен ICQ!


14-22393          Феликс                2001-11-08 21:54  2002.01.08  
Что делать?


14-22417          Yuraz                 2001-10-25 15:02  2002.01.08  
Интересно, Яндекс на чём крутится(IIS..) БД, железо.


14-22362          MIFI                  2001-11-04 02:34  2002.01.08  
как найти человека


3-21977           Амелин Вадим          2001-12-03 20:42  2002.01.08  
Создание БД в InterBase