Как стать автором
Обновить

Комментарии 16

information_schema, pg_catalog

Не узнаю вас в гриме. :-)
А они и не скрывают, что особенно хорошо видно в контексте клиентских библиотек… :-) Вот такое сравнение PgSQL с Cockroach встречал. Уже старое, правда, но вряд ли многое принципиально изменилось.
Уже релиз первой версии близится, а ни одного бенчмарка не видно.
Он уже несколько лет близится :)

Я когда выбирал БД для своего проекта, тестировал таракана. Скорость не особо порадовала, в кластере из 3 нод на достаточно неплохом оборудовании скорость записи была около 3к запросов в секунду даже большим кол-вом потоков. В итоге забил на него и взял Кассандру, не жалею — на том же «железе» выдает х15 TPS.
Они выпустили 1.0rc1, так что релиз сейчас всё же немножко ближе, чем несколько лет назад :). Сами авторы не рекомендовали использовать в продакшене эту базу до наступления 1.0. Ну и они честно говорили, что не пытались особо не оптимизировать производительность до недавнего времени.
Какие книжки читали создатели CockroachDB?
Если всерьёз хочется оценить их техническую адекватность и подготовку, есть большой документ про архитектуру CockroachDB.

Компанию основали выходцы из Google, работавшие там над Google File System (которая с BigTable), а среди их инвесторов — директор Hortonworks, CEO в CoreOS и соучредитель Cloudera.
Спасибо.
Приведу один яркий комментарий из обсуждения новости на news.ycombinator.com по поводу этой базы:
chillydawg 77 days ago [-]
But why scale something when you can just run one postgres instance and provide 10000x the performance?
Причин несколько:

1. Automatic failover. Если вы хотите работать без downtime в случае проблем с мастером, то вам нужна подобная база
2. Ограниченность диска одной ноды. Зачастую в больших системах нагрузка на базы в плане RPS не очень большая за счет кеширования, а вот самих данных очень много и они не помещаются на один узел ни при каких условиях
3. Если у вас всё же есть несколько нод по причине (2), то вам нужны распределенные транзакции. Мне неизвестно ни об одной opensource базе данных, которая бы распределенные транзакции поддерживала на уровне CockroachDB (т.е. вы просто делаете транзакцию и не думаете о том, на каком наборе узлов она выполняется, и база гарантирует, что если транзакция закоммитилась, то данные будут доступны даже при фейле N узлов, а если транзакция не закоммитилась, то данных не будет нигде, в том числе в случае временных фейлов N узлов, участвовавших в транзакции).

В общем, если вам нравится SQL и транзакции, и вам нужен большой кластер, то особого выбора у вас нет.
Фэйловер и без таких систем давно научились организовывать. Остаются только соображения ёмкости/производительности. Большой кластер с пропускной способностью 20-40 QPS? Это лишено смысла.

Дело они делают, конечно же, нужное, но в таком виде как сейчас их кластер не может конкурировать с одиночной инсталляцией.
Касаемо транзакций — я бы не особо доверял заверениям о «Distributed ACID», все же CAP-теорему не так просто обмануть. Тот же гугль со своим Spanner обошел ее ограничения используя свои приватные ДЦ и атомные часы /
GPS для идеальной синхронизации времени.

Хотя я конечно глубоко в таракана не глядел.
Не совсем понятно, что с версией под windows. Скачал архив, размером в 2хх байт, а в нем exe в 0 байт… С оф. сайта
Возможно был какой то временный глюк, сейчас удалось скачать, спасибо
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.