Comments 16
information_schema, pg_catalog
Не узнаю вас в гриме. :-)
А они и не скрывают, что особенно хорошо видно в контексте клиентских библиотек… :-) Вот такое сравнение PgSQL с Cockroach встречал. Уже старое, правда, но вряд ли многое принципиально изменилось.
Уже релиз первой версии близится, а ни одного бенчмарка не видно.
Ощущение, что ждут финального релиза… Вот тут что-то пытаются сделать.
(Нашел в issue #2650: perf: does cockroach have some benchmark tool?)
There's a generic KV, YCSB, and TPC-H. TPC-C isn't added yet, but likely will be in the near future.
(Нашел в issue #2650: perf: does cockroach have some benchmark tool?)
Он уже несколько лет близится :)
Я когда выбирал БД для своего проекта, тестировал таракана. Скорость не особо порадовала, в кластере из 3 нод на достаточно неплохом оборудовании скорость записи была около 3к запросов в секунду даже большим кол-вом потоков. В итоге забил на него и взял Кассандру, не жалею — на том же «железе» выдает х15 TPS.
Я когда выбирал БД для своего проекта, тестировал таракана. Скорость не особо порадовала, в кластере из 3 нод на достаточно неплохом оборудовании скорость записи была около 3к запросов в секунду даже большим кол-вом потоков. В итоге забил на него и взял Кассандру, не жалею — на том же «железе» выдает х15 TPS.
Какие книжки читали создатели CockroachDB?
Если всерьёз хочется оценить их техническую адекватность и подготовку, есть большой документ про архитектуру CockroachDB.
Компанию основали выходцы из Google, работавшие там над Google File System (которая с BigTable), а среди их инвесторов — директор Hortonworks, CEO в CoreOS и соучредитель Cloudera.
Компанию основали выходцы из 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 и транзакции, и вам нужен большой кластер, то особого выбора у вас нет.
1. Automatic failover. Если вы хотите работать без downtime в случае проблем с мастером, то вам нужна подобная база
2. Ограниченность диска одной ноды. Зачастую в больших системах нагрузка на базы в плане RPS не очень большая за счет кеширования, а вот самих данных очень много и они не помещаются на один узел ни при каких условиях
3. Если у вас всё же есть несколько нод по причине (2), то вам нужны распределенные транзакции. Мне неизвестно ни об одной opensource базе данных, которая бы распределенные транзакции поддерживала на уровне CockroachDB (т.е. вы просто делаете транзакцию и не думаете о том, на каком наборе узлов она выполняется, и база гарантирует, что если транзакция закоммитилась, то данные будут доступны даже при фейле N узлов, а если транзакция не закоммитилась, то данных не будет нигде, в том числе в случае временных фейлов N узлов, участвовавших в транзакции).
В общем, если вам нравится SQL и транзакции, и вам нужен большой кластер, то особого выбора у вас нет.
Фэйловер и без таких систем давно научились организовывать. Остаются только соображения ёмкости/производительности. Большой кластер с пропускной способностью 20-40 QPS? Это лишено смысла.
Дело они делают, конечно же, нужное, но в таком виде как сейчас их кластер не может конкурировать с одиночной инсталляцией.
Дело они делают, конечно же, нужное, но в таком виде как сейчас их кластер не может конкурировать с одиночной инсталляцией.
Касаемо транзакций — я бы не особо доверял заверениям о «Distributed ACID», все же CAP-теорему не так просто обмануть. Тот же гугль со своим Spanner обошел ее ограничения используя свои приватные ДЦ и атомные часы /
GPS для идеальной синхронизации времени.
Хотя я конечно глубоко в таракана не глядел.
GPS для идеальной синхронизации времени.
Хотя я конечно глубоко в таракана не глядел.
Не совсем понятно, что с версией под windows. Скачал архив, размером в 2хх байт, а в нем exe в 0 байт… С оф. сайта
Sign up to leave a comment.
Знакомство с СУБД CockroachDB и создание отказоустойчивого кластера с ней на Ubuntu 16.04