User_AndyГоспода, у кого какое мнение?

Имеем:

Информационную систему: D, R, C
С - основной уровень (несколько серверов)
R - база второго уровня, которая напрямую связана с C (в количестве 89 серверов)
D - база третьего уровня, которая напрямую связана с R, а соответственно с C (в количестве от 1 до 30 для каждого сервера R)


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

User_Andy
Таким образом, получаем несколько тыс. серверов, которые так или иначе связаны между собой по след. цепочке(D1_10-R10-C-R89-D89_02-R89-С-R10-D1_10), т.е. связь "один ко многим" и обратно. Взаимодействие клиента с сервером происходит исключительно на уровне D (в какой-то степени на уровне R). Клиентов у каждого D-сервера может быть от 1 до 200. Транзакции между серверами тоже.

Повторяю вопрос: что, не как AS/400?
Ответы типа: "отстой" и т.д. не принимаются. Приветствуются вменяемые аргументы.

С уважением к посетителям форума,
User_Andy

Заменяем интегрирацию на уровне БД интеграцией на уровне web-сервисов или какой-нибудь другой реализации RPC и получаем... Обычную трёхзвёнку. Ну или не очень обычную четырёхзвёнку, если очень хочется.

На чём её реализовать? Вариантов море...

ОС - от Tru64 UNIX и AIX до Windows и Linux.

Сервер приложений - от WebSphere до Apache. А можно и что-нибудь самописаное, некрасивое, но эффективное...

СУБД... Ну, тут наверное, только DB2 с Oracle справятся. Хотя если индексации, кластеризации и репликации прямыми ручками настроить - может, даже Sybase ASE, MS SQL 2005 и (о ужас!) бесплатные PostgreSQL 8 с MaxDB потянут.

Железо... AS/400 - это, конечно, чрезвычайно круто. Но... Кластер из кучи стареньких дешёвеньких серверов со своим MPI его возьмёт да и обгонит, ещё и по надёжности превзойдёт. Выключил 10 серверов из 20 - а мужики-то и не знают :)... Доказано Google.

Перефразируя высказывание про покрывало алтаря и подстилку, "Суперкомпьютер в предыдущей эпохе - наладонник в следующей".

User_Andy
Работа происходит в режиме realtime.


На смом деле? С гарантированным временем реакции системы и жезлово-приоритетной (так это, кажется, называется?) организацией сети, как в бортовой ИС самолёта? Или всё-таки с обычно небольшим, но не гарантированным временем?

*********************************************************
Всё выше сказанное - моё мнение. Я не хочу обидеть кого-нибудь лично или оскорбить чьи-либо высокие чувства. Кластеры Tru64 я видел, кластеры Linux - собирал.

ggvAlex - вот в том то и дело, что задача не описана, со множеством неизвестных.
А если задача не описана - то имеет ли смысл искать её решение? Или есть желание найти решение, реализовать его, ударно освоив несколько сот млн. $ (суперкомпьютеры нынче дороги), а потом уж подобрать к нему задачу? Мне кажется, сначала нужно долго интервьюировать, анализировать, формализовать, моделировать, проектировать, планировать. А уж потом думать, разместить будущую систему на сотне суперкомпьютеров или на одном однопроцессорном intel-серверке начального уровня.

ReNoiZer
потом вспомните что mySAP крутится на MaxDB(SAP DB) уже много лет.

Я-то помню. Но при повышении нагрузки сами SAP'овцы рекомендуют перевести её на Oracle.

ReNoiZerДля до ужаса напуганых чтите
это <...о судебных дрязгах...>
и это <...ещё о о судебных дрязгах...>
<...>
А затем свяжите финансовые показатели организаций.
После этого MaxDB с его бесплатностью, встанет бельмом в глазу у здравомыслящего ораклойда. 8)
Не вижу связи. Мы говорим о СУБД, а в статьях говорят о ERP-системах. Мерять же ERP-системы по используемой СУБД - неправильно. А перехваливать себя (Oracle) и считать чужую прибыль (SAP) - не что иное как усердно валять свою репутацию в несмываемой грязи.

ReNoiZerЭто ещё откуда взялось?! Верояно последние такие рекомендации относятся к 8-10 летней давности, когда в целом и произошел разрыв в сотрудничестве Oracle и SAP! lol
Они могут сколько угодно разрывать сотрудничество. Вот если они сделают свои продукты несовместимыми - то обе компании потеряют много денег.

Если SAP всё ещё часто переводят с бесплатной MaxDB на платную Oracle - значит, это имеет смысл. Не нужно считать всех, кто занимается поддержкой и доработкой готовых ERP, неосведомлёнными простофилями.

ReNoiZer
И почему люди тогда берут на себя смелость говорить так:<...>

Ради PR.

ReNoiZer
Я всегда слышал рекомендацию - при очень тяжелых нагрузках желательно использовать кластерные решения, MaxDB это реализует.

Oracle тоже. Как и большинство совремнных СУБД.

ReNoiZer<...Бенчмарки...>
Кто-то старался доказать всем, что у него работает быстро...

ReNoiZer
AlexTheRavenМерять же ERP-системы по используемой СУБД - неправильно.
Это прикол? Да?
<...>

Отнюдь. Мне одинаково безразличны SAP и Oracle. Ценность ERP-системы - не в чудесной БД на чудесной СУБД, и даже не в комплексной автоматизации деятельности предприятия, а в поддержке безошибочной и организованной работы, а следовательно, экономии денег. Не верите? Спросите у генерального директора.

ReNoiZerЛично мной на вскиду видны только следющие причины использования Oracle для ERP от SAP:
1) отсутствие необходимости переводить с уже купленной ранее и работающей связки
2) не желание осваивать новую систему, если уже ранее Oracle был опыт работы
3) боязнь оказаться не "как все"

Точно не без этого:) . А сведения - от друзей, работающих в нескольких компаниях-системных интеграторах. К которым время от времени обращаются предыдущие клиенты с просьбой перевести с MaxDB на Oracle, т.к. становится некомфортно. Переводят, и вроде бы становится полегче. Хотя, возможно, если бы прямыми ручками почистить и подкрутить MaxDB - эффект был бы тем же.

ReNoiZerЭх если бы наш ген. директор знал что значит абривеатура ERP систем... По-видимому, он хороший директор, у него хорошие сотрудники, и поэтому он может себе позволить ничего не знать об IT :) .

А с AS/400, OS/400 и DB2/400 что делать будем? Таки есть ей альтернатива кроме "Эльбруса" и Шуклинского Cerebrum'а :)?