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

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

Второй терминальный узел обслуживает документы 11–20 и возвращает {doc15}. Третий терминальный узел обслуживает документы 21–30 и возвращает {doc22, doc28}. Корневой узел объединяет ответы и возвращает множество {doc1, doc5, doc15, doc22, doc28}. По этой же причине ресиверы должны использовать службы, а не просто ставить в поток операции, требующие много времени для выполнения.

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

Важно, однако, понимать, что объем накладных расходов в реализации паттерна Scatter/Gather растет с увеличением количества терминальных узлов. Поэтому, несмотря на их небольшой объем, с ростом степени распараллеливания расходы на них со временем могут превысить расходы на реализацию бизнес-логики приложения. А это значит, что рост производительности за счет распараллеливания носит асимптотический характер. Помимо того что добавление терминальных узлов может и не ускорить обработку запросов, Scatter/Gather-системы также подвержены «эффекту отстающего». Чтобы понять причину этого, важно помнить, что в Scatter/Gather-системе корневой узел сможет отправить ответ конечному пользователю не ранее, чем дождется ответа от всех терминальных узлов. Поскольку необходимо получить данные от всех узлов, общее время обработки запроса определяется временем обработки запроса самым медленным узлом. Попытаемся понять, как это влияет на производительность, и рассмотрим сервис, в котором 99-й процентиль задержки составляет 2 секунды. Это значит, что в среднем один из 100 запросов будет обработан с задержкой 2 секунды и более. Иными словами, обработка запроса займет 2 секунды и более с вероятностью 1 %. На первый взгляд, это совершенно приемлемо, так как только один из 100 запросов будет обрабатываться медленно.