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

Со всем выше согласен, но не с этим. Зачем что-то воротить, если это можно сделать на уровне базы? Тем более, что логика может сказать "ДА", а база по какой-то причине "НЕТ".
Если база даёт согласие/отлуп по блокировке, тогда включается логика на 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 от Нэша были к-то не впечетлившие меня цифры)
 
Последнее редактирование:
Но в настоящее время, при задаче получить добротный трактор на довольно-таки краткий строк
а потом-то на что уходить? Могу предположить - потащат в МС, со всеми вытекающими...
 
а потом-то на что уходить? Могу предположить - потащат в МС, со всеми вытекающими...
Необязательно. У нас в стратегии уже 5 лет ориентация на открытые или относительно открытые проекты, потому M$ тут последняя в списке. Раньше вот Nuxeo рассматривали, но она не подошла, т.к. это чисто тупая ECM'ка; её взяли как хранилище файлов из всех систем, где надо хранить какой-то хлам. Сейчас AlmexECM рассматриваем. Есть ещё варианты.
 
  • Нравится
Реакции: Мыш
@VladSh Позвольте полюбопытствовать сударь, а миграцию почты вы рассматривали? Вялотекуще и безуспешно в поиске альтернатив.
 
. Сейчас AlmexECM рассматриваем. Есть ещё варианты.
стек там джава, что неплохо..., но опора на хибернейт налагает требования по памяти.... (правда, в современности, не такая проблема )
НО предполагается реляционный бэк, со всеми вытекающими
Ну и как упоминал @rinsk - с репликацией того же постгре есть "неприятности"
 
а миграцию почты вы рассматривали? Вялотекуще и безуспешно в поиске альтернатив.
А вот это на Exchange мигрировали ещё до 15-года с новой стратегией... Юзеры мучались, потом привыкли. Несколько топов остались с почтовиками в Лотусе, ну и мы) Сейчас этот вопрос не стоит. Всех устраивает... Из личного опыта - раз в пару месяцев наблюдается непонятная ерунда - письма не приходят, а потом вдруг как придут за 2-3 дня скопом)) Лично меня достаёт в любых почтовиках то, что нельзя любому письму тему переименовать; это киллер-фича Лотуса, не имеющая аналогов!) Ну и с помощью Insert снимать/ставить "прочитано/не прочитано". А так вроде всё. Что удобно - правила нормально настроил, без ограничений на размер поля. Письма по папкам автоматом рассовываются, больше ничего и не нужно; вообще стараюсь меньше в почте сидеть. Моё основное - критические баги, которые в Lotus-почту приходят)
 
  • Нравится
Реакции: Мыш
НО предполагается реляционный бэк, со всеми вытекающими
Мне тоже это не нра. И UI туго настраиваемый - контролы слишком по вертикали разъехались, раза в 3 по сравнению с лотусовыми.
И ещё у них нет понятия о том, что на определённых шагах маршрута надо подписывать определённый перечень полей. Слабо продумана технология архивации, есть экспорт доков с маршрутом по каждому в xml, но в никуда, т.е. без обратной связки ссылками архивных и рабочих доков. Ребята такие - мы сделаем любые доработки за ваши деньги))
Двиг workflow такой же, как в большинстве BPM-систем. Общее впечатление - сыровато для нашего прода.
 
А вот это на Exchange
Тошнит, как подумаю о нем) Но может и придется, увы. Угнетает окна, кластер через эт самое и то, что чанга это не тот самый не уловимый джо) Его все хотят ломать.
Ах да, еще даос.
Вот как переведут чангу на линух, вот тогда будет весело.
 
очередное "удовольствие" для винодминов чанги
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы