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

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

НЛО прилетело и опубликовало эту надпись здесь
Заглянул на сайт этой БД, они издеваются! :-)
Оформление сайта и логотип CUBRID как брат близнец Oracle (цвета, шрифт со срезами :)

Месть за MySQL ;-)
А может они просто готовятся хорошо продать ее Ораклу? :)
А почему сравнение с mysql, а не с postgre?
Нет смысла сравнивать узкоспециализированную СУБД, в которой жертвуют соответствием стандартам в обмен на рост производительности, применяют специальные решения и архитектуру с универсальной СУБД, которая может справиться с любой задачей.
Тогда сравните с mongodb, я уже двух программистов знаю, которые её очень хвалят, да и в живую я вижу, что ест она мало.
Спасибо, почитал про БД — выглядит достаточно интересно.
Но ей пока еще расти и расти до уровня чего-либо существенного. Да, Wordpress на ней будет работать, но что-либо более существенное рано или поздно упрется в текущую ограниченность.
Например, недостаточное для серьезных операций количество Aggregate Functions.
Или более редкие, но критичные для моего конкретного юз-кейса, Spatial функции.

Если же пытаться использовать CUBRID в качестве вспомогательной БД для хранения некоторой части данных, то я склоняюсь к использованию любой документ-ориентированной базы, которых развелось достаточно много
А лицензия какая?
НЛО прилетело и опубликовало эту надпись здесь
Ещё одно оригинальное расширение — директива DO, которая указывает БД не возвращать никаких результатов запроса, будь то вывод функции, выборка или сообщение об ошибке.
А здесь так тоже умеют.
ага, в настоящий момент масшабирование методом «втыкания еще одной ноды» не поддерживается? втопку! по моему вопрос масштабирования — это вопрос с которого надо начинать, при разработке нового-очередного-sql-сервера
У меня стойкое ощущение, что у системы с таким дурацким названием нет будущего. Если не переименуют, конечно. :)
Акститесь. Вспомните nginx
И точно, ведь!
SELECT header, text, INCR(read_count) FROM articles WHERE article_id = :requested_id;

Имхо это не совсем красиво давать апдейты в селектах… Особенно наверное прелестно коммиты после селектов делать. И ведь rollback to savepoint не поможет для промежуточного отката.
Оракловый returning нравится гораздо больше:
update articles 
set
  read_count=read_count+1
where
  article_id = :requested_id
returning
  header, test, read_count
into
  v_header,v_text,v_read_count

Или функции с автономными транзакциями.
Блокировка при этом не создаётся
И что происходит при параллельном изменении?
loadjava db_name MyClass.class
Тоже напоминает оракл :)
Соглашусь про нелогичность операции «чтения» которая меняет данные, это сродни геттеру, который меняет поле класса при каждом вызове. UPDATE RETURNING всё же не является эквивалентом именно из-за создания блокировки. Тем не менее, рост производительности пытается всё это оправдать :)

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

С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится
Да не так уж и просто… Параллельное изменение каким образом сделано? не приведут ли простые два селекта с incr к дедлоку или вообще к критической ошибке параллельного доступа? Лень пробовать этот Cubrid, но знать хочется :)
Для вознокновения дедлока необходимо как минимум наличие блокировок.

Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…

Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).

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

В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).

Думаю детали реализации можно подсмотреть — проект же открытый :)
Первая и большая часть совершенно излишняя да и аналогии какие-то совершенно неприменимые.
Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
Аналогии были про накладные расходы для обеспечения изменения поля в зависимости от его значения и без этой зависимости. Апдейтом можно изменить счётчик на 10%, а INCR — нет. За счёт такого ограничения удаётся избежать создания блокировок на уровне строк в БД. Как это реализовано на уровне ядра СУБД, думаю, можно узнать у хабраюзера kadishmal. Мне кажется, это вариация на тему атомиков.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.