в импале Admission Control используете, настроены пулы? много объектов в hive metastore? не было проблем с масштабируемостью hive metastore?
зы. 14 узлов, это всего 14к таблетов для куду, которых минимум на три надо для каждой партиции таблицы. далеко с такими крупными узлами на куду не уедешь.
ну понятно, что RS/6000 от МФ пошла, но последние 20-30 лет все идет из LUW в МФ. cost based optimizator сначала RS/6000 выкатили, потом адаптировали на МФ
абсолютно все локи должны хранится в одном единственном месте, которое становится узким горлышком. прежде чем прочесть данные каждая нода обязана у CF удостовериться что запись безопасно читать. как мы знаем из печальной кончины МФ, никакие танцы этого не смогло изменить.
рынок уже все расставил по местам и рулят БД кластеры не из МФ
центральная часть МФ — db2/zOS, который не развивается, а лишь с опозданием адаптирует фишки из LUW редакции.
у МФ жутко дорогая память, потому реальные МФ, которые еще не выкинули вынуждены ютиться в мизерном объеме памяти, отсюда и повышенный требования на i/o. все равно МФ не в состоянии соревноваться с каким-нибудь хадуп кластером который способен все данные в оперативку забрать гарантируя на 2 порядка меньшее i/o по много меньшей цене.
фишка МФ в оптимальном распределением задач в стесненных ресурсах, но это не кому не нужно по такой цене. добавить терабайт памяти в тысячи и тысячи раз дешевле, чем радоваться тому как МФ хорошо работает забив ресурсы на все 100%
это толком не работает. что бы разные узлы db2 работали в кластере CF нода хранит единый кеш и таблицу блокировок. т.е. все узлы а каждый чих долбят CF ноду проверками на блокировку, порождая гигантский межузловой трафик и нагрузку на один, единственный узел. да, CF можно продублировать на случай сбоя, но активным может быть лишь один CF.
вобщем не взлетело.
было бы интересно услышать почему такой дизайн. судя по цифрам там в полном смысле биг дата, но обычно в бидате вроде аналитику делают на бигадата платформе, а из нее уже результат пишут в витрины рсубд. а тут похоже все происходит в рсубд (постгрес с массивно параллельной примочкой). подозреваю это будет одна из крупнейших баз на гринплуме. нельзя было готовить такую отчетность спарком в хадупе?
бегите от куду. оно не масштабируется. там ограничение около 1000 таблетов на узел. учитывая что каждый таблет требует минимум 2 копии то реально лимит 333 таблетов на узел. это мало учитывая что в бигдате таблицы с сотнями партиций норма.
программистам обычно это не интересно. у нас штук 5 аналитиков/DS, лабают скоркарды. там 95% это ковыряние в кривых данных и переписка с клиентом, почему тут какие-то дубли, а тут транзакции без суммы.
может есть, может нет, это вообще не важно. задачи бывают разные, где то лишний индекс оправдан, где-то нет. тут важно то, что mysql блокирует больше чем необходимо для обеспечения ACID.
это ложь. никто mysql не вынуждает блокировать больше строк, чем указано в предикате запроса. оракл при full scan считывает страницу данных с диска/кеша накладывая latch и блокирует на этой странице лишь те строки, какие будут модифицированы.
открой ссылку и посмотри пример c mysql, параллельные транзакции никак не пересекаются, никакой необходимости их блокировать нет. каждая создает свой набор строк и свой же набор пытаются удалить. у нормальной субд в такой ситуации не будет дедлока.
зы. 14 узлов, это всего 14к таблетов для куду, которых минимум на три надо для каждой партиции таблицы. далеко с такими крупными узлами на куду не уедешь.
рынок уже все расставил по местам и рулят БД кластеры не из МФ
у МФ жутко дорогая память, потому реальные МФ, которые еще не выкинули вынуждены ютиться в мизерном объеме памяти, отсюда и повышенный требования на i/o. все равно МФ не в состоянии соревноваться с каким-нибудь хадуп кластером который способен все данные в оперативку забрать гарантируя на 2 порядка меньшее i/o по много меньшей цене.
фишка МФ в оптимальном распределением задач в стесненных ресурсах, но это не кому не нужно по такой цене. добавить терабайт памяти в тысячи и тысячи раз дешевле, чем радоваться тому как МФ хорошо работает забив ресурсы на все 100%
вобщем не взлетело.
открой ссылку и посмотри пример c mysql, параллельные транзакции никак не пересекаются, никакой необходимости их блокировать нет. каждая создает свой набор строк и свой же набор пытаются удалить. у нормальной субд в такой ситуации не будет дедлока.
пример с DELETE тут
dba.stackexchange.com/questions/238756/mysql-innodb-trying-to-lock-uncommitted-row-from-parallel-transaction-deadlock