"Ro-man" <
nospam@sql.ru>; wrote in message news:
3074341@sql.ru...
Hi!
> Далее, после восстановления соединения с БД все изменения
> (скорее всего будет вестись лог или врЕменные таблицы),
> произведённые за это время в "БД2" ДОЛЖНЫ БЫТЬ
> переданы в "БД1". Равно как и новые записи в таблицах-справочниках
> "БД1" ДОЛЖНЫ БЫТЬ переданы в "БД2" вместе с ещё некоторыми
> данными из "БД1". И на кого, позвольте поинтересоваться, взвалить
> эти "обязанности"? :)
А потом у заказчика поменялась постановка задачи и он говорит:
"Вот в эту таблицу вы можете добавлять, удалять, менять как угодно,
но сумма по всем записям в этом столбце должна быть не более 100,
а в этом столбце не менее 0". И разнести куски таблицы по трем
независимым серверам уже не получается. Или можно клепать
документы на отгрузку только в пределах остатка на единственном
складе. И как три независимые группы клепалщиков будут знать
остатки на складе? На кого взвалить эти обязанности?
В итоге транзакционной целостности данных не получается.
На одном сервере транзакция вроде прошла. При попытке
ее воспроизвести через несколько часов на другом сервере
что-то уже не получается. Там уже и справочники другие, да и данные
поменялись все давно. Потому, что если разные группы юзеров
действительно никогда по данным не пересекаются и описанных
проблем быть не может, то это будут три совершенно независимых
системы и связь между ними не нужна и СП не нужен.
> Это ещё одна причина, по которой планируется создание СП - менее
> болезненный переход (через 5,6,7 лет - кто знает?) на более
> эффективные (и скорее всего, далеко НЕ бесплатные СУБД).
Это миф. Сама по себе замена СУБД эффекта не даст никакого.
Надо будет полностью перепроектировать систему и СП тоже.
> Вместо этого просто перечислили бы основные (проблемы
> и ограничения) - я не думаю, что получилось бы длиной
> как мой пост... :)
Ладно. Начнем с начала. Вот есть у нас система. Очень
сложные данные с кучей зависимостей и констрейнов.
Очень сложная логика. Логика такая сложная, что большинство
нужных нам операций одним SQL запросом выполнить
не получается. Даже прочитать нужные нам данные
одним запросом не получается. А нам нужны транзакции
и логическая целостность данных. И вот мы с клиента
стартуем транзакцию, получаем ответ, что стартовала
успешно. Посылаем запрос, получаем ответ, что
все хорошо. Повторить предыдущее предложение N-раз.
Потом фиксируем транзакцию если все было успешно
или откатываем при ошибках.
В чем у нас тут проблема? Если канал связи медленный,
модемный, или куча юзеров сидит на общей шине не
на свитче, а на банальном хабе, то это все по сети
гоняется медленно. Да пока клиент эти запросы
формирует, да пока переваривает ответы. Короче,
транзакция затягивается.
Чего в этом плохого? Плохо тут то, что транзакция
лочит данные, которые она затрагивает. И все остальные
юзера работать не могут, а просто ждут, пока транзакция
не закончится или не откатится. Понятно, что какой бы
навороченный сервер мы не поставили, он просто будет
простаивать в ожидании снятия блокировок, а ускорить
такую сложную транзакцию никак не сможет, ибо причина
в том, что тормозит клиент и его канал связи. Самое ужасное,
что для возникновения проблемы достаточно, чтобы тормозили
всего несколько клиентов из сотни. А дальше - цепная реакция.
Клиенты ломятся на сервер, пересекаясь по данным,
количество блокировок нарастает, в целях экономии ресурсов
(ибо размер буфера, где хранится информация о блокировках
быстро растет, пожирая память, следовательно лочить надо
более крупными кусками, тогда записей будет меньше, в идеале
нужна одна запись "залочена вся база целиком")
сервер применяет эскалацию блокировок, то есть лочит не
только записи, непосредственно затронутые транзакцией,
но и целиком страницы и даже целые таблицы, блокируя
рядом оказавшиеся ни в чем не виновные записи. В итоге
вероятность очередного клиента влететь на блокировку
еще больше возрастает. Скоро транзакции, так и не дождавшись
заблокированных данных, начинают отваливаться по таймауту.
Алгоритмы тут в разных СУБД разные. Некоторые работают
по принципу: "Кто раньше встал, того и тапки". Т.е. чья транзакция
началась позже, та и отлетит в случае конфликта. Другие поступают
умнее. Они замеряют, сколько ресурсов уже пожрала транзакция.
Понятно, что ту, которая стоила кучу сил серверу, убивать жалко,
потому прибита будет та, что меньше "стоила".
Смотрим, почему транзакции лочат данные и чем "сложные"
данные отличаются от "простых". Допустим, есть у нас таблица.
Куча юзеров могут параллельно в ней что-то делать, добавлять,
удалять, менять. Допустим, к одним и тем-же записям разные
юзера не обращаются. Понятно, что юзера друг-другу не мешают.
При очень быстром диске и мощном сервере юзеров может быть
очень много. Но вот мы захотели, чтобы был констрейн. Допустим,
хотим, чтобы одно из полей в таблице было уникальным.
Тем самым мы ввели неявные зависимости между разными
записями в одной таблице. Допустим, первый юзер стартует
транзакцию и удаляет запись со значением "ААА". Второй
юзер пытается вставить запись со значением "ААА". Можно
или нельзя? Все зависит от первого юзера. Он может как
подтвердить транзакцию (запись исчезнет и второй сможет
вставить свою) так и откатить транзакцию (запись вернется
назад, а второй юзер получит ошибку). Соответственно, второй
юзер должен быть залочен, пока первый не закончит свою
транзакцию. Аналогичные рассуждения можно привести
и для внешних ключей, когда возможность существования
записи с FK в одной таблице зависит от наличия записи с
PR в другой таблице. Т.е. тоже неявные зависимости.
В итоге мы понимаем, что чем больше констрейнов и FK,
т.е. чем более "сложные" данные у нас, тем больше записей
может быть заблокировано каждой транзакцией и много юзеров
уже не могут работать параллельно. Вообще, вопросы
изолирования транзакций и стратегии блокировок описаны
в специальной литературе.
Становится понятно, что необходимо транзакции проводить
как можно быстрее, данные проектировать так, чтобы
зависимостей было как можно меньше, уменьшать вероятность
обращения юзеров к одним и тем-же данным. Если бы клиент
не управлял транзакцией сам, а мог бы передать на сервер сразу
все необходимые для нее данные одним пакетом, то транзакции
не затягивались бы, а медленный канал был-бы проблемой
только этого клиента и не лочил бы всех остальных. То есть нужен
принцип "один пакет - одна транзакция". Аналогично,
было-бы хорошо, если бы все нужные для отображения данные
передавались бы с сервера на клиент также одним пакетом.
Как это сделать? Можно построить "трехзвенку на основе
двухзвенки". То есть данные, нужные для начала транзакции,
клиент неспешно засылает в разные временные таблицы,
никому не мешая. Потом запускает хранимую процедуру,
которая и проводит как можно моментальнее всю транзакцию,
а результат выдает в другие временные таблицы. Клиент,
опять никому не мешая, неспешно их оттуда забирает.
В итоге мы получаем сервер приложений на ХП.
Но гораздо интереснее, все-же не гонять по сети кучу
пакетов, да еще через временные таблицы, а сделать
более нормальный СП. Понятно, что нам мешает "бедность
SQL", который не дает выполнить сложные вещи одним
запросом, а кучу сложноструктурированных данных
нельзя передать параметром в ХП, оттого мы вынуждены сначала
засылать их в кучу временных таблиц. Потому наш СП
будет принимать от клиента сложноструктурированные
запросы и отдавать сложноструктурированные ответы.
Хотим, гоняем в формате XML, хотим, сериализуем в свой
компактный бинарный поток, да еще и зипуем, если с трафиком
совсем тяжко. Важно, что один пакет - одна транзакция.
Даже, если канал медленный и клиент тормозит - не беда.
Важно, что это не мешает остальным и не затягивает
транзакции.
А с другой стороны наш СП имеет толстый канал связи
с СУБД. Совсем физически независимая сеть, даже
отдельная сетевая карта, чтобы никто не мешал ему
как можно быстрее провести транзакцию.
У-ф-ф, руки устали. Как видите, пост получился длинный,
хотя затронули мы только одну проблему - повышения
масштабируемости с помощью трехзвенки и требуемую
конфигурацию сети обсудили.
> Интересует не то, что у Вас проблем не было, а сам принцип
> предоставления "тонким клиентам" их в доступ... Подключил
> я динамически dll... дальше что?
У нас нет dll. Сервер приложений полностью на скриптах. Поставляется
заказчику целиком в хорошо откомментированных исходниках. Если
заказчику нужен новый отчет или слегка измененный старый, он делает
копию существующего, исправляет и компилирует прямо на сервере
приложений. При запуске этот отчета генерит XML и отправляет
на клиента по медленному каналу связи. Клиент пускает XSLT
и получает XSL-FO, на который натравливает FOP
и получает красивый PDF. Ловкость рук и никакого волшебства.
Если заказчик не может сам сделать отчет, то просит нас.
> Как организовать диалог с пользователем (ввод параметров и т.п.), где
> у Вас хранятся эти диалоговые формы (или не хранятся? создаются
> динамически?)?
Диалог с пользователем организует клиентское приложение. Зачем
эти формы хранить? Чтобы потом по сети гонять? Пользователь
вводит параметры, из них формируется XML-запрос и пересылается
на сервер приложений на вход программы генерирующей отчет.
Если заказчику нужно извратится, то формы диалогов и процесс
создания XML-запроса находится в COM-компоненте на клиенте.
Заказчик пишет сам (или просит нас) другой компонент на любом языке
программирования и переопределяет стандартный компонент.
> Вот вопросы Вам "на засыпку" - создавалась эта ИС Вами лично
> с нуля или при Вашем участии, или Вы пришли "на готовое"
> и занимаетесь теперь только её поддержкой и развитием?
Проектировалась мной лично с нуля. Я занимался реализацией
всей серверной части. Клиентские части делали другие
разработчики. Приход меня "на готовое" обычно сопровождается
полным перепроектированием системы. Я это обычно сразу
уточняю при приеме на работу ;) На поддержку готового нанимают
сисадминов, а я - проектировщик.
> Сколько всего Вам довелось создать ИС с использованием 3-х
> звенной архитектуры (первую, наверное, легче всего было
> реализовать :) ).
Мне вообще не довелось делать двухзвенок, не считая
студенческих курсовых. А когда мы делали первую трехзвенку
еще и слова такого небыло. Люди фанатели даже от слов
"клиент-сервер". Была SUN-техника под солярисом,
была нетварь с ее NLM. Сетевой протокол был IPX/SPX.
Всякие дельфи, корбы, д-комы и ком-плюсы появились
сильно позже. Вот и вопрос, проще было или сложнее.
Даже С++ толком небыло. Только голый С.
> Принимали активное участие в проектировании и создании? - и что,
> СРАЗУ вот так всё заработало (без отладки и т.п.) и НИКАКИХ
> проблем не возникало???
Отладка и тестирование - как обычно в любой программе.
На начальном этапе было четыре варианта макета архитектуры.
Четвертый оказался наиболее удачным. На его кости уже
и нарастили мясо.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73
Posted via ActualForum NNTP Server 1.3
