Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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 минуты.
И ничего тут, кроме как перенести расчет на сервер сделать нельзя.

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



Страницы: 1 вся ветка

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

Наверх




Память: 0.48 MB
Время: 0.008 c
3-21937
ANDREY196
2001-12-04 18:24
2002.01.08
Как мне поменять цвет в определённой строке таблице в DBGRID


1-22248
Leviathan
2001-12-17 13:07
2002.01.08
Дельфи издевается!!!


4-22488
Arick
2001-10-31 09:20
2002.01.08
как узнать имя загруженной Dll


1-22078
DJ X
2001-12-15 16:11
2002.01.08
Конвертирование, реестр, INI


4-22456
RedMax
2001-11-01 11:10
2002.01.08
COM объекты NetMeeting





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 Spanish 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
Английский Французский Немецкий Итальянский Португальский Русский Испанский