Состоялся (https://www.cockroachlabs.com/blog/cockroachdb-2-0-release/) выпуск распределённой СУБД CockroachDB 2.0 (https://www.cockroachlabs.com/), ориентированной на создание высоконадёжных географически распределённых хранилищ, отличающихся высокой живучестью и не зависящих от сбоев дисков, узлов и центров обработки данных. CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи. Код проекта написан на языке Go и распространяется (https://github.com/cockroachdb/cockroach/) под лицензией Apache 2.0. Подробнее с особенностями CockroachDB можно познакомиться в анонсе первого выпуска (https://www.opennet.me/opennews/art.shtml?num=46529).
Основные новшества (https://www.cockroachlabs.com/docs/releases/v2.0.0.html)&nbs... 2.0:
- Реализация типа данных для хранения в формате JSON. По аналогии с PostgreSQL используется тип JSONB (https://www.cockroachlabs.com/docs/v2.0/jsonb.html) &nb... JSON") для хранения структурированных наборов данных в бинарном формате с обеспечением высокой производительности выборки за счёт применения инвертированных индексов (https://www.cockroachlabs.com/docs/v2.0/inverted-indexes.html);- Поддержка операции "CREATE SEQUENCE (https://www.cockroachlabs.com/docs/v2.0/create-sequence.html... которая позволяет генерировать последовательность целых чисел в соответствии с заданным правилом (например, могут применяться для генерации значения первичного ключа);
- Экспериментальная возможность ведения лога аудита (https://www.cockroachlabs.com/docs/v2.0/sql-audit-logging.ht... включающего детальную информацию о всех выполненных в системе SQL-запросах;
- Поддержка общих табличных выражений (https://www.cockroachlabs.com/docs/v2.0/common-table-express... (CTE, Common Table Expression (https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que... упрощающих определение и использование подзапросов. CTE могут быть использованы в комбинации с выражениями SELECT, INSERT, DELETE, UPDATE и UPSERT;
- Поддержка вычисляемых столбцов (https://www.cockroachlabs.com/docs/v2.0/computed-columns.html), в которых могут хранится данные, сгенерированные на основании содержимого других столбцов при помощи выражения, заданного при определении столбца (например, "full_name STRING AS (CONCAT(first_name, ' ', last_name))");
- Возможность (https://www.cockroachlabs.com/docs/v2.0/foreign-key.html#for... привязки к внешним ключам операций "ON UPDATE" и "ON DELETE", для вызова обработчиков при обновлении или удалении записей;- Для совместимости с PostgreSQL добавлена поддержка виртуальных схем хранения (https://www.cockroachlabs.com/docs/v2.0/sql-name-resolution.... и добавлено выражение "SHOW SCHEMAS" для показа виртуальных схем для заданной БД;
- Импорт табличных данных при помощи выражения IMPORT теперь производится в полностью распределённой манере, а выполняющие импорт задания могут быть приостановлены, возобновлены и отменены;
- Новый тип данных INET для хранения адресов IPv4 и IPv6;
- Новый тип данных TIME для хранения времени без учёта часового пояса;
- Проведена большая работа по повышению производительности и масштабируемости. При прохождении тестов производительности TPC-C (http://www.tpc.org/tpcc/) СУБД CockroachDB теперь заметно обгоняет MySQL- и PostgreSQL-совместимую облачную СУБД Amazon Aurora (https://aws.amazon.com/rds/aurora/) в режимах симуляции работы очень больших компаний.URL: https://www.cockroachlabs.com/blog/cockroachdb-2-0-release/
Новость: https://www.opennet.me/opennews/art.shtml?num=48405
ну чего, пол-года прошло - кто-то из присутствующих таки попытался у себя эту игого-хрень применить?
Судя по ченжлогу, это жутко сырая прога, я бы опасался ставить (собственно, как и любую не поддержанную коммерцией свободную «программу»)
-> не поддержанную коммерцией
Не думаю - что там нет коммерции.
https://www.cockroachlabs.com/pricing/
Название ... ну такое.> CockroachDB
> отличающихся высокой живучестьюЗаведётся такая база, быстро размножится в темных углах компьютера, сложно будет от неё избавиться...
если до тебя еще не дошло - авторы названия именно это ее свойство и имели в виду. Только в углах интернета, и избавляться от нее они не планируют.
да и монтипитоновский юмор, наверное - cockroach cluster
Фу.. Мать Вашу да это ж тараканы... Ну и деб-ды Весь мир думает как бы всем приятно сделать, а эти прям наоборот. Вангую низкий спрос в Enterprice исключительно из-за брнда и названия ) По детский как то жето
Делаем большую систему, смотрели как раз CockroachDB и PostgreSQL Citus.Сitus с его фирменным шардингом и репликацией выигрывает по всем фронтам, за исключением отсутствия мульти-мастер координатора(для SELECT / UPDATE можно и больше 1-го координатора использовать параллельно). CockroachDB проигрывает сильно по TPS в производительности.
Спасибо тебе, добрый человек, за наводку.
> Сitus с его фирменным шардингом и репликацией выигрывает по всем фронтам, заесли у тебя есть время и вдохновение на тщательную полировку фирменного шардинга и ручную настройку репликации - я вообще не понимаю, что ты забыл в cockroach.
она для тех, кому надо "запустил новую ноду и тут же забыл о ней - еще десять ждут", "докер опять рассыпался? Туда и дорога, щас автоматика снесет контейнер и перезальет заново".
и никаких ручных управлений шардингом на уровне схемы, никаких выделенных мастеров, каждый из которых если навернется, отвалится все что к нему подключено, никакой привязки клиентов к конкретным узлам кластера без явной необходимости.
"если б еще и работало!"
Там достаточно все просто, писал коммент на коленке к другой новости про Citus уже:http://www.opennet.me/opennews/art.shtml?num=48407 - там есть настройка Citus.
Ты считаешь что такие конфиги писать норма ?
У меня для тебя плохие новости. Все ПО стремится к упрощению и CockroachDB быстро заткнет такие поделки как Citus и.т.п, паразитирующие на PostgreSQL.
У тебя есть автоматический шардинг и распределенные JOIN'ы без каких либо костылей.
Парни из Кокроч изначально делали хорошо и надежно, а теперь принялись за производительность и каждая версию ускоряет некоторые операции в десятки раз.
> Ты считаешь что такие конфиги писать норма ?если тебе _на_самом_деле_ важно, с точностью до коробки в стойке, где именно какая таблица лежит (а что - дистрибьютится) и это часть твоего процесса работы с данными - да, норма (как еще-то?)
В качестве бонуса - вся эта информация непосредственно в схеме, поэтому она не может внезапно просраться/стать несовпадающей с реальностью. Минус - что вся эта мегаусложненная конструкция становится хрупкой, ненадежной и чреватой человеческими ошибками. "Зато меня никогда не уволят!"С м-давошь-дебе у тебя есть довольно грубая рулилка, внешняя по отношению к схеме, и кучка интуитивно-приятных интерфейсов, позволяющих (то есть оно - нужно) удостоверяться, что данные в конце-концов переехали туда, где им положено быть - отдельных от схемы. (ну-ка покажи-ка мне архив изменений в такой среде?)
Суперспециалист, вручную раскидывающий шарды по узлам, становится резко ненужен, любая макака может сесть на его еще не остывшую табуретку и продолжить с того же места кликать мышью.Как мы все понимаем, в масштабах байды выбора на самом деле нет. А недостаток скорости (на чем, кстати, говорят, написано? Ась, не слышу? А? Да понял что г-но, а какое? php, небось?) компенсируется наращиванием числа тазиков. У байды их много, картонная фабрика работает где-то на параллельной улице.
жаль что товарищам из Яндекса видимо некогда отвлекаться на опеннеты, их менеджер больно лупит дубинкой, если они хотя бы пять секунд не пашут на благо конторы. А в байде не понимают по-русски.
> Ты считаешь что такие конфиги писать норма ?Ты просто не пробовал в кокроач залить дамп в несколько десятков гигабайт в кластер из 4-х нод, да посложнее со структурой который, получается крайне хреново, тормозит конкретно, даже доходит до того что сервера подвисать начинают, потом он там пересчитывает постоянно эти реплики свои и снова сжираются ресурсы, ну да ладно допустим это через пару лет поправят. Погугли никто не смог собрать нормально кластер-то из 10-ти нод на нем.
Реальность по кокроачу такова, что чем больше там нод, тем тормознее он будет, это как раз проблемы мультимастера. Потом там по архитектуре минимум 3 реплики может быть а не 2 как в Citus, тоже кому-то накладно будет стока копий одинаковых данных хранить.В реальности Citus это нифига не поделка, а очень даже стабильное решение которому и 100 нод не помеха. А по поводу простоты, куда уж проще, вы посмотрите как PostgreSQL-XL настраивается и поддерживается, вот там да - куда ж без админа.
Citus не сложен, абсолютно. Ну и раз уж на то пошло, то в нормальной компании, которой нужен многонодовый кластер БД наверное найдется денег на админа :) Ну по крайней мере там где сейчас делаю, там с деньгами на админа проблем нету.
> Ты просто не пробовал в кокроач залить дамп в несколько десятков гигабайтможет оно банально не для этого придумано?
> Потом там по архитектуре минимум 3 реплики может быть а не 2 как в Citus, тоже кому-то накладно
то же самое. Это вам "накладно". А авторы, похоже, считали что 3 - это минимум, который они могут себе позволить.
у них задача (если верить методичке) - не прочавкать данные (и не получить split-brain) при массовом падеже серверов и каналов.
Задачи размазать то, что не помещается физически в один тазик, и хрен уже с ней, с надежностью - нет.производительности от этого проекта, по-моему, ждать тоже не приходится, байде, видимо, не надо.
А вот что там с надежностью - хотелось бы от кого-то кто пробовал услышать.
Сначала прочитал "Кошкодав"
Не совсем понял на чём написано?
на пэхапэ
> Не совсем понял на чём написано?Бают, что на Go
> Код проекта написан на языке Gohttps://github.com/cockroachdb/cockroach
> Go 91.6%