1024
ну, мне кажется причина всё таки есть - это масштабируемость, т.е. когда
решить проблемы производительности нельзя другим способом. Но это не
касается обычного ПО типа для учёта или планирования это скорей касается
задач типа сбора показаний метеодатчиков по всей стране или чего-то такого.


Posted via ActualForum NNTP Server 1.3

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

softwarer
Определенные проблемы трехзвенка таки решает. Например, представьте себе систему, которая в реальном времени предоставляет доступ к данным из кучи исхочников - just for example, какие-нибудь биржевые котировки со всего мира. В клиент-серверной архитектуре пришлось бы вязать клиентов с серверами схемой "все со всеми", имея все минусы такого подхода. В трехзвенке AS развязывает этот узел, позволяя прозрачно подключать новые источники данных, реагировать на смену форматов; может быть организовано более эффективное, предсказывающее кэширование, могут быть реализованы механизмы, отсутствующие во всех или некоторых источниках (например, оповещение о критическом изменении котировок) итп.


Бред - это все можно решить через шлюзы, либо через кластер либо выложить доступную информацию в интернет-сервер на репликаторе и все, собственно говоря.
А если косая планировка базы данных или неоптимизированные запросы - так при чем тут 2-х звенная архитектура? и 3-х звенная ничего не решит.
Если руки косые, так не нужно вешать проблему на технологии.

andsmЯ работаю с приложением, в котором использована многозвенная архитектура. И не вижу способа как это приложение можно удовлетворительно сделать в архитектуре клиент-сервер. Система обработки ордеров от трейдеров/брокеров - всякие фьючерсы, опционы, и т.п. Требования к производительности - очень высокие, требуется время обработки одного ордера не более нескольких миллисекунд. При этом за это время для каждого ордера нужно успеть провести множество рассчетов. Требования к безопасности - понятны из описания системы. Требования к масштабируемости - система должна нормально обрабатывать поток в 1000 ордеров в секунду.

Как подобное можно удовлетворительно реализовать в клиент-сервер?

Легко и абсолютно не напрягаясь :) а вот в 3-х звенке прийдется попотеть.
Сервер БД нужно выбирать соответствующий, т.е. максимально быстрый, "быстрые" структуры данных, оптимизированные запросы и пр.

andsm Валентин КЛегко и абсолютно не напрягаясь :) а вот в 3-х звенке прийдется попотеть.
Сервер БД нужно выбирать соответствующий, т.е. максимально быстрый, "быстрые" структуры данных, оптимизированные запросы и пр.
Сколько Валентин К сделал аналогичных систем?

Ссылок на системы не будет, потому что они настроены под конкретные предметные области, и в продаже не стоят.

Приношу извинения, если кого-то сильно задел, но прежде чем цитировать умные фразы нужно их понимать.
А трехзвенку я делал, но смысл промежуточного сервера - данные, а не сервер приложений, технологии MIDAS и CORBA.

Я готов обсуждать те предложения, которые вы говорите, а не цитируете третьи лица.
Посему сорри, кому не понравилось поглаживание против шерсти :)
Пиписьками померяемся в другой раз :)

softwarer Валентин КБред
Кстати, полезная привычка - начинать текст с краткого содержания.

Валентин К - это все можно решить через шлюзы,
Шлюзы чего и куда? Впрочем, есть подозрение, что если я не поленюсь вытрясти из Вас определение - выяснится, что нормальная реализация этого и есть третье звено.

Валентин Клибо через кластер
Интересно, Вы когда говорите слова, имеете что-то в виду или просто так, от балды выбираете из записной книжки?

Валентин К либо выложить доступную информацию в интернет-сервер на репликаторе
Можно. Если не думать об эффективности.

Валентин К
А если косая планировка базы данных или неоптимизированные запросы - так при чем тут 2-х звенная архитектура? и 3-х звенная ничего не решит.
Похоже, тоже взяли из записной книжки, не имея никакой связи с тем, на что якобы отвечает.

Повеселило :) думать - полезная привычка.
Отжиг попорядку
Шлюз и репликация подразумевает одно и тоже, вынести доступную информацию из внутренней базы организации во внешнюю, или наоборот, вносить/реплицировать из внешней во внутренюю. 3-х звенная архитектура преполагает звено между пользователем и данными, посему это не одно и тоже, что сказал я.

Кластер - решение для тех, кому не хватает производительности. Решение направленное именно на усиление слабого места, когда нужна скорость. 3-х звенная архитектура ничего подобного не дает.

Когда я говорю слова - я сижу за компом и смотрю только на каменты других афторов. Лаконичность моих высказываний может конечно вызывать недоумение, но они и рассчитаны на тех, кто "на пальцах"(элементарно знаком на практике с технологиями и сам их применял) понимает о чем идет речь.

И исчо на один камент вот этот "Можно. Если не думать об эффективности."
Перекликается с первым ответом.
Репликация никогда не относилась к неэффективным решениям, поскольку репликацию можно настроить как угодно, и в угодном нам направлении. Смысл ее включения несет задача, которую нужно решить, клонировав все или часть данных на 2-х и более серверах.
Посему вопрос эффективности технологии попадает в раздел - афтар не знает о чем говорит, незачот.

andsmРепликация - это секундные задержки. Котировки с такой задержкой профессиональным трейдерам не нужны, и платить за эти данные они не будут. Секундные задержки при исполнении ордеров тоже недопустимы - так как трейдеры могут при этом терять деньги из-за того что цены за это время могут изменится. В performance-critical systems есть свои особенности, и утверждения вида Легко и абсолютно не напрягаясь :) означают отсутствие опыта работы с подобными системами.

Отжаг попорядку.

Для MySQL например не заметно секундных задержек, если сильно хочется, да и скорость работы достаточная.
А вот если проблемы с актуальностью котировок, тогда решение опять же не в 3-х звенке, вообще тому, кто написал такое нужно укол мясом в голову сделать, но я что-то отклонился от темы...
Вобщем проблемы тут вообще нет и быть не может, каждый менеджер ставит себе в настройке, насколько часто себе обновлять информацию и получает ее настолько же часто. А вот планировка базы, выбор сервера БД, каналы связи - это для того, чтобы обновление происходило быстро. А зачем добавлять туда мегатормоз в виде 3-го звена??? лаконичный ответ - бред, и кстати очень очевидный. Видимо при проектировке никто вообще не занимался проектированием системы как быстродействующей, а за немерянно модное 3-е звено взял много денег и впридачу - как это вообще работает...

Отсутствие опыта как раз приводит к неадекватности оценки системы в целом и перевод системы в разряд бога, которому нужно поклоняться, даже если он нагадит на голову...

softwarer
Решение само по себе, без контекста применения, не бывает эффективным или неэффективным. Таковым оно бывает только в контексте.

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


Решение может быть эффективным даже без контекста, с этим я на 100% поспорю. Например поиск по индексу - он не зависит от контекста задачи.
Кстати, вопрос к остальным умникам: кто-то знает как организовать индекс по которому искать можно без перебора значений?

Что за курс? скорее всего получится как обычно - учителя будут обучены прикланому программированию и технологиям :)
Если сообщишь что за курс - буду в Москве - посещу обязательно, повеселимся :)

funikovyuriКак раз трехзвенка никогда не решала проблему масштабиремости, масштабируемости чего? глупости? вместо того, чтобы иметь 1 сервер БД, так исчо нужно купить и сервер для сервера приложений, или объектов перенаправления данных для трехзвенки.

Слова спеца! В школу, однозначно

абсолютно не агрументированный ответ :), тему не раскрыл, кг/ам.

funikovyuri Валентин К

Валентин, шли бы книжнки читать, что ли! Блин, сколько лет одно и тоже... опять какие-то узкие каналы, дурак архитектор и т.д.

Могу задать задачку на быстродействие, которую ты не решишь... :)

funikovyuri Валентин К

Например поиск по индексу - он не зависит от контекста задачи.

Угу, а если в таблице 1 запись?

абсолютно не агрументированный ответ :), тему не раскрыл, кг/ам.

Кто бы говорил :) Эту тему столько народу уже "раскрывало" - но все бестолку

Могу задать задачку на быстродействие, которую ты не решишь... :)

Сэр, я уже отучился!

попорядку
а если нет таблицы, какая разница, сколько в ней записей? Алгоритм индексированного поиска манипулирует данными структуры, которая может не быть связана с таблицей. И для алгоритма все равно будет там 1 запись или много. И как это связано с контекстом задачи, которую решает поиск по индексу? задача к примеру - автоматизация предприятия? Разве поиск по индексу может быть плохим решением для автоматизации, если он выполнен по наиболее быстрой технологии?

Я не знаю, что раскрывал народ, записной книжкой не пользуюсь.

Я тоже давно отучился, да вот думать от этого не перестал...