Comments 10
Не читал, но одобряю.
Но, раз уж вы ее используете, было бы интересно узнать почему. Если это только не JFF.
0
Хотелось посмотреть, как хорошо работает cockroachdb на своем хобби-проекте. Пока что у меня опыт такой, что он достаточно часто (раз в несколько месяцев) «падает» и не поднимается обратно. Но некоторые испотьзуют его на продакшене, так что, видимо, это я такой невезучий.
+1
Не умалая полезности статьи, было бы интересно узнать не только о том что падает, но общее впечатление:
Как выглядит ваш кластер?
Как перформанс?
И что совместимостью с драйвером PostgreSQL?
Дело в том что этот проект вроде как OpenSource эквивалент гугловскому Spanner. Ну по по "духу" покрайнейм мере, что делает его крайне интересным!
Но как-то отпугивает теперь такая вот сыроватость.
0
1. «Кластер» представляет из себя один узел. Разработчики заверяют, что они поддерживают оба варианта — работу на одном хосте и работу в кластере. Но я честные кластера тоже пробовал делать и они тоже падали чернз какое-то время, правда на более ранних версиях, чем 1.0
2. Производительность на запись очень низкая. Причем это касается и latency и пропускной способности. Каждый INSERT-запрос также принудительно флашится на диск (в raft log), поэтому несколько строк лучше одним запросом вставлять — так пропускная способность возрастает в сотни раз. На моей инсталляции с жесткими дисками средний INSERT занимает около 60 мс, но это время примерно одинаково для запроса на вставку одной записи и для вставки 100 записей.
3. На чтение — все зависит от запроса. Если это простенький select по индексу, то производительность близка к постгресу и мускулу. Если запрос сложный, то тут все сильно зависит. Обычно получается намного медленней из-за того, что оптимизатор все же заточен под исполнение на кластере и многие подходы к выполнению запроса, которые использует постгрес или мускул, он не может себе позволить.
4. Проблем с совместимостью с драйвером постгреса не замечал. Для мака даже есть GUI-клиент Postico.app, который уже давно поддерживает как постгрес, так и cockroachdb.
Ну и любая база версии 1.0 вряд ли будет достаточно стабильной и производительной, особенно при таких амбициозных целях. Радует то, что разработчики на проблемы не забивают и стараются во всем разобраться и починить. Я думаю, что через пару мажорных версий таракана уже можно будет не бояться использовать в продакшене (бэкапы надо все равно делать при этом, конечно же).
2. Производительность на запись очень низкая. Причем это касается и latency и пропускной способности. Каждый INSERT-запрос также принудительно флашится на диск (в raft log), поэтому несколько строк лучше одним запросом вставлять — так пропускная способность возрастает в сотни раз. На моей инсталляции с жесткими дисками средний INSERT занимает около 60 мс, но это время примерно одинаково для запроса на вставку одной записи и для вставки 100 записей.
3. На чтение — все зависит от запроса. Если это простенький select по индексу, то производительность близка к постгресу и мускулу. Если запрос сложный, то тут все сильно зависит. Обычно получается намного медленней из-за того, что оптимизатор все же заточен под исполнение на кластере и многие подходы к выполнению запроса, которые использует постгрес или мускул, он не может себе позволить.
4. Проблем с совместимостью с драйвером постгреса не замечал. Для мака даже есть GUI-клиент Postico.app, который уже давно поддерживает как постгрес, так и cockroachdb.
Ну и любая база версии 1.0 вряд ли будет достаточно стабильной и производительной, особенно при таких амбициозных целях. Радует то, что разработчики на проблемы не забивают и стараются во всем разобраться и починить. Я думаю, что через пару мажорных версий таракана уже можно будет не бояться использовать в продакшене (бэкапы надо все равно делать при этом, конечно же).
0
Вот как-то не могу записать эту статью в плюс CockroachDB.
0
Мне кажется странным строить кластер из одного узла и потом долго восстанавливать данные. Изначально есть рекомендация — кластер должен содержать не менее чем из 3 нод (Use at least three nodes to ensure that a majority of replicas (2/3) remains available if a node fails)
0
Sign up to leave a comment.
Восстанавливаем данные из CockroachDB