Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

17.07.20

База данных - HighLoad оптимизация

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

 

Продолжение тут: //infostart.ru/public/1234475/

и вот тут: //infostart.ru/public/1264771/

 

Начну с описания проблем, которые стали для меня критическими при использовании веб-сервисов на базе 1С:Предприятия и что в конечном итоге заставило меня отказаться от 1С и забыть ее как страшный сон.

Для начала я рассматриваю ситуацию с непосредственным подключением через веб-сервис как на картинке ниже:

 

Проблема №1 Время реакции веб-сервиса

Пресловутая проблема первого обращения к сервису когда грузится сеанс и это подвешивает приложение на фронте. Это можно делать асинхронно, но это далеко не всегда устраивает – не все можно делать асинхронно. На больших конфигурациях и базах ситуация первого запуска настолько печальная что Андроид говорит «а не закрыть ли ваше приложение оно вроде немого сломалось». Человек не привыкший к 1С возможно даже успеет снести это приложение и найти другое в маркете пока сеанс грузится.

Некоторой помощью в этом является т.н. переиспользование сеансов – т.е. удержание сеансов через токены в заголовках запросов и увеличенное время жизни, но это порождает другую проблему – большое количество висящих соединений с веб сервисом и по каким то причинам зависшие «мертвые сеансы»

Также или еще хуже дела обстоят и с OData. В описании 1С так и говорится – первый раз нужно подождать. Я добавил в SimpleUI работу с OData но работать с ним можно если ваши пользователи готовы немного подождать.

Проблема №2 Высоконагруженный веб-сервер

Я не берусь ничего утверждать и не могу привести конкретные цифры но на практике при около 300 ТСД подключенных к 1С через HTTP сервис начинают доставлять некоторые неудобства в виде подвисающих и отваливающихся запросов. Могу предположить что если на сервис 1С повесить тот уровень нагрузки котрый рассчитан на то, что в мире разработки (уточню, не 1С-разаработки) называется «высоконагруженный веб-сервис» , то это закончится лавинообразным падением запросов.

Проблема №3 «Данные наружу»

Никто не хочет выставлять свою 1Ску и сервер на котором она стоит во внешний интернет. Тут начинаются всякие решения от VPNов до промежуточной базы (опять же на 1С).

Проблема №4 Доступность 24/7

Это проблема возникает если мобильные приложения вешают к основной базе где периодически требуется регл обслуживание или например изменение конфигурации данных которое в 1С почему то делается монопольно

Проблема №5 Производительность запросов к данным и масштабирование

На самом деле эту причину наверное надо было ставить на 1-е место, просто она не всегда актуальна. В некоторых случаях запросики простые – положить что то в табличку или взять из нее, а в табличках пару тысяч записей. И это просто не критично. Но есть задачи в которых это критично. Пример – WMS. Проблема возникает тогда, когда надо быстро посчитать итоги по табличкам в которых записей побольше - миллионы. На тему как раскочегарить 1С чтобы она работала чуть быстрее написано немало трактатов и есть даже специально обученные люди, которые занимаются не автоматизацией собственно бизнес-процессов а делают так, чтобы эта автоматизация не тормозила уж очень сильно. И для создателей например WMS-систем этот вопрос стоит очень остро. Настолько остро что они придумывают различные интересные архитектурные решения, например расчет и выдачу заданий распараллеленным способом в нескольких потоках. Ну и много чего еще. Какую часть времени разработчик тратит аспекты, связанные с производительностью? 1С это конструктор, на котором можно было быстро разрабатывать автоматизацию с простым языком программирования без ООП и типизации… Так вроде задумывалось? Но если решение проблем занимает больше времени чем сама разработка, может нужно эту ситуацию изменить?

А теперь главный вопрос: возможно ли предположить (в порядке бреда) что запрос в 2-х звенной системе (клиент-SQL сервер) на чистом SQLе выполнится быстрее чем такой же запрос в 3-х звенной системе (клиент-сервер бизнес-логики с интерпретатором-SQL сервер)? Как так получается что в облачных WMS элементарный поиск по штрихкоду в базе с 500 тыс. штрих-кодов выполняется за считанные мс, а чтобы 1C показала такой же результат нужно дорогостоящее оборудование и специальный человек который это оптимизирует.

Я занимаюсь 1С с 2002 года, с тех времен когда еще встречалась 7.5, но в основном была 7.7 и мы для регистрации чеков на кассе не испытывали судьбу (задержка кассы могла обернуться проблемами, бизнесмены тогда были суровыми), а просто писали их в SQL таблицу через ADO, а потом читали. Прошло 18 лет, 1С выпустила 8.3 и конфигурации которые весят Гигабайты,  а я не могу придумать ничего лучше для решения проблем сейчас.

Я еще вернусь к проблеме производительности в разделе «Тестирование»

Путь к решению

Итак, что я должен был сделать чтобы решить все эти проблемы? Из Проблемы №5 вытекает что я должен использовать реляционную СУБД как промежуточное звено между фронтом и 1С. Но в чистом виде это вещь в себе, для того чтобы к ней цеплялись и клиенты и 1С нужно какое то API. SQL сервера сами по себе имеют API в виде драйверов ODBC и 1C может цепляться через них. А клиенты? А если эта база в облаке?

Вообще решения по бекендам для мобильных приложений  на текущий момент такие (имеется ввиду если не использовать 1С):

  • Собственно, взять и написать свой бекенд, т.е. свой сервер с каким то API. Если вы не фуллстек разработчик то придётся привлекать бекендщика который это сделает. Отсюда вытекает минус: бекенд пишется под конкретное решение/внедрение и его нужно поддерживать. Со временем это превращается в т.н. легайси, специалисты которые это писали уходят на другие проекты и знания теряются. Их надо добывать по новой. Но учитывая какая карусель со стеками технологий происходит в последнее время, скорее всего в нагрузку придется изучать «старый» стек технологий. Да, да в мире за пределами 1С творятся страшные вещи.
  • Облачные бекенды  от Гугл, Майкрософт, Амазон и менее известные например Backedless. Вроде бы плати деньги каждый месяц и наслаждайся готовым решением. Но нет и тут есть проблемы. Вкратце они такие:
    • Они почему-то No-SQL т.е.  нереляционные субд. Видимо считается что так проще для разработчика но во-первых множество вещей типа агрегатных функций в NoSQL базе сделать нельзя, во вторых вместо стандартного SQL нужно изучать местный стек технологий и вроде бы это и просто но есть нюансы
    • Ты не хозяин сервера и от тебя ничего не зависит. Однажды одна из вышеперечисленных компаний решила сменить версию своего решения допустим с 4 на 5 в результате, многое из того что было сделано в решении перестало работать, требовалось разобраться в новых доках и пились новую интеграцию. А да, и сделали они это с 1 января)) С утра мне стали поступать письма пользователей. Но коммент)
    • Не смотря на то что это вроде как технологические гиганты подобные облачные сервисы выглядят настолько сырыми что вызывают недоумение. Косяки и неочевидные решения, ради которых надо сидеть на формах и перечитывать кучу доков. Да и функционал убогий.
  • Собственно сторонний OData либо RESTful API для различных SQL-серверов т.е. решение которое прицепляет к SQL серверу API которое сделали уже за Вас, нужно только поставить и пользоваться. Сочетаний много есть такие, которые работают с разными серверами. Например DreamFactory. Ничего не могу сказать про него потому что он платный и довольно недешевый. Но это почти то что нужно.

 

Решение

Пришло время раскрыть карты. Формула решения всех проблем – это перенос высоконагруженных операций в отдельный SQL на том же сервере или в облаке,  а для связи использовать REST API со стороны фронта(клиентов) и тотже REST API либо ODBC со стороны 1С. Либо можно посадить на брокер сообщений типа RabbitMQ но со стороны 1С не так уж это важно.

И это очень, очень просто!  Все гораздо проще чем можно себе представить. Потому что есть PostgREST . Именно так пишется. Смысл: это бесплатный опенсорс REST API для Postgre SQL который организует веб интерфейс для CRUD и некоторых других операций для вашего PostgreSQL. Точнее таких API два – есть еще pREST (они говорят что они лучшие, а PostgREST -… ну вы поняли).

Таким образом мы имеем: бесплатную современную СУБД PostgreSQL 12, бесплатный открытый веб сервер к ней PostgREST через который можно простыми запросами хоть даже в браузере просматривать, создавать, удалять и т.д.  Но ведь эта штука еще и ставится на Линукс! А это значит что можно арендовать VPS сервер за пару евро в месяц, поставить туда  PostgreSQL c PostgREST и мы получим облако которое будет работать 24/7! И еще которое можно легко масштабировать по производительности – поменять конфигурацию на вирт. сервере при необходимости.  

Таким образом у вас в облаке организуется сервер который может делать такие вещи:

  • Запросы на запись, обновление (upsert) в том числе в Bulk-режиме (POST). 5000 записей принимаются и сохраняются за 50 мс
  • Различные запросы на выборку данных из таблиц и views (GET). Самый простой запрос аналог запроса Select * from goods выглядит так: /goods далее при необходимости к строке прибавляются условия, упорядочивание и т.д.
  • Выполнять хранимые процедуры и функции
  • Работать с бинарными данными. Это актуально для мультимедиа и больших документов.
  • Удаления
  • Работает через JSON но может выгружать и в дргом формате, через текст с разделителями. Это настраивается в заголовках

Т.е. организации бекенда нужно зайти в БД через pgAdmin, создать таблицы, вьюшки при необходимости остальные элементы. Дать права и все – дальше можно взаимодействовать с базой через веб-сервис. Примерно тоже самое нужно сделать в люом другом варианте бекенда, в т.ч. на 1С.

Вот инструкция как поставить и как начать пользоваться: http://postgrest.org/en/v6.0/tutorials/tut0.html

Я сам ставил это и на виндовс и на CentOS 7. В инструкции для линукс я не использовал Докер. Больше всего времени я потратил на то чтобы подключить pgAdmin к базе на VPS сервере точнее сделать так чтобы к самому Postgre можно было цепляться извне. Ну я не линуксоид, вообще профан в этих делах, а так как проект экспериментальный все делал своими силами. Остальное проще.  

Связь с 1С

Если PostgreSQL доступен через драйвера ODBC то можно подключаться через них. Хорошей возможностью является использование Внешних источников данных. С ними потом легко стоить отчеты СКД.

Ну и конечно 1С может работать через REST интерфейс. Т.е. точно через то же API что и клиенты.

Вот пример отправки товаров через HTTP - запрос:

	АдресТерминала =Константы.АдресБекенда.Получить();
		Соединение = Новый HTTPСоединение(АдресТерминала);
		Заголовки = Новый Соответствие();
		Заголовки.Вставить("Content-Type","application/json");
		Заголовки.Вставить("Prefer","resolution=merge-duplicates");
		Запрос = Новый HTTPЗапрос("/goods", Заголовки);
		
		З = Новый Запрос;
		З.Текст =  "ВЫБРАТЬ
			           |	ШтрихКоды.Штрихкод КАК Штрихкод,
			           |	ШтрихКоды.Владелец.Наименование КАК Наименование,
			           |	ШтрихКоды.Владелец.Артикул КАК Артикул
			           |ИЗ
			           |	РегистрСведений.ШтрихКоды КАК ШтрихКоды" ;

			
		ТаблицаДанных = З.Выполнить().Выгрузить();
		CтpoкaJSON = "[";
		Для каждого строкаТаблицы из ТаблицаДанных Цикл
				CтpoкaJSON = CтpoкaJSON+?(СтрДлина(CтpoкaJSON)>1,",","")+"{"+"""name"":"+""""+СокрЛП(строкаТаблицы.Наименование)+""""+","+"""article"":"+""""+СокрЛП(строкаТаблицы.Артикул)+""""+","+"""barcode"":"+""""+СокрЛП(строкаТаблицы.Штрихкод)+""""+"}";
		КонецЦикла;	
			
		CтpoкaJSON =CтpoкaJSON+ "]";
		Запрос.УстановитьТелоИзСтроки( CтpoкaJSON,КодировкаТекста.UTF8);
		
		Ответ = Соединение.ОтправитьДляОбработки(Запрос).ПолучитьТелоКакСтроку();

 

А вот пример отчета  на СКД и модуль его заполнения:

Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
	СтандартнаяОбработка = Ложь; 

	Настройки = КомпоновщикНастроек.ПолучитьНастройки(); 
	
	
	ДанныеРасшифровки = Новый ДанныеРасшифровкиКомпоновкиДанных;  
	КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных; 
	
	СхемаКомпоновкиДанных = ПолучитьМакет("ОсновнаяСхемаКомпоновкиДанных");
	МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, 
							Настройки, ДанныеРасшифровки);
							
							
	ВнешниеДанные.Очистить();
	
	АдресТерминала = Константы.АдресБекенда.Получить();
	Соединение = Новый HTTPСоединение(АдресТерминала,3000,,,,,);
	Заголовки = Новый Соответствие();
	Заголовки.Вставить("Content-Type","application/json");
		
   
    Запрос = Новый HTTPЗапрос("/bal");
        Результат = Соединение.Получить(Запрос);
	СтрокаJSON = Результат.ПолучитьТелоКакСтроку();	
	Чтение = Новый ЧтениеJSON;
 	Чтение.УстановитьСтроку(СтрокаJSON);
 	Данные = ПрочитатьJSON(Чтение, Ложь);
	Если типЗнч(Данные) = Тип("Структура") Тогда
		НовСтр = ВнешниеДанные.Добавить();
		ЗаполнитьЗначенияСвойств(НовСтр,Данные);

	ИначеЕсли типЗнч(Данные) = Тип("Массив") Тогда
		для каждого стр из Данные Цикл
			НовСтр = ВнешниеДанные.Добавить();
			ЗаполнитьЗначенияСвойств(НовСтр,стр);
		КонецЦикла;	
		
	КонецЕсли;	
	
 	Чтение.Закрыть();	

							
							
	ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
	ПроцессорКомпоновки.Инициализировать(МакетКомпоновки,
		Новый Структура("ВнешниеДанные", ВнешниеДанные.Выгрузить()), 
		ДанныеРасшифровки);	

	 
	ДокументРезультат.Очистить();
	
	
	ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
	ПроцессорВывода.УстановитьДокумент(ДокументРезультат);	
	ПроцессорВывода.Вывести(ПроцессорКомпоновки);


КонецПроцедуры

 

 

Тест производительности

Для экспериментов я нашел в сети самый слабый вариант какой только смог найти: VPS за 45р/мес: 1 проц Athlon, 1Гб ОЗУ, 5 ГБ HDD (не SSD) на CentOS. И сравнивал с 1С файловый вариант на i5 ,SSD, 16ГБ ОЗУ, Windows.

Методика у меня конечно примитивная, но некоторые выводы можно сделать. Для проведения сравнительных тестов я встроил в SimpleUI возможность измерять время исполнения команд. Так, я помещаю на экран определенную  группу команд и выполняю и в 1С и в бекенде. Потом сравниваю результат. На экраны я поместил следующие команды:

  • Поиск по штрихкоду – 1 штрихкод
  • Вывод списка номенклатуры в таблицу
  • Запись в базу (или в бекенд) 1й операции

Примерно так выглядят результаты теста, теперь их можно организовывать самим – возможности для этого есть:

 

Еще я не создавал индексы в Postgre, а в 1С они есть.

Вот такие получились результаты:

Сначала я провел тест при заполненности таблицы товаров  в р-не 20 строк:

:  1-й запрос – 330 мс, запросы после первого запроса – 19-20 мс в среднем

Postgre: 1-й запрос - 38 мс, последующие запросы – 32 мс

Т.е. сервис 1С может работать быстро, если его раскочегарить. Но давайте проверим что будет на реальном справочнике:

Я добавил 5000 товаров в обе базы, кстати это заняло у меня:

  • 150,34с  в 1С (в режиме транзакции)
  • 1,05с в Postgre (в Bulk режиме)

И после этого я снова замерил результаты:

:  1-й запрос – 480 мс, запросы после первого запроса – 230 мс в среднем

Postgre: 1-й запрос - 40 мс, последующие запросы – 33 мс

Вывод который я сделал: Postgre проглотил справочник и не заметил, разница в обработке запросов на уровне погрешности. 1С - заметно погрустнел. К слову сказать это очень маленький справочник по сравнению с тем, с чем приходится сталкиваться.

 

Связь с Simple UI и новые фишки

Я развиваю собственную платформу-конструктор мобильных приложений - Simple UI. Конечно же я пустился на поиски замены 1С не от хорошей жизни и очень рад что нашел Postgre. Сложно переоценить важность этого инструмента для моих проектов. Теперь легко можно собрать себе свой бесплатный бекенд в максимально упрощенном режиме, прицепить к нему бесплатные клиенты на Simple UI и полноценная система готова.

Пока все возможности работают в режиме беты, они не прошли полноценную проверку в рабочих проектах. Я только начал осваивать это направление. Сервис которым можно поиграться пропишется в настройках приложения при обновлении, авторизации для запросов там нет. 

В Simple UI я добавил возможности для CRUD- операций и выполнения процедур:

Вот так например выглядит  запрос типа Select..Where:

А вот так запрос на добавление строки в таблицу:

И конечно же теперь на своем сервере можно организовать свой облачный магазин приложений. Магазин не в смысле продавать за деньги – а просто место, куда можно выкладывать конфигурации, чтобы на клиентах их скачивать/обновлять. Конфигурация в Simple UI – это XML-строка. Вот так выглядит отправка конфигурации из 1С:

А вот так сам магазин в приложении:

Кстати, теперь можно не скачивая демо базу проверить работу с оборудованием – одна из конфигураций позволяет в off-line режиме (не через бекенд) протестировать работу оборудования штрихкодов и распознавания текста (которое тоже кстати улучшено в последнем релизе).

Ну и коротко, что можно посмотреть в тестовой конфе для работы с бекендом, которую тоже можно скачать из магазина без скачивания базы 1С: показан пример где можно ввести в справочник в бекенде свою номенклатуру. Потом, в проекте есть процесс, в котором имитируется приемка: сканируется либо вводится артикул номенклатуры, она идентифицируется, показываются текущие остатки, вводится количество которое отправляется в облако и, соотвественно меняет остаток. Это можно увидеть в приложении, можно в 1С. Можно отправить/получить данные из 1С. Основная статья, где демо база, доки и остальное тут: //infostart.ru/public/1153616/

Для Pro-версии доступны также дополнительные возможности:

Можно отсылать и получать данные в фоновом потоке (не UI-потоке приложения) – т.е. если надо скачать или закачать большой объем данных программа будет выполняться без торможения. При этом само приложение может взаимодействовать чисто с собственным SQL полностью автономно (без связи) и при необходимости обмениваться с бекендом в фоне.

Кроме того, можно назначить процессы, которые будут выполняться при запуске конфигурации. Для этого в конфигурации есть реквизит в котром можно указать экран, в котором в свою очередь перечислены команды,сам экран не будет выполняться – только команды.

 

бекенд веб-сервис postgre SQL postgrest http мобильная разработка SimpleUI

См. также

"Штрихкод-информер" - мобильный ТСД и прайс-чекер в смартфоне

Мобильная разработка Сканер штрих-кода Терминал сбора данных Управляемые формы Мобильная платформа 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Управленческий учет Платные (руб)

Сбор заказов, инвентаризация, проверка ценников, просмотр полной информации об остатках и ценах со смартфона Онлайн. Отправка данных со смартфона выполняется либо напрямую в открытую форму документа, отсканировав QR-код, либо в общую корзину учетной системы, не подходя к компьютеру. Кассир или оператор сможет просмотреть список присланных данных и загрузить в любую форму, поддерживающую работу с ТСД. Для работы с мобильным приложением требуется опубликовать HTTP-сервис из поставляемого расширения.

2880 руб.

03.12.2018    54425    135    102    

160

SALE! 25%

Что нам стоит бота построить? Нарисуем - будет жить! Графический конструктор телеграм-ботов/Telegram

Мобильная разработка Мессенджеры и боты Платформа 1С v8.3 Платные (руб)

Теперь создать telegram-бота - элементарно. Достаточно просто нарисовать блок-схему телеграм-бота, и он сразу заработает. Это возможно при использовании Графического конструктора телеграм-ботов. Это единственный конструктор ботов для telegram, чье качество и функционал подтверждены фирмой 1С, есть сертификат 1С:Совместимо. Расширение в интерактивном режиме, с помощью блок-схем, позволяет с минимальными трудозатратами создать телеграм-ботов в любой конфигурации, работающей на платформе «1С:Предприятие 8.3».

13200 9900 руб.

27.12.2021    33023    80    157    

173

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме. Без существенных изменений типовой конфигурации. Проверено с брендами: Интеграция 1С и GEELY Интеграция 1С и HAVAL Интеграция 1С и KIA Интеграция 1С и FORD Интеграция 1С и LADA ГАРАНТИЯ 100% ВНЕДРЕНИЯ!

36000 руб.

03.08.2020    15660    9    17    

9

"Мобильный ТСД" - инвентаризация и сбор штрихкодов для iOS и Android

Сканер штрих-кода Терминал сбора данных Мобильная разработка Монитор заказов Оптовая торговля Розничная торговля Ценообразование, анализ цен Платформа 1С v8.3 Мобильная платформа 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Простой мобильный терминал сбора данных для смартфонов на iOS и Android, не требующий сложных настроек и установки дополнительных программ. Обмен между Вашей 1С и мобильным приложением осуществляется через облачный сервис и расширение конфигурации. Работает с конфигурациями УТ 11, ERP, КА2, Розница 2, Розница 3, УНФ 1.6, УНФ 3.0. Полнофункциональный демо-доступ для своей конфигурации можно запросить в настройках мобильного приложения - все необходимое придет на почту автоматически.

2000 руб.

22.04.2019    91745    507    186    

293

Модуль для обмена "1С:Предприятие 8. УАТ. ПРОФ" с FortMonitor

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    12809    30    8    

10
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Konstantin_Lazukov 01.04.20 13:27 Сейчас в теме
А дело не в конкатенации? Просто если сравнить 2 идентичных куска кода, то разница во времени выполнения минимум 15 раз. И это всего 5000 строк.

&НаСервере
Процедура КонкатенацияНаСервере()
З = Новый Запрос;
З.Текст = "ВЫБРАТЬ первые 5000
| АЗС.КлиентВладелец.Наименование как наименование,
| АЗС.КлиентВладелец.Код как код,
| АЗС.ЭлПочта как элпочта
|ИЗ
| Справочник.АЗС КАК АЗС";

ТаблицаДанных = З.Выполнить().Выгрузить();
CтpoкaJSON = "[";
для каждого строкаТаблицы из ТаблицаДанных цикл
CтpoкaJSON = CтpoкaJSON+?(СтрДлина(CтpoкaJSON)>1,",","")+"{"+"""name"":"+""""+СокрЛП(строкаТаблицы.Наименование)+""""+","+"""article"":"+""""+СокрЛП(строкаТаблицы.код)+""""+","+"""elpochta"":"+""""+СокрЛП(строкаТаблицы.элпочта)+""""+"}";
конеццикла;
CтpoкaJSON =CтpoкaJSON+ "]";
сообщить(стрдлина(CтpoкaJSON));
КонецПроцедуры

&НаКлиенте
Процедура Конкатенация(Команда)
КонкатенацияНаСервере();
КонецПроцедуры

&НаСервере
Процедура джейсонНаСервере()
З = Новый Запрос;
З.Текст = "ВЫБРАТЬ первые 5000
| АЗС.КлиентВладелец.Наименование как наименование,
| АЗС.КлиентВладелец.Код как код,
| АЗС.ЭлПочта как элпочта
|ИЗ
| Справочник.АЗС КАК АЗС";

ТаблицаДанных = З.Выполнить().Выгрузить();
Массивчик=новый массив;
для каждого строкаТаблицы из ТаблицаДанных цикл
Структурка=новый структура;
Структурка.Вставить("name",СокрЛП(строкаТаблицы.Наименование));
Структурка.Вставить("article",СокрЛП(строкаТаблицы.код));
Структурка.Вставить("elpochta",СокрЛП(строкаТаблицы.элпочта));
Массивчик.Добавить(Структурка);
конеццикла;
ЗаписьJSON = Новый ЗаписьJSON;
ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON( ,Символы.Таб);
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, Массивчик, Новый НастройкиСериализацииJSON);
CтpoкaJSON=ЗаписьJSON.Закрыть();

сообщить(стрдлина(CтpoкaJSON));

КонецПроцедуры

&НаКлиенте
Процедура джейсон(Команда)
джейсонНаСервере();
КонецПроцедуры
Показать

2. informa1555 2605 01.04.20 16:03 Сейчас в теме
(1) Вы имеете ввиду тот кусок где я товары на сервер отправляю? Не, я мерил от момента отправки PUSH до получения результата запроса. Не, BULK - операции в SQL все таки реально быстрые))
3. Konstantin_Lazukov 01.04.20 16:35 Сейчас в теме
(2) Конечно быстрее,тут даже сравнивать нечего. Проблема в том, что очень часто нужны не просто select или insert а именно пред- или пост- обработка данных.
4. informa1555 2605 01.04.20 16:52 Сейчас в теме
(3) Да, я Вашу мысль понял. Но дело в том что во-первых на примере облачных WMS там простые сущности (т.е. там где требуется быстрота там нет всего что есть в типовых конфах 1С) соответственно и проверки, обработки при транзакциях они проще чем в 1С, во-вторых если это вешается на хранимые процедуры, триггеры, поддержание целостности на уровне БД - ну это еще быстрее работает. Я сравнивал производительность в режиме ОбменДанными.Загрузка =Истина.
5. efin 01.04.20 19:53 Сейчас в теме
Получается, чтобы 1С узнала об изменениях в базе postgres, мне нужно ее регулярно опрашивать?

Или можно как-то организовать типа триггеров, но через rest?
6. informa1555 2605 01.04.20 20:17 Сейчас в теме
(5) там в хранимых процедурах несколько языков можно использовать. Но я не уверен что Postgre может запросы отправлять. Интересный вопрос. Обычно интеграции с sql делают через опрос. И в случае с интеграцией с wms например это совершенно нормально. Там некуда торопиться. Распоряжения отправил, периодически факт забираешь и все.
9. mixsture 02.04.20 13:20 Сейчас в теме
(5) визуально, такой функционал есть у самого постгреса есть. Так что теоретически это возможно. Возможно через эту реализацию rest не пролезет и придется написать свой промежуточный сервис для доставки уведомлений.
https://tapoueh.org/blog/2018/07/postgresql-listen-notify/#postgresql-notifications
7. Chelper 7 02.04.20 12:44 Сейчас в теме
Насчет "в первый раз нужно подождать" - это точно.
Разработал систему для проведения теннисных соревнований, на бэке - 1С.
Первое получение данных - достаточно долгое, в дальнейшем - страницы генерируются достаточно быстро.
Вот ссылка на сайт.
Планирую переписать весь фронт на Vue.js
Вот основная страница сайта:
https://odinservice.asuscomm.com/fntm/
8. mixsture 02.04.20 13:09 Сейчас в теме
Имхо, могут вылезать проблемы 2х-звенной архитектуры:
1) сложности с поддержанием консистентности. Когда появится много связей между таблицами - в 2х звенной придется либо
а) это решать на фронтэнде, что прям очень странный подход. При нем по сути только фуллстэк разработчик может заниматься фронтом, потому что понимает, что там в базе происходит. Выдать этот кусок фронтэнд-разработчикам не выйдет.
либо
б) на уровне базы данных, что посложнее и требует отдельной области знаний. И все равно база может выкидывать глубоко системные сообщения об ограничениях на фронт, что опять же - нетипично для фронтэнд-разработчиков.

2) сложности с контролем прав доступа. Доступ к таблицам базы приходится выдавать заметно более широкий (по сути по-таблично), а само приложение может работать в недоверенных средах.
10. informa1555 2605 02.04.20 14:07 Сейчас в теме
(8) Частично согласен
консистентность на уровне базы в Postgre поддерживается ничего сложного там нет - все виды есть: удаление, запреты, очистка.Как и везде. Частично проверки на уроне фронта. Да, согласен, и я об этом пишу что в принципе тот кто делает фронт сам себе делает и базу. И он частично бекндщик. Но! Одно дело сделать таблички, дать права и т.д. в стандарнтном SQLе, другое дело писать еще к этому RESTful интерфейс. Просто если это делали бы бекендщики они сделали бы какие то функции типа Добавить Товар там которое бы все делала, потом поди разберись что там эта функция делает. А тут все на чистом SQLе, который все знают. Я знаю несколько "облачных" WMS на чистом SQLе - люди как то это сделали. У них нет фронта либо они используют SimpleUI, а раньше использовали веб-интерфейс.
11. maxx 991 05.04.20 20:53 Сейчас в теме
Спасибо за то, что делитесь таким опытом.

Похоже нужно выводить новое понятие

фулстэк русский разрабочик
это веб + 1с + мобильный технологии + субд
akR00b; NoRazum; qazaz2; +3 Ответить
12. informa1555 2605 05.04.20 21:30 Сейчас в теме
(11) спасибо. Ну ещё там интеграции всякие, кролик и т.д. Да в кризис чем шире стек тем лучше...
13. Kondratenko.as 562 06.04.20 17:01 Сейчас в теме
День добрый. А elasticsearch не рассматривали? Там скорость на get запросы максимальная. Сам продукт создан для быстрой записи и отдачи + сама структура хранения базы NoSQL в формате JSON.

https://www.elastic.co/elasticsearch/service?baymax=rtp&elektra=home&storm=sub1&rogue=default&iesrc=ctr
14. informa1555 2605 06.04.20 17:19 Сейчас в теме
(13) Добрый день! Так нет, мне NoSQL не нужен, я больше WMS и т.д. занимаюсь - мне нужны итоги, триггеры, целостность - вот это вот все. Простейшие учетные задачи. Понятно что NoSQL пишет быстрее, но мне надо еще быстро получать например остатки в ячейках (которые нужно быстро пересчитывать)
15. Region102 30.04.20 15:09 Сейчас в теме
Кстати тоже уперся в 350+ соединений с HTTP сервисом в 1С, при большем количестве лезли уже ошибки или вообще не было ответа, но тут проблема скорее в Apache из коробки. Когда я провел нагрузочное тестирование на автономном сервере 1С, то он уже спокойно держал 15000+ одновременных соединений. Скоро выложу на канале тесты.
16. Xershi 1473 13.05.20 22:53 Сейчас в теме
Я так понял это тоже самое, что одата в 1с.
Таблички сделал в СУБД. СУБД опубликовал на веб-сервере, далее ашттп запросы к БД?
17. informa1555 2605 14.05.20 07:20 Сейчас в теме
(16) Да. Очень похоже. Даже синтаксис похож.
18. Xershi 1473 14.05.20 09:07 Сейчас в теме
(17) и выдумывать ничего не нужно. Шикарное решение!
Уровень вхождения практически нулевой. В крайнем случае админа подключить для настройки софта.
o.nikolaev; informa1555; +2 Ответить
19. informa1555 2605 14.05.20 09:41 Сейчас в теме
20. o.nikolaev 211 22.05.20 15:45 Сейчас в теме
Шикарная статья.
informa1555; +1 Ответить
21. informa1555 2605 22.05.20 16:17 Сейчас в теме
22. qazaz2 16 22.07.20 14:26 Сейчас в теме
Подскажите, если помните, в чем были трудности с pgAdmin и как их решили. Уперся в него, возвращает:
{"info":"","success":0,"result":null,"errormsg":"'Request' object has no attribute 'is_json'","data":null}

Спс
23. informa1555 2605 22.07.20 14:49 Сейчас в теме
24. qazaz2 16 22.07.20 15:08 Сейчас в теме
(23) Пробую, спасибо за подсказку
25. VVi3ard 52 28.07.20 13:00 Сейчас в теме
Как вы решаете вопросы доступа к данным и аутентификации?

Т.е. я же правильно понимаю что ваш сервер с PostgREST доступен в интернет всем желающим?

Как вы разграничиваете доступы?

И как вообще происходит аутентификация и авторизация пользователей (мобильных приложений)?
26. informa1555 2605 28.07.20 13:25 Сейчас в теме
(25) конкретно мой - да)) Его можно ломать не жалко. А так там есть и ограничения доступа на уровне публикации сервиса(типа по IP и т.д.) и на уровне уже внутри API : http://postgrest.org/en/v7.0.0/auth.html
27. ITSun 02.08.20 22:39 Сейчас в теме
Прекрасное решение, спасибо за статью!+
informa1555; +1 Ответить
28. informa1555 2605 03.08.20 08:14 Сейчас в теме
29. malikov_pro 1288 23.09.20 07:11 Сейчас в теме
(8)
"1) сложности с поддержанием консистентности." - на сколько понимаю реализуется через хранимые процедуры
"б) на уровне базы данных, что посложнее и требует отдельной области знаний." - в этом правы, нужно повышать свой уровень владения PG.

"Доступ к таблицам базы приходится выдавать заметно более широкий (по сути по-таблично)" - не правы
http://postgrest.org/en/v7.0.0/auth.html
"Anyone accessing the generated API endpoint for the chat table will see exactly the rows they should, without our needing custom imperative server-side coding."
"Любой, кто обращается к сгенерированной конечной точке API для таблицы чата, увидит именно те строки, которые они должны видеть, без необходимости в пользовательском императивном кодировании на стороне сервера."
30. TODD22 18 23.09.20 15:10 Сейчас в теме
Они почему-то No-SQL т.е. нереляционные субд.

У гугла можно развернуть PG, разве нет? С AWS не работал, но и там мне кажется можно развернуть PG.

Видимо считается что так проще для разработчика но во-первых множество вещей типа агрегатных функций в NoSQL базе сделать нельзя, во вторых вместо стандартного SQL нужно изучать местный стек технологий и вроде бы это и просто но есть нюансы

sql и nosql каждая для своих задач.
31. informa1555 2605 23.09.20 15:50 Сейчас в теме
(30) Не, я имел в виду такой класс сервисов котрый есть у Гугла, Амазон, backendless и т.д. как "облачный бекенд" а не просто хостинг для СУБД. Там смысл в том что без программирования, SQL создается документоориентированное хранилище со свои API котрый можно юзать через REST и другими способами. Т.е. как бы готовый бекенд для тех, кто не хочет делать свой бекенд (не заморачиваться с бекенд разработкой) т.е. сделал приложение например и надо где то хранить данные - ты арендуешь это и с этим работаешь
32. MuI_I_Ika 1109 25.12.20 16:21 Сейчас в теме
Если я правильно понял статью, то у вас имеется база, опубликованная на хостинге. К ней могут подключаться как ваши приложения на 1С, так и мобильные клиенты. По приложениям на 1С вопросов нет, они вроде как вами контролируются.

Вопрос про мобильные приложения. Клиент имеет неограниченный доступ к базе данных по логину и паролю зашитому в этом самом клиенте.

Допустим у вас мобильные приложения розданы водителям или вообще это клиент для работы с рабочим кабинетом партнера. Короче говоря, вашим приложением пользуются люди, которые вами не особо контролируются.

Отдает такой пользователь свой телефон с вашим мобильным клиентом знакомому хакеру.

А хакер декомпилирует вашу программу, узнает логин и пароль. Благодаря общедоступному api пишет свой клиент, а дальше делает в вашей базе все что хочет. Например, делает ее полную выгрузку.

Не очень понятно, как такой подход застрахует от подобных вещей?

Если я написал глупость не судите строго.
33. informa1555 2605 25.12.20 16:59 Сейчас в теме
.(32) Добрый день! Статья прежде всего о том, что каждый может собрать такой сервак на постгресте за немного времени, ну т.е. DIY и получить свою быструю базу. Мой сервак котрый в Simple UI - для поиграться/поломать - там ниче интересного не храниться и его обычно юзают те, кто разрабатывает на Simple UI просто как демку.
Вариантов авторизации для PostgREST может быть много вплоть до ограничений по ip и роли для доступа к схемам тоже настраиваются.
Пароль в приложухе не хранится, хранится в зашифрованном виде и передается тоже. Но это конечно слабая защита.
Общедоступный API есть и в 1С же и ее также можно ломануть. Только вот разница будет - ломануть ERP систему или ломануть промежуточную СУБД в которой только данные для мобильных клиентов.

По поводу полной выгрузки - не получится. Через REST - нет, админские логины/пароли раздавать рядовым клиентам тоже не надо. Максимум это CRUD доступ к таблицам котрые выведены в схему REST. Ну как с ODATA в 1С. Ну вообще вопрос конечно интересный. Я то больше для складов использую - там внутренняя сетка.
34. MuI_I_Ika 1109 25.12.20 17:10 Сейчас в теме
(33)
стему или ломануть промежуточную СУБД в которой только данные для мобильных клиент


Я просто сейчас рассматриваю для себя как раз варианты развертывания шлюза данных. То есть, с одной стороны 1Ски декстопные, с другой стороны мобильные приложения.

Например нужно организовать обмен текстовыми сообщениями между пользователями. Каждое сообщение адресовано 1 пользователю системы.

Каждый пользователь со своего клиента должен иметь возможность читать только то, что адресовано ему.

У пользователей есть рабочие группы. Пользователь должен иметь возможность написать сообщение только пользователю из своей рабочей группы.

Пользователи должны иметь возможность самостоятельно регистрироваться.

То есть, очевидно, что доступ у пользователей должен иметься только к определенному набору записей в базе. Причем для каких-то записей только на чтение. Для каких-то на запись, на создание только по определенным кортежам.

Возможно ли это организовать только средствами субд или все таки без серверной части, которая будет обеспечивать логику работы шлюза не обойтись?
35. informa1555 2605 25.12.20 17:27 Сейчас в теме
(34)
(34)
Пользователи должны иметь возможность самостоятельно регистрироваться.
- уже какая то страница должна быть с логикой... по поводу разделения средствами СУБД - посмотрите row level security в постгре. Я честно говоря давно не смотрел как у них там. Ну кстати адресация то сообщений - это на уровне и таблиц можно сделать.
Оставьте свое сообщение