Еще один вопрос. Почему на одном заводе так много серверов? С чем это связано? У вас несколько десятков территориально разнесенных площадок? Или их все-таки гораздо меньше, и есть другие причины для применения множества серверов с механизмами репликации?

Спасибо за ответ.

2 ASCRUS. Давайте отделим котлеты от мух. Давайте вспомним, что я говорил:
GaryaЯ пытался решать вполне определенную задачу и в какой-то момент у меня возникло ощущение, что с помощью Cache решать ее наиболее оптимально. Просто потому, что в этой задаче существенный акцент делается на иерархическую структуру данных и на механизмы наследования .В Sybase ASA, надо полагать, делается упор не на реляционные, а именно на иерархические структуры данных и имеются средства для реализации принципов ООП? Наличие развитых средств репликации является обязательным требованием, но только одним из нескольких обязательных требований, а не единственным. СУБД Cache меня привлекла как раз тем, что она заточена на иерархические структуры данных, в ней реализованы принципы ООП, включая множественное наследование. Но для меня явилось полной неожиданностью, что в ней напрочь отсутствуют средства репликации, которые, как я полагал, есть практически у любой уважающей себя СУБД, хотя бы в зачаточном виде такие средства имеются даже у настольных СУБД (вроде MS Access). Если вы почитаете чуть выше , то обнаружите приведенное мной краткое описание механизмов репликации MS SQL Server. Не думаю, что они по каким-либо параметрам уступают возможностям Sybase ASA. Там тоже автоматом создаются триггеры, обсуживающие репликацию, автоматом добавляются в реплицируемые таблицы служебные поля (GUID или Timestamp в зависимости от используемого вида репликации), если подобных полей в таблице изначально не было предусмотрено, тоже можно в триггерах репликации реализовать собственную бизнес-логику разрешения конфликтов репликации. Я привел две основные причины, по которым именно Cache оказалась плохо подходящим инструментарием для решения стоящих передо мной задач, но у других инструментариев имеются другие причины, которые в этом треде подробно не обсуждались.
А то, что касается конкретно репликации, я расскажу об этой задаче чуточку более подробно. Физические конфликты репликации, происходящие на уровне СУБД, должны быть исключены как класс - при любом раскладе (напомню, что я пытаюсь найти общее решение). Логические конфликты репликации должны разруливаться не DBA, а на уровне бизнес-логики участниками процесса. То есть, самим пользователями, действия которых привели к конфликту репликации. Опять же требуется найти общее решение, а не для конкретного бизнес-процесса с конкретным перечнем пользователей. Так что и в плане репликации существующие механизмы большинства СУБД (Sybase ASA в том числе) прямо в лоб без доработки использовать не удастся - придется нехило пораскинуть мозгами и руками.

2 Чингиз. На MS SQL (v.2000) тоже нормально работает репликация транзакций по модему, на котором рвется связь. Возможно, в MS об этом действительно не думали, и это получилось случайно... :)

Alex Roudnev LakrimosaПрошу прощения, господа, а "М" - это что такое?

Мне попадались ОЧЕНЬ серьезные системы, сделанные на Cache. Просто да, это пока _скрытый игрок рынка_. Вссе таки SQL - ну исключительно неудобный и кривой язык (в смысле - концепция), а всякие ораклы -исключительно перегруженные ненужностями продукты.

Так что будем посмотреть. -:):)
Вы знаете другой язык запросов , который, не объясняя алгоритмов, а только задавая желаемый для получения результат, может более красиво реализовать то же, что SQL? :)
Только именно не алгоритмический язык, а язык запросов , а то уже как-то доводилось слышать сравнение C++ с SQL...

Кстати, я видел очень серьезные системы, сделанные на ассемблере...

Насчет "пока"... Пока эта система будет до такой степени завязана на MUMPS, который исторически изжил себя, он всегда будет оставаться "незаметным игроком", ПМСМ. Пока его ЯДРО будет работать с безтиповыми данными (всё преобразуется в текст), он будет терять на этих самых преобразованиях и существенно проигрывать в быстродействии тем СУБД, у которых целые команды огромными толпами мозги ломают над тем, как еще улучщить работу оптимизатора запросов.

Cache - это "поделка", не более того. Именно для небольших контор с небольшими требованиями к надежности. Транзакционность реализована наполовину. Многоступенчатой фиксации распределенных транзакций - нет! О каких крупных системах можно говорить, если СУБД не содержит встроенных механизмов репликации, если нет поддержки кластеров и многопроцессорных систем? Никто мне не смог ответить на вопрос, как поддерживается логическая целостность данных в БД с "прямой записью" (без журнала транзакций), если архивирование БД делается одновременно с интенсивной записью пользрователями информации в БД... подозреваю, что никак.

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

Всё сказанное - ПМСМ.

Языки запросов в последнее время очень интенсивно перемешиваются с алгоритмическими языками. В конечном итоге на практике нужны возможности и тех, и других.
По поводу "объектности", о которой так много говорят апологеты Cache'... MUMPS изначально представлял из себя язык для манипулирования данными СУБД иерархического типа . Хочу напомнить о том, что СУБД иерархического типа - это ДО реляционные СУБД, а не ПОСТ реляционные. Наличие иерархии - это, конечно же, в некоторой степени роднит с понятиями ООП (которые появились существенно позже, чем MUMPS), однако, это еще далеко не всё, что требуется для полноценного ООП. В частности, требования инкапсуляции в ООП требуют автоматического управления областью видимости объектов, переменных и методов. С этим в MUMPS имеются очень серьезные проблемы. В частности, переменные необходимо явно уничтожать, поскольку по умолчанию они создаются как static-переменные и продолжают существовать далеко за пределами области их определения. Я уж не буду повторять всех тех анахронизмов, которые до сих пор имеются в MUMPS и не имеют никакого отношения ни к постреляционности, но и вообще к удобствам работы, о них я уже высказывался на этом же форуме.

Ну и, наконец, основное, на что я хотел бы сделать упор - это надежность, о которой апологеты Cache' не любят или не хотят говорить. Нет никакого смысла говорить о крупных серьезных информационных системах, в которых вопрос надежности находится на 10-м месте. В Cache' имеется возможность выполнения распределенных вычислений, которые транзакциями назвать язык не поворачивается. Потому что механизм двухступенчатой фиксации - отсутствует. О какой транзакционности, о каком соблюдении непротиворечивости информации может идти речь, если при выполнении распределенных вычислений на одних серверах транзакция может закрепиться, а на других откатиться? Далее... очень много слов о том, какой выигрыш в быстродействии дает отключение ведения журнала транзакций для отдельных баз данных. А как же надежность? Каким образом выполняется архивирование таких баз данных непосредственно во время работы пользователей в этой базе данных? Блокируется работа всех пользователей при старте процедуры архивации? Или в архив совершенно спокойно записываются состояния разных частей базы данных на разные моменты времени, которые могут привести к нарушению логической целостности архива? Я вообще не понимаю, каким образом можно запускать архивирование баз данных, у которых отключена запись в журнал транзакций.
Репликация имеется даже в настольных СУБД. В Cache ее просто нет. Нет, я охотно верю, что кому-то удалось реализовать ее "врукопашную", то есть, убить слона, сделав 1000000000 выстрелов по нему из рогатки, после чего он умер от старости... :) Но говорить о том, что система, которая не обеспечивает столь элементарных вещей, которые обеспечивает любая уважающая себе СУБД с на несколько порядков меньшими амбициями, является " пост ореляционной" - это все равно, что объявить мамонта, на боку на боку которого пришпандорена светящаяся реклама "новое поколение выбирает пепси", пост -слоном. :)

Да, появились новые возможности, да есть множественное наследование... Но нет много другого - того, что используется совместно даже с простым наследованием, а не с множественным. То есть, у мамонта есть крылья с изменяющейся стреловидностью, но нет ни реактивного двигателя, ни даже пропеллера. Поэтому мое общее ощущение о данном продукте таково - да, есть неплохие идеи, которые требуют развития. Но на том уровне, на котором этот продукт находится в настоящий момент - это мамонт с яркими елочными украшениями. Все сказанное - ПМСМ, никому свое мнение не навязываю.

VadimFПодмена тезиса. Надежность и двухфазная транзакция - это не одно и тоже.
Для обеспечения высокой надежности и доступности системы применяются журналы до и после записи, теневые сервера, FailOver кластера, кластерные конфигурации и т.д.Я говорю о надежости информации. О том, что она не исказиться при записи в БД. Кластера никак не помогут избежать нарушения логической целостности информации, если распределенная транзакция будет зафикисрована на одних серверах и откачена на других. Хотя бы в результате ошибки, возникшей на одном из серверов. Программной ошибки, ошибки ввода-вывода, или отсутствия данных, с которыми предполагались некоторые манипуляции - а их не оказалось... Да мало ли может быть причин, от которых кластера не лечат?

VadimF Garya
Репликация имеется даже в настольных СУБД. В Cache ее просто нет.


Есть синхронизация объектов. Можно почитать про нее в документации ( Object Synchronization ).Читал я многое из того, на что Вы даете ссылки, прежде чем сделал выводы. Синхронизация предусматривает взаимодействие всего лишь ПАРЫ серверов. Когда серверов больше двух (а в крупных системах их может быть очень много), то неизбежно должен быть некоторый координатор, который управляет передачей информации со множества источников на множества приемников, в том числе, транзитными передачами информации, в том числе имеющими разные периоды синхронизации и разные размеры порции передаваемой информации, и разные точки приложения ("вытягивание" и "выталкивание"), и много еще чего другого... В Cache подобного координатора не предусмотрено. Делать его врукопашную - это все равно, что пользователю пытаться доделать СУБД за ее вендоров, слишком трудоемко и непонятно, почему каждый отдельный пользователь для себя должен ваять подобного координатора - на это не одну жизнь можно положить. Почему вендоры Oracle и MS SQL, например, будучи НЕ " пост -реляционными", а всего лишь простыми реляционными, все-таки удосужились сделать подобных координаторов, не смотря на свою идеологическую отсталость?

LittleCatИнтересно, где Вы все это прочитали ? Или это Ваши домыслы ?Нет, это не домыслы. Кашисты очень часто смешивают понятия "репликация" и "распределенными БД", что по сути некорректно. Этот вопрос уже обсуждался.

P.S. Дискуссия начинает приобретать эмоциональный окрас. Прошу извинить, если кого-то обидел. :)

LittleCat...вопрос касался архивирования БД :-) Если в двух словах на пальцах, при архивировании без остановки работы запись в базу замораживается, все изменения начинают писаться в журнал. Когда база заканчивает копироваться, изменения вливаются в базу, а журнал копируется.То есть, Вы хотите сказать, что при отключенной записи в журнал эта запись все равно производится при запуске процедуры архивирования? Если это так, то, разумеется, уже горзадо лучше. Но когда я задавал этот вопрос представителям InterSystems, они вразумительно ответить на него не смогли. В документации ответа на него я тоже не нашел. До какой степени Вы уверены, что архивирование производится именно таким образом и на чем основана эта уверенность?

Спасибо. Жаль, что Вы не из InterSystems. :)