Оптимальным решением проблемы информационного взаимодействия САПР на предприятии является внедрение базовой САПР предприятия, которая будет выступать связующим звеном, объединяющим разнородные результаты инженерного труда в единую открытую информационную систему.

Рассмотрим Solidworks как открытую информационную систему, проанализировав некоторые свойства открытой системы:

· Расширяемость;

· Масштабируемость;

· Интероперабельность;

· Способность к интеграция.

Расширяемость

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

Немаловажным при выборе САПР является вопрос расширяемости системы, а именно SolidWorks предлагает пользователям самый широкий выбор дополнений для программного комплекса. Для решения различных прикладных инженерных задач разработчики SolidWorks использовали дополнения MSC.visualNastran, Sigmund1D и EmbassyWorks. Выбор данных изменений был обусловлен двумя факторами. Во-первых, они позволяют решить поставленные задачи с минимальными затратами времени и средств, а во-вторых, эти изменения являются важными для пользователя, использующего SolidWorks, что исключает трудности с передачей геометрии, полностью сохраняет параметризацию и упрощает работу с данными комплексами и увеличивает функционал всей системы.

Например, для расчета напряжений и деформаций конструкций была использовано дополнение MSC.visualNastran. Оно позволяет проводить прочностные расчеты в упруго-линейной зоне с учетом малых деформаций. Его также можно использовать для определения собственных частот и форм колебаний; критических сил и форм потери устойчивости; проведения теплового анализа. Дополнение также включает модуль, позволяющий оптимизировать параметры конструкции при заданных ограничениях.

Масштабируемость

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

Разработчики SolidWorks большое внимание уделяют работе с комплексными сборками, количество компонентов которых может составлять десятки и сотни тысяч единиц. Безусловно, для работы с такими моделями требуется использовать специальные методики управления отдельными деталями и узлами сборки, рационально распоряжаться ресурсами процессора и оперативной памяти. Для этого в SolidWorks существует специальный режим, который так и называется "Режим работы с большими сборками". Этот режим позволяет оптимально распределить программные и аппаратные ресурсы, экономя, таким образом, время загрузки и перестроения сборки.

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

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров - обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности - это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке - сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

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

Типичная архитектура сайта

Жизнь типичного сайта начинается с очень простой архитектуры
- это один web-сервер (обычно в его роли выступает Apache),
который занимается всей работой по обслуживанию HTTP-запросов,
поступающих от посетителей. Он отдает клиентам так называемую «статику», то
есть файлы, лежащие на диске сервера и не требующие обработки: картинки (gif,
jpg, png), листы стилей (css), клиентские скрипты (js, swf). Тот же сервер
отвечает на запросы, требующие вычислений - обычно это формирование
html-страниц, хотя иногда «на лету» создаются и изображения и другие документы.
Чаще всего ответы на такие запросы формируются скриптами, написанными на php,
perl или других языках.

Минус такой простой схемы работы в том, что разные по
характеру запросы (отдача файлов с диска и вычислительная работа скриптов)
обрабатываются одним и тем же web-сервером. Вычислительные запросы требуют
держать в памяти сервера много информации (интерпретатор скриптового языка,
сами скрипты, данные, с которыми они работают) и могут занимать много
вычислительных ресурсов. Выдача статики, наоборот, требует мало ресурсов
процессора, но может занимать продолжительное время, если у клиента низкая
скорость связи. Внутреннее устройство сервера Apache предполагает, что каждое
соединение обрабатывается отдельным процессом. Это удобно для работы скриптов,
однако неоптимально для обработки простых запросов. Получается, что тяжелые (от
скриптов и прочих данных) процессы Apache много времени проводят в ожидании (сначала при получении
запроса, затем при отправке ответа), впустую занимая память сервера.

Решение этой проблемы - распределение работы по обработке
запросов между двумя разными программами - т.е. разделение на frontend и
backend. Легкий frontend-сервер выполняет задачи по отдаче статики, а остальные
запросы перенаправляет (проксирует) на backend, где выполняется формирование
страниц. Ожидание медленных клиентов также берет на себя frontend, и если он использует
мультиплексирование (когда один процесс обслуживает нескольких клиентов - так
работают, например, nginx или lighttpd), то ожидание практически ничего не
стоит.

Из других компонент сайта следует отметить базу данных, в
которой обычно хранятся основные данные системы - тут наиболее популярны
бесплатные СУБД MySQL и PostgreSQL. Часто отдельно выделяется хранилище
бинарных файлов, где содержатся картинки (например, иллюстрации к статьям
сайта, аватары и фотографии пользователей) или другие файлы.

Таким образом, мы получили схему архитектуры, состоящую из
нескольких компонент.

Обычно в начале жизни сайта все компоненты архитектуры
располагаются на одном сервере. Если он перестает справляться с нагрузкой, то
есть простое решение - вынести наиболее легко отделяемые части на другой
сервер. Проще всего начать с базы данных - перенести ее на отдельный сервер и
изменить реквизиты доступа в скриптах. Кстати, в этот момент мы сталкиваемся с
важностью правильной архитектуры программного кода. Если работа с базой данных
вынесена в отдельный модуль, общий для всего сайта - то исправить параметры
соединения будет просто.

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

Распределение вычислений

Типичная ситуация для растущего сайта - база данных уже
вынесена на отдельную машину, разделение на frontend и backend выполнено,
однако посещаемость продолжает увеличиваться и backend не успевает обрабатывать
запросы. Это значит, что нам необходимо распределить вычисления на несколько
серверов. Сделать это просто - достаточно купить второй сервер и поставить на
него программы и скрипты, необходимые для работы backend.
После этого надо сделать так, чтобы запросы пользователей распределялись
(балансировались) между полученными серверами. О разных способах балансировки
будет сказано ниже, пока же отметим, что обычно этим занимается frontend,
который настраивают так, чтобы он равномерно распределял запросы между
серверами.

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

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

• Синхронизация на уровне приложения . В этом случае наши
  скрипты самостоятельно записывают изменения на все копии базы данных (и сами несут
  ответственность за правильность данных). Это не лучший вариант, поскольку он
  требует осторожности при реализации и весьма неустойчив к ошибкам.
• Репликация - то есть автоматическое тиражирование
  изменений, сделанных на одном сервере, на все остальные сервера. Обычно при
  использовании репликации изменения записываются всегда на один и тот же сервер - его называют master, а остальные копии - slave. В большинстве СУБД есть
  встроенные или внешние средства для организации репликации. Различают
  синхронную репликацию - в этом случае запрос на изменение данных будет ожидать,
  пока данные будут скопированы на все сервера, и лишь потом завершится успешно - и асинхронную - в этом случае изменения копируются на slave-сервера с
  задержкой, зато запрос на запись завершается быстрее.
• Multi-master репликация. Этот подход аналогичен
  предыдущему, однако тут мы можем производить изменение данных, обращаясь не к
  одному определенному серверу, а к любой копии базы. При этом изменения
  синхронно или асинхронно попадут на другие копии. Иногда такую схему называют
  термином «кластер базы данных».

Возможны разные варианты распределения системы по серверам.
Например, у нас может быть один сервер базы данных и несколько backend (весьма
типичная схема), или наоборот - один backend и несколько БД. А если мы масштабируем
и backend-сервера, и базу данных, то можно объединить backend и копию базы на
одной машине. В любом случае, как только у нас появляется несколько экземпляров
какого-либо сервера, возникает вопрос, как правильно распределить между ними
нагрузку.

Методы балансировки

Пусть мы создали несколько серверов (любого назначения - http, база данных и т.п.), каждый из которых может обрабатывать запросы. Перед
нами встает задача - как распределить между ними работу, как узнать, на какой
сервер отправлять запрос? Возможны два основных способа распределения запросов.

• Балансирующий узел . В этом случае клиент шлет запрос на один
  фиксированный, известный ему сервер, а тот уже перенаправляет запрос на один из
  рабочих серверов. Типичный пример - сайт с одним frontend и несколькими
  backend-серверами, на которые проксируются запросы. Однако «клиент» может
  находиться и внутри нашей системы - например, скрипт может слать запрос к
  прокси-серверу базы данных, который передаст запрос одному из серверов СУБД.
  Сам балансирующий узел может работать как на отдельном сервере, так и на одном
  из рабочих серверов.

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

• Балансировка на стороне клиента . Если мы хотим избежать
  единой точки отказа, существует альтернативный вариант - поручить выбор сервера
  самому клиенту. В этом случае клиент должен знать о внутреннем устройстве нашей
  системы, чтобы уметь правильно выбирать, к какому серверу обращаться.
  Несомненным плюсом является отсутствие точки отказа - при отказе одного из
  серверов клиент сможет обратиться к другим. Однако платой за это является
  усложнение логики клиента и меньшая гибкость балансировки.

Разумеется, существуют и комбинации этих подходов. Например,
такой известный способ распределения нагрузки, как DNS-балансировка, основан на
том, что при определении IP-адреса сайта клиенту выдается
адрес одного из нескольких одинаковых серверов. Таким образом, DNS выступает в
роли балансирующего узла, от которого клиент получает «распределение». Однако
сама структура DNS-серверов предполагает отсутствие точки отказа за счет
дублирования - то есть сочетаются достоинства двух подходов. Конечно, у такого
способа балансировки есть и минусы - например, такую систему сложно динамически
перестраивать.

Работа с сайтом обычно не ограничивается одним запросом.
Поэтому при проектировании важно понять, могут ли последовательные запросы
клиента быть корректно обработаны разными серверами, или клиент должен быть
привязан к одному серверу на время работы с сайтом. Это особенно важно, если на
сайте сохраняется временная информация о сессии работы пользователя (в этом
случае тоже возможно свободное распределение - однако тогда необходимо хранить
сессии в общем для всех серверов хранилище). «Привязать» посетителя к
конкретному серверу можно по его IP-адресу (который, однако, может меняться),
или по cookie (в которую заранее записан идентификатор сервера), или даже
просто перенаправив его на нужный домен.

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

Распределение данных

Мы научились распределять вычисления, поэтому большая
посещаемость для нас не проблема. Однако объемы данных продолжают расти,
хранить и обрабатывать их становится все сложнее - а значит, пора строить
распределенное хранилище данных. В этом случае у нас уже не будет одного или
нескольких серверов, содержащих полную копию базы данных. Вместо этого, данные
будут распределены по разным серверам. Какие возможны схемы распределения?

• Вертикальное распределение (vertical partitioning) - в простейшем случае
  представляет собой вынесение отдельных таблиц базы данных на другой сервер. При
  этом нам потребуется изменить скрипты, чтобы обращаться к разным серверам за
  разными данными. В пределе мы можем хранить каждую таблицу на отдельном сервере
  (хотя на практике это вряд ли будет выгодно). Очевидно, что при таком
  распределении мы теряем возможность делать SQL-запросы, объединяющие данные из
  двух таблиц, находящихся на разных серверах. При необходимости можно реализовать
  логику объединения в приложении, но это будет не столь эффективно, как в СУБД.
  Поэтому при разбиении базы данных нужно проанализировать связи между таблицами,
  чтобы разносить максимально независимые таблицы.

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

• Горизонтальное распределение (horizontal partitioning) - заключается в
  распределении данных одной таблицы по нескольким серверам. Фактически, на
  каждом сервере создается таблица такой же структуры, и в ней хранится
  определенная порция данных. Распределять данные по серверам можно по разным
  критериям: по диапазону (записи с id < 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
  А, остальные - на сервер Б) или по значению хэш-функции от некоторого поля
  записи. Горизонтальное разбиение данных позволяет хранить неограниченное
  количество записей, однако усложняет выборку. Наиболее эффективно можно выбирать
  записи только когда известно, на каком сервере они хранятся.

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

Как упоминалось выше, кроме базы данных сайту часто требуется
хранилище для бинарных файлов. Распределенные системы хранения файлов
(фактически, файловые системы) можно разделить на два класса.

• Работающие на уровне операционной системы . При этом для
  приложения работа с файлами в такой системе не отличается от обычной работы с
  файлами. Обмен информацией между серверами берет на себя операционная система.
  В качестве примеров таких файловых систем можно привести давно известное
  семейство NFS или менее известную, но более современную систему Lustre.
• Реализованные на уровне приложения распределенные
  хранилища подразумевают, что работу по обмену информацией производит само
  приложение. Обычно функции работы с хранилищем для удобства вынесены в
  отдельную библиотеку. Один из ярких примеров такого хранилища - MogileFS, разработанная
  создателями LiveJournal. Другой распространенный пример - использование
  протокола WebDAV и поддерживающего его хранилища.

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

Выводы

Подводя итог сказанному, сформулируем выводы в виде кратких тезисов.

• Две основные (и связанные между собой) задачи масштабирования - это распределение вычислений и распределение данных
• Типичная архитектура сайта подразумевает разделение ролей и
  включает frontend, backend, базу данных и иногда хранилище файлов
• При небольших объемах данных и больших нагрузках применяют
  зеркалирование базы данных - синхронную или асинхронную репликацию
• При больших объемах данных необходимо распределить базу данных - разделить
  ее вертикально или горизонтально
• Бинарные файлы хранятся в распределенных файловых системах
  (реализованных на уровне ОС или в приложении)
• Балансировка (распределение запросов) может быть равномерная или
  с разделением по функционалу; с балансирующим узлом, либо на стороне клиента
• Правильное сочетание методов позволит держать любые нагрузки;)

Ссылки

Продолжить изучение этой темы можно на интересных англоязычных сайтах и блогах.

Среди многочисленных функций информационной системы, необходимых для управления сетевой логистикой, остановимся вначале на двух ключевых "сетевых" функциях: управление ассортиментом и поддержка категорийного менеджмента.

1. Управление ассортиментом в сетевой торговой компании.

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

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

Задачу управления ассортиментом можно условно разделить на две подзадачи – "внешнюю" и "внутреннюю".

Первая направлена на работу с покупателем в части ассортимента, вторая – на облегчение работы персонала с ассортиментными категориями.

Успешное решение данных задач должно привести к улучшению результатов продаж товаров.

Для эффективного решения "внешней" группы задач необходимо:

• 1) предоставить информацию о товарах покупателям. Информационные и мультимедийные вспомогательные системы призваны помочь покупателям сориентироваться в безграничном море товаров, сделать правильный выбор и получить ценную информацию в кратчайший срок. В то же время они помогают розничным торговцам проанализировать покупательские предпочтения, стимулировать продажу необходимого товара, оптимизировать компоновку торгового зала, рационально размещать ассортимент, что обеспечивает успешное решение внешних задач автоматизации управления ассортиментом;
• 2) решить задачи персонального маркетинга. Реализация функции персонального маркетинга является одной из важнейших задач управления ассортиментом для форматов "супермаркет" и "гипермаркет". Причем, если для супермаркета наибольшую актуальность имеет ведение именно адресного персонального маркетинга с отслеживанием колебаний в предпочтениях конкретных постоянных клиентов данного магазина, то для гипермаркета имеет значение работа с типовыми группами клиентов, принадлежащими к условно определенной категории постоянных покупателей. Что касается дискаунтеров, то персональный маркетинг для них менее актуален. Для выявления предпочтений постоянных покупателей наличие в информационной системе возможности проведения всестороннего анализа продаж и определения структуры покупок также является крайне важной задачей;
• 3) провести качественный визуальный мерчандайзинг. Эффективная выкладка товаров на полках магазинов существенно увеличивает объемы продаж. Для оценки качества решения задач визуального мерчандайзинга информационная система должна иметь возможность ведения и анализа планограмм, описывающих размещение товаров на полках магазинов.

При решении внутренних задач управления ассортиментом необходимо автоматизировать следующие бизнес-процессы:

1) процесс управления активным ассортиментом (ведение ассортиментных матриц).

Дело в том, что информация о товаре, когда-либо внесенная в базу данных, остается в ней длительное время. Например, при актуальном ассортименте в 7000 наименований товаров в системе может храниться 20–30 тыс. наименований товаров. В этих условиях необходимо предоставить пользователю системы возможность работать только с актуальной информацией об активном ассортименте (рис. 3.4).

Рис. 3.4.

Для решения этой задачи требуется обеспечить выполнение следующих функций:

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

системе (обычно происходит при достижении нулевых запасов);

Удаление информации о товарах на кассовых системах (осуществляется, как правило, после проведения инвентаризации).

Преимущества автоматизации данного бизнес-процесса :

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

Автоматизация данного бизнес-процесса позволяет не допустить движение товара на объект управления, к ассортиментным матрицам которого этот товар не принадлежит (рис. 3.5).

Рис. 3.5.

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

2. Процесс поддержки категорийного менеджмента посредством формирования товарных ракурсов и ракурсов объектов управления, с которыми работает конкретный категорийный менеджер.

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

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

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

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

При этом существует как минимум два базовых типа товарных ракурсов – статические и динамические.

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

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

Рис. 3.6.

С целью эффективного администрирования товарных ракурсов для определения бизнес-единиц лучше их определять на узлах классификатора товаров. Назовем такие ракурсы динамическими (рис. 3.7).

Рис. 3.7.

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

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

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

Рис. 3.8.

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

Эта функция очень важна при реализации логистической концепции VMI, когда поставщик или производитель участвует в управлении цепи поставок "своих" товаров.

В заключение сформулируем несколько выводов из вышесказанного:

• 1) управление ассортиментом торгового предприятия является важнейшей задачей, от качества решения которой напрямую зависит его успех;
• 2) решения внешней группы задач управления ассортиментом, особенно торговых предприятий больших форматов, призваны обеспечить системы информирования покупателей (информационные киоски, мультимедийные терминалы, информационные тележки и т.п.);
• 3) возможность ведения в информационной системе ассортиментных матриц, товарных ракурсов и ракурсов объектов управления облегчает возможность решения внутренней группы задач управления ассортиментом, которая напрямую связана с качеством реализации функции категорийного менеджмента на торговом предприятии.

Масштабируемость информационной системы

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

При этом надо учитывать два аспекта – адекватность росту и масштабируемость системы.

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

Информационные системы, неадекватные росту компании, могут привести к опережающему росту затрат на их эксплуатацию.

В первую очередь, архитектура решения должна соответствовать росту компании. Когда компания растет и насчитывает сотни объектов, построить систему на распределенной архитектуре, на наш взгляд, означает столкнуться с все более возрастающим, в пересчете на каждый магазин, ростом расходов на ИТ-сопровождение.

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

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

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

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

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

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

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

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

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

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

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

вертикальным масштабированием, а второй, выражающийся в увеличении количества сетевых компьютеров (серверов)

распределенной системы – горизонтальным масштабированием.

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

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

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

централизованных служб, данных и алгоритмов. А именно, многие службы централизованы в том смысле, что они реализованы в виде единственного процесса и могут выполняться только на одном компьютере (сервере). Проблема такого подхода заключается в том, что при увеличении числа пользователей или приложений, использующих эту службу, сервер, на котором она выполняется, станет узким местом и будет ограничивать общую производительность. Если даже предположить возможность неограниченного увеличения мощности такого сервера (вертикальное масштабирование), то тогда ограничивающим фактором станет пропускная способность линий связи, соединяющих его с остальными компонентами распределенной системы. Аналогично, централизация данных требует централизованной обработки, приводя к тем же самым ограничениям. В качестве примера преимуществ децентрализованного подхода можно привести службу доменных имен (англ. Domain Name Service, DNS), которая на сегодняшний день является одной из самых больших распределенных систем именования. Служба DNS используется в первую очередь для поиска IP-адресов по доменному имени и обрабатывает миллионы запросов с компьютеров по всему миру. При этом распределенная база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определенному протоколу. Если бы все данные DNS централизовано хранились бы на единственном сервере, и каждый запрос на интерпретацию доменного имени передавался бы на этот сервер, воспользоваться такой системой в масштабах всего мира было бы невозможно.

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

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

Отсутствие знания глобального состояния. Как уже было сказано,

централизованные алгоритмы обладают полной информацией о состоянии всей системы и определяют следующие действия, исходя

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

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

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

что то или иное состояние достигается по ходу выполнения распределенного алгоритма.

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

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

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

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

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

репликацию (англ. replication) и кэширование (англ. caching).

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

каждый файловый сервер обслуживает свой набор файлов из общего адресного пространства. Другим примером может являться уже упоминавшаяся служба доменных имен DNS, в которой все пространство DNS-имен разбивается на зоны, и имена каждой зоны обслуживаются отдельным DNS-сервером.

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

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

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

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

) Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.

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

Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.

Обычно масштабирование подразумевает не переписывание кода, а либо добавление серверов, либо наращивание ресурсов существующего. По этому типу выделяют вертикальное и горизонтальное масштабирование.

Вертикальное — это когда добавляют больше оперативки, дисков и т.д. на уже существующий сервер, а горизонтальное — это когда ставят больше серверов в дата-центры, и сервера там уже как-то взаимодействуют.

Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:

Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.

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

Есть еще один параметр — Response time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.

Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…

Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!

Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.

Все перечисленное достаточно просто и дает вам время. Время на то, что когда-то этого станет мало, и к этому уже сейчас надо готовиться.

Как, вообще, понять, в чем проблема? Либо у вас уже настал highload, а это не обязательно какое-то бешеное число запросов и т.д., это, когда у вас проект не справляется с нагрузкой, и тривиальными способами это уже не решается. Надо расти либо вширь, либо вверх. Надо что-то делать и, скорее всего, на это мало времени, что-то надо придумывать.

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

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

На что нужно обращать внимание прямо сейчас при мониторинге? Это:

1. доступность, т.е. жив сервер, вообще, или нет;
2. нехватка ресурсов диска, процессора и т.д.;
3. ошибки.

Вот список замечательных инструментов, которые позволяют мониторить ресурсы и показывать результаты в очень удобном виде:

Этот доклад - расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем за 2015 год.

Старьё! - скажите вы.
- Вечные ценности! - ответим мы. Добавить метки