Миграция с Lotus'а (делимся опытом)

-Это где при отправке на параллельное согласование ста человекам создаётся 100 копий документа? Нет, спасибо!)))
В парадигме продукта и платформы, это наиболее уместно, каждый рецензент работает с изолированной копией только непосредственно в стадии рецензирования, при выходе их рецензирования персональная копия сливается с основным документом и удаляется. Множественные копии процесса не видят пользователи, для них документ один как был так и остался. Если коротко это темповые документы. Если еще резон делать именно так - это поддержка распределенной работы. Логика СЭД позволяется полнофункционально работать в распределенной инсталляции в том числе в цикле рецензирования.
У нас было аналогичное решение, как только начали писать свою СЭД в 99-м. Устарело оно в уже 2001-м. В 2002-м заменили на запросную систему - распределённая работа поддерживается в полном объёме. На данный момент решений, построенных на запросной системе, уже далеко не одно.
Некоторые из наших причин, почему мы ушли от такого решения - куча ненужных документов, влияющих на скорость БД, влияющих на db.Search, репликацию (Authors/Readers-поля для персональных копий) и т.д., ненужные алгоритмы слияния и усложнения с этим связанные, анализ множества документов при разборе тех.специалистами, вместо анализа одного и т.д., и т.п.
По сути "персональная копия" нужна для временного сохранения где-то каких-то данных (если документ не смог быть заблокирован, и данные не добавились напрямую), чтобы потом перенести их в основной документ. Никакого смысла делать это в основной БД нет. Причём, при запросной системе схлопывание всех изменений, накопленных с предыдущей отработки, может происходить за одно сохранение основного документа (в одну "транзакцию"), что сильно уменьшает фрагментированность БД, соответственно повышая её скорость.

Есть и другие решения, где к документу при отправке единожды раздаются доступы, а отметки хранятся в отдельной БД, и схлопывание инфы по документу происходит единожды, в момент архивирования. Это решение похуже (нужно дополнительно вычитывать отметки), но позволяет делать отметки по документу тысячами, т.е. подходит для крупных компаний.
 
"Запросная" реализация возможна когда между площадками есть постоянная онлайн связь, но при наличии такой связи скорее всего уместна вообще централизованная инсталляция. В нашем случае площадки вовсе необязательно должны иметь онлайн между собой. Если онлайн не обеспечивается, то на удаленной площадке все равно надо хранить какие-то данные документа, чтобы пользователь (часто в абс. другом часовом поясе) мог отреагировать на запрос выполнения действия. Работа происходит ассинхронно на домашней площадке пользователя при отсутствии онлайна до "домашней" площадки документа. Так решается проблема в общем виде, без предъявления каких-либо требований к каналам.
 
Это к слову. Движок один и тот же используется и для согласований, и для исполнений, и для ознакомлений. Согласований сейчас слёту нашёл 15. Но бывает до 30-ти. Ознакомлений бывают тысячи.
в Логика СЭД ЛВФ используется только для согласований. для исполнений, рассылки и ознакомлений - отдельные небольшие служебные сущности. и да, ознакомлений бывают тысячи. согласен, при правильной архитектуре приложения, ничего не ломается
В любом случае - решение идиотское. Как оно могло родиться в недрах IBM - загадка.
откуда такой максимализм? решение работало, продавалось, на нём делались решение. одно из них до сих пор активно присутствует на рынке в больших инсталляциях. а вы - "идиотское". ну как так? кто-то научился его готовить, кто-то не стал на это тратить время. всем стоит поаплодировать и обменяться опытом

кстати, насчёт обменяться опытом. приходите на конференцию по лотусу осенью этого года в москве. должно быть круто. хотим поменять формат таких мероприятий, познакомить партнёров и клиентов с новым вендором, они из первых рук расскажут, что нового и перспективного делается в платформе. наверняка много новых знакомств завяжете :)
 
откуда такой максимализм? решение работало, продавалось, на нём делались решение. одно из них до сих пор активно присутствует на рынке в больших инсталляциях. а вы - "идиотское". ну как так? кто-то научился его готовить, кто-то не стал на это тратить время. всем стоит поаплодировать и обменяться опытом
Из опыта. И нами продавалось в том числе. Потом переделали и вздохнули свободно. Потом уже сам делал СЭД для одной конторы - всё работает отлично. А сейчас вынужден поддерживать решение на модели с "персональными копиями" - опять едим кактус... Никто переделывать ничего глобально не будет, т.к. огромное количество баз + скорее всего Лотус будет всё-таки выводиться из эксплуатации.
Кто-то скорее всего просто остановился на решении, которое лежало на поверхности, а на другие не стал тратить время) Потому что это полный пересмотр архитектуры, а это никто не любит. Я в первой конторе додавил шефа на это. У нас был полный пересмотр и переделка каждые 2 года: полтора года эксплуатируем, ищем недостатки и узкие места, ищем решения..., а пол года - полная переделка с написанием конвертера, чтобы прийти к заказчикам, и после установки новой версии нажать кнопку, которая позволила бы поменять старый формат данных на новый. Вот так.
Всем в любом случае стоит поаплодировать - наверное нет ни одной системы, кроме Лотуса, после которой мозг смог бы научиться так изворачиваться :)

кстати, насчёт обменяться опытом
В конце 2008-го в Киеве в Аплане была конфа для разрабов, где я делал подробный доклад по архитектурам бесконфликтной работы в СЭД на Lotus и "запросной" системе. Сейчас не потяну уже. Всё надо делать вовремя)
Тут делюсь вот, - не жалко. Когда бывает на это время.
 
Ну как вы все догадались :) речь идет о миграции приложения, которое в настоящий момент является мастер системой и раздает всем другим системам свои идш-ки. Во все других системах уже нет возможности избавиться от лотусного формата, поэтому новая мастер система должна будет продолжать выделять их в том же формате. Более того, какое-то неограниченное время, лотус всеравно будет мастер системой и работать совместно с новой, в которой будут постепенно замещать лотусные фишки.

делать запросы в лотус на выделение ид для новых документов - изврат по-моему, хотя не самый ущербный вариант, который гарантировано сделает то что надо ... и здесь представляется такой расклад, когда лотус уже совсем не нужен, кроме как для выделения идишек для какой-то системы )))
нынче пых не модно (TS/JS), а для совместимости яб взял couchDB, ведь полюбасу нужен бэк
 
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.
 
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.
смотря для чего) минусов и неудобства - выше крыши
коуч мне оказался куда ближе
хотя, нотусу нет равных, несмотря на застой и не полную открытость, граничащий с идиотизмом
а ващще, фломастеры это всё)
 
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
у коуча - это родное, а еше есть
- возможность блокировки документа;
решается на апликейшн левел, в базе - это зло
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
она есть, но "как говорят" есть у неё и особенности, у коуча есть , но я поддерживаю подход
In many use cases, it should be possible to combine data into a single document to take advantage of these ACID properties.
вот прям пример распределенной транзакции на кластере
- возможность изменения/получения части документов;
для любого REST(коими явл. интерфейс коуч) это типичноа фича или я не понял фразу
- возможность шифрования отдельных полей.
сомнительное преимущество, решается на уровне апсервера
 
Последнее редактирование:
> возможность блокировки документа
решается на апликейшн левел, в базе - это зло
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
 
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
есть ли смысл использовать блокировки "на атомарном уровне", если они - часть транзакционного механизма?
... и потом думать, что с ней делать, если она вдруг оказалась "мёртвой". как то не логично
это же не нотус, где просто нет другого выхода
чувствительная операция - лезь в транзакцию
 
  • Нравится
Реакции: VladSh
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
если не делать блокировки в БД (как самоцель), то не вижу - чем апсервер нарушит логику, да вовсе - прямой доступ к БД без крайней на то необходимости - это неправильно
вот если залочить - что потом с этим делать?
Надо разлочивать, аппликуха "ушла" (не разлочив) - и всё - ковыряния в БД! с таймаутами и прочим...
 
Последнее редактирование:
вот почитал фичи, лицензию и т.п.
скачал комунити версию, как бэк БД - подойдет вполне (если всё ниже - на апп левел), чего нет:
- RBAC очень "загрублен" (базовые роли все/или чтение)
- нет групп
- нет сторонней аутентификации

энтрерпрайз качается при оставлении своего корп мейла, возможно и просто по ссылке ;), как пример:
-
-
-
- не серверных событий (на энтерпрайзе - на TypeScript)

базы условно ассоциируются с "корзинами/ведрами" (bucket)
лицензионный ключ отстут. (для энтерпрайз) и тип использования (как я это понимаю) не отслеживается никак ;)
установка бэты энтерпрайза (комунити нет бэты) требует "активировать" сервис (не путать с активацией виндядко ;) )
требования по памяти/ЦПУ...
При уставновке этнерпрайза видим
Minimum RAM required : 4 GB
System RAM configured : 125.58 GB
Minimum number of processors required : 4 cores
Number of processors on the system : 8 cores
 
Последнее редактирование:
+/- домины и couchbase
мой пост с телеги
теперь о минусах сравнивая с кочем:
- масштабирование, у коча корзины, кот., как я понял могут быть размазаны (а не реплецированы) по кластеру (шардинг)
- перформанс - парадигма мемкэш, у домины её нет
- ACID отсутствует, у коча есть уже транхзакции и по кластеру (про домину без слез не скажешь)
- искаропки бэкап/рекавери, с этим у домины и со сторонними решениями все кастыльно
- CLI для управления данными - тупо нет у домины
- ограниченичя по данным в документе, у коча я прямых указаний не видел 250байт для ключа (не знаю как к это относиться ;) ), 20Мб данных (для многих файлов не подойдет ;) )
- время жизни (TTL) документа/баскета - интресная фича, док/корзина удаляются по истечении
- индексы - у домины ток один тип, да и тот "хромает"
- интерграция со средствами анализа/отображения - читаем выше от @Rinsk ;)
- эвенты (аки агенты) на события в документе, в том числе с интеграцией наружу. Домина, в таком кэйсе, предположительно сдохнет
есть нек. привычная фича домины, которой я не наблюдаю в коче (или плохо искал, вроде в couchDB она есть) - Readers/Authors поля
типы данных
есть эвенты, возможно сделать по схеме
т.е. ввести доп. доки по доступу и их анализировать для юзера, это, в свою очередь, откроет возможность , что в домине можно сделать ток на аппликейшн уровне
схемка для понимания крутости момента
1574169647255.png

и примерчики по событиям (в т.ч. с запросом в др. баскет)

ссылка на сравнение в 2018
там не упомянута couchbase enterprise (что было бы правильным), есть ток couchDB
хвалебная ода коучу
 
Последнее редактирование:
по лимитам
нашел ограничение у коуча - 250байт для ключа (не знаю как к этому относиться ;) ), 20Мб данных (для массы файлов не подойдет ;) )
решение м.б. следующим
для couchDB ограничения такие
4Гб
фильмы хранить не весело получится ;)
для оценки - лимиты домины:
- РТ поле 1Гб
- суммарно по полям 65К, супротив 20Мб коуча или 4Гб коучДБ
- отображаемые во вьюшках поля 32К. Здесь тонкий момент - супротив 250байт индексного поля коуча - вроди бы +, в реале - "такой" индекс домины дает низкую производительность поиска и чтения/обновления документа. Но и в 250 байт можно уместить ток 125 русских букв в UTF8 - тоже не айс (опрадвние в блоге коуча - размер индекса в памяти ;) )
Др. словами хранение файлов в любой из перечисленных БД всегда будет вызывать вопросы. В домине (по опыту) получение больших файлов сопряжено с достаточно низкой пропускной способностью (в материалах RNUG от Нэша были к-то не впечетлившие меня цифры)
 
Последнее редактирование:
Но в настоящее время, при задаче получить добротный трактор на довольно-таки краткий строк
а потом-то на что уходить? Могу предположить - потащат в МС, со всеми вытекающими...
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!