Комментарии 33
Не очень понимаю, как в 1С анализируют планы запросов, если поля называются Fld50703_RTRef, а таблицы _InfoRg50689X1 ? Это же крайне неудобно постоянно куда-то лазить, чтобы догадаться, что это за таблица. Что мешало сделать, как в lsFusion, то есть чтобы имена полей и таблиц соответствовали названиям классов и полей в коде ? Да, в 1С все на русском, но могли бы хотя бы просто транслитерацию сделать...
Потому что 1C - это программа для бухгалтеров, в которой код должны были писать бухгалтеры. Кто ж подумал тогда, что разработчикам придется теперь копаться вот в этом всем.
А еще на выручку самой фирмы "1С" это это никак не влияет, поэтому пофиг, так схавают.
Что значит лазить? Это же все есть в метаданных.
Так в этом же и вопрос. То есть, вот вы видите запрос и читаете его EXPLAIN. И как там понимать, что такое _InfoRg50689X1 ? Это товары, контрагенты, документы или что ? Я должен каждый раз лазить куда-то в сторону, чтобы посмотреть, что это за таблица, и что в ней лежит. И также по каждому полю ? Вы это находите удобным ?
полно обработок которые это умеют интерпретировать, елси не можешь найти подходящую сделай свою, к тому же это требуется разово, ты же сидишь постоянно изучаешь планы для каждого запроса который строит 1с
Вот именно, что приходится постоянно изучать планы. У нас на lsFusion есть клиенты, в которых одновременно работают 2.500 тысяч пользователей, таблицы с миллиардами записей и базой в несколько террабайт. И все это на одном обычно двух-процессорном сервере. Там без оптимизации логики запросов не обойтись.
так и в 1с есть оптимизация запросов, и правила их написания, и базы с большим кол-во данных, вот только смысл хранить эти миллиарды в оперативных системах? это все больше архивные данные.
А если пользователь захочет использовать эти данные в ходе оперативной работы ? Например, во время заказа при подборе товаров видеть, сколько заказывалось и продавалось в тот же период прошлого года ? Или просто посмотреть динамику изменения цен по товару за год ? Ему постоянно переключаться между BI и оперативным контуром ?
Инфорег - регистр сведений. Какой конкретно - понятно из контекста анализируемого запроса, написанного на языке 1С. В некоторых случаях требуется посмотреть что это за конкретный объект метаданных, но не очень часто.
Что значит в некоторых случай посмотреть ? Вообще всегда надо смотреть, что это за объекты. Иначе в чем смысл оптимизации ? И смотреть надо не только таблицы, но и поля. Как по Fld384 понять, что это за поле ? Зачем все было так усложнять в 1С, мне не очень понятно. Что мешало сделать нормальные читабельные поля, как во всех в нормальных системах (про SAP промолчу - это тоже то еще ... мамонта).
Потому что в лицензионной политике 1С прямо запрещено лезть в таблицы в базе данных. Вся работа только средствами платформы.
В 90% случаев нет необходимости дополнительно гадать, что за объект, т.к. он известен из контекста анализируемого запроса. Запрос ВСЕГДА известен, он всегда написан на языке 1С и читаем. Плюс есть его трансляция на скуль и есть план выполнения запроса. Поэтому из контекста и известно всё.
Потому что в лицензионной политике 1С прямо запрещено лезть в таблицы в базе данных. Вся работа только средствами платформы.
Мое удивление было в том, почему 1С не сделает нормально. Отвечать на это, что у них такая лицензионная политика - это тоже самое, что "Жрите, что дают". Никаких недостатков подхода как в lsFusion я не вижу. А вот недостатки подхода в 1С - нечитабельный запрос. Зачем делать хуже, если можно сделать лучше. Впрочем у 1С других проблем выше крыши, так что это - это просто одна маленькая из них.
Нормально, это с чьей колокольни? С точки зрения конкурентов?
Позиция 1С понятна. Она вендор, она сказала - работа с конкретной БД - это задача платформы а не программиста. У вас есть инструменты достаточные для выполнения всех возможных задач в рамках процессов решаемых на платформе 1С. Более того, такой подход позволяет гарантировать неприкосновенность и достоверность данных на уровне БД. Что для учетной системы является критически важной задачей.
Позволив кому-то копаться в БД минуя бизнес-логику, значит лишить систему критически важной функции и достоверности.
Разработчику 1С в общем случае НЕНУЖНО читать запрос сервера БД.
Что качается статьи - вы так и не ответили в той теме на один из вопросов.
Зачем системе автоматизации бизнес-процессов нужно, к примеру,
Приведите конкретные примеры, когда эта функциональность нужна при автоматизации бизнес-приложения.
Что качается всего остального, то учетная система реализованная на яве и js, использующая сторонние приложения для базового функционирования платформы, не может являться эталоном.
Подход 1С такой. Система занимает большую часть рынка учетных систем малого и среднего бизнеса. На волне импортозамещения уверенно развивается у сегменте крупного и сверхкрупного бизнеса.
И тут вы, со своей не известной системой, которую пытаетесь продавать вместо 1С, естественно вы будете искать выдуманные и незначительные в предметной области "недостатки" и пытаться на их основании что-то доказать. Но это не так работает.
Разработчику 1С в общем случае НЕНУЖНО читать запрос сервера БД.
Может разработчик 1С сам будет определять, что ему нужно или нет ? Вот, например, автор читает запрос 1С, а Вы говорите, что ему это не нужно.
Приведите конкретные примеры, когда эта функциональность нужна при автоматизации бизнес-приложения.
Вы спрашиваете зачем нужен полиморфизм в бизнес-приложениях ? Да миллион случаев на практике бывает у нас. Например, вы определяете в базовой логике свойство (или функцию, чтобы было понятнее) "цена" (пусть будет управленческая) по sku, складу и дате. Условно, price (Sku, Stock, DATE). Затем используете ее везде в логике (например, при печати ценников, формировании отчетов, подставляете в документы и т.д.). Но вам без разницы, как она рассчитывается.
При этом можно в lsFusion способ ее расчета можно подменить в конкретной логике как угодно (например, брать последнюю из какого-то документа или с учетом акций, ввести дополнительные условия или еще как угодно). Но ничего, что ее использует изменять не придется, а платформа сама перестроит все запросы под новую логику. В этом и есть суть полиморфизма - меняется реализация, но не меняется использование. И так везде.
И тут вы, со своей не известной системой, которую пытаетесь продавать вместо 1С
Никто ничего не продает. lsFusion - бесплатная платформа. Мы зарабатываем деньги на решениях на ее основе, и даем всем остальным желающим делать тоже самое.
Может разработчик 1С сам будет определять, что ему нужно или нет ? Вот, например, автор читает запрос 1С, а Вы говорите, что ему это не нужно.
Я же написал. В общем случае не нужно.
В конкретных случаях расследований нужно. Это конкретные случаи, которые, в большинстве своём, не встречаются. Потому что такие расследования начинают проводить в случаях баз более 100Гб и пользователей одновременно работающих 100 и более. И в крайне редких случаях на более мелких базах. На стандартного разработчика 1С даже уровня мидла может не встретиться такая необходимость ни разу за всю его карьеру. Это уже статистика набранная за ГОДА использования системы.
Цена
Плохой пример. Даже в вашем примере - она опирается на бизнес-логику конкретного места приложения. Что реализуется либо через метод конкретного экземпляра товара, который возвращает цену, либо через метод объекта, где этот товар используется. Не вижу наследования и полиморфизма.
Давайте более реальный кейс по наследованию и полиморфизму.
И также по каждому полю?
Конечно, нет. В обработке "Структура хранения БД" в составе ИР от Tormozit есть конвертёр текста БД. Он переделывает текст запроса SQL со всеми его Fld50703_RTRef и _InfoRg50689X1 в человекочитаемый текст.
Получается вот так
INSERT INTO #tt4 WITH(TABLOCK) (_Q_000_F_000RRef, _Q_000_F_001, _Q_000_F_002, _Q_000_F_003RRef, _Q_000_F_004RRef, _Q_000_F_005RRef, _Q_000_F_006RRef, _Q_000_F_007RRef, _Q_000_F_008, _Q_000_F_009RRef, _Q_000_F_010, _Q_000_F_011, _Q_000_F_012RRef, _Q_000_F_013RRef) SELECT
T1._IDRRef,
T1._Number,
T1._Date_Time,
T1._Fld37387RRef,
T1._Fld37388RRef,
T1._Fld37392RRef...
превращается в
INSERT INTO #tt4 WITH(TABLOCK) (_Q_000_F_000RRef, _Q_000_F_001, _Q_000_F_002, _Q_000_F_003RRef, _Q_000_F_004RRef, _Q_000_F_005RRef, _Q_000_F_006RRef, _Q_000_F_007RRef, _Q_000_F_008, _Q_000_F_009RRef, _Q_000_F_010, _Q_000_F_011, _Q_000_F_012RRef, _Q_000_F_013RRef) SELECT
ЗаявкаНаОказаниеУслуг_T1.Ссылка,
ЗаявкаНаОказаниеУслуг_T1.Номер,
ЗаявкаНаОказаниеУслуг_T1.Дата,
ЗаявкаНаОказаниеУслуг_T1.СкладОтправитель,
ЗаявкаНаОказаниеУслуг_T1.СкладПолучатель,
ЗаявкаНаОказаниеУслуг_T1.Отправитель...
Потому что нет прямой необходимости анализировать планы запросов. Это тонкий тюнинг конкретного запроса, в котором понятно, какие объекты запрашиваются.
Насколько вижу, lsFusion, это браузерное решение на js, что влечет за собой прямую работу с SQL, поэтому разработчикам и необходимо смотреть как реагирует SQL на их действия.
За взаимодействие с сервером БД отвечает сервер приложения 1С.
А решение оптимизатора, описанное тут - неявно нарушает лицензионную политику 1С.
Насколько вижу, lsFusion, это браузерное решение на js, что влечет за собой прямую работу с SQL, поэтому разработчикам и необходимо смотреть как реагирует SQL на их действия.
Принцип работы lsFusion особо не отличается от принципа 1С. Также автоматически генерируются запросы на основе логики, написанной на внутреннем языке. Основная разница в том, что в 1С как раз есть "псевдо-SQL", который транслируется в SQL очень близко, а в lsFusion все запросы генерируются автоматически.
Потому что нет прямой необходимости анализировать планы запросов. Это тонкий тюнинг конкретного запроса, в котором понятно, какие объекты запрашиваются.
А если у вас запрос на 4МБ ? Да и у автора на скрине как раз и есть лог длинных запросов. Как там сходу определить для чего эти запросы, и где они вообще вызываются, если все имена там Fld2983482 ?
Кроме того, вот допустим у вас сформировался запрос с неправильным планом ? Вот что Вы планируете делать в таком случае ? Единственный вариант, как и в lsFusion - это найти конкретное место и что-то поменять. В lsFusion для этого хотя бы есть механизм, который позволяет менять физическую структуру хранения, вообще без изменения логики. Но иногда приходится и логику менять. И все это требует понимания, где именно ошибся планировщик запроса.
Я, как бы, понимаю, вы тут представитель упомянутого решения, усиленно топите за свой продукт. И пытаетесь выйти на рынок РФ, но не очень-то удается...
. Также автоматически генерируются запросы на основе логики, написанной на внутреннем языке. Основная разница в том, что в 1С как раз есть "псевдо-SQL", который транслируется в SQL очень близко, а в lsFusion все запросы генерируются автоматически.
Вот именно в этом и ключевая разница в подходе, зачем нужно понимание плана запроса у вас и почему его не требуется в 1С в обычном режиме работы. В общем случае ваш разработчик не знает, какой запрос будет сформирован. В 1С есть понимание, какой запрос будет исполняться, более того, есть достаточно широкий опыт и рекомендации сообщества и вендора как строить эффективные запросы. Опять же, сама платформа 1С позволяет конкретизировать и запрос на языке и запрос на sql и получить план выполнения конкретного запроса. Нативно, без использования даже средств sql.
А если у вас запрос на 4МБ ? Да и у автора на скрине как раз и есть лог длинных запросов. Как там сходу определить для чего эти запросы, и где они вообще вызываются, если все имена там Fld2983482 ?
Пример автора - это узкий круг запросов, возникающий в определённые моменты развития системы, когда размер базы достигает уже сотни гигабайт. Приведённый пример автором - это решение вендора из коробки, причём встречающийся в крайне редких случаях, и там да, бывают косяки производительности. Понимание где вызываются - есть и прямое, вплоть до точки в коде. В редких случаях, когда такие запросы вызываются неявно, платформа позволяет это отследить и найти конкретную строку. Опять же, сам текст запроса прозрачен и читается разработчиком, т.к. он ТРАНСЛИРУЕТСЯ а не ГЕНЕРИРУЕТСЯ.
Кроме того, вот допустим у вас сформировался запрос с неправильным планом ? Вот что Вы планируете делать в таком случае ? Единственный вариант, как и в lsFusion - это найти конкретное место и что-то поменять. В lsFusion для этого хотя бы есть механизм, который позволяет менять физическую структуру хранения, вообще без изменения логики. Но иногда приходится и логику менять. И все это требует понимания, где именно ошибся планировщик запроса.
Когда запрос сформировался с неправильным планом - это всегда известная точка. Платформа содержит встроенные средства замера производительности. Мы точно знаем какая строка кода, какой вызванный запрос работает медленно. Мы всегда знаем, как платформа построила таблицы данных, где какие индексы используются, более того, в большинстве случаем можем явно влиять на создание дополнительных индексов. Мы всегда можем оптимизировать сам запрос, т.к. он прописан явно и продвинутый программист всегда знает, какие места могут вызвать тормоза при выполнении.
----
В отношении же самой статьи - рекламная статья решения, которое неявно нарушает лицензионную политику 1С. Автор сознательно не показывает место и текст запроса на языке 1С, который приводит к генерации такого огромного запроса. Так же не слова не сказано о размере базы, и прочих параметрах, необходимых для понимания когда такие запросы генерируются.
Я, как бы, понимаю, вы тут представитель упомянутого решения, усиленно топите за свой продукт. И пытаетесь выйти на рынок РФ, но не очень-то удается...
По моему профилю это нетрудно догадаться. Не пытаемся выйти, а уже давно вышли. Насчет удается или нет - не жалуемся. Уже любое упоминание о lsFusion тут же удаляется на том же infostart'е. Боятся... :)
В 1С есть понимание, какой запрос будет исполняться, более того, есть достаточно широкий опыт и рекомендации сообщества и вендора как строить эффективные запросы.
Что значит понимание ? Понимание как будет формироваться запрос есть везде и в 1С и в Hibernate, и в lsFusion. Но это не отменяет того факта, что СУБД может легко ошибиться с планом, и надо найти где, и потом как-то переделать логику или запрос, чтобы СУБД больше не ошибалось.
Мы всегда можем оптимизировать сам запрос, т.к. он прописан явно и продвинутый программист всегда знает, какие места могут вызвать тормоза при выполнении.
Ну так для того, чтобы оптимизировать запрос, то нужно определить где именно ошибка в плане. Для этого нужно читать план, а когда у вас там будет Fld526, то каждый раз смотреть, а что это именно было в исходном запросе (если запрос большой) скажем прямо не очень удобно.
Опять же, сам текст запроса прозрачен и читается разработчиком, т.к. он ТРАНСЛИРУЕТСЯ а не ГЕНЕРИРУЕТСЯ.
Кстати, это показывает качество платформы 1С, что там приходится фактически самому вручную писать запросы SQL. lsFusion значительно более высокоуровневая платформа, так как там запросы именно генерируются, и разработчику не надо этим заниматься.
В отношении же самой статьи - рекламная статья решения, которое неявно нарушает лицензионную политику 1С.
Вот это моя любимая часть 1С. А еще по лицензии, насколько я помню, запрещено напрямую обращаться с запросами к БД. Я б уже не стал использовать 1С с такими условиями лицензирования, так как это просто неуважение к разработчикам.
Уже любое упоминание о lsFusion тут же удаляется на том же infostart'е. Боятся... :)
Инфостарт - сообщество разработчиков 1С, принадлежащее 1С. Удивительно что удаляют, да?
Никак к разработчикам 1С не относятся, а ещё удивляются, что их с ресурса 1С удаляют.
Что касается выхода на рынок - гугл знает только об одном проекте, что как бы, говорит...
Что значит понимание ? Понимание как будет формироваться запрос есть везде и в 1С и в Hibernate, и в lsFusion. Но это не отменяет того факта, что СУБД может легко ошибиться с планом, и надо найти где, и потом как-то переделать логику или запрос, чтобы СУБД больше не ошибалось.
Это значит что мы знаем текст исходного запроса. Мы знаем как он будет выполняться. План запроса покажет - где мы ошиблись в наложении условий и ограничении выборки и начинаются неоптимальные использования индексов. Возможно возникают лишние соединения. В этом случае нет необходимости знать какое поле за что отвечает. Отсюда возникает понимает как перестроить запрос для ускорения.
У нас есть возможность выполнить запрос частично без необходимости анализировать запрос на пару мегабайт.
Кстати, это показывает качество платформы 1С, что там приходится фактически самому вручную писать запросы SQL. lsFusion значительно более высокоуровневая платформа, так как там запросы именно генерируются, и разработчику не надо этим заниматься.
Это говорит о гибкости а не качестве. Если бы ваша платформа была качественная, вам бы не приходилось смотреть план запроса и анализировать, какое поле и как повлияло на запрос. Более того, для разбора вопросов производительности вам приходится обращаться в серверу БД для извлечения исполняемого текста запроса. Подход 1С гарантирует что в 90% случаев запрос будет исполнен именно тот, который написал программист. Причём, в 80% случаев запрос составляет визуальным конструктором а не пишется ручками. И именно поэтому при анализе плана запросов нет необходимости точно знать наименования всех таблиц и полей. Исходя из исходного запроса уже понятно где и что и почему происходит. Для опытных спецов, конечно.
Вот это моя любимая часть 1С. А еще по лицензии, насколько я помню, запрещено напрямую обращаться с запросами к БД. Я б уже не стал использовать 1С с такими условиями лицензирования, так как это просто неуважение к разработчикам.
1С является монолитной платформой для учетных систем. Одна из основных задач таких систем - гарантировать целостность данных. Позволив кому-то стороннему напрямую трогать данные в БД - потерять гарантию в целостности. Нормальная учетная система содержит 10-ки и 100-ни объектов метаданных со сложными взаимосвязями между собой. Любой кривой запрос insert или update - прощай данные. Именно поэтому и запрещается прямо лезть в базу. Платформа имеет достаточно средств для взаимодействия с внешними системами.
Позволив кому-то стороннему напрямую трогать данные в БД - потерять гарантию в целостности.
Речь не о записи, а о чтении. Например, надо выгрузить в BI большие объемы данных. Проще всего это сделать прямым SQL запросом к БД. Там уже все оптимизировано под это. Или надо гнать все через сервер приложений ? А если там миллионы записей, как обычно бывает в случае с BI ?
Каким образом вы ограничите адекватно запросы в сервер БД только чтением? Учтём что у пользователя, под которым работает исходное приложение есть полный доступ и данные этого пользователя есть у разработчика. Практика показывает что в этом случае разработчик ВСЕГДА напрямую лезет в данные.
1С через обезличивание таблиц даёт базовую защиту.
Да, гнать через сервер приложений. Потому что логика система далеко не такая, как она лежит в таблицах БД. И какие-то данные можно отдать только после преобразования сервером БД.
Каким образом вы ограничите адекватно запросы в сервер БД только чтением?
Средствами СУБД создать пользователя, которому дать права только на чтение. Мы так миллион раз делали.
Учтём что у пользователя, под которым работает исходное приложение есть полный доступ и данные этого пользователя есть у разработчика.
Не путайте разработчика приложения и разработчика внешнего (BI системы, например). Разработчик приложения и без доступа к БД сможет все поломать. А разработчик BI со своими правами ничего не сделает.
Да, гнать через сервер приложений. Потому что логика система далеко не такая, как она лежит в таблицах БД. И какие-то данные можно отдать только после преобразования сервером БД.
Ну только это создаст охрененный оверхед как по памяти, так и по CPU. И с большой вероятностью еще может и не пролезть, если будет большой блок. За этим придется постоянно следить.
Средствами СУБД создать пользователя, которому дать права только на чтение. Мы так миллион раз делали.
Прям миллион? Насколько я понимаю, количество внедрений где требуется BI у вас меньше сотни, и, как бы, не меньше десятки...
Не путайте разработчика приложения и разработчика внешнего
А если это BI, а если возникает желание в базу данные загрузить из внешней системы? Мы же не смотрим узко, мы же в бизнесе. Хотим заказы из интернет-магазина складывать, что мешает напрямую в базу пихать?
Ну только это создаст охрененный оверхед как по памяти, так и по CPU. И с большой вероятностью еще может и не пролезть, если будет большой блок. За этим придется постоянно следить.
Не создаст. Если правильно реализовывать. И пролезет.
А вот когда BI лезет своими запросами, насколько оптимальными?, с выборкой на миллионы записей, она весело так подвешивает систему и не даёт нормально работать полноценным пользователям системы.
имена метаданных могут меняться, а имена таблиц - нет!
А зачем менять имена метаданных ? Можно какой-нибудь практический кейс ? То есть, например в lsFusion, изменилось у вас имя таблицы или "поля" - просто делается ALTER ... RENAME
Просто потому что "Захотелось", либо слегка поменялась логика обработки конкретных данных. И для удобства чтения и обработки данных меняется наименование поля.
В этом случае нет смысла трогать таблицу от слова совсем.
Судя по тому (статьи, комментарии от представителей), что читал на Хабре, isFusion очень токсичная компания. Всё что читал, выглядит голословным, без конкретики. "Ааа как такое можно писать", приводится запрос в 1С, "да если бы я сказал своим так писать, то мне покрутили бы пальцем у виска". Без альтернативных примеров и пр "как надо".
Было бы интересно посмотреть на "to-do" (1С vs isFusion), например программа для библиотеки. С видео, скоростью разработки и пр..
Мне не нравится 1С и стараюсь не связываться с этой платформой. Но как бы она мне не нравилась, по скорости разработки бизнес приложений, ничего лучше не видел (с некоторыми оговорками). Считаю, что она хороша для мелкого, в лучшем случае для среднего бизнеса и желательно не типовые конфигурации.
Судя по тому (статьи, комментарии от представителей), что читал на Хабре, isFusion очень токсичная компания. Всё что читал, выглядит голословным, без конкретики.
Во-первых lsFusion - это не компания, а просто open-source продукт. Open-source продукт - токсичный, а 1С со своим запретом на обращение извне к БД - нет. Ну ок. Примеров там масса и в каждой статье есть.
"Ааа как такое можно писать", приводится запрос в 1С, "да если бы я сказал своим так писать, то мне покрутили бы пальцем у виска".
Это стандартная реакция современного программиста с современным стэком разработки, который увидел 1С.
Было бы интересно посмотреть на "to-do" (1С vs isFusion), например программа для библиотеки. С видео, скоростью разработки и пр..
В документации есть много how-to, а также два простых законченных приложения. Плюс есть даже видео с тем, как идет процесс разработки.
Но как бы она мне не нравилась, по скорости разработки бизнес приложений, ничего лучше не видел (с некоторыми оговорками). Считаю, что она хороша для мелкого, в лучшем случае для среднего бизнеса и желательно не типовые конфигурации.
Да, на 1С писать значительно быстрее, чем на классических средствах разработки. Но lsFusion значительно более высокоуровневая платформа и на ней писать еще быстрее именно сложные приложения. А для простых CRUD большинство современенных nocode/lowcode платформ подходят лучше, чем на 1С.
Вы в каждой статье про 1с будете lsfusion упоминать, да?
Записки оптимизатора 1С (часть 5). Ускорение RLS-запросов в 1С системах