Comments 8
Все описанные выше системы CP. В тот момент, когда SAN отвалится или связь с координатором транзакций прервётся, они перестанут принимать и отдавать данны, чтобы не нарушить целостность.
Вы рассматриваете разные сценарии.
Если прервалась связь с координатором, это равносильно потере узла. Узел без координатора не будет считать себя кластером.
Отвал SAN — это полная гибель кластера, никаких частей не будет. Но обычно SAN там, где она есть, значительно надёжнее, чем сеть, а дисковые массивы, особенно hi-end, на порядок надёжнее самых дорогих серверов.
Пара уточнений:
SAP HANA работает не только на x86, но и на IBM POWER
В продуктивную эксплуатацию допускаются не только сертифицированные апплайнсы с фиксированным core-to-memory, но и серверы из списка supported systems в SAP HANA hardware directory в конфигурациях от 16ти ядер и 128ми GB по модели TDI5 и workload sizing.
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д) (за очень редким и специфическим исключением а-ля очень большие SAP S/4HANA ERP). Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.
SAP HANA работает не только на x86, но и на IBM POWER
В продуктивную эксплуатацию допускаются не только сертифицированные апплайнсы с фиксированным core-to-memory, но и серверы из списка supported systems в SAP HANA hardware directory в конфигурациях от 16ти ядер и 128ми GB по модели TDI5 и workload sizing.
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д) (за очень редким и специфическим исключением а-ля очень большие SAP S/4HANA ERP). Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.
В продуктивную эксплуатацию допускаются… серверы из списка supported systems
Да, это так. Но ведь это тоже сертификация, только ей занимается не поставщик оборудования, а непосредственно клиент. Надо подумать, как корректно сформулировать эту мысль :)
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д)
Вот на счёт и т. д. – можно поподробнее? Мне не удалось найти никаких упоминаний о HANA без связи с SAP. Да и не могу даже придумать, зачем стороннему разработчику писать под HANA.
Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.
Хороший комментарий.
Любая сложная система, включая СУБД, это целый комплекс архитектурных решений, и классифицировать СУБД по какому-то одному признаку я считаю категорически неправильным. Когда я читаю «in-memory базы работают быстрее, чем реляционные» (реальная цитата из статьи на Хабре), моя рука тянется к огнемёту.
Да, подсистема хранения у HANA отличается от Oracle или DB2 радикально. Но что касается устройства кластера – тут их вполне можно сравнивать.
Но ведь это тоже сертификация, только ей занимается не поставщик оборудования, а непосредственно клиент
Да нет никакой сертификации «на клиенте». Теперь даже тест HWCCT не обязательно прогонять перед Go-Live ;)
Вот на счёт и т. д. – можно поподробнее?
Я имел ввиду, что ничто не мешает запилить свое собственное MPP DWH на хАне без BW-блекджека, но, честно признаться, мне про такие кейсы неизвестно (что не означает, что их нет). Да и вообще очень похоже, что SAP'у не сильно интересно продвижение HANA'ы в качестве универсальной СУБД (по большей части сделано «под себя»).
классифицировать СУБД по какому-то одному признаку я считаю категорически неправильным.
Да тут дело не в классификации, а скорее в том, что есть и чего нет в конкретной СУБД. У той же DB2 есть как shared-nothing кластер для OLAP задач (DPF+BLU) так и shared-disk кластер для OLTP задач (pureScale). У HANA'ы по-сути только shared-nothing для OLAP.
Да нет никакой сертификации «на клиенте».
Вот это новость, как и наличие версии под POWER. Спасибо.
shared-nothing для OLAP.
Ну какой же это shared nothing. Это вполне себе shared disk.
DPF+BLU
И ещё раз спасибо. Я как-то совершенно не знаком с портфелем голубого гиганта. Думал, в части OLAP у них в основном Netezza, а оказывается и такое есть.
Ну какой же это shared nothing. Это вполне себе shared disk.
В scale-out-кластере хАны у каждой ноды свои датаволюмы и они не шарятся. Так что логически это вполне себе shared-nothing хоть и физически обычно лежит на одной СХД («shared-disk») ;)
Думал, в части OLAP у них в основном Netezza, а оказывается и такое есть.
Netezza по факту уже давно мертва, с DB2 BLU/DPF ситуация не сильно лучше «благодаря» «усилиям» голубого гиганта. В этой нише они старательно и целенаправлено «прос… ли все полимеры».
В scale-out-кластере хАны у каждой ноды свои датаволюмы и они не шарятся.
Вы же знаете анекдот про Циммермана, который продавал водку по 10 рублей? Недовольные покупатели говорят «а у Зильберовича – по 8!» – «Ну так идите и купите у Зильберовича!» – «А у него кончилась...» – «Ну вот когда у меня кончится, я тоже буду продавать по 8»
То есть до тех пор, пока всё идёт нормально – да, доступ к чужим дискам не нужен. В точности как в NonStop SQL. Но как только узел вылетает, без доступа к чужим дискам – никак.
В этой нише они
Да и не только в этой.
Но это ладно, IBM хотя бы прикладной наукой жива. А вот чем жив HP, с учётом того, что Proliant больше не является уникальным продуктом, я даже и не знаю…
Sign up to leave a comment.
Распределённые СУБД для энтерпрайза