Comments 75
Спасибо за действительно интересную статью, коллеги!
Всегда пожалуйста!
Петр, планируется ли в ближайшее время расширение списка поддерживаемых СУБД?
В ближайшее время - насколько знаю, таких планов нет.
По моей личной статистике - бльше всего пока запросов на поддержку MySQL.
Но моя личная статистика не влияет на планы развития платформы :)
Вот тут ниже в каментах просят например Firebird, меня про него ранее никогда не справшивали.
Как говорится - следите за новостями!
Публичные планы мы размещаем на Зазеркалье.
Вот например предварительный план на версию 8.3.26
Спасибо, очень познавательно про подробности работы 1С с разными СУБД.
Давно не следил за новыми версиями 1С, но не удержусь не спросить.
Появился ли в оптимизаторе Predicate Push Down? Потому как в PostgreSQL он до сих пор не появился и не совсем понятно нужно ли разработчику когда он пишет запрос проталкивать условие запроса внутрь подзапроса.
Встроили ли запросы в язык? Для resolve'инга, подсветки ошибок, синтаксиса и вот этого всего.
Поддержка оконных функций и рекурсивных CTE в запросах для работы с порядками и рекурсиями (без них делать скажем упорядочивание редкий ад)? И опять-таки поддерживается ли там predicate push down.
Появились ли DML запросы? Или какой-то другой механизм для группового изменения данных?
Появилась ли нормальная поддержка версионного режима, в смысле корректный прозрачный откат и перестарт транзакции, чтобы не заниматься ручными блокировками ?
Возможность разработчику изменять самому физическую модель, материализовать показатели и т.п.?
Поддержка наследования и полиморфизма в запросах?
Много вопросов!
Отвечать буду по частям :)
>"4. Появились ли DML запросы? Или какой-то другой механизм для группового изменения данных?"
Не появились, и это на данный момент наша принципиальная позиция.
А чем эта позиция обусловлена? В том плане, что проблема N+1 есть же не только при чтении, но и при записи? Не говоря уже о том, что при использовании механизма "триггеров" (событий) проблема N+1 по сути переносится с записи назад на чтение (когда цепочка триггеров может порождать цепочку запросов на чтение, если в этих триггерах есть бизнес-логика).
То есть проблема техническая или логическая? Потому как с логической точки зрения всякие огромные документы инвентаризации, генерации дисконтных карт никто же не отменял.
Технической или логической проблемы я тут не вижу.
Мы не реализуем механизм для группового изменения данных потому, что это "Веревка достаточной длины, чтобы… выстрелить себе в ногу".
Коротко говоря - слишком мощный механизм при достаточно слабом его контроле. Можно будет, например, одной командой случайно удалить все заказы в системе. Что не очень хорошо.
>"всякие огромные документы инвентаризации "
Документ целиком как раз поменять/удалить можно.
А вот набор документов одной командой - нет.
Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью). И со слабым контролем непонятно, так как как раз именно при групповом изменении обычно все идет одной транзакцией и она скорее всего тупо не успеет закончится (до того как ее снимут), так как обычно нужно много логики пересчитать / проверить, да и блокировок будет много (ну или update conflict'ов в версионном режиме).
Документ целиком как раз поменять/удалить можно.
Ну вот это как раз и странно. В тех же типовых со строками документа работа идет через времянки, то есть запросами (для производительности), а с другими объектами такой возможности нет (хотя справочник штука абстрактная, и может быть очень большим, больше чем строк в документах).
>"Ну у вас с платформой то разработчики работают, а не пользователи. Они если надо в for'е себе в ногу выстрелят (даже с большей легкостью)."
Тут не могу с вами согласиться исходя из личного опыта.
"DELETE FROM ..." написать гораздо проще и быстрее, особенно в консоли запросов (и случайно нажать шорткат для "выполнить" и потом кусать локти), чем в коде написать в for'е, а код потом надо ещё и запустить на исполнение - тут у программиста больше времени остается на "одуматься".
Да, забыл самое важное! Настолько давно и глубоко встроенное в платформу, что про это со временем даже забываешь.
Существенная часть механизмов платформы завязано на объектную технику и контроль над изменениями:
обработчики
обмен данными (регистрация изменений) - для построения распределенных баз
журналирование
хранимые итоги
... и другое
Если будут DML операторы в запросах - всё вышеперечисленное работать не будет, чтобы работало - потребуются ОЧЕНЬ серьезные изменения в платформе. Навскидку - перенос большой части кода в триггеры на уровне СУБД, код триггеров тесно будет привязан к диалекту SQL конкретной СУБД, про кросс-платформенность придется позабыть и т.д. и т.п.
Это я понимаю. Просто ирония, что скажем в типовых работа с документами часто специально делается через времянки, именно чтобы избежать N+1 и бомбардировки сервера одиночными запросами. А при этом существенная часть механизмов все еще завязана на объектную технику.
То есть у вас как будто разработчики типовых борются с разработчиками платформы :) Последние топят за ORM и не хотят уходить от него уходить, а первые, я так понимаю для производительности, наоборот пытаются уйти максимально все делая запросами.
Вот записать пустой набор без отбора в регистре сведений [и очистить его этим в ноль] можно, а массово заменить контрагента Пупкина на Дупкина нет. И это грустно (обе причем ситуации)
>"7. Поддержка наследования и полиморфизма в запросах?"
Если мы про язык запросов - в нем поддерживается ровно столько же наследования и полиморфизма, сколько поддерживается в языке SQL.
Возможно, я не понял ваш вопрос - можете пояснить на примерах?
Я имел ввиду, что можно задать класс скажем ДокументРасхода. Дальше наследовать скажем ДокументСписания от ДокументРасхода, ДокументПродажи от ДокументРасхода, после чего делать скажем SELECT SUM(что-то там) FROM ДокументРасхода GROUP BY что-то там, и платформа сама построит запрос с UNION'ами всякими и т.п. Наследование таблиц называется в некоторых СУБД (хотя там скажем прямо не настолько удобная вещь по ряду причин).
>"5. Появилась ли нормальная поддержка версионного режима, в смысле корректный прозрачный откат и перестарт транзакции, чтобы не заниматься ручными блокировками ?"
"Нормальная" - это от слова "норма".
Можете пожалуйста пояснить (лучше на конкретном примере), что вы считаете нормой для поддержки версионного режима?
Смотрите.
Как можно автоматически обеспечить целостность.
Первый вариант - блокировать все читаемые данные (в 1С как я понимаю это называются автоматические блокировки). Вариант с одной стороны хороший, но не масштабируемый. Какая нибудь долгая операция записи может ввести базу в клинч (чтение тоже, но это частично можно решить переведя такие операции в версионный режим, в MS SQL есть такой мутант)
Второй вариант - мультиверсионность. Хранить версии записей, читать записи на момент начала транзакции, а при выполнении UPDATE (и COMMIT) следить за версиями записей и если версия устарела - кидать UPDATE CONFLICT (в случае UPDATE, или ошибку сериализации в случае COMMIT). После чего клиент (сервер приложений) должен повторить транзакцию заново (желательно пользователя при этом не уведомлять, так как это техническая фишка). Там могут быть нюансы обеспечения целостности нематериализованных данных в определенных случаях (хотя даже Postgres заявляет что поддерживает true serializable и эту проблему решают), но для решения их достаточно просто иметь прозрачные механизмы материализации.
Собственно второй вариант сейчас по сути в мире считается "золотым стандартом" обеспечения целостности и масштабируемости одновременно. Перекладывать же эту задачу на разработчика это конечно жестоко по отношению к нему.
>"6. Возможность разработчику изменять самому физическую модель, материализовать показатели и т.п.?"
Боюсь что не понял вопроса.
"изменять самому физическую модель, материализовать показатели" - это как?
Можете пояснить на примерах пожалуйста?
Ну напримере как я выше кидал. Например если я не хочу UNION'а хочу чтобы была одна таблица, сказать для ДокументРасхода вот эти вот поля храни в такой-то таблице (желательно чтобы можно было задать имена, чтобы потом можно было подключаться напрямую к базе и читать данные из этих таблиц, хотя это скорее бонус).
То, что вы описали, напоминает мне функкциональность VIEW.
Это оно или я ошибаюсь?
И - такой функциональности у нас пока нет.
Складывается впечатление, что то о чем Вы говорите реализовано во встроенном языке/модели. Абстрактные классы - Определямый тип, что в свою очередь тоже самое, что и составной тип. При запросе к свойству экземпляра (к реквизиту через разыменовывание полей через точку) SDBL сам превратит всё в JOIN-ы ко всем таблицами, в которых может храниться. Если не хочется JOIN ко всем таблицам, то можно сделать предварительный CAST встроенным языком запросов. Такой вот Workaround.
А если очень хочется хранить что-то из свойств в отдельной таблице (для ускорения чтения/записи), то платформа позволяет сделать "Регистр сведений" (но придется немного описать логику записи в эту отдельную таблицу), который можно связать по "типизированому" UUID с основной таблицей.
>"2. Встроили ли запросы в язык? Для resolve'инга, подсветки ошибок, синтаксиса и вот этого всего."
Можно сказать что да - в среде разработки 1C:Enterprise Development Tools для этого много сделано.
То есть вы оставили в строковых литералах и сделали что-то типа language injection в IDEA? Круто конечно, только я не понимаю как это может теоретически работать в императивном коде, где запрос может склеиваться в зависимости от услови, скажем, и заведомо не знаешь в данном литерале весь запрос или его кусок (тогда что ошибка светится?). То есть не встраивая синтаксис запросов в язык, как .NET (C#) это сделал с LINQ, не совсем понятно как это все можно парсить / анализировать.
Короткий ответ "никак". Более длинный - запросы в 1С далеко не всегда клеят из частей. 70-80% запросов это цельные литералы. Разумеется, есть и сборка запросов конкатенацией, тогда каких-то прекрасных подсказок не будет.
>"1. Появился ли в оптимизаторе Predicate Push Down?"
Такого пока нет.
>"3. Поддержка оконных функций и рекурсивных CTE в запросах для работы с порядками и рекурсиями "
Такого пока нет, но запросы на эту функциональность есть.
Возьмемся реализовывать - напишем на Зазеркалье с указанием планируемой версии платформы.
Я не очень понял. То есть при каждом формировании запроса, вы собираете строки по определенной грамматике (SDBL), а потом на каком-то уровне обратно разбираете из строк во внутренние структуры, а затем назад собираете уже в SQL нужного синтаксиса ? Нет ли при этом большого overhead'а (все-таки это частая операция) ? И зачем для этого была целая грамматика вместо использования просто какой-то внутренней структуры (классов) без языка ?
При выполнении запроса, написанного на встроенном языке, в общем случае запрос парсится 3 раза:
Исходный запрос из конфигурации
Запрос SDBL
Запрос SQL (движком СУБД)
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и усилия разработчиков на их написание - или программное построение. Запросы бывают весьма сложные. Поэтому и было принято решение о текстовых запросах. Единственным исключением является участие в запросах длинных двоичных данных, для задания которых используется параметр в тексте запроса и отдельное двоичное значение с данными.
Парсинг запросов: Язык запросов - SDBL - SQL привносит дополнительные затраты, но они не значительны. С другой стороны, формулирование запросов в виде текста, а не в виде двоичных данных сложной структуры, значительно экономит время процессора и услилия разработчиков на их написание - или программное построение
По-моему, это противоречивые утверждения.
И не очень понимаю про усилия разработчиков по их написанию. Речь идет о разработчиках платформы (ведь только они работают с SDBL) ? Если так, то они с точки зрения архитектуры же не со строками работают же (хотя конечно можно все replace'ами делать, но это странно). Например, у вас там есть класс SDBLCommand. Чем удобнее делать cmd.append("WHERE ..."), чем cmd.addWhere(...), cmd.addColumn(...) ? Причем передавать туда не строки, а уже ссылки на конкретные объекты, отвечающие за колонки, и т.д...
Всегда было интересно, почему не реализовали поддержку Firebird SQL? Интересная же СУБД. И журнал регистрации на ней же существенно интереснее SQLite смотрится. Есть emedded- варианты, есть полноценные клиент-серверные, ЖР вообще можно в таком случае на другой сервер вынести с минимальными затратами.
>"почему не реализовали поддержку Firebird SQL? "
В смысле - как "рабочей" СУБД где хранятся бизнес-данные?
Наряду с MS SQL, PostgreSQL, Oracle и IBM DB2 ?
Да, как рабочей СУБД для бизнес-данных. Понятно, что у Firebird прошлых версий были достаточно существенные ограничения по реструктуризации объектов базы, это могло быть для вас существенным ограничивающим фактором - если я правильно помню, до 256 раз (1 байтовый счётчик) можно было изменять структуру таблицы, до сброса счётчиков. Но насколько мне известно, у последних версий Firebird эти ограничения уже существенно расширены, не должны уже быть препятствием.
По нашей информации - Firebird в бизнесе используется не так часто, как MS SQL или PostgreSQL например. А поддержка ещё одной СУБД - это серьезные расходы на разработку, тестирование и поддержку.
Я бы не согласился с таким утверждением. Вы же понимаете, что определяющим фактором является широкое использование 1С в бизнесе. Раз уже есть 1С и к ней уже прилагается [относительно честно] купленный MS SQL Server - почему бы и не использовать эту РСУБД и в других бизнес-приложениях. Я даже предположу, что Firebird мог бы поспорить по количеству установок с MS SQL, если бы поддерживался платформой 1С. Он свободный, кроссплатформенный, лёгкий, проще в обслуживании, мощный и к тому же - чистопородный версионник.
В бизнесе я часто с ним сталкивался - достаточно широко используется в отраслевых бизнес-приложения, не говоря уж о том, что я сам разработал на заказ более десятка приложений на основе Firebird.
Ну видите - у каждого свой опыт и своя статистика использования БД.
Я в частности работаю со сбором пожеланий по развитию платформы - пока не встречал запросов по поддержке Firebird (хотя сам лично с ней когда-то работал, когда она называлась Interbase).
Кстати о пожеланиях по развитию платформы - мы их собираем в Телеграме, каждую пятницу собранные тут предложения приезжают ко мне и после уточнения деталей помещаются в нашу базу.
Верно, ранее называлась Interbase. Но с тех пор многое изменилось и эта СУБД не только получила новое имя Firebird, но и сильно выросла.
А можете записать здесь пожелание добавить поддержку Firebird ? Ну, например, в качестве БД для журнала регистрации хотя бы ? Существует embedded-вариант Firebird в виде обычной DLL, но в ней реализован полноценный сервер, только интегрированный в процесс приложения. При возможности указывать путь к файлу базы ЖР легко и тривиально переносится на клиент-серверный вариант Firebird на другом хосте - всего лишь добавлением имени хоста в путь к БД журнала.
А там глядишь, и оцените возможности добавить Firebird в список БД для бизнес-данных :-)
А расскажите в таком же ключе о плане видов характеристик, пожалуйста?
В случае платформы 1С:Предприятие использовать классический ORM не получится, т.к. ORM компилируется вместе с исходным кодом приложения, разработка же конфигураций идет на встроенном языке 1С.
Очень "правильный" ответ! А если это ваш собственный язык. то что мешает вам в него интегрировать свою же версию ORM? Зачем городить ещё одну дополнительную сущность в программах, которую надо программистам-прикладникам изучать (ну это ладно!) и поддерживать (а это плохо, ибо специфические надстройки это значит специфический специалист по ним, а для бизнеса это опасно)?
Я не настоящий программист, но разве объектная модель работы с данными (Справочники.Справочник.СоздатьЭлемент()) — это не ORM?
>"Зачем городить ещё одну дополнительную сущность в программах "
А что вы в данном случае называете дополнительной сущностью?
Дополнительную прослойку запросов к БД. Почему нельзя делать это сразу из скриптов 1С?
Если я вас правильно понял - вы предлагаете писать SQL-запросы непосредственно в коде 1С?
Поправьте меня если ошибаюсь.
Именно. По крайней мере, иметь такую возможность для тех, кто разбирается в том, как это делается грамотно. Я не сомневаюсь в компетенциях ваших специалистов, но то, что у вас между запросом пользователя и конечным запросом к БД несколько ступеней, скорее всего делает вашу схему во первых более уязвимой к ошибкам на любом из этапов, во вторых - однозначно менее гибкой, так как выходит, что изначальный запрос это априори более маленькое подмножество от изначальных возможностей стандарта SQL, не говоря уже об особых нюансах в каждой из реализаций конкретных СУБД
Недостатки - это продолжение достоинств (с).
Наличие прослойки в виде SDBL делает механизм менее гибким, согласен.
Но зато позволяет, в частности:
- Накладывать на запрос условия RLS (Row-Level Security)
- Оптимизировать запросы на уровне платформы (один из примеров оптимизации описан в статье)
- Адаптировать запрос для диалекта SQL конкретной СУБД (как опять же описано в статье)
Стандарт SQL - его даже флагманы индустрии СУБД поддерживают очень по разному - и в синтаксисе, и в реализации. Что-то сложнее "SELECT * FROM ..." уже начинает сильно разниться на MS SQL и Oracle например.
Ещё раз, уточню. Вопрос не в том, что ваш инструмент плох. А в том, что вы не оставляете альтернатив, кроме его использования. Работа с данными предусматривает много разных сценариев, и может быть вы конечно предусмотрели в своей прослойки основные типовые, но далеко не факт, что не найдётся то, что вашим скриптовым языком не решается, а из альтернатив останется писание в админке СУБД своих запросов, с последующим придумыванием как это всё потом импортировать обратно в 1С
А в том, что вы не оставляете альтернатив, кроме его использования.
писание в админке СУБД своих запросов, с последующим придумыванием как это всё потом импортировать обратно в 1С
в лиц.соглашении еще есть прямой запрет на работу с базой в обход штатных средств платформы
Понимаю вас.
Принимая такое архитектурное решение, мы взвесили все "за" и "против", посмотрели на аналогичные продукты а рынке и на архитектурные решения, принятые в них.
Из своего личного опыта разработки (до-1Сного) скажу, что наличие прямых SQL-запросов в коде прикладного решения влечет за собой массу проблем (в частности, с производительностью) даже при переезде с одной версии СУБД на другую. И централизованно эти проблемы решить бывает очень накладно, т.к. их нужно решать в куче мест в прикладном коде. Приходится делать одно "бутылочное горлышко", через которое прикладной код обращается к СУБД, и пытаться оптимизировать запросы в этом "бутылочном горлышке". Ну а отсюда уже один шаг до SDBL.
ну вот кстати по поводу переезда между СУБД
Уже много много лет существует негласное мнение что 1С нормально работает только на MSSQL, на постгри с определенными приседаниями, а смельчаков которые решаются запускать это всё на оракле или db2 так вообще единицы и у них это получается так себе
причем проблемы с совместимостью БД были еще и до восьмерки, в 7.7 были совершенно однозначные различия между файловой и sql версиями, хотя платформа "какбы" должна была скрывать такое
ну и вот сейчас 23 год, а я до сих пор слышу настоятельные рекомендации юзать mssql, несмотря на то что постгри уже достаточно стабильна в поддержке
У PostgreSQL как минимум: нет predicate push down, очень ограниченная работа с cross-column статистикой и "утечки" памяти при активном использовании временных таблиц / сложных запросов (возможно это не утечки, а просто очень большой memory footprint, но сути дела это не меняет). Все это требует достаточно много оптимизаторов со стороны платформы (тем самым выполняя работу СУБД), чтобы сложное решение на нормальных объемах нормально работало на PostgreSQL.
Хотя конечно если у вас решение или очень простое или в нем мало данных (то есть грубо говоря < 100k активно используемых записей в таблице) или сделано императивно спагетти-кодом то может и на PostgreSQL взлететь. Но "стабильность в поддержке" тут не при чем.
Вот тут немного подробней описано: https://habr.com/ru/companies/lsfusion/articles/463095
Это для PeterG скорее. вы лишь подтверждаете мои слова что "универсальность" на самом деле неуниверсальная
Если руками делать predicate push down'ы как это делается в типовых:
ВЫБРАТЬ
РасходнаяНакладнаяСостав.Номенклатура,
УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
РасходнаяНакладнаяСостав.Ссылка = &Документ И
(УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL)и другие оптимизации, то да PostgreSQL будет работать. Просто отзывы в данном случае - средняя температура по больнице. То есть если разработчики (или "доработчики") не будут делать такие оптимизации, то под MS SQL все будет работать хорошо, а под PostgreSQL ляжет. И наоборот, если делать, то PostgreSQL будет даже лучше работать (так как в плане оптимизации сложных запросов он, скажем прямо, туповат, зато время планирования и выполнения у него отличное, как у автомата калашникова условно).
Вы знаете, вот чем больше в последнее время занимаюсь вынужденно вопросами отечественного ПО прикладного порядка, тем больше прихожу к выводу, что наши крупные разработчики просто забили огромный болт, и считают что всё знают заранее лучше конечных пользователей своих продуктов. Никто и не говорит о том, что риски есть, проблема начинается тогда, когда без рисков этих выкрутиться не получается. Вот тогда и плодятся горе программисты, которые вместо основного разработчика начинают на местах делать костыли, раз уж нет штатных методов решения в самом ПО! Вы мне напоминаете всемирно известную компанию из Купертино, в продуктах которой вообще ничего нельзя, чего бы не разрешил "святой" Стив
Спасибо за статью, хотелось бы отметить что отсутствие возможности выполнять операции по записи по списку объектов очень ограничивают применимость платформы для заказчиков с большими объемами и приводит к запросам на запись в цикле.
>"приводит к запросам на запись в цикле. "
Согласен.
Пока это наша принципиальная позиция, почему - объяснил в комментарии выше про DML-запросы.
Например, мы хотим установить прикладному объекту новый код. Для этого в коде платформы формируется текст SDBL-запроса для поиска максимального существующего кода. Затем выполняется запуск этого запроса, который исполняется уже на конкретной СУБД:
[картинка]
А вот как установка нового кода работает на разных СУБД:
Синтаксис самого SQL – стандартный, но в случае каждой СУБД есть нюансы, и чем запрос сложнее – тем их больше.
Вот здесь не понял картинки. Если нужно установить новый код, то делается select max(code) из таблицы? Что там с изолированностью транзакций? Почему не используются последовательности?
Пример получения нового кода сознаетльно описан нами упрощенно.
Функциональность автонумерации описана здесь (но нужен доступ на ИТС).
Когда читаешь про 1С, всё круто. А как только установишь ERP и начнешь работать, обязательно вылезет один из тысячи багов.
А какие планы по облегчению работы с большими базами? Шардинг, партицирование?
В 8.3.23 появилась сегментация данных.
Т.е. возможность размещать данные на разных дисках.
А как это заменяет шардинг или партицирование?
Мы и раньше могли в tablespace на уровне субд сделать несколько файлов и большая таблица по экстентам "распределится" между файлами. Но truncate для удаления архивных данных - будет для всей таблицы а не для партиции.
В части сегментации данных (tablespace файловые группы) достаточно если бы 1с запоминала настройки субд при реструкторизации. Иначе все уедет обратно в default tablespace. A управление хранением отдать админам - там много параметров которые платформа знать не будет
А как это заменяет шардинг или партицирование?
Никак - но это то, что в ближайшее время может облегчить работу с большими БД.
1С будет запоминать настройки субд при реструкторизации.
Все новости по нашим планам мы публикуем здесь.
Как мы в 1С работаем с различными СУБД, не привлекая внимания санитаров (зачеркнуто) разработчиков