ЛЕТОГРАФ даже без компании продолжает жить там где его успели внедрить.
Один проект со 100 ТБ данных, и 2000-3000 конкурентных пользователей, работает
Есть и другие с больше проекты.

Когда он с 5 пользователями работал плохо, это было еще до моего прихода, с моим приходом мы все поправили. И смогли достичь куда больших показателей.

по вашим пунктам, по некоторым уже ответил ранее.

В части лицензий ничего сказать не могу, не имел дело с этим пока. Сейчас по IRIS политика насколько я знаю немного изменилась.

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

3.2 Тут прослеживается, то что вы видимо мало работали с Cache. Не соглашусь ни с чем.
Зачем InterSystems поддерживать экспорт в конкурентные форматы?
есть возможность подключаться из других субд по JDBC/ODBC и выкачать данные в SQL
копирование CACHE.DAT если делать не на живую, никаких проблем с целостностью не будет. Это я вам как человек скопировавший сотни терабайт таких CACHE.DAT, и логики не вижу, как оно может нарушится.

8bit-unicode, это скорее проблема приложения а не InterSystems. И тут много вариантов как это решить, от программных, до простого экспорта импорта в формате XML всего что надо, кода, данных и т.д.
Когда у тебя базы занимают очень много, делать это кроме как копированием CACHE.DAT теряет смысл.
Как часто вы встречали системы с разным порядком байт? Я ни разу. Но в любом случае есть утилита в комплекте, которая решает эту проблему.

4.1. А с чем она должна быть совместима?
Там есть к примеру генерация документации.
Я не оправдываю Ensemble, у меня к ней тоже много вопросов. Но есть проект к примеру, где Ensemble используется как интеграционная шина, между большинством гос.органов всей страны (не Россия), в том числе и госуслуги граждан, обрабатывая огромный поток сообщений, да не на самом мощном сервере, которые я встречал. И оно работает. Да, тут много нужно менять, но больше в силу того что время течет и приходят новые технологии и подходы. При том что это работает даже почти без специалистов по Cache.

4.2 Да есть недокументированные возможности. Но большая часть вещей лежит на поверхности, просто очень мало кто умеет этим пользоваться. Как вы заметили выше я упоминал большой проект, который вполне работает. Ту же интеграционную шину, я тоже помогаю оптимизировать. Не все инструменты профилирования можно применять на боевых системах, в силу того что они сильно влияют на профилируемых. Но найти способы оптимизации возможно, зная узкие места. Если нужна помощь, обращайтесь

4.3 Я пока не сталкивался с другими СУБД с таким же объемом, и не смогу сказать что кто-то будет быстрее чем InterSystems. На счет того что оптимизировано только для маленьких ОЗУ, у меня на сервере работает Cache 2012.2 c 400ГБ буфером глобалов. Это мало, больше у меня пока не было? Работает вполне стабильно.
На самом деле, больше проблем тут возникает от Windows.


4.4, 4.5 Со всеми этими так называемыми проблемами можно справиться. Это особенность работы Cache. В транзакциях еще много чего интересного, и много с чем можно столкнуться на высоконагруженных системах, но все решаемо.

4.6. Да SQL компилируется в M, а вы как бы это сделали на M системе?
Но в этом плане много оптимизаций, не буду углубляться, тему уже ранее обсуждали.

4.7 Не совсем понятно о чем речь, и не совсем понятно почему это проблема. Вы так часто обновляете версии сервера? Они вроде выходят не так часто.

4.8 Документирование довольно подробное, но вот $zu не должно быть документировано от слова совсем и есть много причин для этого, ошибся цифрой и можно навредить. И другие возможности недокументированные, которыми я пользовался, чаще всего могут привести к нежелательным последствиям при неумелом использовании.

4.9 тоже уже обсудили выше.

Пивденный отвалился от ЛЕТОГРАФ очень быстро после моего прихода, у них сервер был на линуксе, а на линуксе по моему опыту работало все гораздо лучше.

Администрация г.Братска (2008 год) - внедрение было завершено в 2011 году, и это я точно знаю, так как процитировали вы мою часть именно про этот проект. Там были проблемы с быстродействием

Правительство Камчатского края (2008 год) - даже не слышал про это внедрение, вероятно отвалилось еще до моего прихода

Странно что вы даже ГПУ тут упомянули, при внедрении которого вы не присутствовали, и данный проект сильно даже рядом не стоит с остальными. И внедрение происходило уже при мне, так же как и ГПРК, и другие национальные проекты Казахстана.

Обновлений ЛЕТОГРАФа не происходит, а поддержкой занимаюсь я, тех проектов которые остались. Добавления новых фич тоже не происходит, чисто поддержка в рабочем состоянии. Некоторые проекты справляются своими силами. Тот же Братск справляется сам, и на удивление, как минимум еще полгода назад, все еще был на ЛЕТОГРАФ.
ГПУ отвалился по политическим причинам. там компания под санкции попала, но система еще долго была доступна из интернета

Для меня ГПУ, это генеральная прокуратура Украины

Сейчас проверил, ЛЕТОГРАФ в генпрокуратуре украины еще живой, что для меня странно, непонятно кто поддерживает систему и сервера в рабочем состоянии а сервера там были хорошие.
При том что доступ открыт в интернете, и можно найти вход через гугл

У каше как ни странно, есть очень много возможностей которые в некоторых случаях могут сделать сильно хуже.
И в том же ЛЕТОГРАФ, было несколько архитектурных решений, которые давали не очень хорошие результаты под высокой нагрузкой. Само приложение оно для веба, и генерация HTML и даже JavaScript происходит на лету. Это когда то было ок, но сейчас такое сложно к примеру перевести на современные рельсы фронтенда.
Еще большая боль это общий индекс в одном глобале. И даже до сих пор приходится решать некоторые проблемы из-за определенных архитектурных решений, особенно на больших системах. Где просто из-за роста объема данных начинает наблюдаться деградация скорости.

да, все верно, говорим мы об одном и том же. Проблемы начали возникать когда системы стали расти. До версии 2012.2 было ограничение памяти на процесс 47МБ, и постепенно стали появляться ошибки <STORE>. А так как уже многое в системе было построено через эти индексы, нужен был больше контроль в коде, чтобы как можно меньше битовых массивов находилось в памяти одновременно. При переходе на 2012.2 (сейчас ЛЕТОГРАФ работает на ней), памяти на процесс уже можно ставить значительно больше, и в большших системах настроено уже больше 1ГБ. И по прежнему иногда могут возникать такие ошибки. Размер Lab3ITIndex достигает уже нескольких терабайт. Чтобы обойти проблемы с тем что битовые массивы занимают много места в памяти

Вот только что выполнил, код на одной из систем, этот код получает битовый массив всех существующих объектов системе, такой код местами используется в коде. Результат выводит, то сколько занимает такой массив в памяти процесса.


На еще одной системе попробовал, там еще на 20 мегабайт больше.

А с этими массивами еще нужно логические операции проводить. И желательно в памяти процесса чтобы это было достаточно быстро.