Практическая работа №13 Развертывание реализации паттерна Ambassador и сервиса memcache для организации шардированного кэша

Задания для выполнения практической работы.

1. 
   Дана последовательность целых чисел а 1, а2, ..., аn. Выяснить, является ли она возрастающей последовательностью простых чисел.
   
2. 
   Даны действительные числа c₁, c₂, ., c_n. Найти произведение среднего арифметического положительных чисел и среднего арифметического отрицательных чисел.
   
3. 
   Даны действительные числа c1, c2, ., cn. Найти произведение суммы чисел с четными индексами и суммы чисел с нечетными индексами.
   
4. 
   Даны целые числа а 1, а2, ..., аn. ПустьМ - наибольшее, а m -наименьшее этих чисел. Получить в порядке возрастания все целые из интервала (m, М), которые не входят в последовательность а 1, а2, ..., аn.
   
5. 
   Дана последовательность чисел а 1, а2, ..., аn. Найти положительную подпоследовательность наибольшей длины.
   

Практическая работа №18


Шардированный поиск в документах
Цель работы: Научится использовать шардированный поиск в документах.
Теоретическая часть.

В предыдущем примере подзапросы отдельных термов распределялись по всему кластеру. Это работает только в том случае, когда все документы реплицированы на все машины в Scatter/ Gather-дереве. Если в каждом отдельном терминальном узле дерева не хватает места для хранения всех документов, приходится прибегать к шардированию, чтобы разные подмножества документов хранились в разных узлах.

Это значит, что, когда пользователь запрашивает все документы, содержащие слова «кот» и «собака», его запрос отправляется всем терминальным узлам Scatter/Gather-дерева. Каждый терминальный узел возвращает набор известных ему документов, содержащих слова «кот» и «собака». Ранее корневой узел отвечал за пересечение наборов документов, возвращенных для каждого поискового терма. В случае шардированного сервиса корневой узел отвечает за вычисление теоретико-множественного объединения наборов документов, возвращенных шардами, которое и является конечным результатом, отправляемым пользователю.
Еще раз посмотрите на рис. 7.3. Первый терминальный узел обслуживает документы 1–10 и возвращает {doc1, doc5}. Второй терминальный узел обслуживает документы 11–20 и возвращает {doc15}. Третий терминальный узел обслуживает документы 21–30 и возвращает {doc22, doc28}. Корневой узел объединяет ответы и возвращает множество {doc1, doc5, doc15, doc22, doc28}.
Может показаться, что в рамках паттерна Scatter/Gather всегда имеет смысл реплицировать вычисления на как можно большее количество узлов. Распараллеливая вычисления, вы сокращаете время обработки конкретного запроса. Увеличение степени распараллеливания несет с собой дополнительные расходы, поэтому для достижения максимальной производительности в распределенной системе чрезвычайно важно правильно выбрать количество терминальных узлов.

Чтобы понять, почему так происходит, следует рассмотреть две вещи. Во-первых, обработка каждого конкретного запроса. подразумевает определенные накладные расходы. Требуется время на анализ запроса, на его пересылку по сети и т. д. В общем случае накладные расходы на обработку запроса операционной системой постоянны и сравнительно невелики по отношению ко времени обработки запроса в пользовательском режиме. Соответственно, при оценке производительности реализации паттерна Scatter/Gather ими, как правило, можно пренебречь.

Важно, однако, понимать, что объем накладных расходов в реализации паттерна Scatter/Gather растет с увеличением количества терминальных узлов. Поэтому, несмотря на их небольшой объем, с ростом степени распараллеливания расходы на них со временем могут превысить расходы на реализацию бизнес-логики приложения. А это значит, что рост производительности за счет распараллеливания носит асимптотический характер. Помимо того что добавление терминальных узлов может и не ускорить обработку запросов, Scatter/Gather-системы также подвержены «эффекту отстающего». Чтобы понять причину этого, важно помнить, что в Scatter/Gather-системе корневой узел сможет отправить ответ конечному пользователю не ранее, чем дождется ответа от всех терминальных узлов. Поскольку необходимо получить данные от всех узлов, общее время обработки запроса определяется временем обработки запроса самым медленным узлом. Попытаемся понять, как это влияет на производительность, и рассмотрим сервис, в котором 99-й процентиль задержки составляет 2 секунды. Это значит, что в среднем один из 100 запросов будет обработан с задержкой 2 секунды и более. Иными словами, обработка запроса займет 2 секунды и более с вероятностью 1 %. На первый взгляд, это совершенно приемлемо, так как только один из 100 запросов будет обрабатываться медленно.
Кроме того, вы можете подписаться на изменение данных в реальном времени. Вы будете получать уведомления об обновлениях данных, например, другими пользователями. Сервис предлагает простой REST API . Но наиболее эффективным способом коммуникации является модель публикации и подписки через веб-сокеты.
Звучит сложно? Google предлагает отдельный SDK для каждой платформы. С Felgo & Qt вам не нужно беспокоиться о различиях в платформах. Felgo включает кроссплатформенный плагин Google Firebase Realtime Database . Один и тот же API на основе QML / JavaScript работает как для Android, так и для iOS.
Если вам нужна помощь в этом, проконсультируйтесь или поручите разработку приложения Felgo .