масштабировать — Викисловарь
| Слово дня 12 апреля 2014. |
Содержание
- 1 Русский
- 1.1 Морфологические и синтаксические свойства
- 1.2 Произношение
- 1.3 Семантические свойства
- 1.3.1 Значение
- 1.3.2 Синонимы
- 1.3.3 Антонимы
- 1.3.4 Гиперонимы
- 1.3.5 Гипонимы
- 1.4 Родственные слова
- 1.5 Этимология
- 1.6 Фразеологизмы и устойчивые сочетания
- 1.7 Перевод
- 1.8 Библиография
Морфологические и синтаксические свойства
| наст./будущ. | прош. | повелит. | |
|---|---|---|---|
| Я | масштаби́рую | масштаби́ровал масштаби́ровала | — |
| масштаби́руешь | масштаби́ровал масштаби́ровала | масштаби́руй | |
| Он Она Оно | масштаби́рует | масштаби́ровал масштаби́ровала масштаби́ровало | — |
| Мы | масштаби́руем | масштаби́ровали | — |
| Вы | масштаби́руете | масштаби́ровали | масштаби́руйте |
| Они | масштаби́руют | масштаби́ровали | — |
| Пр. действ. наст. | масштаби́рующий | ||
| Пр. действ. прош. | масштаби́ровавший | ||
| Деепр. наст. | масштаби́руя | ||
| Деепр. прош. | масштаби́ровав, масштаби́ровавши | ||
| Пр. страд. наст. | масштаби́руемый | ||
| Пр. страд. прош. | масштаби́рованный | ||
| Будущее | буду/будешь… масштаби́ровать | ||
мас-шта-би́-ро-вать
Глагол, двувидовой (может образовывать формы совершенного и несовершенного вида), переходный, тип спряжения по классификации А. Зализняка — 2a.
Корень: -масштаб-; суффиксы: -ир-ова; глагольное окончание: -ть.
Произношение
- МФА: [məʂtɐˈbʲirəvətʲ]
Семантические свойства
Значение
- спец. изменять (изменить) масштаб, размах чего-либо; делать (сделать) более масштабным что-либо ◆ Отсутствует пример употребления (см. рекомендации).
- спец. изменять (изменить) масштаб, представлять (представить) в другом масштабе (об изображениях, шрифтах и т. п.) ◆ Отсутствует пример употребления (см. рекомендации).
Синонимы
Антонимы
Гиперонимы
Гипонимы
Родственные слова
| Ближайшее родство | |
| |
Этимология
Происходит от сущ. масштаб, далее из нем. Maßstab «линейка», далее из Maß «мера» + Stab «палка, веха». Русск. масштаб (впервые маштаб) — при Петре I. Использованы данные словаря М. Фасмера. См. Список литературы.
Фразеологизмы и устойчивые сочетания
Перевод
| изменять (изменить) масштаб, размах чего-либо | |
| |
| изменять (изменить) масштаб изображения | |
| |
Библиография
Для улучшения этой статьи желательно:
|
ru.wiktionary.org
Масштабируемость — Википедия
Материал из Википедии — свободной энциклопедии
Масштаби́руемость (англ. scalability) — в электронике и информатике означает способность системы, сети или процесса справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов (обычно аппаратных).
Масштабируемость — важный аспект электронных систем, программных комплексов, систем баз данных, маршрутизаторов, сетей и т. п., если для них требуется возможность работать под большой нагрузкой. Система называется
В системе с плохой масштабируемостью добавление ресурсов приводит лишь к незначительному повышению производительности, а с некоторого «порогового» момента добавление ресурсов не даёт никакого полезного эффекта.
Вертикальное и горизонтальное масштабирование[править | править код]
Вертикальное масштабирование[править | править код]
Вертикальное масштабирование — увеличение производительности каждого компонента системы с целью повышения общей производительности. Масштабируемость в этом контексте означает возможность заменять в существующей вычислительной системе компоненты более мощными и быстрыми по мере роста требований и развития технологий. Это самый простой способ масштабирования, так как не требует никаких изменений в прикладных программах, работающих на таких системах.
Горизонтальное масштабирование[править | править код]
Горизонтальное масштабирование — разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам), и (или) увеличение количества серверов, параллельно выполняющих одну и ту же функцию. Масштабируемость в этом контексте означает возможность добавлять к системе новые узлы, серверы, процессоры для увеличения общей производительности. Этот способ масштабирования может требовать внесения изменений в программы, чтобы программы могли в полной мере пользоваться возросшим количеством ресурсов.
В контексте высокоскоростных вычислений существует два показателя масштабируемости:
- сильная масштабируемость — показывает, как меняется время решения задачи с увеличением количества процессоров (или вычислительных узлов) при неизменном общем объёме задачи[2]
- слабая масштабируемость — показывает, как меняется время решения задачи с увеличением количества процессоров (узлов) при неизменном объёме задачи для одного процессора (или узла).
- ↑ IBM Redbook: The RS/6000 SP Inside Out, id: SG24-5374-00, стр.15
- ↑ Home Redirect (неопр.) (недоступная ссылка). Дата обращения 26 сентября 2013. Архивировано 2 октября 2011 года.
ru.wikipedia.org
Основы масштабирования / Habr
Прочитав в этом блоге о балансировке на стороне клиента, решил опубликовать свою статью, в которой описаны основные принципы масштабирования для web-проектов. Надеюсь, хабралюдям будет интересно почитать.Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.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, базу данных и иногда хранилище файлов - При небольших объемах данных и больших нагрузках применяют
зеркалирование базы данных — синхронную или асинхронную репликацию - При больших объемах данных необходимо распределить базу данных — разделить
ее вертикально или горизонтально - Бинарные файлы хранятся в распределенных файловых системах
(реализованных на уровне ОС или в приложении) - Балансировка (распределение запросов) может быть равномерная или
с разделением по функционалу; с балансирующим узлом, либо на стороне клиента - Правильное сочетание методов позволит держать любые нагрузки 😉
Ссылки
Продолжить изучение этой темы можно на интересных англоязычных сайтах и блогах:
P.S. Комментарии, конечно, приветствуются 😉
habr.com
Масштаб Автокад — как масштабировать в AutoCAD
Очень часто на чертежах необходимо увеличивать или уменьшать объекты. Как раз для того, чтобы изменить масштаб объекта в Автокаде (AutoCAD) предназначена команда «Масштаб». Про масштаб чертежа (например, 1:100, 1:50 и т.д.) читайте в этой статье.
Давайте познакомимся с тем, как в Автокаде изменить масштаб. Масштабирование в AutoCAD, выполняемое с помощью команды «Масштаб», приводит к изменению размеров построенных объектов. При этом пропорции масштабируемых объектов не меняются.
Необходимо ответить на вопрос — как настроить масштаб в Автокаде? Есть несколько способов вызова данной команды:
1. Вкладка «Главная» → панель «Редактирование». После чего Вам необходимо указать щелчком ЛКМ объект масштабирования. Чтобы закончить выбор, нажмите «Enter» или правую кнопку мыши.
2. Выберите объекты для масштабирования. Нажмите правую кнопку мыши в области чертежа и из контекстного меню выберите «Масштаб» в Автокаде (Аutocad).
Теперь необходимо указать точку, относительно которой будет производиться операция масштабирования. Т.е. это точка, которая после масштабирования должна остаться на том же месте, где и была. Сейчас я ее укажу в левом нижнем углу прямоугольника.
Теперь нужно указать масштабный коэффициент. Т.е. то число, во сколько раз надо увеличить или уменьшить объект. Думаю здесь все понятно. Если ввести 2, о объект увеличится в 2 раза. А если ввести 0.5, то объект уменьшится в 2 раза. Только обязательно используйте точку при введение нецелого числа.
Результат проделанных операций позволяет изменять масштаб в Автокаде (Аutocad). У команды «Масштаб» в AutoCAD есть несколько опций. Их нужно знать и уметь применять. Так как они иногда бывают полезными.
Опция «Копия».
Покажем как задать масштаб в Автокаде. В Автокад масштаб чертежа можно установить таким образом. Например, Вам надо увеличить объект в Х раза, но при этом надо, чтобы в итоге на чертеже появились исходный объект и его увеличенная копия.
Тогда после указания базовой точки, введите с клавиатуры ключевую букву опции «К». А затем введите коэффициент. Его можно задать выражением деления, например 1/8 (или 0.125).
Опция «Опорный отрезок».
Действие этой опции я покажу на примере. Чтобы понять как в Автокаде изменить масштаб необходимо следовать таким этапам. Допустим, Вам надо изменить масштаб в Автокаде (Аutocad) прямоуголька на чертеже в AutoCAD таким образом, чтобы его длина стала равна диаметру окружности.
Для этого мы можем графически на чертеже показать нужные нам размеры. Для начала соединим нужные точки прямоугольника и окружности, как показано на рисунке. Теперь выбираем прямоугольник, так как масштабировать мы будем его. Вызываем команду «Масштаб» в AutoCAD. Базовую точку указываем в точке, в которой мы соединили объекты.
Выбираем опцию «Опорный отрезок». Можно просто ввести с клавиатуры ключевик «О». Программа AutoCAD просит нас указать длину опорного отрезка. Мы ее покажем графически на чертеже. Опорный отрезок — это то расстояние, которое мы хотим отмасштабировать. В нашем случае это длина прямоуголька. Указываем ее щелчками левой кнопки мыши в углах прямоугольника. См. рис.
Теперь если мы начнем отводить курсор , то увидим, что прямоугольник масштабируется относительно базовой точки. Сейчас, чтобы сделать длину прямоугольника, равной диаметру окружности, просто щелкаем ЛКМ по правой точке диаметра окружности.
Итак, мы с Вами рассмотрели команду «Масштаб» в AutoCAD и научились изменять масштаб объектов и задавать в Автокад масштаб чертежа. Также рассмотрели полезные опции команды масштабирования в AutoCAD, таки как «Копия» и «Опорный отрезок».
Видео курсы по AutoCAD:
- Использование AutoCAD на 100%
- 3D моделирование в AutoCAD
- Адаптация AutoCAD под стандарты предприятия
- Советы и хитрости
- Блоки и поля в AutoCAD
autocad-specialist.ru
масштабироваться — это… Что такое масштабироваться?
- масштабироваться
масштаб’ироваться, -руется
Русский орфографический словарь. / Российская академия наук. Ин-т рус. яз. им. В. В. Виноградова. — М.: «Азбуковник». В. В. Лопатин (ответственный редактор), Б. З. Букчина, Н. А. Еськова и др.. 1999.
- масштабировать
- масштабность
Смотреть что такое «масштабироваться» в других словарях:
Видеостена — в аэропорте Маккаран, Лас Вегас[1] … Википедия
Компьютерная графика — (также машинная графика) область деятельности, в которой компьютеры используются как инструмент для синтеза (создания) изображений, так и для обработки визуальной информации, полученной из реального мира. Также компьютерной графикой… … Википедия
Skype — Эта статья о программном обеспечении; об одноимённой компании см.: Skype Limited. Skype Тип … Википедия
Проект TRON — Разработчик Кен Сакамура Состояние Текущее Веб сайт Официальный сайт Проект TRON операционная система реального времени с открытым исходным кодом ядра. Разработка проекта была начата профессором Токийского университета Кеном Сакамурой в … Википедия
Microsoft SQL Server — Тип Реляционная СУБД Разработчик Sybase, Ashton Tate, Microsoft … Википедия
IRIX — Разработчик Silicon Graphics Семейство ОС UNIX Последняя версия 6.5.30 16 августа 2006 г. Тип ядра Монолитное Интерфейс IRIX Interactive Desktop … Википедия
TrueType — Расширение .ttf TrueType (ТруТайп) формат компьютерных шрифтов, разработанный фирмой Apple в конце 1980 х годов. Шрифты в данном формате используются во многих совре … Википедия
Мост (шаблон проектирования) — У этого термина существуют и другие значения, см. Мост (значения). Шаблон проектирования Мост Bridge Тип: структурный Описан в Design Patterns Да Bridge, Мост шаблон проектирования, используемый в … Википедия
DHT — (англ. Distributed Hash Table «распределённая хеш таблица») это класс децентрализованных распределённых систем, которые обеспечивают поисковый сервис, похожий по принципу работы на таблицу хешей, и имеют структуру: (имя, значение),… … Википедия
Btrfs — Информация в этой статье или некоторых её разделах устарела. Вы можете помочь проекту, обновив её и убрав после этого данный шаблон … Википедия
Книги
- Проектируя бизнес. Как захватить рынок, адаптируясь к переменам. Опыт Coca-Cola, Дэвид Батлер, Линда Тишлер. Цитата Если Стив Джобс и Apple еще не убедили вас в том, что к дизайну нельзя относиться как ко второстепенному элементу, то стоит прочитать эту книгу. Автор раскрываетсекреты построения… Подробнее Купить за 520 руб
- Проектируя бизнес. Как захватить рынок, адаптируясь к переменам. Опыт Coca-Cola, Дэвид Батлер, Линда Тишлер. Цитата Если Стив Джобс и Apple еще не убедили вас в том, что к дизайну нельзя относиться как ко второстепенному элементу, то стоит прочитать эту книгу. Автор раскрываетсекреты построения… Подробнее Купить за 340 грн (только Украина)
- Проектируя бизнес: Как захватить рынок, адаптируясь к переменам. Опыт Coca-Cola, Дэвид Батлер. Далеко не каждый бизнес умеет масштабироваться, сохраняя при этом гибкость. Тем не менее, чтобы быть успешным в наше время, компаниям приходится учиться сочетатьэти два, казалось бы,… Подробнее Купить за 299 руб электронная книга
lopatin.academic.ru
Отмасштабировать — Перевод на английский — примеры русский
На основании Вашего запроса эти примеры могут содержать грубую лексику.
На основании Вашего запроса эти примеры могут содержать разговорную лексику.
Отмасштабировать рисунок так, чтобы он совпадал с размером и формой окна.
Scale the image to to the window size.В открывшихся настройках рамки выставим флажок Отмасштабировать под рамку/Scale Image to Frame.
Activate the check box Scale Image to Frame.На Панели настроек увеличим Ширину рамки/Frame Width до 52% и выставим флажок Отмасштабировать под рамку/Scale Image to Frame.
In the Settings panel put Frame Width to 52% and activate the check box Scale Image to Frame.Для того чтобы задать цвет для мелких деталей, необходимо сначала отмасштабировать изображение с помощью кнопок масштабирования (+/-) или ползунка в Окне навигации.
To assign a color to small details, you should first scale the image using the buttons (+/-) or the slider in the Navigation window.Кроме того, отмасштабировать изображение можно, вручную изменив значения параметров трансформации Ш — Ширина (Width) и H — Высота (Height).
You can also scale the image by changing the parameters W (width) and H (height).При выставленном флажке Отмасштабировать под рамку у изображения будет изменен масштаб таким образом, чтобы оно полностью уместилось в рамку.
When the check-box Scale Image to Frame is enabled, the image is scaled to fit the frame.Если необходимо обвести по контуру очень мелкие детали, то следует сначала отмасштабировать изображение с помощью кнопок масштабирования или ползунка в Окне навигации.
Предложить пример
Другие результаты
Нет способов оптимизировать систему, которая неправильно отмасштабирована.
Ну, это ещё не отмасштабировано, Кэм.
Изображение будет загружено в программу и, если оно большое, отмасштабировано по размеру Окна изображения (Image Window).
The image will be loaded into the workspace and, if it is large, scaled to fit the Image window.При включенном значке фрагмент будет отмасштабирован пропорционально, при отключенном можно задать параметрам масштабирования любые значения.
between the parameters W and H. If this option is enabled the image will be scaled proportionally; if it is disabled you can set your own parameters.может не успеть на лету отмасштабироваться). Ваша домашняя страничка будет просто идеально сидеть на GAE с нулевыми расходами на поддержку.
This might be awesome solution for «homepage» with some photos of your cat with rare changes and 0 maintenance and cost.context.reverso.net
масштабировать — это… Что такое масштабировать?
- масштабировать
масштаб’ировать, -рую, -рует
Русский орфографический словарь. / Российская академия наук. Ин-т рус. яз. им. В. В. Виноградова. — М.: «Азбуковник». В. В. Лопатин (ответственный редактор), Б. З. Букчина, Н. А. Еськова и др.. 1999.
- масштабированный
- масштабироваться
Смотреть что такое «масштабировать» в других словарях:
Overscan — Забегание развёртки (англ. Overscan) – выход развёртки за пределы полезной площади экрана. Данное обстоятельство существует, потому что с 1930 х по 1970 е гг. в телевизионных приемниках очень часто менялся принцип формирования изображения… … Википедия
Сазерленд, Айвен — Айвен Сазерленд Ivan Sutherland … Википедия
Windows Azure — Разработчик Microsoft Семейство ОС Windows … Википедия
Проект «Геном человека» — Логотип проекта Проект по расшифровке генома человека (англ. The Human Genome Project, HGP) международный научно исследовательский проект, главной целью которого было опр … Википедия
Проект Геном Человека — Логотип проекта Проект по расшифровке генома человека (англ. The Human Genome Project, HGP) международный научно исследовательский проект, главной целью которого было определить последовательность нуклеотидов, которые составляют ДНК и… … Википедия
атлас географический — систематическое собрание карт, выполненных по единой программе и изданных в виде книги, альбома, комплекта листов в папке в одном или нескольких томах или в электронной форме. По мнению Н. Н. Баранского, «атлас относится к отдельной карте… … Географическая энциклопедия
ХАББАРДА МОДЕЛЬ — одна из фундам. моделей для описания систем сильно взаимодействующих электронов в кристалле. Модель была предложена в 1963 65 Дж. Хаббардом [1 ] и получила широкое развитие в последующие годы. X. м. является осн. моделью для описания зонного… … Физическая энциклопедия
Персональный компьютер — Запрос «PC» перенаправляется сюда; см. также другие значения. Иное название этого понятия «ПК»; см. также другие значения. Эта статья обо всех видах ПК. О самой распространённой платформе см. IBM PC совместимый… … Википедия
Erlang — У этого термина существуют и другие значения, см. Эрланг (значения). Erlang Семантика … Википедия
QNX — Рабочий стол QNX 6 (Neutrino) по … Википедия
lopatin.academic.ru