Статья на Хабре http://habrahabr.ru/company/haulmont/blog/204834/
Сайт https://www.cuba-platform.com/ru (есть бесплатная версия)
Кратко: CUBA.Platform — платформа для разработки бизнес-приложений на java. Имеет свою IDE, однако работа в других IDE (Eclipse, Idea и т.д.) поддерживается.
Самое главное — платформа содержит много готовых компонентов.
Веб и десктоп приложения получаются из одного кода.
В общем, судя по видео, может получиться действительно дельная вещь.
Понятно, что дело за конечными решениями (типовыми), но как платформа выглядит очень интересно. Лично я собираюсь попробовать на этом что-нибудь накидать в свободное время

(209) нет, я не из кубы
как есть так и ответил, что те не нравиться

(208) по поводу 3: ведь есть механизм внешних источников данных, правда, там же мышкой настраивается объектная модель?

(210) не нравится некомпетентность

(208)
1. падение узла в кластере не приводит к остановке системы и сессии пользователей не  теряются.
2. ввод  нового узла в кластер не приводит к остановке системы
Да

3.  установка новой версии решения (включая изменения схемы БД) не приводит к остановке системы
В большинстве случаев требуется остановка, в последних версиях 1с обещали минимизировать время до минимального, по мути в базу надо пере зайти.

4. узлы кластера должны поддерживать переключение между Master и Stand By БД (когда Master БД падает) . Хочется заметить,  что для хороший отказоустойчивости решение «кластер БД с общим SAN»  не самое лучшее так как например при устаревании/разрушении индекса БД встает. Мы применяем подход  когда  данные с Master  реплицируются на  Stand By , поэтому имеется 2 копии БД.
Если я правильно понял, то тут уже дело лишь СУБД 1с тут не причем. В большинстве случаев используется MS SQL и данное поведение можно реализовать

(211) во внешних можно но потом не так просто данные обрабатыват. Мне показалось автор не совсем об этом спрашивал. Внешние Источники действительно для внешних баз

(208) Еще 1с сама агрегирует данные, в БД совещается OLTP и OLAP подходы.

В целом в 1с немного гибкости, многое делается платформой автоматически, что дает очень высокую скорость разработки

(214) можно сделать вьюху на свою же базу и получать данные более оптимально. Полноценно работать с данными не получится изза кеширования как раз.

(212) так все таки что я не так написал)?
так и есть же

(217) в постах было 0 ответов на вопросы.

(216) можно конечно, я не стараюсь вас в чем-то разубедить. Но у меня как-то такой потребности не было. Наверное из за регистров так как они агрегируют данные и все тоже самое что можно сделать через вьюху, можно сделать через регистр

(219) + может не все но многое

(218) приехали...
я писал так чтоб автор вопросов, немного понял что такое 1С

+(221) и не строил иллюзий о его крутости

(213)
Михаил,
Спасибо за ответы. Хотелось бы понять поглубже  
1. что происходит с БД когда ставиться новая версия (она доступна на чтение,запись или переходит в офф лайн)?  
2. как накатываются скрпиты  изменения (автоматически или вы сами вручную запускаете один за другим )?

(221) опять же не хочу обидеть. Но в часто 1с-ники не интересуются как устроена 1с. А На мой взгляд 1с очень крутая платформа для своих задач. Это говорю как человек в данный момент активно изучающий джаву

кстати люди с кубы понимают что у них есть хорошие шансы потеснить 1С в деле автоматизации управленческого учета

(225) сомневаюсь, как я писал в начале ветки есть шансы потеснить только в индивидуальных решениях. Управленческий учет это не сказка написанная на каждом конкретном предприятии, а набор правил ведения учета подобных регламентному. И для этого надо с продуктом продавать бизнес процессы

(224) как изучать закрытую платформу?

>>На мой взгляд 1с очень крутая платформа для своих задач
да ну его))
я тоже джаву изучаю

(208)
Для обеспечения быстрой работы высоконагруженной системы возникает необходимость  явно кэшировать данные и читать их напрямую из кэша ср. слоя . Интенсивность доступа к этим данным бывает на столько высока что даже на уровне кэша ср. слоя возникают локи (когда потоки ждут друг друга) и нам приходилось даже строить кэши 2-ого и 3-его уровня.
не очень понятно как это делается на 1с (кэширование, синхронизация потоков  и репликация такого самописного кэша)

(215) через это имеем проблемы с масштабируемостью ( я имею ввиду высокую скорость разработки)
А по большому счету  из-за закрытости системы внедрение крупных проектов даже на типовых решениях имеет немало проблем как по производительности так и по надежности.
Ну и с типовыми конфами - совсем не все гладко, внедряем сейчас бух3 - некоторые вещи не реализованы, некоторые работают только в воспаленном воображении разработчиков конфы. И это мы говорим о регламентированном учете.

(225) Нет у них таких шансов и целей таких нет !

Вопрос представителям CUBA, кого Вы считаете своим основным конкурентом ?

(228) на 1с не пишут высоконагруженных систем, 1000 пользователей только на стендах запускают

(225)  я думаю что Управленческий Учет лучше делать на 1с (мы свой на 1с написали и очень довольны). В данный момент в платформе CUBA нет регистров (хотя можно добавить), а это сами понимаете очень важно

(230) точно, это как Байтовская бизнес-студио

+(233) я для сравнения

когда законодательство более менее устаканится, предприятия не смогут ввести черный учет потому как деньги будут только электронные, как следствие этого 1С-ка  превратиться в монолитную программу. Тогда у программистов 1С наступят черные дни. Кто выживет, кто - нет, а кто-то пойдет майданить здание на Савелевской
Да здравствует бардак в бухгалтерском, налоговом и каком там еще?.. законодательстве)))
(так мысли в слух)

(235) Футуролог ?

(226) вот кстати очень правильные слова: "для этого надо с продуктом продавать бизнес процессы".

(235) даже если все устаканится и все будет "по белому" очумелые головы в компаниях (которые обожают перестраивать внутренние процессы) никуда не денутся.
Автоматизацию нельзя завершить, её можно только приостановить.

да сам подумайте все к этому идет
т.е. 1С со временем превратиться в одно приложение без необходимости программировать

(239) не будет такого. Вот смотри, Adobe клепает свой основной продукт уже много лет. Казалось бы весь функционал какой только можно уже могли бы сделать. Нет, выходят же новые версии и всегда находятся причины по которым их покупают.

(239) >>  все к этому идет

Несколько сотен лет к этому всё идет.
Жизнь не стоит на месте, всё меняется.

(240) но клепает-то только Adobe. Вся фишка в этом и есть)

(240) Он имеет ввиду не в техническом плане, а в глобальном, изменится методология учета как такового, наверное. ИМХО.

(239) даже если всё "устаканится", эволюцию юзабилити остановить нельзя

(242) ну это да. Тут сторонним разработчикам только фильтры оставили.

Управленческий Учет всегда останется.  так как бухгалтерия никогда не будет считать такие вещи как  например  прибыльность по проектам

Я вот не понимаю на самом деле как может такое быть "установка новой версии решения (включая изменения схемы БД) не приводит к остановке системы". Если ты например поменял логику приложения и для неё тебе нужно расширить набор полей таблиц, а еще хуже изменить сами данные то в любом случае ты так или иначе на момент "обновления" для обработки таблиц должен блокировать к ним доступ. Иначе "старая" логика поназапишет туда некорректных записей. Соответственно в любом случае будет промежуток когда пользователям будет запрещено вводить какие-то данные. 2 копии БД? А если в момент реструктуризации идет активный ввод данных?
Не верится что на деле нет множества "условностей".

Да банально, поменяется протокол взаимодействия узлов кластера и все. Не смогут 2 узла работать параллельно.

(246) конечно, это не её задача, это больше к финансам, но зачастую бухи подчинены финикам

(204) В 1С есть несколько уровней кэширования:
1. Объектный кэш, служит для оптимизации работы с объектными сущностями платформы (элементы документов/справочников/etc.). Разработчиком не управляется, платформа следит за ним сама.
2. Механизм повторного использования возвращаемых значений. Позволяет организовать кэш результатов вычислений. Разработчик  должен просто определить необходимость использования механизма и вариант поддержки этого кэша. Вариантов 2 - на время вызова сервера, либо "на время сеанса" (На самом деле в этом случае система отслеживает 2 таймаута: время с момента создания и с момента последнего обращения. Если хотя бы один из них истек - кэш очищается, и будет обновлен при следующем обращении к функционалу).
3. Параметры сеанса - уровень кэширования полностью управляемый разработчиком.

Что касается репликации - этим 1С разработчику голову не забивает, и берет все это на себя.

Запросы, не устраивающие по производительности, нужно переписывать в самой 1С, тут здоровых альтернатив нет.

Версионирование реализуется, уже довольно давно поставляется в составе типовых решений. Кулибины своих реализаций тоже наплодили достаточно.

+(250) план запроса в субд не управляется из 1с

1. что происходит с БД когда ставиться новая версия (она доступна на чтение,запись или переходит в офф лайн)?
при изменении структуры БД создается новая таблицы нужной структуры затем в нее переливаются данные из старой на это время вся база захвачена монопольно (вроде как в последних версиях платформы монопольный доступ нужен только на момент подмены таблиц)
  
2. как накатываются скрпиты  изменения (автоматически или вы сами вручную запускаете один за другим )?
Обновления накатываются прямо из 1с-ной IDE подключенной к нужной базе 1с. Все делается автоматически. В целом процесс обновления очень простой

(232) -> (252)

(252) 1. это зависит от способа обновления я бы сказал

(251) И это хорошо. Учитывать при разработке архитектуру 4-х разных СУБД было бы... не стоит в общем.

(255) некоторые это считают минусом ) некоторые - это не я )

(250) все эти "кэши" работают в разрезе сеанса. Параметры сеанса вообще для кэша не рекомендуется использовать. К сожаления в 1с нет возможности построить общий кэш на уровне звена сервера приложений.

(257) да лажа это всё, основное кэширование идёт на уровне субд

(256) это действительно больше на фантастику похоже. На сколько я знаю подобного нету даже в том же hibernate а это наверное флагман ORM подхода

(257) И что же класть в такой кэш? Картинки что ли? На самом деле и такой кэш есть - в нем живет p-код и прочая инфраструктура. А вот необходимость такого кэша для элементов бизнес логики еще придумать надо.

(259) тут по тарссировке надо смотреть, когда одноэс попадает, когда нет

трассировке*

может еще что и рабочий процесс кэширует для всех сеансов, но врятли. А уж между собой рабочие процессы с вероятностью 99% вообще ничего не кешируют. "Эй вась, че ты к BD домогаешся? я тут для тебя уже закешировал".

+(261) поэтому не слишком доверяю гипернакрученным запросам

(260) да что угодно можно добавить. Хоть остатки хранить. Вот к примеру бывают очень накрученные АРМы где человеку показывается результат довольно сложного запроса и вычисления. Одновременно таким АРМами могут пользоваться очень много человек. А ведь можно избежать многих запросов к БД, если будет общий кеш.  Через этот кеш можно было бы между сеансами обмениваться данными, а сейчас можно только через СУБД. Это так что первое в голову пришло, но я сам многократно в процессе оптимизации узких мест жалел что нет такой возможности.

(265) в том то и дело, что кэш накапливает субд, сначала проверяет его, а потом уже начинает действовать

+(266) конечно же, сам план запроса остаётся

(266) субд конечно накапливает, с этим никто не спорит, но СУБД производит кэширование довольно грубо. И в примере с АРМами этого недостаточно будет. Нужны хотя бы вьюхи на уровне СУБД и очень было бы не плохо их аналог на уровне сервера 1с. Вот элементарный пример с многократным выполнением одного и того же запроса в консоле. Время выполнения запроса не так уж сильно меняется, а с общим кэшем можно было бы на порядки ускорят узкие места

(268) хм, с одним и тем же меняется, если использовать разные условия

(265) Смысла - ноль. Кэшировать все остатки проще каким-нибудь ioDrive'ом. А если посмотреть внимательнее на работу пользователей - окажется, что одними и теми же остатками они не оперируют, а только по своему складу/товарной группе. И количество реальных пересечений настолько незначительно, что внимания не заслуживает. С сотней пользователей и СУБД справится. А тысяча пользователей не будет торговать с одного склада...

(269) Виноват не предметно выразился и без примера. Вот зашел в рабочую базу и выполнил простой запрос

ВЫБРАТЬ
    СУММА(РеализацияТоваровУслуг.СуммаДокумента) КАК СуммаДокумента,
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ РеализацияТоваровУслуг.Ссылка) КАК Ссылка
ИЗ
    Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг

в итоге запрос выполнялся 12 секунд первый раз и по 4 последующие. А мог выполнятся 0 все последующие разы.

(270) Сложно конечно вести диалог когда ты говоришь, что я сейчас сижу на стуле, а тебе говорят что на самом деле ты сидишь голой попой на асфальте.
Я специально упомянул слово АРМ. Там могут быть остатки с продажами, ценами и кучей прочей дополнительной информации. я не говорю что оно не работает, оно то работать будет и без всяких кэшей, другое дело как с этими лагами мириться. Теже доп права пользователей и настройки обмена могли лежать в общем кэше

(271) странно, у тебя что-то с базой, у меня всё норм )

(271) Сложно разговаривать не предметно. Если бы у тебя был в практике реальный случай, когда тебе понадобился бы такой кэщ - ты бы уже рассказал  об этом а я бы впечатлился. А на деле ты просто говоришь: "хочу кэш, чтобы был". А зачем он тебе понадобился - пытаешься высосать из пальца.

+(271) http://clip2net.com/s/6kZu4d

по поводу кэша.
Reaper_1c правильно написал кэши бывают разные.
и чаще всего это просто НСИ (справочники) хранящиеся на ср. слое.
Но есть и другие случаи.  Пример из реальной жизни, система Такси
- более 3000 конкурентных  пользователей
- данные в БД сильно связанны (сущность "заказ машины" хранится в более чем 25 таблицах)
- высокая update activiy (в секунду примерно 250 новых записей, 450 изменений. кол-во чтений никто не считал)

экраны диспетчеров должны  обновляться  каждые 2с (очень много всякой быстро изменяющейся инфы надо запрашивать с сервера).
Для этого пишется кэш который объявляться раз в 2с а все клиентские сессии читают данные из него.

(275) у вас система какой-то свой кэш делает? помимо субд?

(271) не могу представить, когда требуется сумма чего-то по всей базе. обычно это или по клиенту или за период. но не все клиенты за все время

(277) см (274)

(247) Для установки новой версии без остановки системы , мы используем следующий подход
1. накатываем скрипты изменения БД (БД должна быть совместима с новой и старой версией софта). Это наиболее ответственный момент который выполняется в ручную.
2. устанавливаем новую версию на запасной кластер
3. пересаживаем 10-20 пользователей на   запасной кластер и ждем примерно 1 день
4. если дефектов в новой версии не обнаружилось , то переводим всех пользователей на запасной кластер (так называемая осушка основного  кластера)
5.  как только активных сессий на основном кластере не осталось , обновляем его
6. переводим пользователей с запасного кластера на основной

по вопросу изменение данных при обновлении
1.  просто запустить update на всю таблицу нельзя так как пойдут локи. Для этого пишется хранимая процедура  которая меняет записи пакетами по 1000 штук.
2. изменение   тип поля. Использовать  ”alter table  …. alter column”  тоже нельзя. Поэтому
Создается новое поле с новым типом  
данные между старым полем и новым синхронизируются с помощью триггера.
Новая версия работает с новым полем  а старая со старым.
После обновления триггер удалятся

(276) да свой кэш

(280) чего не заполнишь, что из Самары

(279) а если надо ключи добавить?

(273) в (275) в тоже самое написано, что и я написал.
(272) реализаций 8 миллионов, база 1.7 ТБ.

(283).2 дефрагай

(273) про рабочие места менеджеров был реальный случай

(284) да все регламентные процедуры СУБД регулярно проводятся

(279) хотел бы уточнить что это просто пример высоконагруженной системы которая должна работать 24/7. Ее просто нельзя останавливать. В простых случаях - когда базу можно остановить - все эти навороты естественно не обязательны.

(255) По поводу оптимизации запросов. В CUBA тоже по умолчанию все делает ORM (OpenJPA), в этом случае ты планом не управляешь.
Но бывают случаи когда запрос очень часто выполняется, или очень тяжелый, или ORM строит запрос не оптимально. Таких запросов наверное менее 1%, но они могут быть критичными для производительности приложения. В этом случае мы можем использовать нативный SQL и мапить данные на объектную модель с помощью MyBatis.
Как я понимаю в 1С можно хранимки для этого использовать? Но в этом случае как быть с именованием полей?

(288) хранимки использовать нельзя без нарушений лиц. соглашения и потенциальных косяков при реструктуризации.
Но читающие запросы в 1с очень близки к нативному sql, есть возможности по оптимизации через индексируемые временные таблицы, там только нет возможности использовать хинты по блокировкам и ступеням оптимизации.
Что же касается кэша - в указанном примере, когда огромному числу пользователей нужна определенная сложновычисляемая инфа, то её помещают в отдельные таблицы - регистры, таким образом обпеспечивая аналог OLAP, а кеширование регистров и скорость получения этих данных обеспечиваются субд.

(202) обязательно передам! :)

(288) я про MyBatis только читал когда-то. И думаю что при чтении данных (язык запросов 1с) на много ближе в этой технологии. Язык запросов 1с - это очень похожий на нативный SQL с некоторыми ограничениями.

(289) Понятно. Возможно ORM в 1С сильно более продвинутая по сравнению с Hibernate/OpenJPA, но последние далеко не всегда строят хороший запрос в сложных случаях - когда есть с десяток join'ов и необязательно просто по ключу.

По поводу кэша - согласен, хорошее решение. Но все равно получается лишнее звено (средний слой - БД), и дополнительная нагрузка на базу, которая всегда будет узким местом. С другой стороны в большинстве случаев это будет некритично.
И еще - эти таблицы (регистры) в нашем примере нужно будет обновлять каждые 2 секунды. Не будет ли база лочить запросы на чтение в этом случае? Низкий уровень изоляции транзакций нельзя использовать.

(292) В 1с используется read committed, что на версионниках не создаст блокировок на чтение, на mssql также не создаст, так как с 8.3 там используется read committed snapshot. Кроме того, если мы говорим о данных для вывода на форму пользователя, то есть не получаемые в процессе записи объекта, то они получаются в read uncommitted, если разработчик явно не указывал другое.

(292) план запросов с десятками джоинов по неиндексируемым полям или не по эквивалентности будет также непредсказуем, да. Хинтов на использование того или иного способа соединения для планироващика передать нельзя. В 1с для таких случаев пользуются функциональностью временных таблиц, разбивая такой один сложный запрос на несколько запросов более простых. Возможность использовать прямой запрос или хранимку есть, но это уже использование ado/odbc вместо встроенных средств и является нарушением лиц. политики.

(293) логично

(294) да, это тоже вариант решения. В общем понятно что проблемы схожие и механизмы их решения должны быть, иначе платформа (и 1С и CUBA) просто не могла бы использоваться в больших проектах.

(289)
Алексей,
Ваш вариант очень хороший ,  но не всегда применим.
у нас немного другой случай  и регистры  здесь применять нет смысла (у нас агрегация как таковая не требуется).
- кэш это  набор из примерно 30 000 записей которые получаются в результате  очень сложных запросов к БД  (нет  никакой агрегации ,  просто много хитрых условий  )
-  каждые 2 сек он обновляться. В это время пока идет обновления читать его нельзя (будут не консистентные  данные).

Думаю на 1с лучше сделать так
  - создать вымышленный справочник (скажем "кэш заказов").  
  - каждые 2 секунды удалять все данные из него и заполнять новыми данными (можно попытаться сделать процедуру которая сравнивает  кэш с новыми данными и вносить только изменения , но это тоже не просто ) .
  - На время заполнения справочника  "кэш заказов"   блокировать его от чтений.  
  
минусом такого решения будет
а) излишняя нагрузка на БД (в принципе не страшно , но и хорошего ничего нету)  
б) высокая update activity  (15 000 удалений  15 000 добавлений в секунду ) . Что для    Highly  Available  конфигурации   БД,  построенной на репликации, очень не хорошо (растет replication queue)

(297)AlexZotkin, доброго дня, я так пониманию Вы переставляете на форуме разработчиков платформы CUBA. Скажите какие требования предъявляются к программисту и какими навыками он должен обладать, чтоб уверено разрабатывать нечто уровня ТиС(это простая торговля и учет ТМС, без бухгалтерии). Заранее спасибо.

(298)
Для разработки на платформе CUBA требуются:
- знания JSE (Java Standard Edition),  в дальнейшем придется разобраться с работой ORM,  но это не сложно
- начальные знания БД (DDL и  DML).

триста

(299)Знание какой именно ORM? Их же много и на любой вкус. Я вот, к примеру, знаком с Hibernate. Этого хватит?

вас ист дас ОРМ - оперативно-разыскные мероприятия?
.
и заметим, что речь идет об обсуждении каких-то сферических программистских знаний.
.
мое глубокое убеждение - если в предметке не варился или нет рядом внятного и грамотного объясняльщика/постановщика задач/ТЗшника - то все ОРМЫ, ДДЛ, и особенно джава идут лесом - бо ничего путного хоть на Кубе, хоть на сильверлайте хоть на чем - не выйдет.
.
как тупой пример - работают уменя девки через один сетевой портал - к программистам пртетензий нет. просто работать противно и неудобно.

(301) в платформе CUBA используется  OpenJPA. Если Вы знаете Hibernate то у вас проблем с OpenJPA не будет.

а где русския язык?

(302)wiki:ORM
ORM (англ. Object-relational mapping, рус. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как проприетарные, так и свободные реализации этой технологии.

В 1С она тоже есть.

(303)OpenJPA с этим у меня как раз проблемно, не освоил, как-то сложней Hibernate.
Ладно, пойду вашу студию дальше изучать. Пробую на ней нечто вроде ТиС изобразит.

(235) На панель пойдут студенты-обновляльщики. Для крутых спецов 1С наступят золотые времена. Их перестанут отвлекать тупыми заданиями, приносящие только одни расходы для предприятий. Бюджеты предприятий будут тратится на достойные проекты => эти проекты будут приносить неплохой профит => бюджеты будут расти вместе с зарплатами спецов.

(185) "я не нашел, как cuba подружить с ActiveDirectory (в 1С из коробки);"
Интеграция с AD в CUBA есть:
http://docs.cuba-platform.com/cuba/latest/security/ru/webhelp/section_AD.html

(304) В CUBA поддерживается локализация - каждый пользователь может выбрать язык, с которым он хочет работать, при условии что вы задали локализованные сообщения для ваших экранов.
Стандартные экраны CUBA имеют локализацию на английском, русском и французском языках.

Если вы про разработку, то код естественно на англ. Студия сейчас тоже на английском, но ее не сложно локализовать, если увидим реальную потребность - сделаем.

(305)Не ТиС не получится, там регистров нет. Это типа Дельфи, только для Джавы.