трехзвенка. выбор технологии
Модератор: kdv
трехзвенка. выбор технологии
Задача такая: складская БД 3-5млн записей (прайсы) в основных таблицах, которую нужно ежедневно обновлять большими потоками данных (100 тыс - 700тыс записей)
Пока задача решается так: исходные данные хранятся на том же сервере на котором сама БД, а приложение "обновлялка" на моем ПК. Получается фигня т.к. данные по сети считываются сначала на мой ПК и направляются "обновлялкой" обратно на тот же сервер.
Типа "туда-сюда-обратно
о боже как приятною.."
В результате перегружается сетевой канал сервера, процесс сам по себе небыстрый (сеть 100МБ) и мой ПК жуть как тормозит в этот момент.
С трехзвенкой раньше не работал и мутно представляю как это ваще делается. Но унтуитивно представляю что ей тут самое место. Хочется чтобы среднее звено типа удаленного модуля данных находилось на сервере, и все действия по перекачке выполнялись именно там без гуляния по сетям в адресном пространстве самого сервера. А тонкий клиент на моем ПК лиш управлял этим процессом
По этой теме нарыл в нете 2е вещи
Первый вариант - Мидас
http://rsdn.ru/article/db/midas.xml
Второй вариант - CORBA
http://www.interface.ru/case/Hpbd.htm
Но каждая из них тоже имеет разные варианты
Посоветуйте как лучше всего решить этот вопрос с точки зрения высокого быстродействия (производительности) и в тоже время простоты реализации. Какую технологию применить?
Буду рад выслушать любые мысли как по теме так и вобщем
Пока задача решается так: исходные данные хранятся на том же сервере на котором сама БД, а приложение "обновлялка" на моем ПК. Получается фигня т.к. данные по сети считываются сначала на мой ПК и направляются "обновлялкой" обратно на тот же сервер.
Типа "туда-сюда-обратно
о боже как приятною.."
В результате перегружается сетевой канал сервера, процесс сам по себе небыстрый (сеть 100МБ) и мой ПК жуть как тормозит в этот момент.
С трехзвенкой раньше не работал и мутно представляю как это ваще делается. Но унтуитивно представляю что ей тут самое место. Хочется чтобы среднее звено типа удаленного модуля данных находилось на сервере, и все действия по перекачке выполнялись именно там без гуляния по сетям в адресном пространстве самого сервера. А тонкий клиент на моем ПК лиш управлял этим процессом
По этой теме нарыл в нете 2е вещи
Первый вариант - Мидас
http://rsdn.ru/article/db/midas.xml
Второй вариант - CORBA
http://www.interface.ru/case/Hpbd.htm
Но каждая из них тоже имеет разные варианты
Посоветуйте как лучше всего решить этот вопрос с точки зрения высокого быстродействия (производительности) и в тоже время простоты реализации. Какую технологию применить?
Буду рад выслушать любые мысли как по теме так и вобщем
чего-то я не понял, каким образом выбор места "обновлялки" и ее особенности функционирования связаны с трехзвенкой? Трехзвенка это расширение клиент-сервера, вынос бизнес-логики на промежуточный слой, и т.п.
тебе твою софтину просто надо поставить на сервер, и оптимизировать заливку данных. По-моему все. Про трехзвенку, конечно, можно думать, но не в этом смысле
p.s. если пишешь на Delphi, то лучше слово "corba" не упоминай.
тебе твою софтину просто надо поставить на сервер, и оптимизировать заливку данных. По-моему все. Про трехзвенку, конечно, можно думать, но не в этом смысле

p.s. если пишешь на Delphi, то лучше слово "corba" не упоминай.
Пока - никаким. Сейчас это классический Клиент/Сервер. Но это не устраивает по скорости и загрузке сетевых ресурсов. Вот я и задумался, а можно ли это реализовать как трехзвенку.kdv писал(а):чего-то я не понял, каким образом выбор места "обновлялки" и ее особенности функционирования связаны с трехзвенкой?
А управлять удаленно ею как? Бегать к серверу каждый раз тоже не выход. RemoteAdmin-ом разве что лазить по серверу. Какие еще варианты?kdv писал(а): тебе твою софтину просто надо поставить на сервер, и оптимизировать заливку данных. По-моему все. Про трехзвенку, конечно, можно думать, но не в этом смысле
Странно, а Хьюлит Паккард выбрал именно этот вариант и доволен.kdv писал(а): p.s. если пишешь на Delphi, то лучше слово "corba" не упоминай.
Так что трехзвенка тут не нужна получается?
Можно. Данные из базы, которые нужны именно для функций управления (не заливаемые данные) подавать на клиента по его инициативе через стандартную связку TIBQuery - TDataSetProvider - TClientDataSet, оформить функции аппсервера по заливке как методы-расширения его интерфейса и инициировать с клиента.DSKalugin писал(а):Пока - никаким. Сейчас это классический Клиент/Сервер. Но это не устраивает по скорости и загрузке сетевых ресурсов. Вот я и задумался, а можно ли это реализовать как трехзвенку.kdv писал(а):чего-то я не понял, каким образом выбор места "обновлялки" и ее особенности функционирования связаны с трехзвенкой?
kdv писал(а): тебе твою софтину просто надо поставить на сервер, и оптимизировать заливку данных. По-моему все. Про трехзвенку, конечно, можно думать, но не в этом смысле
Ну как бы вариантов межзадачного взаимодействия в сети немало... В том числе и трёхзвенка.DSKalugin писал(а): А управлять удаленно ею как? Бегать к серверу каждый раз тоже не выход. RemoteAdmin-ом разве что лазить по серверу. Какие еще варианты?
kdv писал(а): p.s. если пишешь на Delphi, то лучше слово "corba" не упоминай.
Ы що, неужто на Delphi?DSKalugin писал(а): Странно, а Хьюлит Паккард выбрал именно этот вариант и доволен.



1. если сейчас задача реализована как К/C то переход на трехзвенку будет означать следующее - перенос приложения на промежуточный слой, и управление им через третий слой. То есть, с точки зрения заливки данных это будет ТО ЖЕ САМОЕ. Или я тебя не понимаю, или ты не понимаешь "трехзвенку". В трехзвенке промежуточный слой это "клиент" в клиент-сервере.
2. не знаю твоей задачи, но судя по всему заливка у тебя не автоматизирована. если задача заливки представляет собой заливку неких файлов данных в базу, то это автоматизируется элементарно - достаточно кинуть файл в опр. каталог, чтобы программа заливки его "съела", обработала и выдала лог ошибок (если таковые будут).
3. Corba используется в C++. В Delphi доступ к корбе, насколько я в курсе, выполнен несколько экзотическим способом, что делает ее использование в Delphi имеющим мало смысла. Против корбы как таковой ничего не имею против.
2. не знаю твоей задачи, но судя по всему заливка у тебя не автоматизирована. если задача заливки представляет собой заливку неких файлов данных в базу, то это автоматизируется элементарно - достаточно кинуть файл в опр. каталог, чтобы программа заливки его "съела", обработала и выдала лог ошибок (если таковые будут).
3. Corba используется в C++. В Delphi доступ к корбе, насколько я в курсе, выполнен несколько экзотическим способом, что делает ее использование в Delphi имеющим мало смысла. Против корбы как таковой ничего не имею против.
Задача примерно такая: ежедневно отслеживать изменения у поставщков на сайтах, которые выкладывают там свои базы с прайсами, или наличие на складе, скачивать, если обновилось там или извлекать из почтовой рассылки и с помощью программы "обновлялка" заправлять эти данные в общую нашу базу. Обновлялка выглядит как список поставщиков с кнопкой "обновить выбранного".kdv писал(а): 2. не знаю твоей задачи, но судя по всему заливка у тебя не автоматизирована. если задача заливки представляет собой заливку неких файлов данных в базу, то это автоматизируется элементарно - достаточно кинуть файл в опр. каталог, чтобы программа заливки его "съела", обработала и выдала лог ошибок (если таковые будут).
Кидать в каталог и автосъедание тут не целесообразно. Это тоже что и нажатие на кнопку "обновить". Исходники надо оставлять живими.
Можно еще автоматизировать проверку обновленных архивов в нете и закачку, но руки не доходят пока
C Corba весьма убедительно мне пояснили что пытаться копать в эту сторону не стоит. На кобру забиваю.
Спасибо kdv и Merlin
-
- Сообщения: 31
- Зарегистрирован: 26 окт 2004, 15:18
точка
Вопрос закрыт.
В результате обсуждения этой темы я сделал вывод что тут не нужна ни трехзвенка, ни клиент/сервер.
Обновлялка с исходными базами должна лежать на сервере где вертится FireBird. Остается реализовать механизм удаленного управления этой обновлялкой. Пока это будет RemoteAdmin, а в необозримом(несбыточном) будущем - сервис(служба сервера). Управлялка обновлялкой будет на моем ПК и соединяться с обновлялкой будет по сети через сокеты.
В результате обсуждения этой темы я сделал вывод что тут не нужна ни трехзвенка, ни клиент/сервер.
Обновлялка с исходными базами должна лежать на сервере где вертится FireBird. Остается реализовать механизм удаленного управления этой обновлялкой. Пока это будет RemoteAdmin, а в необозримом(несбыточном) будущем - сервис(служба сервера). Управлялка обновлялкой будет на моем ПК и соединяться с обновлялкой будет по сети через сокеты.