The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск отказоустойчивой СУБД CockroachDB 2.0

06.04.2018 22:53

Состоялся выпуск распределённой СУБД CockroachDB 2.0, ориентированной на создание высоконадёжных географически распределённых хранилищ, отличающихся высокой живучестью и не зависящих от сбоев дисков, узлов и центров обработки данных. CockroachDB гарантирует целостность ACID-транзакций, предоставляет возможность использования SQL для манипуляции с данными, позволяет вносить изменения в схему хранения на лету, поддерживает индексы и внешние ключи. Код проекта написан на языке Go и распространяется под лицензией Apache 2.0. Подробнее с особенностями CockroachDB можно познакомиться в анонсе первого выпуска.

Основные новшества CockroachDB 2.0:

  • Реализация типа данных для хранения в формате JSON. По аналогии с PostgreSQL используется тип JSONB ("binary JSON") для хранения структурированных наборов данных в бинарном формате с обеспечением высокой производительности выборки за счёт применения инвертированных индексов;
  • Поддержка операции "CREATE SEQUENCE", которая позволяет генерировать последовательность целых чисел в соответствии с заданным правилом (например, могут применяться для генерации значения первичного ключа);
  • Экспериментальная возможность ведения лога аудита, включающего детальную информацию о всех выполненных в системе SQL-запросах;
  • Поддержка общих табличных выражений (CTE, Common Table Expression), упрощающих определение и использование подзапросов. CTE могут быть использованы в комбинации с выражениями SELECT, INSERT, DELETE, UPDATE и UPSERT;
  • Поддержка вычисляемых столбцов, в которых могут хранится данные, сгенерированные на основании содержимого других столбцов при помощи выражения, заданного при определении столбца (например, "full_name STRING AS (CONCAT(first_name, ' ', last_name))");
  • Возможность привязки к внешним ключам операций "ON UPDATE" и "ON DELETE", для вызова обработчиков при обновлении или удалении записей;
  • Для совместимости с PostgreSQL добавлена поддержка виртуальных схем хранения и добавлено выражение "SHOW SCHEMAS" для показа виртуальных схем для заданной БД;
  • Импорт табличных данных при помощи выражения IMPORT теперь производится в полностью распределённой манере, а выполняющие импорт задания могут быть приостановлены, возобновлены и отменены;
  • Новый тип данных INET для хранения адресов IPv4 и IPv6;
  • Новый тип данных TIME для хранения времени без учёта часового пояса;
  • Проведена большая работа по повышению производительности и масштабируемости. При прохождении тестов производительности TPC-C СУБД CockroachDB теперь заметно обгоняет MySQL- и PostgreSQL-совместимую облачную СУБД Amazon Aurora в режимах симуляции работы очень больших компаний.


  1. Главная ссылка к новости (https://www.cockroachlabs.com/...)
  2. OpenNews: Первый стабильный выпуск отказоустойчивой СУБД CockroachDB
  3. OpenNews: Доступна отказоустойчивая СУБД CockroachDB 1.1
  4. OpenNews: Компания Bloomberg открыла код распределённой СУБД Comdb2
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48405-cockroachdb
Ключевые слова: cockroachdb, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, пох (?), 00:56, 07/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну чего, пол-года прошло - кто-то из присутствующих таки попытался у себя эту игого-хрень применить?

     
     
  • 2.2, Altman (?), 01:11, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Судя по ченжлогу, это жутко сырая прога, я бы опасался ставить (собственно, как и любую не поддержанную коммерцией свободную «программу»)
     
     
  • 3.4, Andrey (??), 02:34, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    -> не поддержанную коммерцией
    Не думаю - что там нет коммерции.
    https://www.cockroachlabs.com/pricing/
     

  • 1.6, Аноним (-), 06:37, 07/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Название ... ну такое.

    > CockroachDB
    > отличающихся высокой живучестью

    Заведётся такая база, быстро размножится в темных углах компьютера, сложно будет от неё избавиться...

     
     
  • 2.11, пох (?), 10:30, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    если до тебя еще не дошло - авторы названия именно это ее свойство и имели в виду. Только в углах интернета, и избавляться от нее они не планируют.

     
     
  • 3.15, Ю.Т. (?), 17:27, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да и монтипитоновский юмор, наверное - cockroach cluster
     
     
  • 4.19, Аноним (-), 02:29, 09/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Фу.. Мать Вашу да это ж тараканы... Ну и деб-ды Весь мир думает как бы всем приятно сделать, а эти прям наоборот. Вангую низкий спрос в Enterprice исключительно из-за брнда и названия ) По детский как то жето
     

  • 1.7, Аноним (-), 07:07, 07/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Делаем большую систему, смотрели как раз CockroachDB и PostgreSQL Citus.

    Сitus с его фирменным шардингом и репликацией выигрывает по всем фронтам, за исключением отсутствия мульти-мастер координатора(для SELECT / UPDATE можно и больше 1-го координатора использовать параллельно). CockroachDB проигрывает сильно по TPS в производительности.

     
     
  • 2.12, Алексей Морозов (ok), 11:23, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо тебе, добрый человек, за наводку.
     
  • 2.13, пох (?), 11:45, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Сitus с его фирменным шардингом и репликацией выигрывает по всем фронтам, за

    если у тебя есть время и вдохновение на тщательную полировку фирменного шардинга и ручную настройку репликации - я вообще не понимаю, что ты забыл в cockroach.

    она для тех, кому надо "запустил новую ноду и тут же забыл о ней - еще десять ждут", "докер опять рассыпался? Туда и дорога, щас автоматика снесет контейнер и перезальет заново".

    и никаких ручных управлений шардингом на уровне схемы, никаких выделенных мастеров, каждый из которых если навернется, отвалится все что к нему подключено, никакой привязки клиентов к конкретным узлам кластера без явной необходимости.

    "если б еще и работало!"

     
     
  • 3.17, raver (ok), 12:11, 08/04/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там достаточно все просто, писал коммент на коленке к другой новости про Citus уже:

    http://www.opennet.dev/opennews/art.shtml?num=48407 - там есть настройка Citus.

     
     
  • 4.18, Teeder (?), 23:37, 08/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты считаешь что такие конфиги писать норма ?
    У меня для тебя плохие новости. Все ПО стремится к упрощению и CockroachDB быстро заткнет такие поделки как Citus и.т.п, паразитирующие на PostgreSQL.
    У тебя есть автоматический шардинг и распределенные JOIN'ы без каких либо костылей.
    Парни из Кокроч изначально делали хорошо и надежно, а теперь принялись за производительность и каждая версию ускоряет некоторые операции в десятки раз.
     
     
  • 5.20, нах (?), 10:10, 09/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты считаешь что такие конфиги писать норма ?

    если тебе _на_самом_деле_ важно, с точностью до коробки в стойке, где именно какая таблица лежит (а что - дистрибьютится) и это часть твоего процесса работы с данными - да, норма (как еще-то?)
    В качестве бонуса - вся эта информация непосредственно в схеме, поэтому она не может внезапно просраться/стать несовпадающей с реальностью. Минус - что вся эта мегаусложненная конструкция становится хрупкой, ненадежной и чреватой человеческими ошибками. "Зато меня никогда не уволят!"

    С м-давошь-дебе у тебя есть довольно грубая рулилка, внешняя по отношению к схеме, и кучка интуитивно-приятных интерфейсов, позволяющих (то есть оно - нужно) удостоверяться, что данные в конце-концов переехали туда, где им положено быть - отдельных от схемы. (ну-ка покажи-ка мне архив изменений в такой среде?)
    Суперспециалист, вручную раскидывающий шарды по узлам, становится резко ненужен, любая макака может сесть на его еще не остывшую табуретку и продолжить с того же места кликать мышью.

    Как мы все понимаем, в масштабах байды выбора на самом деле нет. А недостаток скорости (на чем, кстати, говорят, написано? Ась, не слышу? А? Да понял что г-но, а какое? php, небось?) компенсируется наращиванием числа тазиков. У байды их много, картонная фабрика работает где-то на параллельной улице.

    жаль что товарищам из Яндекса видимо некогда отвлекаться на опеннеты, их менеджер больно лупит дубинкой, если они хотя бы пять секунд не пашут на благо конторы. А в байде не понимают по-русски.


     
  • 5.21, raver (ok), 21:00, 09/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты считаешь что такие конфиги писать норма ?

    Ты просто не пробовал в кокроач залить дамп в несколько десятков гигабайт в кластер из 4-х нод, да посложнее со структурой который, получается крайне хреново, тормозит конкретно, даже доходит до того что сервера подвисать начинают, потом он там пересчитывает постоянно эти реплики свои и снова сжираются ресурсы, ну да ладно допустим это через пару лет поправят. Погугли никто не смог собрать нормально кластер-то из 10-ти нод на нем.
    Реальность по кокроачу такова, что чем больше там нод, тем тормознее он будет, это как раз проблемы мультимастера. Потом там по архитектуре минимум 3 реплики может быть а не 2 как в Citus, тоже кому-то накладно будет стока копий одинаковых данных хранить.

    В реальности Citus это нифига не поделка, а очень даже стабильное решение которому и 100 нод не помеха. А по поводу простоты, куда уж проще, вы посмотрите как PostgreSQL-XL настраивается и поддерживается, вот там да - куда ж без админа.

    Citus не сложен, абсолютно. Ну и раз уж на то пошло, то в нормальной компании, которой нужен многонодовый кластер БД наверное найдется денег на админа :) Ну по крайней мере там где сейчас делаю, там с деньгами на админа проблем нету.

     
     
  • 6.22, пох (?), 14:24, 10/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты просто не пробовал в кокроач залить дамп в несколько десятков гигабайт

    может оно банально не для этого придумано?

    > Потом там по архитектуре минимум 3 реплики может быть а не 2 как в Citus, тоже кому-то накладно

    то же самое. Это вам "накладно". А авторы, похоже, считали что 3 - это минимум, который они могут себе позволить.

    у них задача (если верить методичке) - не прочавкать данные (и не получить split-brain) при массовом падеже серверов и каналов.
    Задачи размазать то, что не помещается физически в один тазик, и хрен уже с ней, с надежностью - нет.

    производительности от этого проекта, по-моему, ждать тоже не приходится, байде, видимо, не надо.

    А вот что там с надежностью - хотелось бы от кого-то кто пробовал услышать.

     

  • 1.9, Аноним (-), 09:15, 07/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сначала прочитал "Кошкодав"
     
  • 1.10, Аноним (-), 09:29, 07/04/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не совсем понял на чём написано?
     
     
  • 2.14, Аноним (-), 12:55, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на пэхапэ
     
  • 2.16, Аноним84701 (ok), 23:27, 07/04/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не совсем понял на чём написано?

    Бают, что на Go
    > Код проекта написан на языке Go

    https://github.com/cockroachdb/cockroach
    >  Go 91.6%

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру