|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
EvLaUy с каждым годом - всё более и более редкая Предпринимаются попытки, пойти в сторону большей поддержки более популярных языков, чтобы убрать необходимость изучать ObjectScript. Посмотрим, что из этого выйдет. Мне все еще кажется, что само комьюнити могло бы помочь с популяризацией InterSystems и раскрутить само себя. Разные разработчики, делают какие то вещи для себя, для автоматизации каких то своих задач, и такие решения иногда можно выложить на публику, поделиться со всеми. Так увеличится объем проектов с IRIS в общем потоке проектов, и знать о таких проектах будет больше людей, о том что есть еще InterSystems. С учетом того что сейчас уже давно есть CommunityEdition версия IRIS, такие проекты будет проще показывать в работе. И любой сможет его запустить. Еще лучше, если такие проекты будут на стыках технологий и языков, когда можно будет сообщать о проекте на площадках других технологий. Для других более популярных СУБД, расширение поддержки разными продуктами происходит в основном за счет комьюнити, и иногда такие проекты становятся очень популярными. Есть проекты которые были разработаны сообществом, с открытым исходным кодом, в дальнейшем получили поддержку InterSystems. Тот же мой проект расширения для VSCode, теперь имеет официальную поддержку через WRC. И развивается в InterSystems, и используется на платформе Learning для обучения ObjectScript прямо в браузере. Есть проект WebTerminal, который так же активно используется в InterSystems в том числе в Learning. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2021, 10:51 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Так уж сложилось, что мой опыт был связан преимущественно только с InterSystems. Другие СУБД можно считать вообще не использовал, и нет понимания минусов по сравнению с другими СУБД. И я очень хотел бы знать, от тех кто уже получил хороший опыт с другими СУБД имея опыт с InterSystems, и может оценить, что не хватает в InterSystems чтобы быть выбранным вместо той СУБД на проекте с которым он работает. А если взять и попробовать заменить на IRIS и посмотреть кто лучше в реальном проекте. У меня сейчас уже есть возможности делать проекты любой сложности. И я бы взялся за подобный проект, независимо от языка программирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2021, 10:59 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor что не хватает в InterSystems чтобы быть выбранным вместо той СУБД на проекте с которым он работает Не хватает бесплатности... И про это всегда писали тут. $100 "за место" и полное отсутствие хостинга прикроет много каких начинаний. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2021, 19:16 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
krvsa Не хватает бесплатности... И про это всегда писали тут. Бесплатная версия уже есть, да с некоторыми ограничениями, но все же, уже начало. krvsa и полное отсутствие хостинга прикроет много каких начинаний. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 01:31 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Значит теперь все попрет! ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 09:51 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Не хватает открытого исходного кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 11:57 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
EvLaUy Не хватает открытого исходного кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 13:25 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor, ну, даже не знаю, как ответить. Ну например, что-нибудь наподобие вот такого: https://github.com/mysql/mysql-server Или тоже уже есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 14:07 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Нуу, это вы многого хотите, Oracle и. MSSQL исходники открывали? Какой смысл от раскрытия исходников коммерческого продукта? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2021, 15:36 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Не хватает среды разработки. Пишем всё на том же убожестве конца 90х, которое стыдно показывать разработчикам желающим изучить Cache:( Даже Delphi образца 2001г уделывает Cache Studio из Iris как боксер младенца. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2021, 00:03 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
StasMa Не хватает среды разработки. Пишем всё на том же убожестве конца 90х, ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2021, 08:39 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor Я уже давно сделал поддержку VSCode, которая официально поддерживается в InterSystems. Пру лет назад смотрел. Там не было полноценного Code Complete (по методам, возвращающим объекты). Сейчас он есть? Например s item=obj.collection.GetAt(1) s item. После установки точки, появится список св-в из объекта в переменной item? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2021, 10:49 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
StasMa Пру лет назад смотрел. Там не было полноценного Code Complete ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2021, 11:12 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor StasMa Пру лет назад смотрел. Там не было полноценного Code Complete Не поленился и еще раз установил "современный редактор". Ничего не изменилось за 2 года. Code complete еще хуже чем в родной Studio. То что функции могут возвращать типы, редактор совсем не знает. Даже вставка #dim не помогает ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2021, 12:46 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
Тут как-то сформулировал для себя, почему я больше никогда по своей воле не буду иметь дело с продукцией Интерсистемс и производными от нее: 1. Нетехническая часть 1.1. Лицензионное соглашение и Договор на поставку Иск требует, чтрбы Ла (License Agreement) регулировалось штатом Массачусетс (США). Это не всегда просто объяснить российским заказчикам. Конкуренты допускают такое для Ла, но не для Договора! 1.2. Практикой Иск является то, что стоимость лицензий регулярно (ежегодно) повышается. В среднем повышение для России составляет 10% в год. В результате, похоже, Каше стала самой дорогой Субд. В частности, Каше существено дороже Оракл для сравнимой конфигурации. 1.3. Ежегодное повышение стоимости лицензий влияет и на стоимость сопровождения, так как стоимость сопровожденя привязана к текущей стоимости лицензий. И если на покупку новых лицензий можно получить скидку, то на сопровождение скидок не дается. 1.4. Иск стоит пересмотреть свою лицензионную политику в части уменьшения числа лицензий - если я стал использовать меньше лицензий, то платить за поддержку и обновление должен за все ранее купленные. 1.5. При увеличении числа пользователей (при достижении некоторых пороговых значений) стоимость каждой лицензии (каждого пользователя) возрастает! Бред! Иск объясняет это повышением функционала, но реезультатом является то, что бюджет на Субд тяжело заплвнировать точно. 1.6. У Иск есть приятная возможность - аренда лицензий. Единственный минус - стоимость аренды каждый год увеличивается, так как рассчитывается от стоимости лицензии. Исходя из повышения на 10% в год стоимость аренды удвоится через 10 лет. 1.7. Vision у компании меняется каждый год. Это странно. 2. Безопасность 2.1. Разделение ролей между DBA и DBSO (офицера по безопасности) в Каше принципиально невозможно - у роли %All всегда должен быть хотя бы один пользователь, то есть суперадминистратор, который может абсолютно все. В других промышленных СУБД разделение возможно. DBA может все, кроме настройки контроля за действиями пользователей, в том числе себя. Такой контроль есть только у офицера безопасности. Выделение роли офицера безопасности оставляет контроль за суперадминистратором - он может все, кроме того, что потереть информацию о своих действиях и быть пойманным. В Каше такое невозможно - суперадмин может все, в том числе замести следы. 2.2. При использовании прямого доступа можно случайно разрушить структуры данных для объектов или таблиц. Никакой защиты нет. Нужна возможность запретить прямой доступ для админов, но такой возможности нет. 3. Сопровождение 3.1. Период сопровождения версий у Иск -1 год. Это очень мало и неприемлемо для промышленных Субд, которые эксплуатируются по несколько лет. Понятно, что таким образом Иск подталкивает пользователей на использование более новых версий и снижает свои накладные расходы. Но следствием, например, является то, что сертифицированная по К1 152ФЗ версия Ensemble не поддерживается. 3.2. У Иск крайне ограничен набор вспомогательных утилит для администратора. Наприме, перенести БД - проэкспортировать схему БД и ее содержимое в смысле SQL невозможно. Иск рекомендует копировать cache.dat. Этот путь опасен, так как может быть нарушена целостность данных. Кроме того он не сработает при различии в кодировках в базах или при различии в использовании Unicode или для платформ с разным порядком байт. 4. Техническое 4.1. Ensemble workflow несовместима ни с чем, модель нельзя не передать, ни импортировать. Более того, модель нельзя распечатать (printscreen не в счет). 4.2. Производительность Каше является вещью в себе. Возможности по тонкой настройке отсутствуют. Впрочем, существуют специалисты, знающие некоторые недокументированные возможности. Но использование таких возможностей чревато, более того, настройки обычно слетают при обновлении версии. 4.3. Быстродействие Каше является мифом. Каше можкт показать сравнительно высокую производительность только на компьютерах с небольшим ОЗУ. Модель данных Каше рассчитана именно на такие компьютеры - она не менялась последние 40 лет. При добавлении памяти Каше начинает проигрывать MS SQL Server даже на маленьких транзакциях. Агрегатные функции и сложные запросы Каше не умеет оптимизировать вообще - простой перебор таблицы. Каше не умеет распараллеливать запросы, для пользовательских сессий создаются не нити, а процессы, по одному на каждую сессию. 4.4. В прямом доступе транзакции в Каше не поддерживаются - существующие команды TStart и TCommit исходят из предподожения, что есть только один пользователь. Многопользовательский доступ никак в транзакциях не учитывается. Блокировки и конкурентный доступ нужно делать на уровне приложения. Ошибка в реализации или неверное действие админа в терминале приводят к неконсистентности данных. База может просто посыпаться. Найти такую ошибку очень трудно. 4.5. В SQL у Каше реализовано всего 2 уровня изоляции - dirty read и read committed. Причем read committed реализован частично - он не распространяется на доступ к индексам. Поэтому даже при правильно написанном приложении возможно самопроизвольное рассыпание базы и эффект мерцающих ошибок. Такое ощущение, что Иск не подумал о том, что с системой может работать более одного пользрвателя. 4.6. Встроенный SQL компилируется в М. Поэтому план исполнения запроса при изменении параметров базы изменен быть не может. В результате даже для огромной базы будет использован тот же алгоритм, что и для тестовой базы разработчика. Итог - деградация производительности в продакшене. Способ борьбы - перекомпиляция всех классов. На реальных базах (десятки гигов) перекомпиляция (да или просто накат новой версии) может занимать по нескольку суток. 4.7. Версия СУБД Каше должна быть не ниже версии клиентских программ. Это неудобно - обновляя СУБД на сервере надо обновлять и всех клиентов. У конкурентов обычно наоборот. 4.8. Очень слабое документирование. Ннапример $zu. Некоторые гуру знают и используют недокументированные фичи. Для промсистем так делать нльзя. В Каше без этого нельзя. 4.9. При работе с SQL если захочется добавить новый индекс (это обычная практика по настройке производительности), то надо перекомпилировать все связаннык классы, по факту обычно надо перекомпилировать весь проет - чтобы быть уверенным, что база не развалится. Перекомпиляция реальных бд может занимать дни. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2021, 07:57 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
exdba, Многие пункты не верные или слишком устаревшие, либо не знаете как готовить. О каком размере проекта идет речь, где перекомпиляция проекта может занимать дни? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2021, 08:52 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
vassil exdba, Многие пункты не верные или слишком устаревшие, либо не знаете как готовить. О каком размере проекта идет речь, где перекомпиляция проекта может занимать дни? Что именно не верно? Какой пункт? Конкретику, пжл. Проект, где перекомпиляция шла днями (проект, умерший, в том числе и по этой причине) - ПФ РФ ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2021, 09:21 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
exdba Проект, где перекомпиляция шла днями (проект, умерший, в том числе и по этой причине) - ПФ РФ А вы пробовали собрать свой Chromium? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2021, 09:24 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
exdba, Не совсем понятно, почему пересборка проекта является проблемой именно для Caché Будто вы написав приложение на любом компилируемом языке не запускаете сборку проекта целиком? Реальные базы десятки гигов, это что такое? у меня реальные (еще работающие) базы десятками Терабайт, и почему я не видел таких проблем о которых вы описываете. Проект ПФ РФ, судя по по вашим словам умер не из-за проблем с InterSystems, а потому что им не умели пользоваться. Проблема сс индексами будто бы только в Caché? Если вы добавили индекс по существующим данным, в любой БД нужно этот индекс построить, и если база будет большая, это все равно займет время. Или по вашему, в любой другой СУБД создание любого индекса не занимает времени вообще? И база моментально соберет индекс, независимо от объема данных? exdba Встроенный SQL компилируется в М. Поэтому план исполнения запроса при изменении параметров базы изменен быть не может. В результате даже для огромной базы будет использован тот же алгоритм, что и для тестовой базы разработчика. Итог - деградация производительности в продакшене. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2021, 09:39 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor StasMa Не хватает среды разработки. Пишем всё на том же убожестве конца 90х, Если под средством разработки подразумевается редактор кода, тогда сделан "гигантский" шаг вперед . ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2021, 14:53 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor exdba, Не совсем понятно, почему пересборка проекта является проблемой именно для Caché Будто вы написав приложение на любом компилируемом языке не запускаете сборку проекта целиком? Реальные базы десятки гигов, это что такое? у меня реальные (еще работающие) базы десятками Терабайт, и почему я не видел таких проблем о которых вы описываете. Проект ПФ РФ, судя по по вашим словам умер не из-за проблем с InterSystems, а потому что им не умели пользоваться. Проблема сс индексами будто бы только в Caché? Если вы добавили индекс по существующим данным, в любой БД нужно этот индекс построить, и если база будет большая, это все равно займет время. Или по вашему, в любой другой СУБД создание любого индекса не занимает времени вообще? И база моментально соберет индекс, независимо от объема данных? exdba Встроенный SQL компилируется в М. Поэтому план исполнения запроса при изменении параметров базы изменен быть не может. В результате даже для огромной базы будет использован тот же алгоритм, что и для тестовой базы разработчика. Итог - деградация производительности в продакшене. Про проблемы с индексами - это только у Каше. Это было документировано, это была "фича". То есть, уровень есть, а использовать нельзя. Фишка только в Каше. Про Ирис - не скажу. А в Каше накатка версии требовала перекомпиляции базы. Отсюда и полтора суток на обновление базы в МО. Исправили? Хорошо. Про неумение готовить код - ну да, все просто. Отказываемся от встроенного SQL)))). Или "разогреваем" после обновления. Ручками) или умением программировать)). Почему у Оракла и прочих для этого ничего выдающегося на уровне *софта* делать не надо? В крайнем случае, админ запустит обноаление статистики. В фоне. А еще база растет и статистика меняется. "Разогревать" каждый раз? Конечно, все преодолимо. Вопрос цены, надежности, времени, удобства. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2021, 17:32 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
exdba, Кажется вы немного путаете. Какой смысл сравнивать Oracle и Caché. Если про говоря про каше имеете ввиду код приложения, его вы компилируете. А c Oracle у вас приложение где то отдельно, которое тоже компилирует, и сколько времени? И не понимаю, что значит перекомпиляция базы? Это как? вот комиплияция кода это понятно. В каше не нужно базу компилировать, достаточно только код. Обновление статистики можно делать и для Каше. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2021, 20:19 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor exdba, Кажется вы немного путаете. Какой смысл сравнивать Oracle и Caché. Если про говоря про каше имеете ввиду код приложения, его вы компилируете. А c Oracle у вас приложение где то отдельно, которое тоже компилирует, и сколько времени? И не понимаю, что значит перекомпиляция базы? Это как? вот комиплияция кода это понятно. В каше не нужно базу компилировать, достаточно только код. Обновление статистики можно делать и для Каше. Обновление приложения в Каше - это обновление классов. Перекомпиляция класса в Каше тянула за собой и пересборку связанных с классом таблиц и индексов. Даже если хранение не затрагивалось, а речь шла о каком-то расчетном методе. Если говорить о прямом доступе, то такой проблемы, конечно, не возникало. Так что именно в Каше при использовании объектов не удавалось отделить логику приложения от логики хранения. Обновление статистики можно делать, но оно не повлияет на ту логику, которая была использована на момент компиляции встроенного SQL. Если компилятор на момент компиляции метода со встроенным SQL решал, что запрос реализуется через прямой перебор записей таблицы, то эта логика оставалась той же и при увеличениии объемов таблицы в тысячи раз. Здесь надо было перекомпилировать класс на реальной базе, чтобы учесть новую статистику - возвращаемся к проблеме долгой перекомпиляции классов. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2021, 07:58 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
exdba Перекомпиляция класса в Каше тянула за собой и пересборку связанных с классом таблиц и индексов Вот у меня есть реальный работающий проект в котором данных 100 ТБ, и такой не один, и если бы все было так как вы говорите, то у меня месяцы бы уходили но сборку новой версии. Но я собираю версию отдельно от данных, код подключаю к данным, и о чудо все работает. И даже если бы я собирал это все вместе с данными, ничего, абсолютно ничего не изменилось бы. Время сборки было бы такое же. Во время компиляции не запускается ни пересборка индексов ничего что должно затрагивать данные в таблицах. То о чем вы говорите может происходить если вы делаете после обновления пересборку всех индексов, наверно потому что вы их постоянно меняли (Зачем?) или просто потому что так решили? То есть на вашем оракле на 100ТБ данных если вы каждый раз будуте перестраивать полностью все индексы, это будет занимать сколько времени? минуты, секунды? Не думаю, вероятно это тоже будет занимать слишком много времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2021, 08:58 |
|
Что не хватает в Cache/IRIS
|
|||
---|---|---|---|
#18+
DAiMor exdba Перекомпиляция класса в Каше тянула за собой и пересборку связанных с классом таблиц и индексов Это не бред. Оно так работало. Почему оно так работало - вопрос к Иск. Когда а ПФ РФ аозникли проблемы с этим, на ушах стяла вся Иск. Какой-то апдейт для частичного устранения проблемы выпкстили. Помогло мало. Глобпльно (хорошее слово)) ничего сделать не смогли. Проект закрыли. Вы, вероятно, из Летографа, и таких подробностей не знаете. Кстати, как поживает Летограф как продукт (про фирму не спрашиваю, знаю)? PS Кстати, а хорошо ли Летограф переваривал большие объемы данных и число пользователей более 5? ))) PPS Каше хорошо работало только тогда, когда становилось М-ом. PPPS Я правильно понял, что из 20 пунктов "почему не Каше" сомнение вызвал только 1? ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2021, 19:11 |
|
|
start [/forum/topic.php?fid=39&msg=40073930&tid=1556104]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 174ms |
0 / 0 |