Комментарии 27
Вот только их IDE, в которой собственно и ведется бОльшая часть разработки, только под Windows. Да и в целом СУБД странная настолько, что мотивов для ее выбора вместо доступных (свободных) аналогов я даже придумать не могу.
В общем-то у нее достаточно плюсов, да и портировать существующие проекты под Cache достаточно просто в связи с тем, что она поддерживает и SQL. Обзор я писать не стал, так как их достаточно много, но если будет нужно могу попозже написать небольшое тестирование производительности на иерархических данных.
Ну вот только если и поддерживать существующие проекты, писать что-то новое с использованием Cache я смысла не вижу. А SQL там, кстати, немного странный, с одной стороны есть возможность напрямую оперировать свойствами объектов (через ->), с другой в SELECT отсутствует OFFSET как класс, т.е. реализация, например, пейджера становится нетривиальной задачей.
в InterSystems вот-вот обещают выпустить средства разработки под *nix, в частности точно под MacOS, ну и под linux должно быть, им самим надоело сидеть под винду когда у некоторых уже давно маки, и самим сотрудникам приходится юзать виртуальные машины на маках, чтобы работать с каше, так что ситуацию это должны исправить
а субд имхо странная настолько насколько может быть странная постреляционная объектно-орентированная субд, для кого-то там много плюсов, для кого то только минусы, но всем не угодишь, я лично ничего против нее не имею, и честно не знаю аналогов где можно с такой же легкостью оперировать данными, и делать все то что умеет она, и то чего она еще сможет уметь
а субд имхо странная настолько насколько может быть странная постреляционная объектно-орентированная субд, для кого-то там много плюсов, для кого то только минусы, но всем не угодишь, я лично ничего против нее не имею, и честно не знаю аналогов где можно с такой же легкостью оперировать данными, и делать все то что умеет она, и то чего она еще сможет уметь
В случае необходимости переноса проектов с древних mumps'ов (msm, etc) можно посмотреть на GT.M. Из плюсов: работает на современном linux без всяческих танцев с abi, неплохо поддерживает стандарт, быстрое портирование кода, скорость и надежность.
С cache у меня дело не пошло. В качестве альтернативы можно посмотреть на документо-ориентированные хранилища вроде couchdb — не думаю, что mumps'ерам будет сложно адаптироваться.
С cache у меня дело не пошло. В качестве альтернативы можно посмотреть на документо-ориентированные хранилища вроде couchdb — не думаю, что mumps'ерам будет сложно адаптироваться.
Вы используете его в продакшн? Как он в сравнении с Каше?
GT.M? Да, можно сказать что в production. С cache близко не знаком, ставил на поиграть немного и не более. В любом случае это системы разного класса и сравнивать их не стоит. Скажу точно что в GT.M нет плюшек вроде sql, объектов, способов общения с разными ЯП из коробки и т.д. По сути GT.M более современный ремейк старого доброго MSM, устраняющий многие его недостатки: маленький размер бд, невозможность работы на современных системах без бубна и т.д. Так же улучшена интеграция с ОС: теперь можно без проблем писать расширения на С, отказались от концепции «ОС в ОС» (управлением процессами и прочими системными вещами GT.M не занимается).
P.S.: на «Вы» ко мне не обязательно обращаться ;)
P.S.: на «Вы» ко мне не обязательно обращаться ;)
Почитал, посмотрел… Честного говоря, GT.M выглядит как-то сыровато.
Не знаю — не знаю… Не замечал я чтобы что-то из заявленного не работало. Поддержка тоже вполне достойная (разработчики всегда быстро реагируют в comp.lang.mumps, насчет платной ничего не скажу). Как приемник msm вполне подходит, а на остальное разработчики даже не претендуют. Так что всяких модных штучек ожидать не стоит. Вот только 64битной версии все нет и нет…
Новые разработки на GT.M конечно начинать не стоит, mumps себя уже давно исчерпал :) Однако живых проектов на msm еще достаточное количество и для них это хороший вариант. /me же плотно смотрит на couchdb, mongodb и т.п.
Новые разработки на GT.M конечно начинать не стоит, mumps себя уже давно исчерпал :) Однако живых проектов на msm еще достаточное количество и для них это хороший вариант. /me же плотно смотрит на couchdb, mongodb и т.п.
Не сразу заметил, что парсер кое-что съел…
Хмъ, видимо зря писал :) Ну хоть плюшки всем раздам :)
гы) а мы до сих пор юзаем 2009 версию, которая ставится под юзером cacheusr а не cacheserver… Читаю дальше…
Дело в том что через ODBC — можно подключится только к SQL-данным в каше, то есть использовать его можно для связи со сторонними SQL БД.
Лично мне кажется что использование прямого доступа в каше даёт много плюсов, по сравнению с SQL (а кроме нас am.ua ещё кто-то использует каше в продакшн?)
Дело в том что через ODBC — можно подключится только к SQL-данным в каше, то есть использовать его можно для связи со сторонними SQL БД.
Лично мне кажется что использование прямого доступа в каше даёт много плюсов, по сравнению с SQL (а кроме нас am.ua ещё кто-то использует каше в продакшн?)
нет у нас вовсе не CSP — вы вообще прайс на комерческое использование csp смотрели??? Скажу вкратце ДОРОГО!
Мы используем свой собственный Middle Ware написаный на эрланге и си, который распаралеливает входные запросы пользователей на доступные процессы (по интерсистемским условиям на одного юзера полагается 24 процесса — не больше)
20ти процессов оказывается достаточным для обслуживания 30 000 пользователей в сутки. Даже сами ребята из интерсистемса удивились и спросили у нас «как это вы с пятипользовательской лицензией — обслуживаете 30 000, может вы нас поломали» — но наш ответ их устроил — лицензионное соглашение не нарушено am.ua использует каше полностью официально.
Да а ориентироваться на то что пхпистов больше не надо — врядли пхписты заинтересуются каше…
Мы используем свой собственный Middle Ware написаный на эрланге и си, который распаралеливает входные запросы пользователей на доступные процессы (по интерсистемским условиям на одного юзера полагается 24 процесса — не больше)
20ти процессов оказывается достаточным для обслуживания 30 000 пользователей в сутки. Даже сами ребята из интерсистемса удивились и спросили у нас «как это вы с пятипользовательской лицензией — обслуживаете 30 000, может вы нас поломали» — но наш ответ их устроил — лицензионное соглашение не нарушено am.ua использует каше полностью официально.
Да а ориентироваться на то что пхпистов больше не надо — врядли пхписты заинтересуются каше…
Да, честно говоря, мне CSP не понравились, и смысла особого в них не вижу. Да и думаю, что проще, правильнее и быстрее написать свои библиотеки под необходимое, чем изучить и внедрить csp.
А не сталкивались ли вы с проблемой, что при работе через их C API после примерно 500 SQL запросов cbind_alloc_query начинает плеваться ошибкой 460 до тех пор пока реконнект не сделаешь?
нет не сталкивался — так как мы в каше SQL — только в редких случаях для связи со сторонними БД
основные же данные хранятся и обрабатываются в глобалах посредством прямого доступа.
основные же данные хранятся и обрабатываются в глобалах посредством прямого доступа.
я ни о чем подобном не слышал, может поподробней расписать, да и можно в техподдержку в InterSystems написать
Я пробовал когда-то писать в гуглогруппу (http://groups.google.com/group/intersystems-public-cache) о проблемах работы со Stream данными из C, но как-то там с низкоуровневыми вещами совсем глухо.
если вы пользуетесь лицензированной Cache то стоит обратится на WRC
а логин и пароль зарегистрировать у консультанта
а логин и пароль зарегистрировать у консультанта
Скажите, пожалуйста, во сколько вам обошлась ваша лицензия? Есть это не для огласки, то можно в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка и настройка Intersystems Cache на RHEL для работы с PHP