На клиентской стороне находится довольно много логики связанной и с подбором ссылочных полей по распознанному тексту, и с отобржаением документа, с подсветкой полей, откуда вязта информация, с расчетом контрольных сумм и так далее. Подсистема довольно большая и просто API тут будет недостаточно для использования сервиса.
Да,видно в прикладных решениях, баланс отображается на форме, предназначенной для работы с распознанными документами. На портале ИТС эта информация тоже имеется.
Да, отдельный модуль, но там довольно тесная степень интеграции с прикладным решением по части справочников, создаваемых документов и так далее. Пока она встроена в 1С: Бухгалтерию и 1С:ERP и 1С:УТ, в облачную УНФ. Полный список поддерживаемых конфиграций https://ocr.1c.ai/easystart/
Поиск соответсвия распознанного текста и элементов справочника происходит на стороне клиента, в прикладном решении. Реализован вариант нечеткого поиска, который позволяет подобрать наиболее "похожие" товарные позиции из тех, которые есть в базе пользователя. Если таких нет(или уверенность слишком мала) пользователю предлагается создать новую позицию на основе распознанного текста.
Мы планируем ещё одну статью по этой тематике - уже с деталями (алгоритмы, фильтры по данным и структура федеративных и агрегирующих узлов (адаптация с высокой нагрузке)). В эту сатью детали решили не вставлять чтобы не перегрузить читателей.
И дело не только в DSL - просто проекты действительно бывают очень большие.
Понятие "бизнес-проекта" сейчас для 1С достаточно большое - так как сейчас на 1С существуют очень крупные проекты.
Например, полнофункциональная ERP с очень широким спектром решаемых задач (в финальной части статьи про это написано - 1 Гб собственно кода, 8 000 экранных форм, 800 отчётов и т.д.).
Если бы это все было только на императивном языке, то объем кода был бы еще больше.
То есть я правильно понимаю, что Дата акселератор умеет выполнять все запросы, которые можно выполнить в 1С ?
Дата акселератор умеет выполнять все отчеты, разработанные на платформе 1С:Предприятие.
А на платформе 1С можно делать рекурсивные запросы и оконные функции ?
Такая возможность не предоставляется.
И можно уточнить, что насчет предагрегаций ? То есть одно дело суммировать что-то на таблице в миллиард записей (пусть и in-memory), а другое дело, когда данные уже преподсчитаны, и расчет идет уже от них, что делает выполнение гораздо быстрее (собственно в чем и смысл OLAP).
Дата акселератор имеет преимущесто в том, что позволяет делать аналитику на часто обновляемых данных, приближенных к реальным (данные в Дата акселераторе периодически обновляются из "боевой" базы данных через механизм копий БД ), и тут предагрегации не очень работают.
Нам была нужна СУБД, на которой отчеты, разработанные на платформе 1С:Предприятие, исполнялись бы быстро. Перед тем, как начать разработку, мы рассмотрели несколько вариантов реализации требований проекта. Оптимальным с точки зрения нескольких важных для нас критериев (время реализации решения, поддерживаемость кода, производительность конечного решения и т.д.) было выбрано написание написание собственной In-memory СУБД, "совместимой" с отчетами, разработанными на платформе 1С:Предприятие.
Поскольку Дата акселератор не является продуктом, предназначенным для использования вне плафтормы 1С:Предприятие, мы не декларируем совместимость с каким-либо конкретным стандартом SQL. Одно из основных требований к Дата акселератору - уметь испольнять все отчеты, которые работают на поддерживаемых платформой 1С:Предприятие СУБД. Дата акселератор этому требованию соответствует.
В статье дан минимальный пример для понимания нашего подхода к кодогенерации. Из алгоритмов джойна у нас есть nested loop (в примере), hash join, merge join.
Алгоритмы выбирает оптимизатор, но такие вещи в двух словах тяжело описать. Возможно, со временем напишем отдельную статью на эту тему.
По поводу сравнения с другими решениями - попробую узнать у коллег.
Да. Есть внедрения в Австрии, Германии, Италии, Румынии, Польше, Испании, США, Канаде, Турции, Латинской Америке, ОАЭ, Англии, Швеции, Болгарии, Чехии, Китае и других странах. Список партнеров 1С за рубежом.
написал вам в личку.
На клиентской стороне находится довольно много логики связанной и с подбором ссылочных полей по распознанному тексту, и с отобржаением документа, с подсветкой полей, откуда вязта информация, с расчетом контрольных сумм и так далее. Подсистема довольно большая и просто API тут будет недостаточно для использования сервиса.
Да, для этого нужно адаптировать подсистему "Распознавание документов", встроенную в 1С:Бухгалтерию, под вашу конфигурацию.
Да,видно в прикладных решениях, баланс отображается на форме, предназначенной для работы с распознанными документами. На портале ИТС эта информация тоже имеется.
Да, отдельный модуль, но там довольно тесная степень интеграции с прикладным решением по части справочников, создаваемых документов и так далее. Пока она встроена в 1С: Бухгалтерию и 1С:ERP и 1С:УТ, в облачную УНФ. Полный список поддерживаемых конфиграций https://ocr.1c.ai/easystart/
Cмотрели, но по гибкости нам данная архиетктура не подошла. Для разметки и сегментации используется собственная разработка.
Поиск соответсвия распознанного текста и элементов справочника происходит на стороне клиента, в прикладном решении. Реализован вариант нечеткого поиска, который позволяет подобрать наиболее "похожие" товарные позиции из тех, которые есть в базе пользователя. Если таких нет(или уверенность слишком мала) пользователю предлагается создать новую позицию на основе распознанного текста.
Мы планируем ещё одну статью по этой тематике - уже с деталями (алгоритмы, фильтры по данным и структура федеративных и агрегирующих узлов (адаптация с высокой нагрузке)).
В эту сатью детали решили не вставлять чтобы не перегрузить читателей.
И дело не только в DSL - просто проекты действительно бывают очень большие.
Понятие "бизнес-проекта" сейчас для 1С достаточно большое - так как сейчас на 1С существуют очень крупные проекты.
Например, полнофункциональная ERP с очень широким спектром решаемых задач (в финальной части статьи про это написано - 1 Гб собственно кода, 8 000 экранных форм, 800 отчётов и т.д.).
Если бы это все было только на императивном языке, то объем кода был бы еще больше.
this
Здесь есть информация (но, наверное, не вся): https://www.youtube.com/watch?v=HjXmFeOcx_A&list=PLaf6kEnNhxlpyAbdO_KfI-yMVtY5PCbPK&index=4
За счет чего достигается ускорение на порядок:
другой способ обработки запросов, отказ от итерационной модели Volcano (например, тут https://habr.com/ru/company/badoo/blog/461699/)
компиляция кода для крупных блоков исполнения, т.е. большего количества вложеных циклов - предмет данной статьи
поколоночная модель хранения данных
Про целостность данных - насколько знаю, копируются только закоммиченые данные. Уточню у коллег.
Дата акселератор умеет выполнять все отчеты, разработанные на платформе 1С:Предприятие.
Такая возможность не предоставляется.
Дата акселератор имеет преимущесто в том, что позволяет делать аналитику на часто обновляемых данных, приближенных к реальным (данные в Дата акселераторе периодически обновляются из "боевой" базы данных через механизм копий БД ), и тут предагрегации не очень работают.
Нам была нужна СУБД, на которой отчеты, разработанные на платформе 1С:Предприятие, исполнялись бы быстро. Перед тем, как начать разработку, мы рассмотрели несколько вариантов реализации требований проекта. Оптимальным с точки зрения нескольких важных для нас критериев (время реализации решения, поддерживаемость кода, производительность конечного решения и т.д.) было выбрано написание написание собственной In-memory СУБД, "совместимой" с отчетами, разработанными на платформе 1С:Предприятие.
Поскольку Дата акселератор не является продуктом, предназначенным для использования вне плафтормы 1С:Предприятие, мы не декларируем совместимость с каким-либо конкретным стандартом SQL.
Одно из основных требований к Дата акселератору - уметь испольнять все отчеты, которые работают на поддерживаемых платформой 1С:Предприятие СУБД. Дата акселератор этому требованию соответствует.
В статье дан минимальный пример для понимания нашего подхода к кодогенерации.
Из алгоритмов джойна у нас есть nested loop (в примере), hash join, merge join.
Алгоритмы выбирает оптимизатор, но такие вещи в двух словах тяжело описать. Возможно, со временем напишем отдельную статью на эту тему.
По поводу сравнения с другими решениями - попробую узнать у коллег.
Да, пишем свою, Дата акселератор, SQL-совместимая in-memory база данных в третьем абзаце статьи написано.
Да, для ограничения прав используется платформенный механизм ограничения прав на уровне записей (RLS).
Список партнеров 1С за рубежом.