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

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

1. 
   Проверить, является ли данное натуральное число числом Фибоначчи
   

2. Проверить, является ли данное натуральное число палиндромом (перевертышем). Натуральное число называется палиндромом, если его запись читается одинаково с начала и с конца, например, 2332, 313, 6.
3. Две точки на плоскости заданы своими координатами. Выяснить, образуют ли эти точки вместе с центром координат прямоугольный треугольник.
4. Проверить, можно ли представить данное натуральное число в виде суммы квадратов двух натуральных чисел.

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


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

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

Ранее, когда шардирование вводилось для масштабирования реплицированных систем, оно осуществлялось на уровне отдельных запросов. Для определения того, на какой узел направить запрос, использовался некоторый его фрагмент. Этот узел впоследствии полностью обрабатывал запрос и выдавал ответ пользователю. В случае шардирования Scatter/Gather, напротив, запрос отправляется всем терминальным узлам (шардам) в системе. Каждый терминальный узел обрабатывает запрос, используя данные, содержащиеся в своем шарде. Частичный ответ возвращается корневому узлу — он объединяет все частичные ответы в один полный ответ, который и возвращается пользователю.
В качестве конкретного примера такой архитектуры рассмотрим реализацию поиска в большом массиве документов (например,
среди всех патентов в мире). Такой массив данных слишком велик для одной машины, поэтому данные шардируются среди нескольких экземпляров сервиса. Первые 100 тысяч патентов, к примеру, могут находиться на первой машине, вторые 100 тысяч — на второй и т. д. Заметьте, подобная схема шардирования плоха тем, что по мере регистрации новых патентов придется
добавлять в систему новые шарды. На практике следует использовать остаток от деления номера патента на общее количество шардов. Когда пользователь делает поисковый запрос по всем патентам с определенным словом (к примеру, «ракеты»), запрос отправляется всем экземплярам сервиса, каждый из которых затем выполняет поиск совпадений в своем шарде В ответ на шардированный запрос все найденные совпадения возвращаются корневому узлу сервиса. Корневой узел затем объединяет все ответы в один общий ответ, который содержит все патенты, включающие определенное слово. Схема работы такого поисковика изображена на рис. 7.3

Элемент <application> также поддерживает атрибут android:process, позволяющий задать значение по умолчанию, которое применяется ко всем компонентам.
Система Android пытается сохранять процесс приложения как можно дольше, но в конечном счете вынуждена удалять старые процессы, чтобы восстановить память для новых или более важных процессов. Чтобы определить, какие процессы сохранить, а какие удалить, система помещает каждый процесс в «иерархию важности» на основе компонентов, выполняющихся в процессе, и состояния этих компонентов. Процессы с самым низким уровнем важности исключаются в первую очередь, затем исключаются процессы следующего уровня важности и т. д., насколько это необходимо для восстановления ресурсов системы.