Comments 21
10 млн строк сможет обработать Nokia 3110, у вас нет случайно опыта переноса, например, 10 трлн строк с оракла хоть куда-нибудь?
Горечь в Ваших словах слышу я. Могу посоветовать Hadoop. 10 млрд строк из Oracle в Hadoop мы переносили аж два раза. Впрочем, CockroachDB не аналитическая БД, а также use case немножко другой, так что сравнение с Nokia 3110 неуместно. Для начала попробуйте утопить Нокию в сортире, а потом обработать ей 10 млн строк.
Как мы мигрировали критичную БД с Oracle в CockroachDB
Ожидания:
Терабайты данных, миллиарды записей в таблицах, десятки-сотни таблиц.
Реальность:
Можно было заморочиться с использованием команды IMPORT из csv-файла. 3 минуты вставляли данные
Добавлю к ожиданиям: тысячи или десятки тысяч хранимок и вьюх.
А иногда это и есть самый сложный и затратный этап из всей миграции.
Парни, вы проедаете деньги инвесторов с такими "задачами".
Думаю из минусов CockroachDB, все упрется в аналитические выборки. Конечно, это может и не ваш вариант, но как бы хотелось чтобы база и считала быстро.
Стоит также посмотреть и сюда https://www.singlestore.com. Такой же непотопляемый черт, петабайт ready, но с чертовски скоростной аналитикой. Платный однако. Накормить его данными можно кучей способов и очень быстро.
Соглашусь с Вами. Типы нагрузки по личному опыту лучше не смешивать, а всё что декларирует совместимость с разными типами нагрузки, сразу вызывает кучу вопросов и подозрений. Мы же не пишем, что это универсальная база общего назначения, а рассматриваем конкретный use case. В нем она мега-хороша.
Дык, таракан не аналитическая же база. Конечно упрется, это OLTP база. Под каждый тип нагрузок нужно свой сторадж иметь. Хотя бы разные движки, если база позволяет. Singlestore, судя по документации, имеет сомнительную консистентность, когда в списке неподдерживаемых MySQL фич видишь foreign keys и referential integrity. А поддерживаемый уровень изоляции - read committed. Я сторадж с такими же гарантиями на какой-нить касандре смогу собрать. Хочется аналитику - кликхуаз, пожалуйста.
При упоминании тестов Jepsen, неплохо все же предостережения из этих тестов указывать:
Like Spanner, Cockroach’s correctness depends on the strength of its clocks. If any node drifts beyond the clock-offset threshold (by default, 250 ms), all guarantees are basically out the window. Unlike Spanner, CockroachDB users are likely deploying on commodity hardware or the cloud, without GPS and atomic clocks for reference. Their clocks may drift due to VM, IO, or GC pauses, NTP misconfiguration or faults, network congestion, and so on, especially in certain cloud environments.
В одной статье же нельзя объять необъятное, если копнуть, то узел кластера CockroachDB при дрифте времени в <параметр> миллисекунд просто выводит себя из состава кластера ("падает"). Это приводит к регулярным "падениям" узлов, если вы держите узлы на гипервизоре, который по тем или иным причинам решает мигрировать свою "виртуалку"
Вы упомянули, что Postgres оказался недостаточно надёжным. Опишите подробнее ваш опыт, который показал проблемы при переключениях мастера в Postgres.
Один из недостатков CockroachDB - маркетинг, ассоциированный с тараканами. Сейлзы CockroachDB те еще жуки. Ты их в бан, они с другого адреса пишут: "Где-то скучает одинокий таракан". Ты им пишешь "спасибо-не-надо", они через неделю интересуются "а может сейчас уже надо?".
Даже интересно, сколько раз в день им угрожают тапком или диклофосом за навязчивость.
Кокроач изо всех сил пытается выглядеть обычной RDBMS, но на деле не является такой. В итоге на какой-нибудь очень простой запрос в специальных условиях задержка улетает в небо.
Ну и отсутствие привычного READ_COMMITTED ломает многие привычные паттерны проектирования.
Как мы мигрировали критичную БД с Oracle в CockroachDB