1) В Atelier есть ошибки и ещё много, что нужно доделывать (https://community.intersystems.com/post/atelier-10-release). Всё равно это шаг в правильном направлении, потому что база для Atelier — Eclipse — открытая, расширяемая, мультиплатформенная IDE, для которой уже существует множество плагинов, которые теперь можно использовать и для работы с Caché ObjectScript.
2) Этот пункт я не очень понял. Caché поставляется с собственным веб-сервером — урезанной сборкой Apache. Как CSP Gateway мешает использовать уникальные возможности Caché ObjectScript — непонятно.
3) SQL в Caché не «вместо», а «вместе с» объектной моделью. Идеология в том, чтобы использовать тот взгляд на данные, который удобней в данном конкретном случае. Если быстродействия SQL и объектов не хватает всегда можно использовать прямой доступ к глобалам.
Возможность использовать Caché как низкоуровневую и быструю иерархическую СУБД никуда не делась.
NoSQL изначально означало «No SQL». Это уже потом появились альтернативные расшифровки, вроде «Not only SQL», «No! SQL» и так далее.
Вот, например, Мартин Фаулер в 2012 году предлагает расшифровку «Not only SQL», сравнивая с давно устоявшейся «No SQL».
http://martinfowler.com/bliki/NosqlDefinition.html.
Там же Фаулер приводит общие характеристики таких NoSQL СУБД:
Not using the relational model (nor the SQL language)
Open source
Designed to run on large clusters
Based on the needs of 21st century web properties
No schema, allowing fields to be added to any record without controls
Как минимум 1,2 и 5 условиям GT.M удовлетворяет. Так что, по-моему, вполне корректно называть GT.M NoSQL СУБД.
Ну мне кажется, что тут интересней исходники смотреть, как это сделано. А демо можно достаточно просто запустить на своём компьютере — в статье описано как.
Вводных статей про глобалы было уже несколько.
Эту выделяют отличные рисунки. Тот, на котором изображено дерево из одних груш, — мастерский, как раз из-за аналогии.
Нужно смотреть в каждом конкретном случае, какой будет процент дырок. Это зависит от того, как данные загружаются.
В примере из статьи, после выполнения загрузки, значение ^Person = 2007040.
То есть, узлы 2'000'001 — 2'007'040 значений не имеют, и следующий узел будет вставлен в 2'007'041
7'040 / 2'000'000 = 0,00352 = 0.352%
С другой стороны, если сохранение каждого объекта влечёт обновление многих индексов, то, возможно, $Increment не узкое место, и заменять его смысла нет.
Я могу в начале статьи вставить дисклаймер, что статья частная позиция автора и ни в коей мере не позиция фирмы и так далее и тому подобное. Я хотел рассказать о новой интересной функции. Это вполне удалось. Что с ней делать или не делать — решать вам, как разработчику.
«не формулируя чётко критерии, когда это возможно»
Достаточно чётко, что делает функция $Sequence описано в документации.
Можно ли в ваших сценариях использования менять $Increment на $Sequence решать вам. Правильно, что вас настораживает. Нельзя автоматом менять А на Б в сотне тысяч строк кода.
Ведь функция $Increment должна увеличить значение ^a на 1
Равенство id == ^a гарантируется только в момент присваивания, не так ли? Нигде не обещается, что уже в следующую секунду не налетят «100500 процессов» и не увеличат ^a ещё на 100500.
Я имел в виду, что спецификация $Increment(^a) — это увеличить значение глобала ^a ровно на 1. У $Sequence такого ограничения нет.
В общем случае, одноаргументный $Increment нельзя заменить на $Sequence? Радикальный пример:
for i=1:1:20 {
set a = $Increment(^a)
write "^a=",^a,!
if i#10=0 {
kill ^a
}
}
В некоторых популярных случаях одноаргументный $Increment можно заменить на $Sequence. В общем случае — нет.
Если вы используете $Increment исключительно для генерации Id, как в примере статьи, то я не знаю причин, чтобы не заменить его на $Sequence (что, конечно же, не значит, что их нет).
Пусть в программе написано
set id = $Increment(^a)
За счёт чего здесь может происходить кеширование? Ведь функция $Increment должна увеличить значение ^a на 1.
Работать с локальными переменными функции $Sequence, по-моему мнению нет никакой необходимости (как и функции $Increment), ведь внутри одного процесса конкурентного доступа нет, и set a = $Increment(a) это то же самое, что и set a = $Get(a) + 1.
Разброс Id можно, конечно, сделать и без $Sequence. В данном случае это побочный эффект.
1) В Atelier есть ошибки и ещё много, что нужно доделывать (https://community.intersystems.com/post/atelier-10-release). Всё равно это шаг в правильном направлении, потому что база для Atelier — Eclipse — открытая, расширяемая, мультиплатформенная IDE, для которой уже существует множество плагинов, которые теперь можно использовать и для работы с Caché ObjectScript.
2) Этот пункт я не очень понял. Caché поставляется с собственным веб-сервером — урезанной сборкой Apache. Как CSP Gateway мешает использовать уникальные возможности Caché ObjectScript — непонятно.
3) SQL в Caché не «вместо», а «вместе с» объектной моделью. Идеология в том, чтобы использовать тот взгляд на данные, который удобней в данном конкретном случае. Если быстродействия SQL и объектов не хватает всегда можно использовать прямой доступ к глобалам.
Возможность использовать Caché как низкоуровневую и быструю иерархическую СУБД никуда не делась.
Вот, например, Мартин Фаулер в 2012 году предлагает расшифровку «Not only SQL», сравнивая с давно устоявшейся «No SQL».
http://martinfowler.com/bliki/NosqlDefinition.html.
Там же Фаулер приводит общие характеристики таких NoSQL СУБД:
Как минимум 1,2 и 5 условиям GT.M удовлетворяет. Так что, по-моему, вполне корректно называть GT.M NoSQL СУБД.
Фаулер, конечно, не истина в последней инстанции.
http://yomaker.ru/pismoMONRF.htm
1) В статье реклама явная. Как может быть _скрытая_ реклама в блоге компании InterSystems. Конечно явная.
2) Как мы можем изображать просто прохожих, если у нас в профилях написано «работаю в InterSystems». (см также)
3) У меня в комментарии (не буду говорить за других) моё личное мнение. Я до сих пор не понимаю, чем он рекламный.
4) Вы ни в коем случае верить не должны! Должны убедиться сами.
На всякий случай помещу тут ссылку — en.wikipedia.org/wiki/No_Silver_Bullet.
Если вы не согласны с моим комментарием, давайте обсудим. В чём в нём реклама я не понимаю.
Глобалы и NoSQL действительно не нужно путать.
А то это выглядит как обвинение, но совершенно не ясно в чём.
Эту выделяют отличные рисунки. Тот, на котором изображено дерево из одних груш, — мастерский, как раз из-за аналогии.
В примере из статьи, после выполнения загрузки, значение ^Person = 2007040.
То есть, узлы 2'000'001 — 2'007'040 значений не имеют, и следующий узел будет вставлен в 2'007'041
7'040 / 2'000'000 = 0,00352 = 0.352%
С другой стороны, если сохранение каждого объекта влечёт обновление многих индексов, то, возможно, $Increment не узкое место, и заменять его смысла нет.
«не формулируя чётко критерии, когда это возможно»
Достаточно чётко, что делает функция $Sequence описано в документации.
Можно ли в ваших сценариях использования менять $Increment на $Sequence решать вам. Правильно, что вас настораживает. Нельзя автоматом менять А на Б в сотне тысяч строк кода.
Я имел в виду, что спецификация $Increment(^a) — это увеличить значение глобала ^a ровно на 1. У $Sequence такого ограничения нет.
В общем случае, одноаргументный $Increment нельзя заменить на $Sequence? Радикальный пример:
В некоторых популярных случаях одноаргументный $Increment можно заменить на $Sequence. В общем случае — нет.
Если вы используете $Increment исключительно для генерации Id, как в примере статьи, то я не знаю причин, чтобы не заменить его на $Sequence (что, конечно же, не значит, что их нет).
Пусть в программе написано
set id = $Increment(^a)
За счёт чего здесь может происходить кеширование? Ведь функция $Increment должна увеличить значение ^a на 1.
Работать с локальными переменными функции $Sequence, по-моему мнению нет никакой необходимости (как и функции $Increment), ведь внутри одного процесса конкурентного доступа нет, и set a = $Increment(a) это то же самое, что и set a = $Get(a) + 1.
Разброс Id можно, конечно, сделать и без $Sequence. В данном случае это побочный эффект.