Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2007.09.23;
Скачать: [xml.tar.bz2];

Вниз

Как выполнить много асинхронных запросов к БД (ADO)?   Найти похожие ветки 

 
Сергей Ю   (2007-08-24 10:02) [0]

Есть БД к которой нужно довольно часто обращаться, при этом программа должна работать дальше не дожидаясь когда придет результат. Хочу сделать асинхронные запросы (вроде именно это и должно мне помочь). Но вот как сделать чтоб создавался следущий запрос если еще и первый то не успел выполниться? И как узнать потом в обработчике onfetch какой именно из запросов выполнился?


 
Sergey13 ©   (2007-08-24 10:08) [1]

> [0] Сергей Ю   (24.08.07 10:02)

Просто ради интереса, если не трудно, расскажи, что за предметная область? Что за задача такая - задавать БД вопросы и не слушать ответы?


 
alshtam ©   (2007-08-24 10:09) [2]

у меня была подобная проблема, когда долго запросы выполнялись, я ее решил оптимизировав запросы  и индексы в БД правильно раставил, отпала необходимость асинхронных запросов


 
Сергей Ю   (2007-08-24 10:21) [3]

Нет ответы надо слушать обязательно. Просто во время обработки запроса необходимо чтоб программа выполняла и другие функции. А как только ответ пришел от БД то выполнила бы еще и обработочку этого ответа :)
Ну например: ставим таймер на раз в секунду на 1 минуту в целом. В нем запрос к БД. А запрос выполняется 5 секунд. Вот надо чтоб все результаты этих запросов программа обработала. Т.е. последний результат при обычной работе может вернуться через 60*5=300 секунд. А если асинхронный режим выбрать то через 60+5сек=65 секунт.
Или я не прав?


 
iXT ©   (2007-08-24 10:28) [4]

Какие запросы? За целостность данных не боитесь?


 
Сергей Ю   (2007-08-24 10:30) [5]

неа. в БД пишет другая программа, эта только селекты к ней делает.


 
DVM ©   (2007-08-24 10:34) [6]


> Просто во время обработки запроса необходимо чтоб программа
> выполняла и другие функции. А как только ответ пришел от
> БД то выполнила бы еще и обработочку этого ответа :)

Работай с БД из нескольких параллельных потоков. Только учти, что в каждом потоке надо создавать свой AdoConnection.


 
Sergey13 ©   (2007-08-24 10:34) [7]

> [3] Сергей Ю   (24.08.07 10:21)

Это все понятно. Мне интересно зачем это надо по жизни? Что за данные ты запрашиваешь раз в секунду?
Это не совсем праздный интерес - очень часто коллективный разум подсказывает вопрошающему более оптимальные методы работы, отметающие такие возможности в принципе.


 
Суслик ©   (2007-08-24 10:46) [8]


>  [6] DVM ©   (24.08.07 10:34)
> Работай с БД из нескольких параллельных потоков. Только
> учти, что в каждом потоке надо создавать свой AdoConnection


поддерживаю
у меня так и сделано.


 
Сергей Ю   (2007-08-24 10:48) [9]


> Работай с БД из нескольких параллельных потоков. Только
> учти, что в каждом потоке надо создавать свой AdoConnection

А как это? Я ноль в этом.


 
Суслик ©   (2007-08-24 10:57) [10]

Ноль в чем
В потоках?
Или в АДО?

1. создаешь поток. не забудь в потоке вызывать coinitialize(nil) (иначе в потоке адо работать не будет).
2. создаешь в потоке новый AdoConnection.
3. посылаешь в потоке запросы.
4. там же обрабатываешь ответы.
5. при появлении нового задания см. п. 1

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

возможно, что тебе этого всего не нужно :)
достаточно сделать очередь запросов. а обрабатывать их последовательно в единственном доп. потоке.


 
DVM ©   (2007-08-24 11:36) [11]


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

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


 
Ega23 ©   (2007-08-24 11:49) [12]


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


Я с дилерами консультировался по этому вопросу. Считается за один коннект. И если несколько программ с одного IP работают с одним и тем же сервером - тоже как один коннект считается. Или, типа, апп-сервера: 5 клиентов, шестой - апп-сервер, седьмой - сервер БД. клиенты работают только с апп-сервером, а тот - уже с сервером БД. Но считается, вроде, всего 5 коннектов.


 
sniknik ©   (2007-08-24 11:59) [13]

> Считается за один коннект
ну да, особенно если у него например Firebird Embeded. ;о)) ... база то как вижу не озвучена.


 
Сергей Ю   (2007-08-24 12:09) [14]

база mysql
а в потоке запрос делать обычным? или асинхронным?
и почему нельзя просто ограничиться асинхронными запросами?


 
sniknik ©   (2007-08-24 12:45) [15]

> а в потоке запрос делать обычным? или асинхронным?
в потоках с обычными проще, для асинхронных еще придётся делать выборку/обработку сообщений для потока.

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


 
sniknik ©   (2007-08-24 12:46) [16]

+ к 1, там не только сложнее с асинхронными но еще и бесполезно, т.к. никакой выгоды от них нет.


 
Сергей Ю   (2007-08-24 12:55) [17]

ну ладно колюсь :): мне надо постоянно считать потребленный за минуту траффик 100 компов. траффик лежит в mysql-ой базе. когда все 100 висят в инете, то БД довольно большая (поменять ее архитиктуру и т.п. я не могу, она не моя). Причем архитиктура БД такова что одним запросом я не могу получить результат для всех. Т.е приходится раз в минуту создавать 100 запросов. А эти 100 запросов частенько не могут обработаться за минуту. При этом программа просто "тупо висит" пока их все дождется.И реально возникает ситуация когда она вобще перестает на чтолибо реагировать. А надо бы чтоб она контролировала получаемую информацию и постоянно ее выводила на экран. Вот.


 
Sergey13 ©   (2007-08-24 13:01) [18]

> [17] Сергей Ю   (24.08.07 12:55)
> Причем архитиктура БД такова что одним запросом я не могу получить результат для всех.

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


 
Anatoly Podgoretsky ©   (2007-08-24 13:05) [19]

> Ega23  (24.08.2007 11:49:12)  [12]

Лицензии они разные могут быть, ты вроде об МС - лицензия на устройство.


 
Ega23 ©   (2007-08-24 13:08) [20]


> Лицензии они разные могут быть, ты вроде об МС - лицензия
> на устройство.


На Oracle, вроде, такая же. Хотя могу ошибаться - давно дело было.


 
Сергей Ю   (2007-08-24 13:09) [21]

ip,port,bytes,time
т.к. компы включают в разное время то делаю так:
select sum(bytes) from table where ip="ip" and port=3128 and time>time_on

где ip-ipшник машины траффик которого надобы посчитать
time_on-время когда она начала свою сессию (это время я знаю).

Вот только сижу я щас и думаю, а ведь наверно дурак я. Зачем мне постоянно считать от времени включения машины до текущего? Ведь проще будет просто запоминать время последнего подсчета траффика и складывать уже имеющуюся цифирь с периодом от посленего обращения к бд до настоящего времени (т.е. за последнюю минуту)
Блин и не надо лопатить всю БД :)
Ну я и тормоз :)


 
Ega23 ©   (2007-08-24 13:12) [22]


> Вот только сижу я щас и думаю, а ведь наверно дурак я. Зачем
> мне постоянно считать от времени включения машины до текущего?


Если ты ещё побольше подумаешь, то выяснится, что и это лишнее, а проблему ещё изящнее можно решить.
Не кидайся с ходу "кодить". Привыкай вначале думать.


 
Sergey13 ©   (2007-08-24 13:13) [23]

select ip,sum(bytes) from table where port=3128 and time>time_on
group by ip


 
Сергей Ю   (2007-08-24 13:28) [24]


> Если ты ещё побольше подумаешь, то выяснится, что и это
> лишнее, а проблему ещё изящнее можно решить

Как?

> select ip,sum(bytes) from table where port=3128 and time>time_on
> group by ip

Не пойдет. Т.к. time_on у всех машин разный.


 
Ega23 ©   (2007-08-24 13:33) [25]


> Не пойдет. Т.к. time_on у всех машин разный.


и чё?


 
Anatoly Podgoretsky ©   (2007-08-24 13:34) [26]

> Ega23  (24.08.2007 13:08:20)  [20]

Это очень простая и жирная лицензия, особенно для Веб сервисов.
Каждому пользователю по лицензии.


 
Anatoly Podgoretsky ©   (2007-08-24 13:36) [27]

> Ega23  (24.08.2007 13:33:25)  [25]

Вообще то трафик считают за период, а не от time_on
Автор почему то другого мнения.


 
Sergey13 ©   (2007-08-24 13:42) [28]

> [24] Сергей Ю   (24.08.07 13:28)
> Не пойдет. Т.к. time_on у всех машин разный.

Он где то лежит в базе? Если да, то привяжи к этому запросу типа

select ip,sum(bytes)
from table,table_time_on tto
where tto.ip=table.ip and port=3128 and time>tto.time_on
group by ip


 
Сергей Ю   (2007-08-24 13:52) [29]

В том то и дело что в базе этой информации нет. А есть только у меня.
Траффик мне и нужен за период времени. От начала работы компа до текущего момента. А это самое начало у всех компов разное и в БД его нет. Поэтому 100 запросов придется делать все равно.


 
Sergey13 ©   (2007-08-24 13:58) [30]

> [29] Сергей Ю   (24.08.07 13:52)
> А есть только у меня.

ну так добавь табличку в БД - это не страшное вмешательство в структуру.


 
Сергей Ю   (2007-08-24 14:15) [31]


> ну так добавь табличку в БД - это не страшное вмешательство
> в структуру

С правами на селект ;)?


 
sniknik ©   (2007-08-24 14:18) [32]

> Поэтому 100 запросов придется делать все равно.
UNION ALL не поддерживается mysql-ем?


 
Sergey13 ©   (2007-08-24 14:23) [33]

> [31] Сергей Ю   (24.08.07 14:15)
> С правами на селект

Попроси того, кто тебе дал это право самому сделать ее.


 
Сергей Ю   (2007-08-27 13:06) [34]

Время получения данных с БД сократилось с 3 минут до 30-40 секунд. Уже прогресс, щас еще асинхронный запрос прикручу и наверно вобще можно будет жить с этим :)


 
Sergey13 ©   (2007-08-27 13:13) [35]

> [34] Сергей Ю   (27.08.07 13:06)
> Время получения данных с БД сократилось с 3 минут до 30-40 секунд

За счет чего?


 
Сергей Ю   (2007-08-27 14:38) [36]

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


 
sniknik ©   (2007-08-27 14:46) [37]

это сколько же там данных за последнюю минуту если запрос 30-40 секунд идет?
несколько миллионов записей похоже...  а обработка потом на клиенте получается уже часы?
нда... крутые базы у народа...


 
Sergey13 ©   (2007-08-27 14:55) [38]

> [36] Сергей Ю   (27.08.07 14:38)

А если твой комп пеерзагрузится (или как то по другому сбросятся старые данные), заново считать будешь?
Можно ли в мускуле обработать запрос к нескольким базам сразу? Это типа (возвращаясь к [30]) если к твоей боевой БД есть только право на селект, можно ли создать рядом еще одну БД с одной таблицей и селектить из 2 баз.


 
Сергей Ю   (2007-08-27 14:55) [39]

Да вот я тоже думаю что договато идет. Это вобщемто обычный лог проксисервера. На серваке mySQL. Я к нему хожу по ADO+ODBC. Может тут "узкое место"? Кстати а обновление драйверов ODBC может помочь увеличить быстродействие?


 
sniknik ©   (2007-08-27 15:07) [40]

> можно ли создать рядом еще одну БД с одной таблицей и селектить из 2 баз.
вряд ли, mysql гетерогенных запросов не поддерживает. (имхо конечно. может уже что нибудь изменилось)

> Может тут "узкое место"?
"узкое место" обычно сидит перед компьютером, и думает что пишет программу.



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

Форум: "Начинающим";
Текущий архив: 2007.09.23;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.55 MB
Время: 0.046 c
15-1187864995
DVM
2007-08-23 14:29
2007.09.23
MD5


15-1187801365
ferr
2007-08-22 20:49
2007.09.23
Бука.


11-1171730658
Dy1
2007-02-17 19:44
2007.09.23
"много вопросов, мало ответов" (с)


2-1188178818
wesel
2007-08-27 05:40
2007.09.23
Проблема с Потоками


2-1188116137
Daedr
2007-08-26 12:15
2007.09.23
Чтение из файла





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