Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Заглянул на сайт этой БД, они издеваются! :-)
Оформление сайта и логотип CUBRID как брат близнец Oracle (цвета, шрифт со срезами :)
Месть за MySQL ;-)
Оформление сайта и логотип CUBRID как брат близнец Oracle (цвета, шрифт со срезами :)
Месть за MySQL ;-)
А почему сравнение с mysql, а не с postgre?
Спасибо, почитал про БД — выглядит достаточно интересно.
Но ей пока еще расти и расти до уровня чего-либо существенного. Да, Wordpress на ней будет работать, но что-либо более существенное рано или поздно упрется в текущую ограниченность.
Например, недостаточное для серьезных операций количество Aggregate Functions.
Или более редкие, но критичные для моего конкретного юз-кейса, Spatial функции.
Если же пытаться использовать CUBRID в качестве вспомогательной БД для хранения некоторой части данных, то я склоняюсь к использованию любой документ-ориентированной базы, которых развелось достаточно много
Но ей пока еще расти и расти до уровня чего-либо существенного. Да, Wordpress на ней будет работать, но что-либо более существенное рано или поздно упрется в текущую ограниченность.
Например, недостаточное для серьезных операций количество Aggregate Functions.
Или более редкие, но критичные для моего конкретного юз-кейса, Spatial функции.
Если же пытаться использовать CUBRID в качестве вспомогательной БД для хранения некоторой части данных, то я склоняюсь к использованию любой документ-ориентированной базы, которых развелось достаточно много
А лицензия какая?
Ещё одно оригинальное расширение — директива DO, которая указывает БД не возвращать никаких результатов запроса, будь то вывод функции, выборка или сообщение об ошибке.А здесь так тоже умеют.
ага, в настоящий момент масшабирование методом «втыкания еще одной ноды» не поддерживается? втопку! по моему вопрос масштабирования — это вопрос с которого надо начинать, при разработке нового-очередного-sql-сервера
У меня стойкое ощущение, что у системы с таким дурацким названием нет будущего. Если не переименуют, конечно. :)
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. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
Насколько я понял коммиты для такой экзотики не нужны, равно как и роллбэки, которые просто не будут работать.
С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличитсяДа не так уж и просто… Параллельное изменение каким образом сделано? не приведут ли простые два селекта с incr к дедлоку или вообще к критической ошибке параллельного доступа? Лень пробовать этот Cubrid, но знать хочется :)
Для вознокновения дедлока необходимо как минимум наличие блокировок.
Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…
Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).
Второй вариант. INCR предполагает что у нас есть стопка карточек со всеми возможными номерами, а каждая операция лишь сбрасывает верхнюю карту.
В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).
Думаю детали реализации можно подсмотреть — проект же открытый :)
Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…
Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).
Второй вариант. INCR предполагает что у нас есть стопка карточек со всеми возможными номерами, а каждая операция лишь сбрасывает верхнюю карту.
В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).
Думаю детали реализации можно подсмотреть — проект же открытый :)
Первая и большая часть совершенно излишняя да и аналогии какие-то совершенно неприменимые.
Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
Аналогии были про накладные расходы для обеспечения изменения поля в зависимости от его значения и без этой зависимости. Апдейтом можно изменить счётчик на 10%, а INCR — нет. За счёт такого ограничения удаётся избежать создания блокировок на уровне строк в БД. Как это реализовано на уровне ядра СУБД, думаю, можно узнать у хабраюзера kadishmal. Мне кажется, это вариация на тему атомиков.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CUBRID