Моё меню Общее меню Пользователи Правила форума Все прочитано
Вернуться   uForum.uz > ИКТ и телеком > IT-индустрия > Софт > OpenSource
Регистрация
Знаете ли Вы, что ...
...для каждой темы существует свой раздел. Изучите структуру форума. Если соответствующего раздела нет, то всегда есть раздел "Разное" :)
<< Предыдущий совет - Случайный совет - Следующий совет >>


Ответить

 
Опции темы Опции просмотра
Старый 29.12.2008 18:55   #81  
Real ID Group uParty Member Ultimate
Аватар для Nadir Zaitov
Оффлайн
Сообщений: 13,214
+ 4,958  9,176/3,940
– 170  137/105

UzbekistanОтправить сообщение для Nadir Zaitov с помощью Skype™
Цитата:
Сообщение от Leonid Khrisanfov Посмотреть сообщение
Только сравнивать её нужно с подобными ей.
Что еще Оракула отличает от простых смертных других СУБД, например, от послеГре кроме этого (RAC):
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Явного аналога в PostgreSQL точно нет. Это - однозначно.
Дайте ясное понятие.
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим.

Последний раз редактировалось Nadir Zaitov; 29.12.2008 в 19:01.
Ответить 
Старый 29.12.2008 19:17   #82  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,846
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Дайте ясное понятие
Долго пытался выудить от кого-либо из специалистов по системам управления базами данных ясные и четкие (практические, не маркетинговые) заключения. Без какого-либо ощутимого результата. Поэтому остановлюсь на "маркетинговой" постановке вопроса: реальных аналогий технологическому решению Oracle Real Application Clusters (Oracle RAC) нет не только в PostgreSQL, но и в любой другой СУБД (попадавшейся мне в поле зрения в качестве потенциального кандидата на СУБД промышленной корпоративной информационной системы).

Такая постановка вопроса совершенно не отменяет саму возможность использования альтернативных СУБД в качестве ядра прикладной информационной системы. Просто масштабирование системы будет осуществляться или по вертикали (путем удорожания серверной аппаратной платформы) без каких-либо серьезных проблем, или по горизонтали с большими "бубнами" на всех уровнях (приложение, СУБД)
__________________
DWBH

Последний раз редактировалось Eldar Fattakhov; 29.12.2008 в 19:20.
Ответить 
Старый 29.12.2008 19:30   #83  
Real ID Group uParty Member
Аватар для Erkin Kuchkarov
Оффлайн
Временно безработный
Сообщений: 19,982
+ 1,053  10,223/4,873
– 6  573/377

UzbekistanОтправить сообщение для Erkin Kuchkarov с помощью Yahoo
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
в любой другой СУБД
У любых других есть другие методы
Ответить 
Старый 29.12.2008 19:37   #84  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,846
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Erkin Kuchkarov Посмотреть сообщение
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
в любой другой СУБД
У любых других есть другие методы
Совершенно согласен! Но другие. Я не о том веду речь, что ничего нет лучше Oracle (с её RAC). Вопрос только в готовности разработчиков прикладных комплексов и системных интеграторов реализовывать те или иные методы обеспечения доступности и отказоустойчивости прикладных комплексов, а также (при необходимости) балансировку приложений между узлами кластеров. На другой чаше весов - готовность заказчика платить за одни механизмы, или за другие (включая все составные части - обучение, сопровождение, развитие и т.п.)...
__________________
DWBH
Ответить 
"+" от:
Реклама и уведомления
Старый 29.12.2008 21:24   #85  
Real ID Group uParty Member Ultimate
Аватар для Nadir Zaitov
Оффлайн
Сообщений: 13,214
+ 4,958  9,176/3,940
– 170  137/105

UzbekistanОтправить сообщение для Nadir Zaitov с помощью Skype™
Оффтоп:
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Но другие.
Вопрос, как всегда в маркетинге: ценовой (сколько мне выложить, за такое счастье) или временной (сколько месяцев "танцевать с бубунами"). Мне на ум в таких случаях приходит идея не рости уже в ширь, а только ввысь -стройнее будешь .
Вместе с тем, я что-то не вижу других преимуществ Oracle....
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим.
Ответить 
Старый 29.12.2008 21:28   #86  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,846
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Вместе с тем, я что-то не вижу других преимуществ Oracle....
Их много. В том числе - в продвинутых средствах бизнес-аналитики (даже на уровне самой СУБД, в виде дополнений к версии Enterprise). Нужно учиться всем - и разработчикам в первую очередь.
__________________
DWBH

Последний раз редактировалось Eldar Fattakhov; 29.12.2008 в 21:40.
Ответить 
Старый 29.12.2008 21:29   #87  
Real ID Group uParty Member
Аватар для Erkin Kuchkarov
Оффлайн
Временно безработный
Сообщений: 19,982
+ 1,053  10,223/4,873
– 6  573/377

UzbekistanОтправить сообщение для Erkin Kuchkarov с помощью Yahoo
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
я что-то не вижу других преимуществ Oracle....
Ну скажем возможность хранить в одном BLOB поле несколько "сложных" объектов. Для начала
Ответить 
Старый 29.12.2008 21:47   #88  
Real ID Group uParty Member Ultimate
Аватар для Eldar Fattakhov
Оффлайн
Сообщений: 11,846
+ 1,339  5,806/3,144
– 64  125/105

Uzbekistan
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
приходит идея не рости уже в ширь, а только ввысь -стройнее будешь
Кошелёк тоже будет стройнеть. Отгрузим midrange или hi-end серверы с огромным удовольствием!
__________________
DWBH
Ответить 
Старый 29.12.2008 22:54   #89  
Аватар для Vsevolod Usmanov
Оффлайн
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3  6/6
– 0  0/0

Uzbekistan
Оффтоп:
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Цитата:
Сообщение от Erkin Kuchkarov Посмотреть сообщение
По дисковым?
Мы говорим о разных вещах. Для меня кеш - это кусок памяти любого где угодно (внутри процессора, перед процессором, в оперативке под контролем СУБД, в оперативке под контролем ОС, в контроллере дисковой подсистемы, у самого физического диска - мне по барабану, главное, что этот кусок памяти хранит информацию исходя из последних насущных потребностей вышестоящего уровня в реальном ЭВМ. И мне все по баробану, как Фон Нейман представлял ЭВМ в далеком начале 20 века...
Цитата:
Сообщение от Leonid Khrisanfov Посмотреть сообщение
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Цитата:
Сообщение от Erkin Kuchkarov Посмотреть сообщение
Данные для записи не хранятся в кеше (-ах). Они каким то чудесным образом модифицируют хранимые данные в БД. Иначе никто бы этим не пользовался - не было бы гарантий изменения данных в БД. И всякие там хьюлеты и паккарды, фуджики и сименсы совместно с емсями или нетапами не продавали бы хранилища централизованные и бедное циско не выступало бы в противовес брокейдам со своими сан свитчами... могу ошибатся
Да, они из кеш одного сервака в узле записываются в БД, да вот как потом БД как меняет кеш другого сервака, чтоб другой сервак отрабатывал уже измененые данные, а не перечитывал всю информацию с ДП, иначе на скорости чтения с ДП теряется весь смысл распрелеления нагрузки БД?
Оффтоп:
Вы издеваетесь или проверяете на стойкость мои нервы?
Всё верно. Приблизительно так всё и происходит, кэш-память общая, и название этому тоже имеется - "Cache Fusion" - одна из главных "фишек" RAC.
По поводу Cache Fusion, "кешей" различного рода и их синхронизации... Тоже самое кратко изложил в своих постах ранее г-н Erkin Kuchkarov, но, как мне показалось был не понят.

В Oracle DB есть область памяти, называемая буферный кэш, где временно хранятся блоки данных. При первоначальном запросе каких-либо данных соответствующий процесс Oracle считывает блоки данных с дискового устройства и сохраняет их в буферном кэше (в идеале предполагется, что эти данные больше не придется считывать). При изменении данных изменения происходят в соответствующих блоках буферного кэша, а не на устройствах физического хранения.

Oracle RAC состоит из нескольких узлов серверов базы данных. Каждый узел имеет набор своих процессов и свою структуру памяти – в том числе и буферный кэш.

Далее вырезка из документации Oracle (Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide).
Цитата:
Oracle RAC databases have two or more database instances that each contain memory structures and background processes. An Oracle RAC database has the same processes and memory structures as a single-instance Oracle database as well as additional process and memory structures that are specific to Oracle RAC. Any one instance's database view is nearly identical to any other instance's view within the same Oracle RAC database; the view is a single system image of the environment.
Each instance has a buffer cache in its System Global Area (SGA). Using Cache Fusion, Oracle RAC environments logically combine each instance's buffer cache to enable the instances to process data as if the data resided on a logically combined, single cache.
To ensure that each Oracle RAC database instance obtains the block that it needs to satisfy a query or transaction, Oracle RAC instances use two processes, the Global Cache Service (GCS) and the Global Enqueue Service (GES). The GCS and GES maintain records of the statuses of each data file and each cached block using a Global Resource Directory (GRD). The GRD contents are distributed across all of the active instances, which effectively increases the size of the System Global Area for an Oracle RAC instance.
After one instance caches data, any other instance within the same cluster database can acquire a block image from another instance in the same database faster than by reading the block from disk. Therefore, Cache Fusion moves current blocks between instances rather than re-reading the blocks from disk. When a consistent block is needed or a changed block is required on another instance, Cache Fusion transfers the block image directly between the affected instances. Oracle RAC uses the private interconnect for inter-instance communication and block transfers. The Global Enqueue Service Monitor and the Instance Enqueue Process manages access to Cache Fusion resources as well as enqueue recovery processing.
Ответить 
Старый 30.12.2008 14:42   #90  
Аватар для kdima71
Оффлайн
Nihol
тех. специалист
Сообщений: 16
+ 0  2/2
– 0  0/0

Uzbekistan
Цитата:
Сообщение от Eldar Fattakhov Посмотреть сообщение
Цитата:
Сообщение от Nadir Zaitov Посмотреть сообщение
Дайте ясное понятие
Долго пытался выудить от кого-либо из специалистов по системам управления базами данных ясные и четкие (практические, не маркетинговые) заключения. Без какого-либо ощутимого результата.
Сравнивать ту или иную СУБД это не благодарный труд.

В Сети существует куча материала на это счет. И эта тема ни к чему как правило не приводит.

Специалисты Oracle остануться на своем, специалисты DB2 скажут что Oracle со своей версионностью достал уже всех. Oracle возразит и скажет, а у Вас в DB2 «читатель ждет писателя» по умолчанию, если не использовать уровень изоляции «чтение грязных данных», на что DB2 скажет, Вы со своими «сегментами отката» порождаете огромное количество redo информации. Или, у нас есть RAC, а у Вас что? А у нас есть, секционная База Данных!!!

Что касается, PostgreSQL (и других условно-бесплатных СУБД), то они просто пытаются повторить с некоторым опозданием ТЕХНОЛОГИИ старших братьев и все! Никаких НОВЫХ и ПЕРЕДОВЫХ технологий ОНИ не изобретают!

Кроме того, все понятно...бесплатно и открыто....а кто отвечать будет, если что случиться???

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

Друзья, поверьте никто не отменял поговорку..."Скупой платит дважды!"

Последний раз редактировалось kdima71; 30.12.2008 в 14:53.
Ответить 
Ответить
Опции темы
Опции просмотра




Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot
Advertisement System V2.5 By Branden
OOO «Единый интегратор UZINFOCOM»


Новые 24 часа Кто на форуме Новички Поиск Кабинет Все прочитано Вверх