Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практикум языка запросов

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

Поговорим про условия в секции «ГДЕ».

Все знают, что для фильтрации результата запроса удобно использовать параметры. Но люди очень часто мыслят шаблонно и, проверяя параметры запроса, размещают поля таблицы в левой части условия.

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

Следующий момент. Очень часто при анализе чужого кода я наблюдаю конструкцию: «ВЫБОР КОГДА…ТОГДА ИСТИНА».

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

Также не все знают, что конструкцию ЕСТЬNULL можно использовать прямо в секции условий вместо того, чтобы писать какие-то сложные параметрические условия. Для случая, когда левое соединение не отрабатывает, у вас есть значение по умолчанию – это очень удобно, очень наглядно.

Объединения таблиц и индексы

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

Например, очень часто в документах перемещения (выпуска продукции, комплектации номенклатуры) одну и ту же таблицу требуется двинуть по регистрам дважды – в приход и в расход. И, чтобы движение cформировалось быстрее, его результат рассчитывается в запросе. Но тут получается, что мы к одной и той же таблице обращаемся два раза, хотя у нас отличаются только поля «ВидДвижения», «&СкладОтправитель», «&СкладПолучатель».

Вместо этого можно сгенерировать таблицу «в памяти», которая вообще не будет обращаться к СУБД – и делать левое соединение с ней.

Вот, например, наиболее сложный случай, когда используется какой-то «&СкладВПути», и в одном документе надо объединить 4 таблицы.

А вот пример, как это оптимизируется – мы делаем левое соединение с двумя числовыми селекторами и в конструкциях «ВЫБОР КОГДА… ТОГДА» подставляем нужные значения полей – именно то, которое нам необходимо. Одну из таблиц SQL при этом держит в памяти и, по мере выборки из второй физической таблицы, он ее строки размножает. В результате мы получаем наборы движений, обратившись к СУБД только один раз. Это – значительно эффективнее.

Очень часто можно встретить рекомендацию использовать временные таблицы. А я немного расскажу о том, как их не надо использовать.

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

Например, как здесь, эта «ТаблицаСписания» в дальнейшем используется для отбора виртуальной таблицы оборотов по полям «Склад» и «СерияНоменклатуры».

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

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

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

Но оно выполняется далеко не для любой глубины вложенных запросов. Поэтому вам рекомендуют их не использовать. Если вы сделаете 3-4 уровня вложенности, наследование индексов работать перестанет.

Речь идет о свойствах таблиц в памяти SQL-сервера сохранять рассчитанные хэш-значения измерений до вытеснения таблиц из ОЗУ, что позволяет выполнять HASH JOIN в планах запросов без значимых потерь производительности. Множественные вложенные запросы повышают риск длительного выполнения запроса.

Дисковая нагрузка

Все видели эту стандартную 1С-ную картинку типового конвейера записи в СУБД.

Надо понимать следующее – при использовании левых соединений или конструкции «ОБЪЕДИНИТЬ» (в отличие от «ОБЪЕДИНИТЬ ВСЕ») сервер MS SQL может принимать решение о том, что в таблице временных файлов будет выполнена предварительная сборка вашего результата запроса – построчное хэширование (формирование хэша для каждой записи в вашей промежуточной таблице) для последующего обращения к уже условно проиндексированному результату. Это накладывает определенные требования к оборудованию – у него должна быть аппаратная поддержка функций по работе с хэшем.

Что откуда читается и куда пишется? MS SQL имеет три группы дисковых нагрузок.

• Основной файл базы данных с расширением mdb;
• Файл журналов транзакций;
• И системная база данных tempdb, куда складываются все выборки вложенных запросов и все временные таблицы, которые вы генерируете.

Следовательно, для этих файлов вам могут одновременно понадобиться разные стратегии обработки дисковой нагрузки:

• tempdb необходима, чтобы быстро размещать в ней много мелких таблиц и быстро доставать из них данные.
• Файл журналов транзакций должен собирать транзакции и быстро отдавать их в тот момент, когда вы эту транзакцию фиксируете.
• А у базы данных основная задача – не быстро писать, а быстро оттуда читать. Например, когда у вас запуск проекта выполняется впервые – активных пользователей еще нет, в памяти SQL-сервера какие-либо данные вообще отсутствуют, вам необходима максимальная пропускная способность, чтобы эти данные оттуда достать и разместить в качестве кэша. Потому что быстрый старт – это важно.

Дисковая нагрузка для кластера 1С – это дикая штука. Почему?

Например, в каталог кластера 1С могут складываться результаты выборки запросов. Как это выглядит? На сайте 1С:ИТС существует рекомендация не использовать выгрузку таблицы из результатов запроса, поскольку это накладывает ограничения на память, а использовать вместо этого метод «Выбрать()». И тут возникает такой момент: когда вы для результата запроса делаете «Выгрузить()», у вас весь результат запроса попадает в память вне зависимости от размера таблицы. А когда вы делаете «Выбрать()», результат запроса попадает на диск. Получается, что если вы из запроса хотите выбрать 4 строчки, то кластер 1С сначала запишет весь результат где-нибудь у себя на медленный диск, а потом эти 4 строчки начинает открывать TCP-соединениями и отдавать вашему клиенту. И можно увидеть такую картину – СУБД отрабатывает в течение долей секунды, а выборка результатов затормаживается – особенно, если кластер 1С развёрнут на некэшируемых дисках с отказоустойчивым рейдом.

Согласно материалам ИТС, данное поведение кластера 1С наблюдается только в 32-битной редакции платформы при большой загрузке ОЗУ.

Также важен быстрый доступ в каталог TEMP пользователя, от имени которого запущен кластер 1С. Этот каталог используется для обмена данными через временное хранилище (когда вы вызываете «ПолучитьИзВременногоХранилища» и «ПоместитьВоВременноеХранилище») и работы с фоновыми заданиями – при использовании фоновых заданий туда попадают их параметры.

На слайде показано, каким образом дисковая нагрузка MS SQL Server привязывается непосредственно к коду 1С. Это – код запросов.

• Чёрными кружками обозначено, где идет нагрузка на базу tempdb;
• А зелеными – где идет чтение из основной базы данных.

Казалось бы, все очевидно.

Теперь посмотрим обычный код.

• Здесь показан этот же запрос (я его немножко свернул), он при выполнении вызывает два типа дисковой нагрузки – на файлы базы данных и на файл tempdb, куда будет сложена выборка из результатов запросов.
• И затем, когда мы вызываем метод «Выбрать()», возникает дисковая нагрузка в каталоге кластера 1С (этот тип нагрузки показан розовым кружком) – результат выборки запроса пишется на диск.

А на этом слайде голубым кружком показано, в каком месте кода возникает нагрузка на каталог TEMP пользователя, от имени которого запущен кластер 1С.

Давайте разберемся, как происходит процесс обмена данными между основным потоком приложения и фоновыми заданиями:

• Клиент 1С помещает данные во временное хранилище;
• В этот момент в каталоге TEMP пользователя на стороне клиента образуется файл, в котором закодировано все, что вы передаете.
• Затем открывается TCP-соединение, и этот файл практически сторонними средствами (через winsock.dll) передается на сервер;
• И только после того, как закроется соединение, сервер подберет этот файл и начнет с ним работать.

Поэтому фоновые задания – это вопрос для оптимизации. Не стоит их использовать для того, чтобы передать пару байт, обработать их и героически вернуть. Фоновые задания нужны только для обработки чего-то большого, такого, ради чего стоит заморочиться.

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

Если вы, допустим, запустите параллельно 5-10 фоновых заданий и расставите в отладчике для них точки останова – например, поставите точку останова в первом фоновом задании, а в остальных не поставите. Казалось бы, когда у вас в этом первом фоновом задании срабатывает точка останова, остальные должны работать. Так? Нет, не так.

Дело в том, что кластер 1С генерирует процессы для выполнения вашего кода на серверной стороне. И если у вас сгенерирован один процесс, который обрабатывает 256 соединений с базой данных, то весь контекст выполнения ваших 5-10 фоновых заданий будет находиться в рамках одного физического процесса на стороне кластера. И, останавливая одно фоновое задание, вы останавливаете сразу все фоновые задания, которые крутятся в этом же процессе. Поэтому, пока вы в отладчике не пойдете дальше, ничего не пойдет дальше.

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

Казалось бы, это плохо. Нет. Потому что есть ещё такая вещь, как возврат результатов из фонового задания обратно в основной поток приложений. И в зависимости от того, находится ваша серверная часть в одном физическом процессе с фоновым заданием или в разных, возврат результатов может очень драматически различаться.

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

Смешно, да? То есть, с SQL мы умеем работать через Shared Memory, а внутри кластера 1С не умеем. Это замечательно, это гениальное решение разработчиков.

Бэкграунд нашего проекта

На нашем проекте нам приходится обрабатывать очень много данных – просто невменяемое количество. У нас одна отгрузка содержит порядка 7 тысяч тонн зерна.

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

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

И получается, что в одном документе на 600 морских контейнеров у нас генерируется 112 000 движений. Для нашего старого сервера Fujitsu это было больно – он проводил документ полтора часа. Бесполезно что-то оптимизировать, если оборудование вообще не способно подобный массив данных как-то «пережевывать». Поэтому после исследования вопроса была выдана рекомендация закупать новое железо.

Немного о «железках»

Сначала мы выбирали платформу для сервера – в качестве вариантов рассматривали либо Intel Xeon E5, либо EPYC (новые процессоры AMD, которые могут содержать огромное количество ядер).

Как мы принимали решение? Очень просто – Intel стоит 3000 долларов на один сокет, а EPYC – 750 долларов. Разница в 4 раза – о чем дальше говорить? Но сказать нужно.

Дело в том, что у Intel очень мало линий PCI Express – на одном чипе всего лишь 28 линий, а так как часть из них задействована для нужд чипсета, то максимально на один сокет можно будет получить всего лишь один полноскоростной 16-канальный разъем PCI Express.

А AMD EPYC нам сразу понравился тем, что там на один сокет 128 линий. То есть, туда можно втыкать просто невообразимое количество высокоскоростных плат расширения.

Сэкономленные на Intel деньги мы пустили на покупку лицензий. Это избавило нас от «писем счастья» Microsoft, где было бы написано, что по их данным в нашей компании эксплуатируется не совсем правильное ПО.

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

• Контроллер RAID 5 – в нем куча памяти, но к нему подключены медленные шпиндельные диски с SAS-интерфейсом. То есть, он в состоянии принять в себя до 16 гигабайт данных, после чего у него резко падает производительность приема данных на запись.
• SSD-диск. Он чуть медленнее принимает данные на запись, зато в состоянии очень быстро выдавать данные на чтение.
• Intel Optane характерен тем, что стек команд у него переполняется где-то в 2 раза медленнее, чем у SSD, и он в состоянии чутко реагировать на большое количество мелких запросов. То есть, если у SSD дисков Samsung стек запросов кратен 64 килобайтам (это физическая организация SSD-дисков, где один блок – 64 килобайта), то у Intel Optane один блок – это 4 килобайта. А MS SQL, как вы знаете, читает данные двумя 8-килобайтными страницами (за 1 одну операцию чтения MS SQL считывает 16 килобайт). Поэтому очередь запросов к дискам Intel Optane переполняется несколько медленнее, чем к обычным SSD-дискам.
• И для того, чтобы хранить бэкапы, мы выбрали медленный диск с максимальной в отрасли надежностью – Hitachi. Он имеет наименьшее количество отказов на тысячу проданных накопителей – 0,4% за весь жизненный период. Бэкапы у нас хранятся там.

Настройка системы – простые сложные потоки

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

Дисковый массив на RAID 5 был разделен на 2 части:

• Одна часть – для работы в нормальном режиме эксплуатации, со сбрасыванием буфера записи на диск.
• А для второй части обязательное сбрасывание дискового кэша на физические носители было отключено. На этом диске с отключенной записью был развернут кластер 1С для того, чтобы не наблюдалось проблем с обращением к методу «Выбрать()» и складыванием на диск всех результатов в выборке. Также на этот диск был перенесен каталог всех пользователей.

Это дало значительный выигрыш по скорости обмена данными между различными экземплярами 1С (клиентскими, серверными), между фоновыми заданиями и т.д.

Как мы настраивали MS SQL? На слайде показаны наши настройки параллелизма.

• В инструкции Microsoft описано, что максимальное количество потоков не стоит выставлять больше восьми. А реальное количество потоков должно быть равно количеству физических ядер в одной ноде (если это NUMA-архитектура), либо в одном физическом процессоре (если это процессор Intel, который не умеет применять NUMA-архитектуру). На EPYC первого поколения в одной ноде находится 4 физических ядра и максимальная степень параллелизма была выставлена равной 4.
• Стоимостной порог для параллелизма был подобран опытным путем – мы установили его равным 3, это дало наибольший эффект в наших условиях.

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

Есть только одна проблема – tempdb у вас должен лежать на диске, который не выполняет приоритизацию трафика. Потому что если tempdb лежит на обычном RAID-контроллере MegaRAID, то он при поступлении в стек какого-то очень большого запроса выставляет приоритет на всю дальнейшую обработку данных и тормозит все остальные потоки. И получается, что если мы будем размещать tempdb на обычном RAID-контроллере, то реально будет работать только 1 файл из 8. Поэтому tempdb должен лежать либо на SSD-диске, либо на диске Intel Optane, либо на диске в памяти, но это нерационально.

Что дает «размножение» tempdb? Дело в том, что tempdb – это системная база данных в MS SQL, на которую не распространяются ограничения по условиям лицензирования. Поэтому даже если вы используете Developer Edition, tempdb у вас сможет параллельно работать с 8 файлами. Но с вашими базами данных tempdb будет работать в один поток.

Согласно документации Майкрософт на настройку «affinity mask Server Configuration Option», применяются строгие лицензионные ограничения как для автоматического, так и для ручного режима, что и приводит к отличиям в эксплуатации Enterprise Edition от бесплатных редакций:

«Licensing Issues 

Dynamic affinity is tightly constrained by CPU licensing. SQL Server does not allow any configuration of affinity mask options that violates the licensing policy».

Опытным путем определено, что лицензионные ограничения не затрагивают системные базы данных.

Далее – создаем новую базу данных 1С. Ничем ее не заполняем. Потом заходим в SQL и выполняем настройку базы данных, задавая количество файлов журналов транзакций для нее в пропорции 3:1, то есть на каждые три файла базы данных нам понадобится 1 файл журнала. Эта пропорция была выявлена экспериментальным путём. Общее количество файлов здесь 16.

Почему именно 16? Дело в том, что, покупая сервер на 32 физических ядра, который может обрабатывать 64 логических потока, мы сначала решили посмотреть, как это все будет крутиться на 32. Потому что было непонятно: нужны ли нам лицензии на все 64 логических ядра или нам хватит лицензий на 32.

В дальнейшем этот вопрос выяснился следующим образом. Опять же, как пишет Microsoft, технологии Hyper-Threading, а также технологии SMT – это не про MS SQL. Потому что это работает следующим образом: когда первый логический поток в вашем физическом ядре запрашивает данные, которых нет в кэше первого и второго уровня, его выполнение останавливается, и контекст выполнения переключается на второй логический поток. То есть, в кэше процессора должны быть данные либо для первого, либо для второго потока вашего Hyper-Threading. Либо у вас Windows будет показывать красивую картинку, что процессор загружен на 100%, но это всего лишь означает, что он ждет поступления данных из памяти в кэш. А ребята из Microsoft умные – они за 224 такта до того, как эти данные в кэше понадобятся, посылают команду загрузить их из памяти.

Практика использования MS SQL показала, что включение многопоточности (использование 64 потоков вместо 32), и, соответственно, повышение порога параллелизма с 4 до 8, даёт 5%-ый прирост. Но этот 5%-ый прирост возникает не потому, что технология позволяет, а потому что где-то на задворках начинают эффективно параллелиться DLL-ки Windows, а SQL все равно работает с той же самой скоростью. Предзагрузка данных полностью нивелирует преимущества Hyper-Threading. Поэтому если вы сидите на Intel Xeon с 4 физическими ядрами и 8 потоками, помните, что на самом деле ваш SQL Server крутит все на 4 ядрах, а не на 8 – значение имеют только физические ядра.

Первоначально, на новом сервере, как только мы достали его из коробки, проведение нашего документа с сотней тысяч движений выполнялось 15 минут. Это нас очень опечалило. Потому что на старом сервере оно выполнялась 10 минут. И надо было как-то объяснить, почему новый дорогой сервер работает на 50% медленнее.

Добавление количества файлов экспериментальным путем показало вот такой график – перегиб на нем показывает, при каком количестве файлов время проведения документа стабилизировалось. Соответственно, было установлено, что оптимальный расход лицензий – по две на каждый файл, а поскольку у нас 32 лицензии, то у СУБД должно быть 16 файлов. Большее количество лицензий не имеет смысла – у нас нет столько ядер.

После распараллеливания нагрузки и оптимизации аппаратных настроек нам удалось добиться уменьшения времени проведения с 15 до 2,2 минут.

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

После оптимизации аппаратных настроек общее время открытия рабочего стола, которое складывалось из времени последовательной выборки таблиц плюс время, необходимое на инициализацию управляемой формы, стало 7 секунд. Но мы не остановились на этом результате.

Для уменьшения времени инициализации было решено использовать обработчик формы «ПриСозданииНаСервере», где мы настроили запуск 15 фоновых заданий (по одному на каждую таблицу управленческих данных). Дело в том, что обработчик управляемой формы «ПриСозданииНаСервере» запускается до того, как вообще начинается инициализация. Это особенно хорошо было видно на старых сырых версиях веб-интерфейса 1С: если при создании происходило обращение к данным формы, то браузер не успевал их сгенерировать, и выскакивали сообщения вида «is not null» и т.д. Поэтому в обработчике «ПриСозданииНаСервере» мы генерируем фоновые задания по выборке данных, объединенные в 3 группы, которые подобраны по среднему времени выполнения. Эмпирическим путем таблицы побольше были отнесены к третьей группе фоновых заданий, поменьше – ко второй и самые маленькие к первой.

• Первыми у меня отрабатывают самые маленькие 8 таблиц - я ожидаю выполнения 8 фоновых заданий и когда получаю от системы информацию, что они отработали, забираю эти данные и начинаю размещать их на управляемой форме;
• На следующем этапе производится выборка данных по второй группе таблиц, куда относится обработка заказов поставщикам и заказов покупателей;
• И на последнем этапе формируется самая большая таблица - это обеспечение заказов:
  • обеспечение за счет перемещаемых товаров (внутрискладские перемещения);
  • обеспечение за счет еще не выполненных заказов поставщику;
  • и обеспечение за счет существующих складских остатков (это самый длинный запрос, для которого в принципе нереально его дальнейшее разделение на более элементарные задачи).

После того как мы переместили выборку данных в фоновые задания, и эти выборки стали обрабатываться параллельно, самый длительный запрос при первом обращении к СУБД на SSD-диске у меня получился 1,5 секунды. Я имею в виду стартовое чтение данных с SSD-диска, когда их еще нигде больше нет, при втором обращении, когда SQL-сервер уже держит все данные в памяти, показатели гораздо меньше.

Теперь самым «узким» местом стала инициализация управляемой формы – непосредственно уже 1С-овский механизм. И тут первое, что выяснилось – работа клиента 1С внутри виртуального Windows-сервера происходит быстрее, чем внутри физического Windows-сервера. Т.е. на хосте сервера в принципе никогда нельзя запускать клиента 1С, потому что это – системный супервайзер, и там работа клиентских приложений будет постоянно «спотыкаться» о различные системные проверки, запросы прав доступа. Поэтому для клиента 1С использовать RDP на виртуалку выгоднее, чем RDP на хост.

Дальше – после анализа этих «узких» мест был найден замечательный процессор в линейке Intel – это NUC7i7BNH Baby Canyon, процессор с кэшем четвертого уровня на базе памяти eDram. Intel позиционирует эти процессоры как «тихие» рабочие станции, которых не слышно, не видно и которые быстро работают.

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

В итоге мы добились уменьшения времени открытия рабочего стола с 15 до 0,3 секунд, теперь он открывается «на щелчок» – очень быстро, очень хорошо.

Update: текстовая версия доклада исправлена 27.06.2019.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019!