|
guest_20040621ОК, дайте ответы на эти вопросы не публично, не в форуме, а, скажем, опишите задачу Вашему интегратору. Типичный ответ, который Вы, уверен, получите (речь сейчас об аппаратной части) будет таким: с одной стороны, характеристики кластера и СХД ограничены Вашими требованиями, с другой стороны - бюджетом.
Вот именно с таким подходом мы и получили от двух разных поставщиков два разных решения с детализацией до стандартных продуктов, доработок, и железа и со стоимостями, отличающимися на порядок.
Решения абсолютно разные. Разные платформы, разная база, разное все.
Не могут этих вещей определить требования. Требования могут только сказать (с долей вероятности) - подходит или не подходит конкретное решение. Ну, если про деньги еще забыть.
guest_20040621
Да нет такой характеристики: высокая доступность. Сколько девяток? Пять, семь, девять? Вы вообще представляете себе разницу в стоимости реализации? Представляете, сколько будет стоить катастрофоустойчивое решение? ;)
Катастрофоустойчивое будет стоить немного дороже двух просто отказоустойчивых :) Катастрофоустойчивое пока не нужно, слава Богу. Пока.
guest_20040621
Сотни гигабайт, терабайт, петабайт? Динамика роста какова?
Ну, где-то пару сотен гигов в год. Что это вам дало?
guest_20040621
> даже вообще не на RDBMS
Поэтому я и спросил про природу данных.
Природу я вам не скажу :) Природа одна, а решения нам уже предложили разные :) Люди, у которых была вся информация. И нас устроят оба эти решения, если их действительно сделают .
guest_20040621
Многое. Например, на выбор СУБД может влиять (не всегда, просто как пример) схема бэкапа, которая в свою очередь связана с топологией кластера, который выбирается исходя из требуемой доступности.
Эк вы загнули... Гипотетически - возможно. Но на практике - это "шиворот на выворот" получается.
guest_20040621
> "Как хранить данные" - это уж точно из области проектирования, а не
> постановки требований.
Нет.
Значит, задайте вопрос нормально. Как система хранит свои данные - это не влияет на бизнес.
guest_20040621
> делать надо на Oracle + EJB на WebLogic
Imho плохое решение.
Пусть плохое. Не в этом суть. А суть в том, что нам технология НЕ критична. пусть поставщик ее определяет. Вот если бы вы были поставщиком, а мы бы к вам приперлись с требовнаием сделать на Orcle + EJB + WebLogic с нашими требованиями - вам бы не понравилось. А нам реально - не важно на чем это БУДЕТ СДЕЛАНО и на чем это БУДЕТ РАБОТАТЬ. Лишь было сделано хорошо, и работало, и поддерживалось и изменялось при необходимости.
guest_20040621
> то уж поставщика это все равно абсолютно не определяет
Еще как определяет. Очень немногие в России могут реализовать такую задачу.
Итак, кто те немногие, кто может? :)
guest_20040621
> если поставщик умеет и любит работать с продуктами IBM
;) Т. е., оказывается, какие-то предпочтения априори существуют?
Нет. Замените в предложении IMB на HP или SUN, по вашему усмотрению.
guest_20040621
;) Вы замечаете, что постепенно начинаете уточнять задачу?
Замечаю. Хотя мне этого очень не хочется.
И не нужно. Мы сейчас с вами начинаем что-то прикидывать, как что-то делать с моими требованиями. Я этого принципиально не хочу от беседы здесь. Прикинуть и я могу. Но задача - не просто Оракл настроить в DataGuard или в RAC. Это, как правильно заметили, всего-лишь СУБД. А есть функционал. Разный. Некоторые вещи - на стыке отраслей. Некоторые - требовательны к времени выполнения и надежности. Некоторые - требуют гибких изменений в процессе эксплуатации.
Попробую еще раз вернуть беседу в нужное мне русло - в предположении , что мы хотим отдать эту разработку на заказ одному из ведущих российский разработчиков ПО - кого можно было бы нам посоветовать, чтобы обеспечить максимально качественный и гарантированный результат? Если выданная выше дополнительная информация чем-то поможет в таком совете - ну чтож, хорошо...
|
