Ну т.е. типа опять происки "злобного запада", "англичанка гадит", "пиндосы проклятые".
Та ни, это вот - ваши персональные проЭкции. А тут - opensource, в котором НИКТО НИКОМУ НИЧЕГО НЕ ДОЛЖЕН(ТМ)
Вот пошто в ванильке нет 64х битного счетчика транзаций, который нужен ВОТ ВООБЩЕ ВО ВСЕХ крупных инсталляциях? Набор патчей - есть. Реализация (На основе этого же патчсета, ага) во всех коммерческих дистрибутивах - есть. А в апстриме - не-а, нету. Тоже 1С должен, небось?
А пошто 1с все еще свою сборку postgresql таскает, а не "влил в апстрим"? А апстриму - внезапно - на проблемы одноэсенных положить. У них свой "проджект вижн" и делать из слоника мысыкуель они - н-ннегодяи! не хотят. Даже вот за деньги и чужими руками.
Вам надо - вы в своем приложении и. Вот 1С и. На удивление даже - небезуспешно.
Эммм... если что - то заказчик примерно так это и считает. Количество пользователей == количество активных УЗ в системе, затраты разносятся пропорционально, в результате в KPI СМ'а торчит аудит этих УЗ и "лишнего" там не то, чтобы много.
Так, чтобы кто-то из заказчиков выполнял профилирование пользователей и\или опирался на это профилирование при составлении ТЗ - ну... околонаучная фантастика. Реально у тебя будет выкопировка из того же APDEX в разделе "требования к эрогономике и технической эстетике" ну и вот "количество одновременно работающих пользователей", шт. Причем что это за "пользователь" такой - зооказчег тебе не скажет, "хоть дерись".
Я бы сказал - что проведенный тест вполне релевантен условиям задачи, как я их понимаю.
Но если что - в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
"не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн"(C)
Это, в общем, изрядно режет эффективность оффлоада, усложняет логику и увеличивает пространство для возможных ошибок, поскольку в жизни у тебя цепочка может быть сильно развесистей - а ловятся такие редко всплывающие гонки ох, как хреново.
По личному опыту - вынос аналитики на слейв "да", разнесение обычных запросов на ro реплику - неа. Не стоит того.
Условно - увеличиваем количество позиций товара на 2 шт - делаем запрос на чтение того, что есть - RO запрос, идет на слейв, увеличиваем-записываем, ой - а слейв отстал! Что оказалось в базе?
Эта ситуация ничем не отличается от ситуации когда между результатом выборки данных и нажатием кнопки "сохранить" проходит какое-то время.
не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн
Тут как бы это сказать? Нюансы. Если делать синхронную репликацию - то она весь выигрыш съест, если асинхронную - то в случае, когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Нееее... в моем понимании, "фрактал звиздеца" несколько более многогранен.
А кто сказал, что приложение вот с этим набором зависимостей запустится на вот этой версии интерпретатора\ос?
А какие из зависимостей можно задаунгрейдить не поломав все к чертям?
А можно ли использовать более старую версию самого приложения\библиотеки?
А что делать с зависимостями, которые требуют вот сборки кода? Ну, какой-нибудь драйвер для постгре?
А есть ли версия вот этого вот драйвера под эту вот ХП?
А будет старая версия работать с вот этой вот версией постгри (Привет, tls 1.3)?
Тут даже наличие интернета не всегда спасает, если что...
Контейнеризация приложений с рантаймом помогает... не всегда. В том плане что немае под XP доскеров да и под, например, mac m1 собирать надо отдельно. Пару раз неожиданно выручал даже не pyinstaller, а вовсе nuitka - но то прям ОЧЕНЬ такоЭ.
Ниет. В смысле, он туда определенную версию интерпретатора запихнет - и на ХПшке она работать не будет, да и кроссплатформенно собрать - не выйдет, насколько я помню.
ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
Есть перечень бизнес-процессов, обеспечиваемых набором ИТ-систем. Ролевые модели интегрированы с AD с кодификацией имен ресурсных групп. Есть оргструктура предприятия в виде набора OU, есть иерархия сотрудников, построенная через поле manager. Задача - визуализация + поиск аномалий с возможностью смены детализации (граф больше 100к узлов) и переходу к метаинформации.
Делал через запись дампа АД в бд с версионностью, операции на графе с помощью redisgraph, визуализация через генерацию графов server-side на лету "по первому обращению", при смене хэша - перегенерация, заняло около двух недель - и вроде даже все еще используется.
Я для решения (как мне кажется) схожей задачи (Визуализации оргструктуры предприятия - проектов - полномочий по данным из AD с возможностью перключения детализации между уровнями\слоями) использовал graphviz + графовую бд с оберткой на фласке - предполагаю, что операции по поиску на графе\отсечению\визуализации подграфов будут сильно проще\лучше реализованы - ну и в тыкву оно с ростом числа объектов не превратиться - в отличие от.
Так еще раз - "какую задачу решаем"? Зачем вам "выгружать в эксель"? Чтобы что? А связывать - зачем? Подгрузить перечень объектов по слоям? А откуда он у вас в базе? У вас есть CMDB, в которой почему-то нет возможности связывать объекты разных типов или что?
Та ни, это вот - ваши персональные проЭкции. А тут - opensource, в котором НИКТО НИКОМУ НИЧЕГО НЕ ДОЛЖЕН(ТМ)
Вот пошто в ванильке нет 64х битного счетчика транзаций, который нужен ВОТ ВООБЩЕ ВО ВСЕХ крупных инсталляциях? Набор патчей - есть. Реализация (На основе этого же патчсета, ага) во всех коммерческих дистрибутивах - есть. А в апстриме - не-а, нету. Тоже 1С должен, небось?
А пошто 1с все еще свою сборку postgresql таскает, а не "влил в апстрим"? А апстриму - внезапно - на проблемы одноэсенных положить. У них свой "проджект вижн" и делать из слоника мысыкуель они - н-ннегодяи! не хотят. Даже вот за деньги и чужими руками.
Вам надо - вы в своем приложении и. Вот 1С и. На удивление даже - небезуспешно.
Эммм... если что - то заказчик примерно так это и считает. Количество пользователей == количество активных УЗ в системе, затраты разносятся пропорционально, в результате в KPI СМ'а торчит аудит этих УЗ и "лишнего" там не то, чтобы много.
Так, чтобы кто-то из заказчиков выполнял профилирование пользователей и\или опирался на это профилирование при составлении ТЗ - ну... околонаучная фантастика. Реально у тебя будет выкопировка из того же APDEX в разделе "требования к эрогономике и технической эстетике" ну и вот "количество одновременно работающих пользователей", шт. Причем что это за "пользователь" такой - зооказчег тебе не скажет, "хоть дерись".
Я бы сказал - что проведенный тест вполне релевантен условиям задачи, как я их понимаю.
"Осталось апстрим уговорить", ага.
Но если что - в последнюю пару-тройку лет тесты показывают, что на postgresql (Наконец-то!) 1с стала работать быстрее, чем на mssql. "В среднем", конечно же - по тому же apdex'у.
"не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн"(C)
Это, в общем, изрядно режет эффективность оффлоада, усложняет логику и увеличивает пространство для возможных ошибок, поскольку в жизни у тебя цепочка может быть сильно развесистей - а ловятся такие редко всплывающие гонки ох, как хреново.
По личному опыту - вынос аналитики на слейв "да", разнесение обычных запросов на ro реплику - неа. Не стоит того.
Условно - увеличиваем количество позиций товара на 2 шт - делаем запрос на чтение того, что есть - RO запрос, идет на слейв, увеличиваем-записываем, ой - а слейв отстал! Что оказалось в базе?
не-не. В норме ты выборку + последующую запись в одну транзакцию упаковал и все у тебя норм - а с оффлоадом их две, стейт не консистентный и что там в итоге вышло - Ктулху Фтагн
Тут как бы это сказать? Нюансы. Если делать синхронную репликацию - то она весь выигрыш съест, если асинхронную - то в случае, когда на основании результата выборки данных производится запись - возможны нехорошие варианты.
Опять же, в оффлоад readonly-запросов на slave умеют не только лишь все...
Плохо, больно, неудобно. Человековменяемый способ разрешения конфликтов считай "отсутствует".
А какой NiFi взят за основу, и как собираетесь бежать за апстримом, если не секрет?
Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Это была замечательная иллюстрация исходному комменту :)
en masse ушло в прошлое вместе с редактированием конфигурации на сервере же?
Нееее... в моем понимании, "фрактал звиздеца" несколько более многогранен.
А кто сказал, что приложение вот с этим набором зависимостей запустится на вот этой версии интерпретатора\ос?
А какие из зависимостей можно задаунгрейдить не поломав все к чертям?
А можно ли использовать более старую версию самого приложения\библиотеки?
А что делать с зависимостями, которые требуют вот сборки кода? Ну, какой-нибудь драйвер для постгре?
А есть ли версия вот этого вот драйвера под эту вот ХП?
А будет старая версия работать с вот этой вот версией постгри (Привет, tls 1.3)?
Тут даже наличие интернета не всегда спасает, если что...
Контейнеризация приложений с рантаймом помогает... не всегда. В том плане что немае под XP доскеров да и под, например, mac m1 собирать надо отдельно. Пару раз неожиданно выручал даже не pyinstaller, а вовсе nuitka - но то прям ОЧЕНЬ такоЭ.
Ниет. В смысле, он туда определенную версию интерпретатора запихнет - и на ХПшке она работать не будет, да и кроссплатформенно собрать - не выйдет, насколько я помню.
ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
Обычный офисный работник точно так же НЕ знает VBA, как и python :)
Есть перечень бизнес-процессов, обеспечиваемых набором ИТ-систем. Ролевые модели интегрированы с AD с кодификацией имен ресурсных групп. Есть оргструктура предприятия в виде набора OU, есть иерархия сотрудников, построенная через поле manager. Задача - визуализация + поиск аномалий с возможностью смены детализации (граф больше 100к узлов) и переходу к метаинформации.
Делал через запись дампа АД в бд с версионностью, операции на графе с помощью redisgraph, визуализация через генерацию графов server-side на лету "по первому обращению", при смене хэша - перегенерация, заняло около двух недель - и вроде даже все еще используется.
Я для решения (как мне кажется) схожей задачи (Визуализации оргструктуры предприятия - проектов - полномочий по данным из AD с возможностью перключения детализации между уровнями\слоями) использовал graphviz + графовую бд с оберткой на фласке - предполагаю, что операции по поиску на графе\отсечению\визуализации подграфов будут сильно проще\лучше реализованы - ну и в тыкву оно с ростом числа объектов не превратиться - в отличие от.
Но вашу задачу я все еще не представляю\понимаю.
Так еще раз - "какую задачу решаем"? Зачем вам "выгружать в эксель"? Чтобы что? А связывать - зачем? Подгрузить перечень объектов по слоям? А откуда он у вас в базе? У вас есть CMDB, в которой почему-то нет возможности связывать объекты разных типов или что?
Не-по-ни-мать.