не важно, реплицируется диск целиком или только журнал базы
Как раз это очень важно, потому что «запись на диск» и «проигрывание журнала» – это разные вещи. Вы правы, чем ниже уровень репликации, тем выше вероятность переноса ошибки на реплику. Но в случае с репликацией средствами БД эта вероятность существенно меньше.
кворумная запись с автоматическим leader election
Технология репликации и топология кластера – это два совершенно отдельных вопроса. Никто не мешает сделать две синхронных реплики и успешно фиксировать транзакцию, когда ответила хотя бы одна из них.
но, насколько я знаю, физическую никто не выбирает.
Вас обманули :))
У MySQL действительно нет общедоступного средства физической репликации, поэтому выбирать не из чего. Но у всех промышленных экземпляров «взрослых» СУБД – Oracle, MS SQL, PostgreSQL, DB2 – есть физическая реплика, она же standby.
Фундаментальных причин для этого нет. Ответ на вопрос «почему так» надо искать в условиях тестирования:
насколько прогрет кэш в первом и втором случае
какие диапазоны идентификаторов (работа с длинными идентификаторами может быть чуть медленнее, чем с короткими, но заметно это на сценариях типа NUMBER vs VARCHAR2)
какие параметры PCTFREE/PCTUSED у индекса и у таблицы
Вообще-то тему «будущего» вы сами подняли в заголовке. СУБД будущего ориентируются всё-таки на современные подходы к разработке, а не на поддержку дремучего legacy. Как по мне, так будущее за KV-хранилищами (потому что при использовании JPA навороченный SQL не очень-то нужен) и умными сетевыми СХД (типа Amazon Aurora).
Своим методом я выигрываю уменьшение конкуренции за последовательность. Это не магический объект, а просто строка в системной таблице, обёрнутая «синтаксическим сахаром».
А вот мне даже любопытно, какая операция выполняется медленнее, если в PK есть промежутки? У меня фантазии не хватает.
Использование первичного ключа для чего-то кроме первичного ключа – это тоже очень плохой шаблон. Судя по вашему описанию, там вся система – костыль на велосипеде копипейстом погоняет, а требования – к СУБД будущего…
2. Потому что это не относится к СУБД. Управление НСИ – это совершенно отдельная область знаний.
3. Автоинкремент – это плохой шаблон, триггер – тоже плохой шаблон. Так писали 20 лет назад, а сейчас так писать не надо. Гораздо лучше взять из базы значение последовательности, а идентификатор новой записи вычислять как S*1000+i, где i – номер вставляемой записи. Как тысячу записей вставили – взяли новый элемент последовательности.
2. Вот тут непонятно, какой вопрос к разработчикам СУБД. Не так много языков, где есть понятие «падежа», и не во всех языках с падежами изменяется само слово
3. returning без into – очень странный запрос. Но если есть суровая революционная необходимость, то копайте в сторону ref_cursor или pipelined functions
1. Edition-based redefinition
2. TO_CHAR(SYSDATE,'MONTH','NLS_LANGUAGE=RUSSIAN')
3. Начиная с 11g точно есть, раньше – лень смотреть
4. Такое поведение по умолчанию некорректно, но если очень надо, можно за полчаса написать скрипт, выдающий соответствующие полномочия, с использованием USER-DEPENDENCIES
В scale-out-кластере хАны у каждой ноды свои датаволюмы и они не шарятся.
Вы же знаете анекдот про Циммермана, который продавал водку по 10 рублей? Недовольные покупатели говорят «а у Зильберовича – по 8!» – «Ну так идите и купите у Зильберовича!» – «А у него кончилась...» – «Ну вот когда у меня кончится, я тоже буду продавать по 8»
То есть до тех пор, пока всё идёт нормально – да, доступ к чужим дискам не нужен. В точности как в NonStop SQL. Но как только узел вылетает, без доступа к чужим дискам – никак.
В этой нише они
Да и не только в этой.
Но это ладно, IBM хотя бы прикладной наукой жива. А вот чем жив HP, с учётом того, что Proliant больше не является уникальным продуктом, я даже и не знаю…
Вот это новость, как и наличие версии под POWER. Спасибо.
shared-nothing для OLAP.
Ну какой же это shared nothing. Это вполне себе shared disk.
DPF+BLU
И ещё раз спасибо. Я как-то совершенно не знаком с портфелем голубого гиганта. Думал, в части OLAP у них в основном Netezza, а оказывается и такое есть.
Действительно, ни у одной системы не бывает доступности 100%, а предприятию важна не сама по себе доступность системы, а возможность выполнить операцию. Поэтому молодец тот, у кого есть альтернативные каналы выполнения операции.
Вообще – чем меньше MC систем, тем лучше. Есть какое-то количество систем, которые не могут не быть MC, а плодить ли их – зависит больше от владельцев, чем от IT. В случае с электронной почтой это скорее служба безопасности. И если все каналы, кроме корпоративного Exchange, выжжены напалмом, то служба безопасности, конечно, не молодец.
В продуктивную эксплуатацию допускаются… серверы из списка supported systems
Да, это так. Но ведь это тоже сертификация, только ей занимается не поставщик оборудования, а непосредственно клиент. Надо подумать, как корректно сформулировать эту мысль :)
SAP HANA в scale out кластерах на практике испольуется только для OLAP/BI (SAP BW и т.д)
Вот на счёт и т. д. – можно поподробнее? Мне не удалось найти никаких упоминаний о HANA без связи с SAP. Да и не могу даже придумать, зачем стороннему разработчику писать под HANA.
Ставить ее в один ОLTP-ряд c Oracle RAC и DB2 pureScale я бы не стал.
Хороший комментарий.
Любая сложная система, включая СУБД, это целый комплекс архитектурных решений, и классифицировать СУБД по какому-то одному признаку я считаю категорически неправильным. Когда я читаю «in-memory базы работают быстрее, чем реляционные» (реальная цитата из статьи на Хабре), моя рука тянется к огнемёту.
Да, подсистема хранения у HANA отличается от Oracle или DB2 радикально. Но что касается устройства кластера – тут их вполне можно сравнивать.
Вы рассматриваете разные сценарии.
Если прервалась связь с координатором, это равносильно потере узла. Узел без координатора не будет считать себя кластером.
Отвал SAN — это полная гибель кластера, никаких частей не будет. Но обычно SAN там, где она есть, значительно надёжнее, чем сеть, а дисковые массивы, особенно hi-end, на порядок надёжнее самых дорогих серверов.
Хм. Это если работодатель – частная компания, которая платит за офис из своего кармана. А если работодатель – компания государственная, а содержанием офиса занимается частная фирма, принадлежащая кому надо, то тут расклад немного меняется…
Хм. Давайте тогда определимся, как мы нумеруем банки.
Как по мне, так имеет смысл ранжировать их по какому-то объективному показателю. Ну вот хотя бы по рейтингам на banki.ru
По активам нетто ВТБ – номер 2. Тиньков отстаёт от Сбера примерно в 42 раза, а ВТБ – в 2. Тиньков на 17 месте, что для чисто розничного банка настолько круто, что вообще ни в каких комментариях не нуждается.
По чистой прибыли ВТБ отстаёт от Сбера в 5.5 раз, уступая 2 место Альфе, а Тиньков – на 6 месте с отставанием от Сбера в 21 раз.
К сожалению, рейтинга по количеству выпущенных карт в нормальном доступе нет, но тут Тиньков скорее всего именно что №2
Ну, а если про государство… У государства 61% акций ВТБ (Росимущество) и 52% акций Сбера (ЦБ). Сделать из этого какие-то выводы я не решусь. Но немного зная, как работает тот и другой банк, на ВТБ не поставлю и ломаного гроша.
ВТБ – банк номер 1?
Я даже не знаю, как это комментировать.
Если бы вы назвали Альфу или Тинькова, я бы ещё понял, но ВТБ…
По корпоративному сегменту ВТБ, конечно, банк №2, и скорее всего, всегда им останется. Но розницу они уже просрали, и предпосылок к тому, что станет лучше, нет.
Конечно, СУБД так никто не сравнивает, ибо их сильные и слабые стороны хорошо известны. Как правило, сравнению подлежат платформы, решающие какую-либо прикладную задачу.
То есть этот инструмент применяется для таких систем, которые с пет-проектами действительно живут в параллельных вселенных.
Статью можно сравнить с инструкцией по выбору карьерного экскаватора на примере лопат. Выбор лопат баз данных в пет-проектах и в параллельной вселенной практически не отличаются.
Как раз это очень важно, потому что «запись на диск» и «проигрывание журнала» – это разные вещи. Вы правы, чем ниже уровень репликации, тем выше вероятность переноса ошибки на реплику. Но в случае с репликацией средствами БД эта вероятность существенно меньше.
Технология репликации и топология кластера – это два совершенно отдельных вопроса. Никто не мешает сделать две синхронных реплики и успешно фиксировать транзакцию, когда ответила хотя бы одна из них.
Вас обманули :))
У MySQL действительно нет общедоступного средства физической репликации, поэтому выбирать не из чего. Но у всех промышленных экземпляров «взрослых» СУБД – Oracle, MS SQL, PostgreSQL, DB2 – есть физическая реплика, она же standby.
Ну и так далее.
Своим методом я выигрываю уменьшение конкуренции за последовательность. Это не магический объект, а просто строка в системной таблице, обёрнутая «синтаксическим сахаром».
А вот мне даже любопытно, какая операция выполняется медленнее, если в PK есть промежутки? У меня фантазии не хватает.
3. Автоинкремент – это плохой шаблон, триггер – тоже плохой шаблон. Так писали 20 лет назад, а сейчас так писать не надо. Гораздо лучше взять из базы значение последовательности, а идентификатор новой записи вычислять как S*1000+i, где i – номер вставляемой записи. Как тысячу записей вставили – взяли новый элемент последовательности.
3. returning без into – очень странный запрос. Но если есть суровая революционная необходимость, то копайте в сторону ref_cursor или pipelined functions
2. TO_CHAR(SYSDATE,'MONTH','NLS_LANGUAGE=RUSSIAN')
3. Начиная с 11g точно есть, раньше – лень смотреть
4. Такое поведение по умолчанию некорректно, но если очень надо, можно за полчаса написать скрипт, выдающий соответствующие полномочия, с использованием USER-DEPENDENCIES
Вы же знаете анекдот про Циммермана, который продавал водку по 10 рублей? Недовольные покупатели говорят «а у Зильберовича – по 8!» – «Ну так идите и купите у Зильберовича!» – «А у него кончилась...» – «Ну вот когда у меня кончится, я тоже буду продавать по 8»
То есть до тех пор, пока всё идёт нормально – да, доступ к чужим дискам не нужен. В точности как в NonStop SQL. Но как только узел вылетает, без доступа к чужим дискам – никак.
Да и не только в этой.
Но это ладно, IBM хотя бы прикладной наукой жива. А вот чем жив HP, с учётом того, что Proliant больше не является уникальным продуктом, я даже и не знаю…
Вот это новость, как и наличие версии под POWER. Спасибо.
Ну какой же это shared nothing. Это вполне себе shared disk.
И ещё раз спасибо. Я как-то совершенно не знаком с портфелем голубого гиганта. Думал, в части OLAP у них в основном Netezza, а оказывается и такое есть.
Действительно, ни у одной системы не бывает доступности 100%, а предприятию важна не сама по себе доступность системы, а возможность выполнить операцию. Поэтому молодец тот, у кого есть альтернативные каналы выполнения операции.
Вообще – чем меньше MC систем, тем лучше. Есть какое-то количество систем, которые не могут не быть MC, а плодить ли их – зависит больше от владельцев, чем от IT. В случае с электронной почтой это скорее служба безопасности. И если все каналы, кроме корпоративного Exchange, выжжены напалмом, то служба безопасности, конечно, не молодец.
Да, это так. Но ведь это тоже сертификация, только ей занимается не поставщик оборудования, а непосредственно клиент. Надо подумать, как корректно сформулировать эту мысль :)
Вот на счёт и т. д. – можно поподробнее? Мне не удалось найти никаких упоминаний о HANA без связи с SAP. Да и не могу даже придумать, зачем стороннему разработчику писать под HANA.
Хороший комментарий.
Любая сложная система, включая СУБД, это целый комплекс архитектурных решений, и классифицировать СУБД по какому-то одному признаку я считаю категорически неправильным. Когда я читаю «in-memory базы работают быстрее, чем реляционные» (реальная цитата из статьи на Хабре), моя рука тянется к огнемёту.
Да, подсистема хранения у HANA отличается от Oracle или DB2 радикально. Но что касается устройства кластера – тут их вполне можно сравнивать.
Вы рассматриваете разные сценарии.
Если прервалась связь с координатором, это равносильно потере узла. Узел без координатора не будет считать себя кластером.
Отвал SAN — это полная гибель кластера, никаких частей не будет. Но обычно SAN там, где она есть, значительно надёжнее, чем сеть, а дисковые массивы, особенно hi-end, на порядок надёжнее самых дорогих серверов.
Именно поэтому никакого «Сбербанк-онлайн» – только через браузер.
Как по мне, так имеет смысл ранжировать их по какому-то объективному показателю. Ну вот хотя бы по рейтингам на banki.ru
По активам нетто ВТБ – номер 2. Тиньков отстаёт от Сбера примерно в 42 раза, а ВТБ – в 2. Тиньков на 17 месте, что для чисто розничного банка настолько круто, что вообще ни в каких комментариях не нуждается.
По чистой прибыли ВТБ отстаёт от Сбера в 5.5 раз, уступая 2 место Альфе, а Тиньков – на 6 месте с отставанием от Сбера в 21 раз.
К сожалению, рейтинга по количеству выпущенных карт в нормальном доступе нет, но тут Тиньков скорее всего именно что №2
Ну, а если про государство… У государства 61% акций ВТБ (Росимущество) и 52% акций Сбера (ЦБ). Сделать из этого какие-то выводы я не решусь. Но немного зная, как работает тот и другой банк, на ВТБ не поставлю и ломаного гроша.
Я даже не знаю, как это комментировать.
Если бы вы назвали Альфу или Тинькова, я бы ещё понял, но ВТБ…
По корпоративному сегменту ВТБ, конечно, банк №2, и скорее всего, всегда им останется. Но розницу они уже просрали, и предпосылок к тому, что станет лучше, нет.
То есть этот инструмент применяется для таких систем, которые с пет-проектами действительно живут в параллельных вселенных.
Статью можно сравнить с инструкцией по выбору карьерного экскаватора на примере лопат. Выбор
лопатбаз данных в пет-проектах и в параллельной вселенной практически не отличаются.