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

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

    Скидки до 10%

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

Связь Многие Ко Многим

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
и тут вылазит минус когда используется встроенный вид в той же самой базе - так как документ ты будешь менять всегда - в архив, еще какие-то действия на прямую никак не связанные со "связью" в любом случае заставят индексер обновить и встроенный вид тоже - чего никак не наблюдается если встроенный вид в отдельной базе
Постарался и зашифровал сообщение. Я не понял, что ты тут написал.

По поводу дальнейшей части сообщения. Никакой трагедии, документы по 100 штук сразу редко изменяются. Если правильно организована работа с оперативной информацией, то вся остальная инфа сгружается во "внутренний архив" (индексер будет 1 раз нагружен ночью), а в конце года ненужная инфа просто выгружается в архивные базы (индексер также нагружается 1 раз ночью). Таким образом юзеры работают всегда с оперативной инфой, которой, если разобраться, не так и много. И этого принципа (такой архитектуры) всегда хватало и для заводов с хреновой тучей филиалов, и для других не мелких организаций с сотнями пользователей, притом хватало так, что не надо было даже думать о серверах-кластерах, чтобы "прыгать туда-сюда" пытаясь уйти от нагрузки, и сервера эти были бесконечно далеки от идеала железа под сервер, в большинстве случаев даже без рейда.

Не выгружая доки в архивные базы тем самым увеличивается время работы индексера, это конечно не определяющая величина, но тоже фактор.

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

Darker
Не могли бы рассказать чуть подробнее? Что значит 'темповый документ'? Это документ-"линк" на основной документ?
Всё в одной базе или отдельная БД для документов-линков?
И что, вообще вьюх нету? А как пользователи видят перечень документов? А как полнотекстовый поиск?
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
И что, вообще вьюх нету? А как пользователи видят перечень документов? А как полнотекстовый поиск?
да это он походу так жирно тролит :)

хотя если вместо видов они юзают HTML таблицы то это не плохо

я когда-то сайтик-базку так делал - там все возможные виды я заранее уже отрендерил в нужный док и приходилось только его открывать
так сказать взять индексер под полный контроль

но это только при условии что все доки видимы всем и нет разных зон видимости
 
D

Darker

VladSh
Отказ от вьюх коснулся лишь "вспомогательных" баз, в которых хранится часто изменяемая связанная информация. Что касается "рабочих" баз, там все как у всех, но кол-во вьюх сведено к минимуму.

Что касается полнотекстового поиска (в т.ч. вложенных файлов), для этого создана отдельная база индексов, в которой настроечно индексируются "отборная" часть документов со всех баз данных. Вложения, относящиеся к отдельному документу, обрабатываются java-агентом, который "выдергивает" текстовый контент из файла (doc, excel). Все это богатство помещается в RT поле, по которому и производится поиск. В конечном итоге получаем единый источник для полнотекстового поиска.

Что значит 'темповый документ'? Это документ-"линк" на основной документ?

Это документ-линк (по нашему, зеркало), в котором аккумулируется данные, необходимые для отображения пользователю, а также линк на документ-оригинал. Такие документы, создаются при первом создании связи. Сама "связь" - это ответные документы к документу-линку, в которых хранится unid-ы к другим документам-линкам (не напрямую к оригиналам).

все возможные виды я заранее уже отрендерил в нужный док и приходилось только его открывать
В нашем случае HTML таблица рендерится "на лету", считывая информацию с БД Связи. А отображается в форме с помощью встроенного Web Browser Control-a (да простит меня Imike).
 
N

nayke

Добавлено: ну и в довесок, чтобы народ понимал масштаб трагедии

Допустип у вам мега правильная база в ней 7 видов и 10К документов

так вот когда вы поменяете 100 документов ваш диск "дёрнется" 7*100=700 раз!!!

при отдельном виде в отдельной базе диск будет дёргаться только когда связь удалена/создана - тоесть не весь док а конкретная функция документооборота - СВЯЗЬ
а это значит из 100 измененных документов связей было изменено всего 5 а значит диск дёрнется 5 раз

видим разницу между 700 раз и 5 раз - разница в 700 / 5 = В 140 РАЗ!

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

отсюда и попытка "натягивать" лотус на реляционную структуру - каждой отдельной функции отдельный вид и отдельная база

Ну да, только:

1. Обычно связь добавляется при редактировании документа, соответственно никаких плюсов индексер от отдельного документа не получает. Так как обновляется и текущий документ и документ связи. Поэтому подобную структуру неплохо использовать лишь при системных связях.

2. Врят ли вы для каждой базы будете делать свою "links.nsf" соответственно имея 8-10 прикладных баз БД связей не хило засоряется. И если прикладные базы достаточно просто архивируются и делятся на оперативную и архивную информацию, то, что делать со связью, если скажем Входящий документ отправлен в Архив, а внутренний в статусе актуален и т.д.

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

4. Проблемы при стандартной репликации.

Поэтому я бы сказал, что это не универсальное решение, а только для высоконагруженных приложений, где эффективность доказана "мозолями серверных служб".
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Поэтому я бы сказал, что это не универсальное решение, а только для высоконагруженных приложений, где эффективность доказана "мозолями серверных служб".
любое приложение, при условии что оно успешное в конечном счёте станет высоконагруженным и тот кто это понял раньше всех и заранее к этому подготовился прежеивет это с наименьшими потерями ;)

1) вы плохо поняли суть
допусти вы в документе ничего НЕ поменяли а только в поле бросили унид - у вас есть 20 видо для которых формула отбора ничего нового не выявила(там не используется поле с унидом) - однако индексеры всё равно придется для этих видов этот документ пересчитать заново - исключительно из-за того что поменялась дата модификации
И это еще хорошо если у тебя в доке нет компьютед полей, которые "случайно" получат новое значение и это заставит еще агенты по изменению дергаться

2) "links.nsf" обычно делается для всех прикладных баз, и архивируя базы вы разве не оставляете функционал с показом связей? - если оставляете то в чём смысл архивации тогда?

3) "усложняет администрирование" - не знаю как вы, но у меня правило хорошего тона сейчас это полное отсутствие администрирования - сел и поехал, все модули диагностики внутри

4) репликация на удивление просто решается - сохраняем в документе-связи сервера(просто копируем их документов и суммируем доступ) - тем самым сервер на котором есть этот документ получит и док-связь
и даже если в доступе вы не сильны то отреплицировав все доки-связи на все серера вы ничего не потеряли - когда там появятся доки связи будут видны, когда не появятся тоже не видны, безопасность от этого не страдает

Вот было бы жирно если бы для индексера был создан журнал индексации - наподобие журнала репликации, но это всё сказка ;)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
Отказ от вьюх коснулся лишь "вспомогательных" баз, в которых хранится часто изменяемая связанная информация.
Можете привести примеры "часто изменяемой связанной информации", для наглядности?
Что касается полнотекстового поиска (в т.ч. вложенных файлов), для этого создана отдельная база индексов, в которой настроечно индексируются "отборная" часть документов со всех баз данных. Вложения, относящиеся к отдельному документу, обрабатываются java-агентом, который "выдергивает" текстовый контент из файла (doc, excel). Все это богатство помещается в RT поле, по которому и производится поиск. В конечном итоге получаем единый источник для полнотекстового поиска.
Т.е. есть одна БД для полнотекстового поиска, которая содержит столько документов, сколько существует во всех базах целиком? Если да, то работу индексера, которая однообразна, Вы переложили на агент-менеджер, который капризен (сильно зависит от кода), и я не знаю, что на самом деле лучше.
Сама "связь" - это ответные документы к документу-линку, в которых хранится unid-ы к другим документам-линкам (не напрямую к оригиналам).
А почему не напрямую? Почему такая сложная система? В чём выигрыш?
Я понимаю, что это уже я лезу в чисто ваши идеи, но если можно, то прошу комментариев :mellow:
В нашем случае HTML таблица рендерится "на лету", считывая информацию с БД Связи.
Каким образом, если, как я понял, во вспомогательных линк-базах у вас нет видов? Или ищете нужные доки по db.Search?

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

Darkhan

Green Team
14.12.2012
99
2
BIT
0
Можете привести примеры "часто изменяемой связанной информации", для наглядности?
По факту пока только Связи и Исполнители документа. В планах изменить методологию хранения Сроков исполнения, Статуса документа, Отв. исполнителей, все эти сущности довольно часто меняются в течении "жизни" документа.
Т.е. есть одна БД для полнотекстового поиска, которая содержит столько документов, сколько существует во всех базах целиком? Если да, то работу индексера, которая однообразна, Вы переложили на агент-менеджер, который капризен (сильно зависит от кода), и я не знаю, что на самом деле лучше.
Да, одна БД Индексов на всех. Сделали ставку на "точечную" индексацию и "инкапсуляцию" реквизитных и содержательных частей документа, что позволяет при выводе результата поиска подсвечивать найденные фрагменты.
А почему не напрямую?
Из соображения дотошной оптимизации: получение данных из "облегченного" документа в текущей базе выглядело предпочтительней.
Каким образом, если, как я понял, во вспомогательных линк-базах у вас нет видов? Или ищете нужные доки по db.Search?
Все искомые документы в вспомогательных базах созданы "суррогатно" по технологии DigestSearch, эту тему я уже мусолил на этом форуме тут (однако, широкого обсуждения не добился). Поэтому и поиск проходит "влет".
 
N

nayke

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

Вы создаете документооборот внутри компании из 5 филиалов на 200 человек. Успешный система увеличит численность до 2000?

1) вы плохо поняли суть
допусти вы в документе ничего НЕ поменяли а только в поле бросили унид - у вас есть 20 видо для которых формула отбора ничего нового не выявила(там не используется поле с унидом) - однако индексеры всё равно придется для этих видов этот документ пересчитать заново - исключительно из-за того что поменялась дата модификации

Вы даете добавлять связь пользователю в режиме чтения? Я говорю о том, что данные манипуляции производятся только в режиме редактирования и только с сохранением документа.
Почему в режиме редактирования - думаю понятно.
Почему только при сохранении - пользователю все равно как организована система, но он предполагает, что нажав отмену он вернет документ в исходное состояние.

2) "links.nsf" обычно делается для всех прикладных баз, и архивируя базы вы разве не оставляете функционал с показом связей? - если оставляете то в чём смысл архивации тогда?
Архив можно сводить в статичную информацию(тот же РТФ) и переносить на съемные носители. По вашему если необходимо поднять архив нужно сервер поднимать с n+ базами?

3) "усложняет администрирование" - не знаю как вы, но у меня правило хорошего тона сейчас это полное отсутствие администрирования - сел и поехал, все модули диагностики внутри
Админу клиента это скажите когда он будет раздавать права, подписывать базы, искать причины возникновения проблем и т.д.
Один из конкурентных плюсов Domino - стандартные средства администрирования, которые включаются в требования и дальше не морочат вам голову.

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

Лишний геморрой стоит вешать на себя и клиента только когда он оправдан - думаю единственное правило хорошего тона.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
Архив можно сводить в статичную информацию(тот же РТФ) и переносить на съемные носители.
Мы так делали для информации по активностям (контролям) каждого документа. Это хорошее решение.
Один из конкурентных плюсов Domino - стандартные средства администрирования, которые включаются в требования и дальше не морочат вам голову.
Хороший стиль - все доступы на группах. ACL настроен 1 раз разработчиком и никогда не меняется. Для изменения прав доступа пишется свой механизм, который "раздаёт доступ" определённой персоне либо нескольким персонам сразу, а на деле всего лишь меняет состав персон в группах доступа. Это гораздо удобнее и проще, чем "стандартные механизмы", где админ вынужден искать группы, вручную добавлять туда людей, карячить ACL баз... - всё это мрак. И также предложенный способ корректней - будут участвовать только персоны, зарегистрированные в СЭД(!), а не вообще все имеющиеся в АК сервера.
а проблемы с репликацией отдельных баз? - среплицировалось 2 из 3 документов. Либо пропала связь, либо не работают переходы.
Эта проблема есть всегда. Даже в пределах одной базы. Например, почему-то оборвалась связь и доки той же самой БД все не отреплицировались, что вполне реально.

Добавлено:
Все искомые документы в вспомогательных базах созданы "суррогатно" по технологии DigestSearch, эту тему я уже мусолил на этом форуме тут (однако, широкого обсуждения не добился). Поэтому и поиск проходит "влет".
Честно сказать, я особо не разбирался с DigestSearch. Возможно, что и остальные тоже, потому тема и малопопулярна.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Вы даете добавлять связь пользователю в режиме чтения? Я говорю о том, что данные манипуляции производятся только в режиме редактирования и только с сохранением документа.
Почему в режиме редактирования - думаю понятно.
Почему только при сохранении - пользователю все равно как организована система, но он предполагает, что нажав отмену он вернет документ в исходное состояние.
Я считаю правилом хорошего тона работать с документов в режиме чтения - меньше конфликтов, меньше индексации, больше коллективной работы!

Архив можно сводить в статичную информацию(тот же РТФ) и переносить на съемные носители. По вашему если необходимо поднять архив нужно сервер поднимать с n+ базами?
мы не обсуждаем тут как организовывать архивы - только связи :)

А трафик?
а логические конфликты? - в одном филиале выбраны одни связи, в другом другие. Дописывать обработку конфликта?
а проблемы с репликацией отдельных баз? - среплицировалось 2 из 3 документов. Либо пропала связь, либо не работают переходы.
если в одном филиале установили одни связи в другом другие то где тут конфликты если основные документы НЕ меняли? - связи просто обьединятся

а по поводу проблем со связью и репликации - как думаете что легче репликатору? передать ваш ОСНОВНОЙ документ в среднем 2Мб с вложениями и новыми связями или же документ связь - размером в 1Кб?
 
N

nayke

Я считаю правилом хорошего тона работать с документов в режиме чтения - меньше конфликтов, меньше индексации, больше коллективной работы!
С каких пор затирание правок коллег и редактирование документа без блокирования - это правило хорошего тона.
Про коллективную работу в рамках одного экземпляра notes документа в режиме чтения вообще странно говорить.

мы не обсуждаем тут как организовывать архивы - только связи :)
Я думал мы говорим об оптимальном проектировании, которое не рассматривается с одного края.

если в одном филиале установили одни связи в другом другие то где тут конфликты если основные документы НЕ меняли? - связи просто обьединятся
И будет логический конфликт, разве нет? При отсутствии сигнализирующего механизма.

а по поводу проблем со связью и репликации - как думаете что легче репликатору? передать ваш ОСНОВНОЙ документ в среднем 2Мб с вложениями и новыми связями или же документ связь - размером в 1Кб?
Связи в документе не несут значительного объема. А отсутствие доступа/проблемы с репликацией базы/документа связи нарушат целостность данных.
т.е. документ в 2МБ в любом случае передавать, а вы предлагаете передавать что-то дополнительно.


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

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
а по поводу проблем со связью и репликации - как думаете что легче репликатору? передать ваш ОСНОВНОЙ документ в среднем 2Мб с вложениями и новыми связями или же документ связь - размером в 1Кб?
Не так. При наличии в документе поля $Revisions реплицируются только изменения, а не весь документ.
Нагрузка на репликатор прямо пропорциональна количеству документов, и чем документов больше, тем больше вероятности "недореплицированности" в одной сессии репликации.

С каких пор затирание правок коллег и редактирование документа без блокирования - это правило хорошего тона.
Не согласен. Механизм с доками-линками исключает необходимость правок (редактирования), в т.ч. и затирания.
Про коллективную работу в рамках одного экземпляра notes документа в режиме чтения вообще странно говорить.
Не согласен. Трудно реализуется, но прекрасно работает.
Коллективная работа в смешанном режиме (ReadMode + EditMode) реализуется ещё труднее, но также работает.
 
N

nayke

Не согласен. Механизм с доками-линками исключает необходимость правок (редактирования), в т.ч. и затирания.
Не согласен. Трудно реализуется, но прекрасно работает.
Коллективная работа в смешанном режиме (ReadMode + EditMode) реализуется ещё труднее, но также работает.
Я говорил что любые изменения предполагаются в режиме редактирования документа.
Если давать курочить одну карточку не блокируя - получится очень много проблем их смысла нет.
Банально 10 человек открыли карточку, не увидели прописанного поставщика и добавили связь - получили 10 поставщиков и 8 одинаковых.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
Банально 10 человек открыли карточку, не увидели прописанного поставщика и добавили связь - получили 10 поставщиков и 8 одинаковых.
Такое (логический конфликт) всё равно будет возможен, даже если и не использовать доки-линки; только на разных серверах. Вы будете блокировать и изменять док на чужом сервере?
Но в случае архитектуры с изменением документов проблему "дубликатов" решить правда легче.
 
N

nayke

Такое (логический конфликт) всё равно будет возможен, даже если и не использовать доки-линки; только на разных серверах. Вы будете блокировать и изменять док на чужом сервере?
Но в случае архитектуры с изменением документов проблему "дубликатов" решить правда легче.

Вариантов много - копию каждому, а затем сведение. Или блокирование.
Но даже если на разных серверах блокирование не сделано, то в одном документе Lotus даст конфликт - сигнал к тому что есть проблема и ее надо решить.

А если в случае с дубликатами пока автор дубля не открыл документ - будет проблема.
 
A

Anatoly

С интересом наблюдаю за ходом дискуссии. Но, к сожалению, уже утерял нить... :)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
Вариантов много - копию каждому, а затем сведение. Или блокирование.
Но даже если на разных серверах блокирование не сделано, то в одном документе Lotus даст конфликт - сигнал к тому что есть проблема и ее надо решить.
Есть такой подход; используется, на удивление, достаточно часто.
Недостатки:
1. "копию каждому":
- нагрузка на репликатор, т.к. действительно придётся по большей части, хоть и однократно, но передавать весь док по количеству пользователей-участников процесса;
- тупо нагрузка на индексер, т.к. нужно удалять доки-"дубликаты" после сведения + "стабы".
2. "затем сведение": определение отличающихся данных - тот ещё геморрой...
3. "конфликт - сигнал к тому что есть проблема и ее надо решить": кто или что будет решать эти проблемы? Автоматически или надо держать штат админов, которые только и будут этим заниматься? Ещё одна радость...

Кстати док на другом сервере штатной блокировкой заблокировать не удастся, если только он не в локальной сети или выключена галка "Enforce a-a-a...", т.к. доки блокируются на админ-сервере.

В этом смысле архитектура с доками-линками (если с ней сравнивать) выглядит куда лучше.

Добавлено:
С интересом наблюдаю за ходом дискуссии. Но, к сожалению, уже утерял нить... :)
Мы ж не знаем, где Вы её утеряли :) Задайте вопросы, если интересует тема.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Я говорил что любые изменения предполагаются в режиме редактирования документа.
Если давать курочить одну карточку не блокируя - получится очень много проблем их смысла нет.
Банально 10 человек открыли карточку, не увидели прописанного поставщика и добавили связь - получили 10 поставщиков и 8 одинаковых.
и что?
1) все 10 довольны - каждый сдалал что хотел
2) система не упала
3) агент одинаковые связи прибьёт

что мы потеряли то?

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

Добавлено:
Не так. При наличии в документе поля $Revisions реплицируются только изменения, а не весь документ.
Нагрузка на репликатор прямо пропорциональна количеству документов, и чем документов больше, тем больше вероятности "недореплицированности" в одной сессии репликации.
немного не так
прежде всего репликатор всегда реплицирует документы которые весят меньше всего, самые тяжелые идут на самый конец - это уже само по себе не логично но этим нужно уметь пользоваться

по этому отсюда удобнее сначала передать связь, а уже потом и сам документ
или же отдельно документ, отдельно связь
разнеся всё по разным базам мы тем самым диктуем логику и порядок репликации БЕЗ использования формул репликации - а это упрощение администрирования и слежения за целостностьюй данных
 

VladSh

начинающий
Lotus Team
11.12.2009
1 788
157
BIT
92
прежде всего репликатор всегда реплицирует документы которые весят меньше всего, самые тяжелые идут на самый конец
Вначале речь шла о больших объёмах, "курсирующих" при каждом изменении, чего на самом деле нет.
По моим наблюдениям доки реплицируются в хронологическом порядке изменений или близко к этому. Можно "оборвать" сеть в процессе и посмотреть, какие доки отреплицировались. Возможно 'о тяжёлых' речь идёт для новых документов, но это не так важно, т.к. любой новый документ не сильно выбивается по объёму из себе подобных. Если "тяжёлый" док вдруг не отреплицируется, так ничего страшного в этом не будет, пройдёт в следующий раз, но весь целиком.

В плане большей управляемости репликацией при разносе доков по разным БД, - это так. Но я бы для каких-то голимых доков-линков не стал выстанавливать приоритет в high, т.к. для этого есть более важные "системмные" базы; а также посмотрел бы я на объяснения, когда ген.директору срочно нужен док стоимостью в сотни тысяч $, отправленный уже как минут 5 назад, а он ждёт, пока отреплицируются линки 'для обеспечения "целостности"'. Также как и не стал бы загонять основную часть баз в low.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
а также посмотрел бы я на объяснения, когда ген.директору срочно нужен док стоимостью в сотни тысяч $, отправленный уже как минут 5 назад, а он ждёт, пока отреплицируются линки 'для обеспечения "целостности"'. Также как и не стал бы загонять основную часть баз в low.
я тебя прошу, не перегибай папку
если у него в системе есть такие доки, то какой же он скряга, что не обеспечил кластеризацию всех серверов домино?
он бы эти доки мгновенно получал
нельзя экономить на железе :D
 
Мы в соцсетях:

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