Microsoft признала унизительное поражение после долгой борьбы за права своих партнеров.
Microsoft давала бесплатные лицензии своим партнерам в течение многих лет, утверждая, что это нужно делать, потому консультанты должны хорошо знать как использовать продукты для того чтобы хорошо продавать эти самые продукты.
Однако, в начале недели 8 июля Microsoft незаметно объявила, что лицензионные льготы будут отменены с 1 июля 2020 года.
Партнеры компании пришли в ярость, потому что они привыкли к бесплатным лицензиям и считают, что использование программного обеспечения Microsoft делает их лучшими продавцами программного обеспечения Microsoft и, следовательно, лучшими источниками дохода для Microsoft.
Microsoft отбилась иронично: поскольку большая часть портфеля фирмы была перенесена в облако, стоимость предоставления бесплатных лицензий своим партнерам оказалась слишком большой дырой в ее карманах.
Это очень достойный аргумент: когда-то партнерам приходилось платить за аппаратное обеспечение для запуска своего бесплатного программного обеспечения, таким образом, стоимость делилась. В соответствии с новой облачной моделью Microsoft несет больше затрат.
Но это объяснение не успокоило партнерв Microsoft и они продолжают бушевать.
И к субботе Microsoft отменила изменения, дополнив их обычными откоряками и пообещав в будущем стать более консультативными.
При том, что его большая ежегодная партнерская конференция пройдет на этой неделе, и, скорее всего, она будет испорчена, если лицензионный спор не будет разрешен.
Но факт остается фактом: Microsoft безоговорочно науськивает читателей iTnews к Azure. Тем не менее, мы слышим многочисленные истории о возврате вычислительных мощностей из облака.
Комментарии
Понял только, что Майкрософт фсё. Это же хорошо?
Простите, но вы неверно поняли. "Фсё" пришло к баранам, которые сделали кассу мокрософту. И теперь бараны будут платить и каяццо.
У баранов тоже на полшестого? Нет? Не будут тогда платить.
может и найдутся особо "одаренные". Но очевидно же, что платить не за что.
Вы просто представьте, сколько нужно продать месячных подписок, чтобы получить 6000 долларов в месяц при марже 3-4 процента с подписки? Всех баранов просто просят выйти и больше не мешать. А если хотят мешать, то только за деньги
Да, да, пользуюсь 1С на постгрес =)))
Ага и мы тоже, уже года два.
А вот специалисты говорят, что на постгрессе 1С медленнее работает... Да и сколько у вас пользователей? И какое железо на ваше количество пользователей?
Вопрос в первую очередь компетенции специалистов.
Начиная с оптимизаций под особенности реализации конкретной БД.
Лично наблюдал результат переноса одного проекта с оракла (администрировавшегося абы как, если вообще администрировывшегося) на оракл, должным образом настроенный и администрируемый.
Как Вы считает, какой рост производительности при этом наблюдался? ☺ Ну хотя бы порядок величин…
Помню мы с админом два дня настраивали в винде дрова для подключения 1С к ораклу. Та еще песня :)))
А так, если руки с одного места растут, то разницы особой не будет. Что MS что Posgres
Оптимизатор запросов в MSSQL сильнее, чем в Постгре. Правда в Оракле он сильнее, чем в MS =))) Да и ГРИД в оракле, оставляет MS далеко позади.
Ну так вопрос цены и задач. Возможностей постгреса хватит в 99% случаев для малого/среднего бизнеса
Ага. Многие понять не могут что цена решения - это цена сервера + цена лицензий. И если отказаться от лицензий MS можно позволить себе сервер много лучше.
В Вашей модели куда-то потерялось сопровождение.
Цена сопровождения MS и Постгре примерно равна.
"Правда в Оракле он сильнее, чем в MS"
Инфа 100% ?
В МС-СКЛ действительно хороший оптимизатор.
Да, правда. Гуглите Оракл-грид. Там чудеса до которых мс "писать и писать".
"В МС-СКЛ действительно хороший оптимизатор."
Хороший. Но в оракле он лучше. Когда МС сделает что то похожее на грид, тогда посмотрим.
Кажется, оптимизатор запросов и система распределенных вычислений не одно и тоже.
Не совсем. Это означает, что оптимизатор умеет работать с распределенными данными. И глупо было бы не применить эту модель к локальным данным, которые на физическом уровне так же "распределены".
МС-СКЛ умеет одну таблицу разложить по разным файлам на разных дисках. И умеет выполнять запросы со степенью параллелизма по числу имеющихся процессоров. И оптимизатор все это учитывает и применяет. Наверное грид это круто, но надо смотреть во что это выливается на конкретных примерах.
При чем тут оракл, если речь изначально шла про MSSQL?
При том, что иллюстрируется пропущенный Вами вопрос администрирования сервера БД.
Опыт подсказывает что от одного до полутора порядков.
Видно мало у вас опыта. Безграмотными настройками можно так упороть сервер, что потом такой простор для улучшения производительности останется, там и два и три порядка легко можно получить. Непонятно, что сравниваем.
Не думаю. Все же обычно стоят настройки по умолчанию. Мало кто лезет и начинает "творить". Тем более настройки того же МС жутко не очевидны.
Другое дело, оптимизация под нагрузку. Но и тут есть проблемы. Я помню мы делали "профили" один для обычной работы, а другие для закрытия периода. Когда бух хотела закрыть период, то сначала профили, потом рестарт сервиса, потом только старт закрытия =))) потом опять смена профиля, потом опять рестарт.
Задача была за ночь период гарантировано закрылся.
Так что задача оптимизации очень интересная и творческая.
Ну там же вопрос был задан явно с подвохом ☺ так что ожидать можно было чего угодно :) В 1С я не специалист, но все же интересно, чего там такого у нее внутри может быть, что для сервера БД в разных ее режимах требуются шибко разные настройки? Речь о Микрософте?
1С общается с серверами на SQL92... что дает возможность использовать разные БД. Но. это рождает и трудности с быстродействием. Т.к. тот же оракл \ мс могут использовать разные расширения, например для графов. Что, конечно делает запросы много быстрее, с другой под каждую БД нужно писать свои обработчики.
Речь про постргре.
Что касается оптимизации, например, память. При работе в хх человек, памяти выделяется около 16 гбайт на 1С и 16 на посттгре. Когда закрывается период, то 6 на 1С, все остальное на постгре. Там же размер журналов увеличиваются, что бы не записывались часто, увеличиваются все кеши ну и т.д. Т.е. при закрытия периода идет оптимизация на чтение. При работе 100 чел на запись. Ибо главное это быстрая запись документа и выставление счета =)))
Надо было на сэкономленные на микрософтовских лицензиях деньги воткнуть в сервер еще на 16 гбайт больше и не мучиться :)
"Речь про постргре." читайте внимательно. И так сэкономили и воткнули и 2 проца и памяти в 2 раза больше и рейд на SSD. Но написание скрипта для оптимизации работы сервере стоила не так уж и дорого, а пользы от нее вагон. Ибо кроме закрытия периода, ночью 1С выполняет миножество других процедур, от проверки контрагентов в ФНС до расчета себестоимости...
я так и понял, просто решил, что еще 16 гигов не такая уж большая роскошь по нынешним временам :)
Вообще с 1С сталкивался последний раз больше десяти лет назад, и мне интересно поменялось ли что-нибудь с тех пор, в плане оптимизации работы с базой со стороны приложения. Я в том смысле, что раньше 1С базу использовала исключительно как помойку, просто сваливая туда данные, и о том, чтоб обрабатывать данные на стороне базы, 1Сные разработчики, похоже, даже не задумывались.
И как масштабировать то логику и нагрузку в БД?
1С может использовать кластер серверов приложений. Ну например на 1000 пользователей - 10 физических серверов по 100 пользователей на сервер с балансировкий нагрузки и резервированием, горячей переброской сессий пользователей на другой сервер и прочими чудесами. И все они используют один сервер БД, "как помойка".
А распределенные вычисления использует только оракл грид. А это дорого, опять же. Есть попытки у веток постгре что то сделать, но пока они не выглядят промышленным решением.
Пока не будет стандарта по распределенным вычислением, и их реализации в БД, думаю и 1С и другие системы типа Microsoft Axapta (такой же принцип) не будут менять логику работы.
Ну не обязательно прям всю логику в базу запихивать, и собственно распределенные вычисления ста пользователям могут быть и не нужны, достаточно распределить самих пользователей, как вы написали. Нагрузку на чтение Микрософт уже научился распределять. Но речь скорей про то, что данные можно обрабатывать очень по разному, некоторые на SQL умудряются такие скрипты писать, которые потом сервер БД и за сутки пережевать не может, тогда как то же самое, написанное специалистом, выполняется за несколько минут.
Все же обычно 1С используется как база для ввода данных. Множество договоров, продаж, банковских транзакций и т.д. Получение информации, читай отчетность с аналитикой, можно вывести в отдельные OLAP кубы. Что на мой взгляд эффективнее.
Да эффективность sql92 и транзакт\пл-sql очень разная. Но опять же, именно этим 1С уходит от единого поставщика баз данных делая решение много дешевле.
Но в целом, на мой взгляд, дешевле и вернее обрабатывать бизнес-логику на сервере приложений, а серверу БД оставить только функционал хранения.
И все же есть вещи, которые могут быть весьма эффективно выполнены на стороне БД. Вы же понимаете, что СУБД это не только про "сложить и выдать обратно". Некоторые процессы уже оптимизированы их создателями и нередко на порядки лучше, чем это могут сделать доморощенные разработчики приложений.
Да, могут быть выполнены. Но не всегда. Все же та же 1С заточена на бизнес-логику. И в 1С я с понятными заранее трудозатратами нарисую бизнес-процесс утверждения документа. Как насчет графа в 40 действий + 50 условий ветвления? А как насчет его изменения так, что старые документы идут по старому БП, а новые по новому =)))
В SQL, такое сделать можно. Но дико сложно. А в 1С есть стандартные механизмы. Графический интерфейс, отображающий пользователю что и как утверждается. На выходе задачи пользователям и документ. Все это учитывая сложный доступ, включая заместителей и т.д.
Но самое главное, от SQL этот механизм не требует особых ресурсов. Так слезы. Вся логика реализована на сервере приложений.
Ну и самая главная беда всех SQL они не умеют вести обработку данных на клиенте =))) Потому что я считал массив, он висит в памяти и мне нужно найти там максимум. На SQL понятно, повторный запрос и в дамках. А в 1С можно обойтись без серверного вызова, сделать на клиенте, у которого ресурсов навалом =))))
Ну на клиенте клиент и ведет обработку данных, как ему надо, то есть ровно всё так, как вы и хотите :) Только вот заканчивается это тем, что когда пользователю нужно только найти максимум, шибко умный клиент запрашивает весь массив и ищет его там, увеличивая тем самым нагрузку и на клиента и на сервер БД на несколько порядков. В итоге, когда сто таких клиентов подключается к базе, создается впечатление, что база не тянет и необходимо срочно что-то масштабировать, а на самом деле проблема просто в подходе.
Не совсем. Если предлагаете передать бизнес логику на SQL то SQL должен иметь возможность работать как сервер приложений =)))) а он не умеет.
"Только вот заканчивается это тем, что когда пользователю нужно только найти максимум, шибко умный клиент запрашивает весь массив и ищет его там, увеличивая тем самым нагрузку и на клиента и на сервер БД на несколько порядков."
не совсем. Ну вот давеча решал задачу обработку документов. Получил их массив. И дальше обрабатывал их на клиенте в 3 прохода. Потому что последовательно нужно было провести расчет. Всего 2 серверных вызова - один чтение, а другой запись измененных документов. Все остальное делается на клиенте. Если реализовывать на SQL вся математика, должны дергать SQL нещадно, туда-сюда.
"В итоге, когда сто таких клиентов подключается к базе, создается впечатление, что база не тянет и необходимо срочно что-то масштабировать, а на самом деле проблема просто в подходе."
Для этого у 1С есть кеширование, включая кеш выполнения функций. Если вы даете ей одинаковые параметры, она вам вернет то же значение. Кешированием вы можете управлять, что по сессии, что по вызову. Если клиент запросил кол-во документов, то второй раз он получит их мгновенно. Читай хранимая вьюха, только процедура\функция =))))
Ну если вы внимательно меня читали, то я нигде не предлагал передать бизнес-логику на SQL. Я сказал, что подход к обработке данных может быть разный, и далее мы рассмотрели некий утрированный пример сферического коня с получением максимума. Дело в том, что если нужен только максимум, то сервер при наличии соответствующего индекса вернет его на порядки быстрее, чем весь массив. А дальше можете кэшировать этот результат в своем сервере приложений. База не подменяет собой ни сервер приложений, ни кэш. Последовательная обработка - тоже отдельная песня, когда речь идет об MS SQL. Например, разработчики не сильно знакомые с особенностями сиквела, любят открыть курсор и обрабатывать свой массив данных построчно, тогда как те же самые действия можно производить сразу над всем массивом, что может быть выполнено сервером в сто раз быстрее.
"Я сказал, что подход к обработке данных может быть разный, и далее мы рассмотрели некий утрированный пример сферического коня с получением максимума."
согласен.
"Дело в том, что если нужен только максимум, то сервер при наличии соответствующего индекса вернет его на порядки быстрее, чем весь массив."
Да. а если у вас уже есть массив с документами? Зачем дергать сервер? Проще дернуть массив, который вернет кол-во быстрее, чем серверный вызов.
"Последовательная обработка - тоже отдельная песня, когда речь идет об MS SQL. Например, разработчики не сильно знакомые с особенностями сиквела, любят открыть курсор и обрабатывать свой массив данных построчно, тогда как те же самые действия можно производить сразу над всем массивом, что может быть выполнено сервером в сто раз быстрее."
Когда у вас расчет данных в одном документе, влияете на расчет данных в другом? Ну например задача оптимизации резервирования остатков. Т.е. если в документе, есть 100% предоплата, и клиент хочет получить часть товара уже завтра, то он будет отгружен в первую очередь, чем заказ по которому нет предоплаты. А еще нужно учесть товары в пути, наличие на складе, обороты по клиенту и т.д.
Это классическая задача по теории оптимизации (у меня используются штрафные баллы). И классически она решается только итерационными проходами. Да можно разбить на потоки по "коллекциям" номенклатуры. В худшем случае задача решается в один поток, в лучшем в n, где n = кол-во заказов.
когда массив уже есть, понятно что незачем
когда влияет, тогда делается последовательно. Я ж не выступаю против последовательной обработки или обработки на стороне клиента вообще. Я лишь сказал о том, что зачастую разработчиками иные варианты и не рассматриваются, даже там где это возможно, потому что их голова ничего кроме вот таких вот цикличных алгоритмов с последовательными действиями над одним объектом не вмещает. Часть массива документов в качестве одного объекта они уже рассмотреть не в состоянии.
Спасибо вам за диалог. Было познавательно.
Взаимно.
Практика показывает, что тут нельзя проходить мимо задачи грамотного и согласованного с настройками сервера проектирования базы данных.
Ибо на одном только преобразовании числа в строку можно почти словить описанный эффект.
Ну, судя по всему, 1Сникам это не грозит :) я про проектирование
Там где мне пришлось набираться опыта - настолько профнепригодные до серверов не допускались. Бизнес все же деньги считает худо-бедно.
Если бы действительно считал — мы бы хотя бы знали что такое «домен AD».
А ещё результат оценки сильно зависит от уровня анализа.
Полагаю, феерию, сопутствующую включению линукс-сервера в домен со стороны увидеть… сложно, а верифицировать — скорее невозможно.
Если БД дергалась только SQL-запросами - то процентов десять-пятнадцать. Если же большая часть логики на хранимых процедурах, которые переписали умеющие люди - то и в разы могло подрасти...
Вы исходите из результатов анализа содержимого чёрного ящика.
Что далеко не всегда реализуемо. И дело даже не в известной карикатуре о чтении чужого кода…
Товарищ выше правее ☺ Но недостаточно радикален ☺
У меня исходные условия не совсем ужас-ужас - выше написал почему. А так-то да, нет предела тупизне.
Ну, оракл много чего позволяет и может.
Даже - изначально.
Помницца, исчо о 2001 годе, в эдинбургском охвисе Оракла народ конкретно прифигел, когда, вместо привычной, многолетней традиции аренды на три недели для обсчёта своего биллинга, Дойчетелеком вдруг запросил всего два с половиной часа...
Да работает медленнее. Подтверждаю. Вот только если брать совокупную стоимость лицензий на MSSQL + сервер и Постгре + сервер... то на разницу можно позволить шикарный сервер =))) И рейд на SSD и памяти раза в 4 больше... И процессоры тактовой частотой побольше =)))
И в итоге работает быстрее =)))
Страницы