Но, к сожалению, используемая нами функциональность медленно разрабатывается другими производителями.
Выглядит что root cause на самом-то деле вот тут. Было бы очень интересно ознакомиться с оценкой рисков "уникальный функционал vs затраты на альтернативное массовое решение")
Для любой распределенной БД можно придумать такое распределение данных и такой запрос, что время отклика будет стремиться к бесконечности. Задача архитектора - избегать таких кейсов.
TiDB позиционирует себя как гибридное решение, но для меня это скорее недостаток, а не преимущество. Из платных вариантов верю в VoltDB, там внушительный список фаундеров.
В одной статье же нельзя объять необъятное, если копнуть, то узел кластера CockroachDB при дрифте времени в <параметр> миллисекунд просто выводит себя из состава кластера ("падает"). Это приводит к регулярным "падениям" узлов, если вы держите узлы на гипервизоре, который по тем или иным причинам решает мигрировать свою "виртуалку"
Соглашусь с Вами. Типы нагрузки по личному опыту лучше не смешивать, а всё что декларирует совместимость с разными типами нагрузки, сразу вызывает кучу вопросов и подозрений. Мы же не пишем, что это универсальная база общего назначения, а рассматриваем конкретный use case. В нем она мега-хороша.
Горечь в Ваших словах слышу я. Могу посоветовать Hadoop. 10 млрд строк из Oracle в Hadoop мы переносили аж два раза. Впрочем, CockroachDB не аналитическая БД, а также use case немножко другой, так что сравнение с Nokia 3110 неуместно. Для начала попробуйте утопить Нокию в сортире, а потом обработать ей 10 млн строк.
EBR это не система контроля версий кода — она в GIT или в других аналогичных инструментах у подавляющего числа разработчиков. EBR это инструментарий снижения простоев high-load приложений с бэкендом на Oracle PL/SQL.
Если придет человек на собеседование и на вопрос «а вы использовали EBR?» он ответит «да, наша команда из 10 человек использовала его для совместной разработки и хранила в нём разные версии кода, это было очень неудобно, но мы плакали, кололись и продолжали» — мы вежливо постараемся закончить собеседование, потом будем 15 минут ОЧЕНЬ ГРОМКО СМЕЯТЬСЯ, а потом смеяться будут все, кому мы про это расскажем. В итоге наш производственный процесс будет нарушен примерно на месяц.
Точный ответ на этот вопрос находится в компетенции Oracle, но мои наблюдения такие: если ваша политика установки патчей основана на PSU — на данный момент нет, не включаются. Если ваша политика патчей основана на Bundle Patch — какая-то часть, возможно, и включена, но достоверно проверить это можно лишь сравнивая списки багов в самом Bundle Patch и в указанном документе.
Выглядит что root cause на самом-то деле вот тут. Было бы очень интересно ознакомиться с оценкой рисков "уникальный функционал vs затраты на альтернативное массовое решение")
Комментарий напомнил по стилю старый добрый форум sql.ru
"В инторнете опять кто-то неправ"
Вертика и аналогичные аналитические СУБД пригодны скорее для аналитических, а не для транзакционных нагрузок
За 8 лет работы в поддержке Oracle я могу сказать что ухищрения для того, чтобы сделать его распределённым, не соответствуют критерию цена/качество.
Теоретизировать на эту тему смысла нет, у всех практические задачи. У меня такие задачи, мне ехать, а не шашечки. Мб кому-то важно шашечки.
Для любой распределенной БД можно придумать такое распределение данных и такой запрос, что время отклика будет стремиться к бесконечности. Задача архитектора - избегать таких кейсов.
Может быть в следующий раз)
TiDB позиционирует себя как гибридное решение, но для меня это скорее недостаток, а не преимущество. Из платных вариантов верю в VoltDB, там внушительный список фаундеров.
В одной статье же нельзя объять необъятное, если копнуть, то узел кластера CockroachDB при дрифте времени в <параметр> миллисекунд просто выводит себя из состава кластера ("падает"). Это приводит к регулярным "падениям" узлов, если вы держите узлы на гипервизоре, который по тем или иным причинам решает мигрировать свою "виртуалку"
Соглашусь с Вами. Типы нагрузки по личному опыту лучше не смешивать, а всё что декларирует совместимость с разными типами нагрузки, сразу вызывает кучу вопросов и подозрений. Мы же не пишем, что это универсальная база общего назначения, а рассматриваем конкретный use case. В нем она мега-хороша.
Горечь в Ваших словах слышу я. Могу посоветовать Hadoop. 10 млрд строк из Oracle в Hadoop мы переносили аж два раза. Впрочем, CockroachDB не аналитическая БД, а также use case немножко другой, так что сравнение с Nokia 3110 неуместно. Для начала попробуйте утопить Нокию в сортире, а потом обработать ей 10 млн строк.
Если придет человек на собеседование и на вопрос «а вы использовали EBR?» он ответит «да, наша команда из 10 человек использовала его для совместной разработки и хранила в нём разные версии кода, это было очень неудобно, но мы плакали
, кололисьи продолжали» — мы вежливо постараемся закончить собеседование, потом будем 15 минут ОЧЕНЬ ГРОМКО СМЕЯТЬСЯ, а потом смеяться будут все, кому мы про это расскажем. В итоге наш производственный процесс будет нарушен примерно на месяц.