Оптимистичных блокировок по сравнению с пессимистичными? Более высокая масштабируемость, надежность и т.п. То есть если вы начнете проводить инвентаризацию (или запустите большой отчет, хотя это иногда решают делая версионный режим тольк для отчетов) у вас вся база не ляжет. Ну и накладные расходы меньше, так как обычно данные неконкурентны (если у вас не биржевая торговля ограниченных позиций например).
Ну собственно версионными СУБД (и update conflict'ами в частности), то есть СУБД все записи читает на момент начала транзакции. А в момент записи СУБД проверяет версию записи, если она изменилась, кидает update conflict, который платформа ловит и просто заново проводит транзакцию. С phantom read проблема решается или материализацией (которая в платформе прозрачна, тут немного про это), ну или "true serializable" в Postgres.
Вопрос в том, что в сложных логиках (не обычных CRUD) большинство данных для вычислений есть только на сервере (например цены товаров, условия поставки и т.п.), соответственно придется эти данные туда сюда на клиента гонять как минимум. Не говоря уже о том, что для вычислений придется императивщину вместо SQL использовать. Т
о есть непонятно в чем смысл. Использовать вычислительные ресурсы клиента, за счет большего трафика, неудобства разработки (то есть к SQL и условной Java / Python серверной логике еще клиентский JavaScript добавить) и т.п.? И это не говоря еще о безопасности.
Есть внутренний пул соединений, куда складываются неиспользуемые потоками соединения без временных таблиц / транзакций, и потом выдаются при необходимости новым потокам. Но так как таких соединений не сильно много по понятным причинам, особой роли этот пул не играет.
Правда есть важный механизм асинхронного "перестарта соединений", когда отдельный поток периодически собирает (весьма хитрым скорингом) соединения, которые давно работают, использовали много временных таблиц, и т.п. и асинхронно перестартовывает такие соединения (создает новое соединение, копирует все временные таблицы в новое соединение, закрывает старое соединение, и это все не прерывая поток использующий старое соединение). Это очень важно, так как у PostgreSQL есть не совсем объяснимая утечка памяти на долгоживущих соединениях, использующих временные таблицы. Кстати этот же механизм перестарта соединений может использоваться в том числе для кластеризации. Баунсеры к сожалению такого делать не умеют (они просто ограничивают использование временных таблиц ЕМНИП).
ЗЫ: Есть еще пул временных таблиц в соединении, но это из другой оперы.
Ну в temporary table я бы не сказал, что прям совсем не нужна транзакционность. Потому как если в них хранятся какие-то (пусть и временные) данные, вы проводите транзакцию и, в том числе, изменяете эти временные таблицы (что бывает часто), а потом ловите скажем update conflict, то вам нужно заново начать транзакцию. И если вы не откатите временные таблицы на начало транзакции у вас будет нецелостное состояние и повторить транзакцию заново (что подразумевается при update conflict) уже не получится.
Может вы все же нацизм вы имели ввиду? Потому как фашизм это совсем про другое.
Ну и новость же вроде звучит не "русским пользователям", а "пользователям из России". И если это считать нацизмом, то тогда можно сказать что и визы в страну для одних граждан в отличии от безвизового въезда для других это тоже "нацизм".
С такой махровой демагогией спорить тяжело. Но кстати все эти ваши квоты и новые мигранты это одно из того, что делает экономику США такой сильно. А именно благодаря тому что выжимает из общества все что можно, даже самые маленькие меньшинства, и пытается их запихнуть в экономику, чтобы еще больше увеличить внутренние потребление и человеческий потенциал.
Ну любой банк обвалится, если к нему придут все вкладчики забирать деньги. Только чем банк больше, тем меньше вероятность этого. А для самой передовой экономики мира (с точки зрения технологий и человеческого капитала) эта вероятность близка к падению метеорита.
Ну и это в принципе самобалансирующаяся система. Инвесторы уходят, ставки растут, инвесторы приходят назад. Не говоря уже о том, что как показал опыт пандемии все ЦБ завязаны друг на друга, и не заинтересованы в падении друг друга. То есть падать некуда, потому как все в одной лодке.
Китай окончательно перешёл в разряд развитых стран
Ну прям-таки. А ничего что по ВВП по ППС на душу населения (единственный хоть чуть чуть объективный показатель благосостояния) Китай на 80 месте. Отставая даже от Беларуси, не говоря уже о России.
Нет никакой проблемы госдолга в США. Была "проблема" его быстрого роста, в результате массового печатанья денег в пандемию, чтобы не допустить схлопывания потребления (и соответственно спирали падения экономики). Хотя сам рост не проблема, проблема в том что по окончании пандемия возникла проблема дефицита уже производства (в частности из-за отложенного потребления), а это привело к инфляции (что как раз является проблемой). Но проблему инфляции сейчас решат просто сжиманием денежной массы (что собственно и происходит), экономика адаптируется и продолжит жить как раньше.
А сам госдолг (что США, что Китая) вообще особой роли не играет, он полностью управляем финансовыми институтами США, это всего лишь циферки в компьютере.
Все эти финансовые выкрутасы не так уж и важны. В конечном итоге финансовая система подстроится (также как и с госдолгом США).
Фундаментальная проблема Китая - ловушка средних доходов. Для дальнейшего роста Китая ему необходим рост потребления среднего класса (ну и прежде всего его создание), а следствием или причиной этого является создание гражданского общества, которое в свою очередь неизбежно создает политические риски. Собственно поэтому пока не помню случаев в истории, когда государство преодолевало ловушку средних доходов, не избавившись при этом от диктатуры. А именно туда сейчас движется Китай. Так что торможение его экономики в ближайшее десятилетие неизбежно.
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.
Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.
Не понял примера вашего с join'ом. Join это чистая композиция (например в lsFusion): habr.com/ru/company/lsfusion/blog/458376/#rest
Да в структурном программировании композиция проще и понятнее (так как оперирует функциями, а не таблицами), чем join. Но скажем цикл, разбиение или примитивная рекурсия в комбинаторном (SQL) проще.
В любом случае непонятно какое отношении это к ООП имеет. ООП это прежде всего про наследование и полиморфизм (ООП может быть как в структурном, так и в комбинаторном программировании), вы же рассуждаете про то, что SQL оперирует таблицами, а не функциями. Да это создает дополнительную accidental complexity, но опять-таки причем тут ООП?
Теперь бы еще поддержать рекурсии, наследование с полиморфизмом, сессии изменений, события, ограничения, логику представлений, и еще много чего и получится lsFusion.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.
Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи.
Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.
АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.
То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.
Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.
В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).
Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).
То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.
Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну а про порог входа в 1С не шутит разве ленивый
Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).
А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
очень большие компании используют полностью кастомную разработку
Согласен, даже рынок полного custom made никто не отменял.
Т.е. нет риска оказать без кадров и возможности сопровождать решение.
Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)
У нас вся инфраструктура на гитхабе (точнее сейчас туда документацию переносим, тогда точно будет вся). Но при этом нужно понимать, что, как я уже писал, баги у нас имеют наивысший приоритет, то есть мы их фиксим сразу когда их нам сообщают / мы обнаруживаем, поэтому часто задачи создаются уже постфактум.
Вы же понимаете, что бизнесу фиолетово коробочное решение или нет. Ему нужно решить свои проблемы (то есть получить ИТ-систему которая будет эффективно автоматизировать именно его процессы, как текущие так и будущие) быстро / дешево / с минимальными рисками. А будет это 100% коробочное решение, 60% коробочное 40% доработки, или 100% разработки, уже дело десятое. Если опять-таки устроит бизнес по срокам и стоимости (так например некоторые бизнесы готовы ждать, некоторые нет и т.п.)
Оптимистичных блокировок по сравнению с пессимистичными? Более высокая масштабируемость, надежность и т.п. То есть если вы начнете проводить инвентаризацию (или запустите большой отчет, хотя это иногда решают делая версионный режим тольк для отчетов) у вас вся база не ляжет. Ну и накладные расходы меньше, так как обычно данные неконкурентны (если у вас не биржевая торговля ограниченных позиций например).
Ну собственно версионными СУБД (и update conflict'ами в частности), то есть СУБД все записи читает на момент начала транзакции. А в момент записи СУБД проверяет версию записи, если она изменилась, кидает update conflict, который платформа ловит и просто заново проводит транзакцию. С phantom read проблема решается или материализацией (которая в платформе прозрачна, тут немного про это), ну или "true serializable" в Postgres.
Вопрос в том, что в сложных логиках (не обычных CRUD) большинство данных для вычислений есть только на сервере (например цены товаров, условия поставки и т.п.), соответственно придется эти данные туда сюда на клиента гонять как минимум. Не говоря уже о том, что для вычислений придется императивщину вместо SQL использовать. Т
о есть непонятно в чем смысл. Использовать вычислительные ресурсы клиента, за счет большего трафика, неудобства разработки (то есть к SQL и условной Java / Python серверной логике еще клиентский JavaScript добавить) и т.п.? И это не говоря еще о безопасности.
Есть внутренний пул соединений, куда складываются неиспользуемые потоками соединения без временных таблиц / транзакций, и потом выдаются при необходимости новым потокам. Но так как таких соединений не сильно много по понятным причинам, особой роли этот пул не играет.
Правда есть важный механизм асинхронного "перестарта соединений", когда отдельный поток периодически собирает (весьма хитрым скорингом) соединения, которые давно работают, использовали много временных таблиц, и т.п. и асинхронно перестартовывает такие соединения (создает новое соединение, копирует все временные таблицы в новое соединение, закрывает старое соединение, и это все не прерывая поток использующий старое соединение). Это очень важно, так как у PostgreSQL есть не совсем объяснимая утечка памяти на долгоживущих соединениях, использующих временные таблицы. Кстати этот же механизм перестарта соединений может использоваться в том числе для кластеризации. Баунсеры к сожалению такого делать не умеют (они просто ограничивают использование временных таблиц ЕМНИП).
ЗЫ: Есть еще пул временных таблиц в соединении, но это из другой оперы.
Ну в temporary table я бы не сказал, что прям совсем не нужна транзакционность. Потому как если в них хранятся какие-то (пусть и временные) данные, вы проводите транзакцию и, в том числе, изменяете эти временные таблицы (что бывает часто), а потом ловите скажем update conflict, то вам нужно заново начать транзакцию. И если вы не откатите временные таблицы на начало транзакции у вас будет нецелостное состояние и повторить транзакцию заново (что подразумевается при update conflict) уже не получится.
Может вы все же нацизм вы имели ввиду? Потому как фашизм это совсем про другое.
Ну и новость же вроде звучит не "русским пользователям", а "пользователям из России". И если это считать нацизмом, то тогда можно сказать что и визы в страну для одних граждан в отличии от безвизового въезда для других это тоже "нацизм".
О, трамписты-популисты на марше.
С такой махровой демагогией спорить тяжело. Но кстати все эти ваши квоты и новые мигранты это одно из того, что делает экономику США такой сильно. А именно благодаря тому что выжимает из общества все что можно, даже самые маленькие меньшинства, и пытается их запихнуть в экономику, чтобы еще больше увеличить внутренние потребление и человеческий потенциал.
Ну любой банк обвалится, если к нему придут все вкладчики забирать деньги. Только чем банк больше, тем меньше вероятность этого. А для самой передовой экономики мира (с точки зрения технологий и человеческого капитала) эта вероятность близка к падению метеорита.
Ну и это в принципе самобалансирующаяся система. Инвесторы уходят, ставки растут, инвесторы приходят назад. Не говоря уже о том, что как показал опыт пандемии все ЦБ завязаны друг на друга, и не заинтересованы в падении друг друга. То есть падать некуда, потому как все в одной лодке.
Китай окончательно перешёл в разряд развитых странНу прям-таки. А ничего что по ВВП по ППС на душу населения (единственный хоть чуть чуть объективный показатель благосостояния) Китай на 80 месте. Отставая даже от Беларуси, не говоря уже о России.
Нет никакой проблемы госдолга в США. Была "проблема" его быстрого роста, в результате массового печатанья денег в пандемию, чтобы не допустить схлопывания потребления (и соответственно спирали падения экономики). Хотя сам рост не проблема, проблема в том что по окончании пандемия возникла проблема дефицита уже производства (в частности из-за отложенного потребления), а это привело к инфляции (что как раз является проблемой). Но проблему инфляции сейчас решат просто сжиманием денежной массы (что собственно и происходит), экономика адаптируется и продолжит жить как раньше.
А сам госдолг (что США, что Китая) вообще особой роли не играет, он полностью управляем финансовыми институтами США, это всего лишь циферки в компьютере.
Все эти финансовые выкрутасы не так уж и важны. В конечном итоге финансовая система подстроится (также как и с госдолгом США).
Фундаментальная проблема Китая - ловушка средних доходов. Для дальнейшего роста Китая ему необходим рост потребления среднего класса (ну и прежде всего его создание), а следствием или причиной этого является создание гражданского общества, которое в свою очередь неизбежно создает политические риски. Собственно поэтому пока не помню случаев в истории, когда государство преодолевало ловушку средних доходов, не избавившись при этом от диктатуры. А именно туда сейчас движется Китай. Так что торможение его экономики в ближайшее десятилетие неизбежно.
Проблема в том, что в Postgres похоже есть явная утечка памяти (во всяком случае при работе с временными таблицами и большом количестве разных сложных запросов). То есть долго существующие соединения при такой схеме постепенно подъедают память, пока не сожрут ее полностью. Это очень хорошо на графиках мониторинга видно (выключаешь перестарт соединений, линия потребления начинает постепенно уходить вниз до нуля, после чего здравствуй своп / oom killer и сервер БД ложится). Видимо поэтому существуют мифы, что Postgres не тянет больше 1к одновременных соединений и вообще без пулинга из очень малого количества соединений не может эффективно работать.
Ну и надо сказать, что при выборе соединений на перестарт используется сложная система скоринга (пытающаяся определить "зажравшиеся" соединения) и один из параметров это время жизни соединения, который все же старается не перестартовывать недолго существующие соединения, чтобы эффективно утилизировать использование их кэшей.
habr.com/ru/company/lsfusion/blog/458376/#rest
Да в структурном программировании композиция проще и понятнее (так как оперирует функциями, а не таблицами), чем join. Но скажем цикл, разбиение или примитивная рекурсия в комбинаторном (SQL) проще.
В любом случае непонятно какое отношении это к ООП имеет. ООП это прежде всего про наследование и полиморфизм (ООП может быть как в структурном, так и в комбинаторном программировании), вы же рассуждаете про то, что SQL оперирует таблицами, а не функциями. Да это создает дополнительную accidental complexity, но опять-таки причем тут ООП?
Теперь бы еще поддержать рекурсии, наследование с полиморфизмом, сессии изменений, события, ограничения, логику представлений, и еще много чего и получится lsFusion.
Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.
АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.
То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).
То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Именно. Причина распространенности такая же как у SAP — «давно тут сидим» ©. Только опять-таки после какого-то уровня (на примере того же SAP) количество разработчиков уже не играет такой роли, а скорее наоборот позволяет дифференцировать себя на рынке (например, не знаю как сейчас, но раньше ABAP разработчики ценились выше 1С, потому как были более редкими).
Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).
А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
Согласен, даже рынок полного custom made никто не отменял.
Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)