Comments 10
Не читал, но одобряю.
Но, раз уж вы ее используете, было бы интересно узнать почему. Если это только не JFF.
Хотелось посмотреть, как хорошо работает cockroachdb на своем хобби-проекте. Пока что у меня опыт такой, что он достаточно часто (раз в несколько месяцев) «падает» и не поднимается обратно. Но некоторые испотьзуют его на продакшене, так что, видимо, это я такой невезучий.
Не умалая полезности статьи, было бы интересно узнать не только о том что падает, но общее впечатление:
Как выглядит ваш кластер?
Как перформанс?
И что совместимостью с драйвером PostgreSQL?
Дело в том что этот проект вроде как OpenSource эквивалент гугловскому Spanner. Ну по по "духу" покрайнейм мере, что делает его крайне интересным!
Но как-то отпугивает теперь такая вот сыроватость.
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 вряд ли будет достаточно стабильной и производительной, особенно при таких амбициозных целях. Радует то, что разработчики на проблемы не забивают и стараются во всем разобраться и починить. Я думаю, что через пару мажорных версий таракана уже можно будет не бояться использовать в продакшене (бэкапы надо все равно делать при этом, конечно же).
Вот как-то не могу записать эту статью в плюс CockroachDB.
Мне кажется странным строить кластер из одного узла и потом долго восстанавливать данные. Изначально есть рекомендация — кластер должен содержать не менее чем из 3 нод (Use at least three nodes to ensure that a majority of replicas (2/3) remains available if a node fails)
Sign up to leave a comment.
Восстанавливаем данные из CockroachDB