• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

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

VladSh

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

Есть и другие решения, где к документу при отправке единожды раздаются доступы, а отметки хранятся в отдельной БД, и схлопывание инфы по документу происходит единожды, в момент архивирования. Это решение похуже (нужно дополнительно вычитывать отметки), но позволяет делать отметки по документу тысячами, т.е. подходит для крупных компаний.
 
L

launcher

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

кстати, насчёт обменяться опытом. приходите на конференцию по лотусу осенью этого года в москве. должно быть круто. хотим поменять формат таких мероприятий, познакомить партнёров и клиентов с новым вендором, они из первых рук расскажут, что нового и перспективного делается в платформе. наверняка много новых знакомств завяжете :)
 

VladSh

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

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

VladSh

начинающий
Lotus Team
11.12.2009
1 786
157
BIT
81
Тогда ещё не было привычки снимать)
 
  • Нравится
Реакции: savl

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
Ну как вы все догадались :) речь идет о миграции приложения, которое в настоящий момент является мастер системой и раздает всем другим системам свои идш-ки. Во все других системах уже нет возможности избавиться от лотусного формата, поэтому новая мастер система должна будет продолжать выделять их в том же формате. Более того, какое-то неограниченное время, лотус всеравно будет мастер системой и работать совместно с новой, в которой будут постепенно замещать лотусные фишки.

делать запросы в лотус на выделение ид для новых документов - изврат по-моему, хотя не самый ущербный вариант, который гарантировано сделает то что надо ... и здесь представляется такой расклад, когда лотус уже совсем не нужен, кроме как для выделения идишек для какой-то системы )))
нынче пых не модно (TS/JS), а для совместимости яб взял couchDB, ведь полюбасу нужен бэк
 

VladSh

начинающий
Lotus Team
11.12.2009
1 786
157
BIT
81
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
37
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
- возможность блокировки документа;
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
- возможность изменения/получения части документов;
- возможность шифрования отдельных полей.
смотря для чего) минусов и неудобства - выше крыши
коуч мне оказался куда ближе
хотя, нотусу нет равных, несмотря на застой и не полную открытость, граничащий с идиотизмом
а ващще, фломастеры это всё)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
А я бы MongoDb. Из преимуществ:
- обалденная настройка индексов (аналог вьюх);
у коуча - это родное, а еше есть
- возможность блокировки документа;
решается на апликейшн левел, в базе - это зло
- полноценная транзакционность (в транзакции может быть неограниченное количество документов);
она есть, но "как говорят" есть у неё и особенности, у коуча есть , но я поддерживаю подход
In many use cases, it should be possible to combine data into a single document to take advantage of these ACID properties.
вот прям пример распределенной транзакции на кластере
- возможность изменения/получения части документов;
для любого REST(коими явл. интерфейс коуч) это типичноа фича или я не понял фразу
- возможность шифрования отдельных полей.
сомнительное преимущество, решается на уровне апсервера
 
Последнее редактирование:

VladSh

начинающий
Lotus Team
11.12.2009
1 786
157
BIT
81
> возможность блокировки документа
решается на апликейшн левел, в базе - это зло
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
 

alexas1

Green Team
10.04.2014
1 202
225
BIT
37
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
есть ли смысл использовать блокировки "на атомарном уровне", если они - часть транзакционного механизма?
... и потом думать, что с ней делать, если она вдруг оказалась "мёртвой". как то не логично
это же не нотус, где просто нет другого выхода
чувствительная операция - лезь в транзакцию
 
  • Нравится
Реакции: VladSh

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на APP-уровне.
если не делать блокировки в БД (как самоцель), то не вижу - чем апсервер нарушит логику, да вовсе - прямой доступ к БД без крайней на то необходимости - это неправильно
вот если залочить - что потом с этим делать?
Надо разлочивать, аппликуха "ушла" (не разлочив) - и всё - ковыряния в БД! с таймаутами и прочим...
 
Последнее редактирование:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
вот почитал фичи, лицензию и т.п.
скачал комунити версию, как бэк БД - подойдет вполне (если всё ниже - на апп левел), чего нет:
- 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
 
Последнее редактирование:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
+/- домины и couchbase
мой пост с телеги
теперь о минусах сравнивая с кочем:
- масштабирование, у коча корзины, кот., как я понял могут быть размазаны (а не реплецированы) по кластеру (шардинг)
- перформанс - парадигма мемкэш, у домины её нет
- ACID отсутствует, у коча есть уже транхзакции и по кластеру (про домину без слез не скажешь)
- искаропки бэкап/рекавери, с этим у домины и со сторонними решениями все кастыльно
- CLI для управления данными - тупо нет у домины
- ограниченичя по данным в документе, у коча я прямых указаний не видел 250байт для ключа (не знаю как к это относиться ;) ), 20Мб данных (для многих файлов не подойдет ;) )
- время жизни (TTL) документа/баскета - интресная фича, док/корзина удаляются по истечении
- индексы - у домины ток один тип, да и тот "хромает"
- интерграция со средствами анализа/отображения - читаем выше от @Rinsk ;)
- эвенты (аки агенты) на события в документе, в том числе с интеграцией наружу. Домина, в таком кэйсе, предположительно сдохнет
есть нек. привычная фича домины, которой я не наблюдаю в коче (или плохо искал, вроде в couchDB она есть) - Readers/Authors поля
типы данных
есть эвенты, возможно сделать по схеме
т.е. ввести доп. доки по доступу и их анализировать для юзера, это, в свою очередь, откроет возможность , что в домине можно сделать ток на аппликейшн уровне
схемка для понимания крутости момента
1574169647255.png

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

ссылка на сравнение в 2018
там не упомянута couchbase enterprise (что было бы правильным), есть ток couchDB
хвалебная ода коучу
 
Последнее редактирование:

lmike

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

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 941
609
BIT
217
Но в настоящее время, при задаче получить добротный трактор на довольно-таки краткий строк
а потом-то на что уходить? Могу предположить - потащат в МС, со всеми вытекающими...
 
Мы в соцсетях:

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