Как загружать большие объемы данных? Часть 1.

Привет, друзья! Наша команда более 10 лет занимается вопросами эффективной передачи данных на мобильные устройства. Мы исследовали разные варианты: одни оказались слишком медленными, другие приводили к переполнению памяти на мобильном устройстве.

Хотим рассказать, как мы в команде «Форсайт. Мобильная платформа» сделали синхронизацию больших объемов данных, чтобы это работало, в том числе, на ТСД (терминал сбора данных). Для экономии батареи ТСД специально снабжают слабыми процессорами. Весь подбор инструментов и алгоритмов мы уже апробировали в продукте «Форсайт. Мобильная платформа» (ФМП).

Специфичные условия для мобильного приложения начнем РАЗБИРАТЬ С КРЫШИ, так будет проще подобраться к существу вопроса. В среднем, отличие общедоступных приложений от бизнес-приложений – в объеме потребляемых данных. У бизнес-приложений объем данных значительно больше. Но, как водится, ожидание бизнес-пользователей от приложения точно такие же, как и у всех: приложение должно работать не просто быстро, а моментально. А это значит, что нужно найти особые техники по ускоренной передаче данных. При подборе технологий для транспорта данных нам хотелось получить:

А) Стабильный механизм передачи данных.

Б) Самый быстрый/производительный протокол из возможных.

Поскольку мы производим спецшину по транспорту данных, для нас это означает, что мобильный пользователь будет обращаться в наш инструмент за «чемоданом» данных, и мы должны как можно быстрее передать ему этот «чемодан» целиком. У разработчиков возникает вопрос — насколько большой может быть «чемодан»? Насколько будет нескромен кейс, который нужно будет тащить? За ориентир мы взяли ½ миллиона записей табличных данных.

У вас может возникнуть вопрос: зачем тащить ½ миллиона записей на мобильное устройство?

ВЫ АРХИТЕКТУРНО НЕ ТАК ДЕЛАЕТЕ! Ведь можно подгружать данные по мере необходимости.

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

70% пользователей сообщили: «нормально работает».

30% пользователей написали: «приложение работает плохо, зависает и не грузит».

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

Снова смотрим на архитектуру перегрузки ½ миллиона записей. Будем исследовать, какой протокол даёт приемлемую надёжность и скорость. Для этапа загрузки БОЛЬШИХ данных мы стали применять термин «Первичная синхронизация». Процедура может быть сверхтяжёлая, и всё равно было нужно, чтобы она проходила гладко, не падала из‑за переполнения памяти, какой бы объем ни тащили в мобильное приложение.

Проводя исследования и сравнения различных форматов и протоколов, мы выделили:

1. Большие объемы способен передать потоковый алгоритм. Он же показал низкую чувствительность к объемам данных.

2. Максимальную стабильность в разных условиях связи имеет потоковый алгоритм передачи. Так как есть механизм дозагрузки пакета.

3. За счёт объявления в заголовке структуры данных и далее передачи массива значений через разделитель (без сжатия GZip), мы увидели сопоставимый размер данных, передаваемых по сети.

Что получаем? Давайте сравним и подытожим:

Посмотрите на схему в точку «А» на мобильном устройстве. Изначально тут мы с благими намерениями сделали несколько лишних вычислений, которые потом пришлось исправлять.

Перечислим лишние, если вы решите повторять алгоритм:

1. При разрыве соединения возобновление дозагрузки начинается со следующего байта. Хотели максимально сэкономить трафик. Подсчёт байтов реализовали через запись в промежуточный файл.

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

3. Проводили на устройстве конвертацию формата из JSon в SQL команду.

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

1. Внутри формата JSon на сервере ФМП мы стали формировать записи в нотации SQL языка, чтобы не делать этого на мобильном устройстве, а сразу брать пакет и делать вставку в БД.

2. Возобновление дозагрузки стали делать по ID номеру строки, внутри пакета, перестали считать номера байтов и стали использовать ID номера строки.

3. Отказались от промежуточного формирования файла.

Мы рекомендуем избегать записей в промежуточный файл. Если задача записать в БД, проектируйте вставку (insert) без промежуточных вычислений и действий. В этом случае вы, как и мы, приблизитесь к скорости, фактически равной ширине предоставляемого канала.

У ФМП сложилась схема из двух частей:

А) серверная часть умеет отправлять данные в потоке
Б) мобильный фреймворк умеет принимать поток и складывать его в БД на телефоне.

Посмотрите на схему ниже.

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

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

Посмотрите листинг кода на Kotlin для Android Фреймворка. Под столь компактный код упакованы:

1. Аутентификация

2. Создание БД

3. Создание структур в БД под хранение объекта данных

4. Обработка входного потока данных

5. Чтение данных из БД.

val fmp: FMP = FMP.Builder() // Создать конструктор FMP.
.api(FMP.API.V2) // Указать версию API сервера.
.address("https://HOST") // Адрес сервера платформы.
.environment("ENVIRONMENT") // Среда на сервере.
.project("PROJECT") // Проект внутри среды.
.username("USERNAME") // имя пользователя.
.deviceID("device_id") // Указать ID устройства.
.storage("/path/to/storage") // Указать рабочую директорию.
.build() // Создать FMP.

val auth_password: FMPResult = fmp.user.auth("password") // Аутентификация по паролю.

val resource: FMPResource = fmp.resource
.name("...") // Указать название ресурса на сервере.
.params("...") // Указать параметры ресурса.
.cacheByParams(true) // Использовать кэширование по параметрам.
.delta(true) // Использовать дельту.
.filter(true) // Использовать фильтрацию FMPQuery.
.build() // Получить FMPResource.

val download: FMPResult = resource.download() // Потоковая загрузка данных ресурса и сохранение в БД на телефоне.

val tableData: FMPResult>> = resource.database.select("SELECT * FROM mTable;") // 

Получение данных из БД на телефоне.

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

Взгляните на схему, на ней за единицу времени удвоили производительность, можно запустить ещё несколько параллельных потоков, и тогда будет в три раза быстрее и так далее x4, x5…

Что можем порекомендовать: первым на загрузку ставьте самый большой по объёму справочник. Параллельно запрашивайте цепочку из меньших по объёму.

В схеме с многопотоковой загрузкой часто бывает, что время на загрузку коррелирует с объёмом самого большого справочника.

Ниже приведём
package ru.fsight.fmp.test

import org.junit.After
import org.junit.Before
import org.junit.Test
import org.junit.Assert
import ru.fsight.fmp.FMP
import ru.fsight.fmp.FMPQuery
import ru.fsight.fmp.FMPResource
import ru.fsight.fmp.FMPResult

class SandboxTest {

@Before
fun setUp() {
}

@After
fun cleanUp() {
}

@Test
fun `Initialization FMP`() {
	val fmp: FMP = FMP.Builder()
		.address("http://mobilefmp.dev.fs.fsight.world")
		.environment("env_denis")
		.project("proj_test")
		.api(FMP.API.V2)
		.deviceID("denistest")
		.storage("./test")
		.username("test")
		.build()
}

@Test
fun `User authentication by password`() {
	val fmp: FMP = FMP.Builder()
		.address("http://mobilefmp.dev.fs.fsight.world")
		.environment("env_denis")
		.project("proj_test")
		.api(FMP.API.V2)
		.deviceID("denistest")
		.storage("./test")
		.username("test")
		.build()
	val auth: FMPResult = fmp.user.auth("testtest")
}

@Test
fun `Getting the resource data manually`() {
	val fmp: FMP = FMP.Builder()
		.address("http://mobilefmp.dev.fs.fsight.world")
		.environment("env_denis")
		.project("proj_test")
		.api(FMP.API.V2)
		.deviceID("denistest")
		.storage("./test")
		.username("test")
		.debug(false)
		.build()
	val auth: FMPResult = fmp.user.auth("testtest")
	val resource_1: FMPResource = fmp.resource
		.name("GetPlanningPeriodsCount")
		.params("{\"Count\":500000}") // 1C Basic
		.build()

	val resource_2: FMPResource = fmp.resource
		.name("GetPlanningPeriodsCount_2")
		.params("{\"Count\":500000}")
		.build()

	val resource_3: FMPResource = fmp.resource
		.name("GetPlanningPeriodsCount_3")
		.params("{\"Count\":500000}")
		.build()

	val start = System.currentTimeMillis()
	var total1 = 0L
	var total2 = 0L
	var total3 = 0L

	val t1 = Thread {
		val start1 = System.currentTimeMillis()
		val Download_1 = resource_1.download()
		total1 = System.currentTimeMillis() - start1
	}
	val t2 = Thread {
		val start2 = System.currentTimeMillis()
		val Download_2 = resource_2.download()
		total2 = System.currentTimeMillis() - start2
	}
	val t3 = Thread {
		val start3 = System.currentTimeMillis()
		val Download_3 = resource_3.download()
		total3 = System.currentTimeMillis() - start3
	}

// Parallel //параллельная
t1.start()
t2.start()
t3.start()
t1.join()
t2.join()
t3.join()

// Seq //последовательная
//t1.start()
//t1.join()
//t2.start()
//t2.join()
//t3.start()
//t3.join()

	val total = System.currentTimeMillis() - start
	println("Total = ${total}, 1 = ${total1}, 2 = ${total2}, 3 = ${total3}")

}

}

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

• Затрат времени почти нет, код компактный и понятный.

• Не нужно тратить время на апробации подходящих решений для надёжной загрузки больших объёмов.

• Стабилизация приложения также занимает меньше времени. А это, как вы знаете, наиболее эмоционально напряжённая часть проекта. Из-за возможных остановок сервиса и перевыпуска релизных сборок.

Как итог — бизнес‑пользователь получает приложение быстрее, а значит дешевле.

Желаем всем добра и высокой скорости передачи данных.