Home
Top.Mail.Ru Yandeks.Metrika
Forum: "Bases";
Current archive: 2002.01.08;
Download: [xml.tar.bz2];

Down

Quick access to the ORACLE DB Find similar branches


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]

Это уже хуже.Придется carefully почитать про параметры хранения 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;
и посмотрев, сколько выполняется it



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 минуты.
И ничего тут, кроме как перенести расчет на сервер сделать нельзя.

Alexander Sviridenkov



Pages: 1 whole branch

Forum: "Bases";
Current archive: 2002.01.08;
Download: [xml.tar.bz2];

Top









Memory: 0.87 MB
Time: 0.042 c
3-21904
Andrei
2001-11-29 22:18
2002.01.08
query


1-22010
dorixe
2001-12-17 19:21
2002.01.08
treeview on dblclick


4-22487
bike
2001-11-05 00:40
2002.01.08
Create Macro in Excel


6-22310
SERGX
2001-10-13 23:48
2002.01.08
HELP !! How to create a program to send a file or text by mail


7-22433
igor_prg
2001-09-25 21:28
2002.01.08
How to register a class ???





afrikaans albanian Arabic armenian azerbaijani basque belarusian bulgarian catalan Chinese (Simplified) Chinese (Traditional) croatian Czech danish Dutch English estonian filipino finnish French
galician georgian German greek haitian Creole hebrew Hindi hungarian icelandic indonesian Irish italian japanese Korean latvian lithuanian macedonian malay maltese norwegian
persian polish portuguese Romanian russian serbian slovak Slovenian Español swahili Swedish thai turkish Ukrainian urdu vietnamese welsh yiddish bengali bosnian
cebuano Esperanto gujarati hausa hmong igbo javanese kannada khmer lao latin maori marathi mongolian nepali punjabi somali tamil telugu yoruba
zulu
English French German Italian Portuguese Russian Spanish