пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Современные IP сети должны обеспечивать надежную передачу пакетов сети VoIP и других важных служб. Эти сервисы должны обеспечивать безопасную передачу, определенную долю предсказуемости поведения трафика на ключевых узлах и конечно гарантированный уровень доставки пакетов. Сетевые администраторы и инженеры обеспечивают гарантированную доставку пакетов путем изменения параметров задержки, джиттера, резервирования полосы пропускания и контроля за потерей пакетов с помощью Quality Of Service (QoS).
Современные сети конвергентны. Это означает, что приходящей трафик в корпоративный сегмент сети, будь то VoIP, пакеты видеоконференцсвязи или обычный e-mail приходят по одному каналу передачу от Wide Area Network (WAN) . Каждый из указанных типов имеет свои собственные требования к передаче, например, для электронной почты задержка 700 мс некритична, но задержка 700 мс при обмене RTP пакетами телефонного разговора уже недопустима. Для этого и создаются механизмы QoS [описаны в рекомендации Y.1541]. Рассмотрим главные проблемы в корпоративных сетях:
Размер полосы пропускания: Большие графические файлы, мультимедиа, растущее количество голосового и видео трафика создает определенные проблемы для сети передачи;
Задержка пакетов (фиксированная и джиттер): Задержка – это время, которое проходит от момента передачи пакета до момента получения. Зачастую, такая задержка называется «end-to-end», что означает точка – точка. Она бывает двух типов:
Фиксированная задержка: Данные вид задержки имеет так же два подтипа: задержка сериализации и распространения. Сериализация - это время затрачиваемое оборудованием на перемещение бит информации в канал передачи. Чем шире пропускная способность канала передачи, тем меньше время тратится на сериализацию. Задержка распространения это время, требуемое для передачи одного бита информации на другой конец канала передачи;
Переменная сетевая задержка: Задержка пакета в очереди относится к категории переменной задержки. В частности, время, которое пакет проводит в буфере интерфейса, зависит от загрузки сети и относится так же к переменной сетевой задержке;
Изменение задержки (джиттер): Джиттер это дельта, а именно, разница между задержками двух пакетов;
Потеря пакетов: Потеря пакетов, как правило, вызывается превышением лимита пропускной способности, в результате чего теряются пакеты и происходят неудобства в процессе телефонного разговора.
Размер полосы пропускания
Рисунок иллюстрирует сети с четырьмя «хопами» - промежуточными узлами на пути следования пакета между сервером и клиентом. Каждый «хоп» соединен между собой своим типом среды передачи в разной пропускной способностью. В данном случае, максимальная доступная полоса для передачи равна полосе пропускания самого «узкого» места, то есть с самой низкой пропускной способностью.
Расчет доступной пропускной способности - это неотъемлемая часть настройки QoS, которая является процессом, осложненным наличием множества потоков трафика проходящего через сеть передачи данных и их необходимо учесть. Расчет доступной полосы пропускания происходит приблизительно по следующей формуле:
A=Bmax/F
где A – доступная полоса пропускания, Bmax – максимальная полоса пропускания, а F – количество потоков. Наиболее правильным методом при расчете пропускной способности является расчет с запасом в 10-20% от расчетной величины. Однако, увеличение пропускной способности вызывает удорожание всей сети и занимает много времени на осуществление. Но современные механизмы QoS могут быть использованы для эффективного и оптимального увеличения доступной пропускной способности для приоритетных приложений.
С помощью метода классификации трафика, алгоритм QoS может отдавать приоритет вызову в зависимости от важности, будь то голос или критически важные для бизнеса приложения. Алгоритмы QoS подразумевают предоставление эффективной полосы пропускания согласно требованиям подобных приложений; голосовой трафик должен получать приоритет отправки. Перечислим механизмы Cisco IOS для обеспечения необходимой полосы пропускания:
Priority queuing (приоритетная очередь или - PQ) или Custom queuing (пользовательская или настраиваемая очередь - CQ);
Modified deficit round robin - MDRR - Модифицированный циклический алгоритм с дополнительной очередью (маршрутизаторы Cisco 1200 серии);
Распределенный тип обслуживания, или Type Of Service (ToS) и алгоритм взвешенных очередей (WFQ) (маршрутизаторы Cisco 7x00 серии);
Class-Based Weighted Fair Queuing (CBWFQ) или алгоритм очередей, базирующийся на классах;
Low latency queuing (LLQ) или очередь с малой задержкой. Оптимизация использования канала путем компрессии поля полезной нагрузки «фреймов» увеличивает пропускную способность канала. С другой стороны, компрессия может увеличить задержку по причине сложности алгоритмов сжатия. Методы Stacker (укладчик) и Predictor (предсказатель) - это два алгоритма сжатия, которые используются в Cisco IOS.
Другой алгоритм эффективного использования канала передачи это компрессия заголовков. Сжатие заголовков особенно эффективно в тех сетях, где большинство пакетов имеют маленькое количество информационной нагрузки. Другими словами, если отношение вида (Полезная нагрузка)/(Размер заголовка) мало, то сжатие заголовков будет очень эффективно. Типичным примером компрессии заголовков может стать сжатие TCP и Real-time Transport Protocol (RTP) заголовков.
Задержка пакетов из конца в конец и джиттер
Рисунок ниже иллюстрирует воздействие сети передачи на такие параметры как задержка пакетов проходящих из одной части сетевого сегмента в другой. Кроме того, если задержка между пакетом с номером i и i + 1 есть величина, не равная нулю, то в добавок к задержке "end-to-end" возникает джиттер. Потеря пакетов в сети при передаче трафика происходит не по причине наличия джиттера, но важно понимать, что его высокое значение может привести к пробелам в телефонном разговоре. Каждый из узлов в сети вносит свою роль в общую задержку:
Задержка распространения (propagation delay) появляется в результате ограничения скорости распространения фотонов или электронов в среде передачи (волоконно-оптический кабель или медная витая пара);
Задержка сериализации (serialization delay) это время, которое необходимо интерфейсу чтобы переместить биты информации в канал передачи. Это фиксированное значение, которое является функцией от скорости интерфейса;
Задержка обработки и очереди в рамках маршрутизатора.
Рассмотрим пример, в котором маршрутизаторы корпоративной сети находятся в Иркутске и Москве, и каждый подключен через WAN каналом передачи 128 кбит/с. Расстояние между городами около 5000 км, что означает, что задержка распространения сигнала по оптическому волокну составит примерно 40 мс. Заказчик отправляет голосовой фрейм размером 66 байт (528 бит). Отправка данного фрейма займет фиксированное время на сериализацию, равное:
tзс = 528/128000=0,004125с=4.125 мс.
Также, необходимо прибавить 40 мс на распространение сигнала. Тогда суммарное время задержки составит 44.125 мс. Исходя из рисунка расчет задержки будет происходить следующим способом:
D1+Q1+D2+Q2+D3+Q3+D4
Если канал передачи будет заменен на поток Е1, в таком случае, мы получим задержку серилизации, равную:
tзс=528/2048000=0,00025781с=0,258 мс
В этом случае, общая задержка передачи будет равнять 40,258 мс.
Нормализация базы данных (БД) - это метод проектирования реляционных БД, который помогает правильно структурировать таблицы данных. Процесс направлен на создание системы с четким представлением информации и взаимосвязей, без избыточности и потери данных.
В данной статье рассказывается, что такое нормализация базы данных, и объясняются принципы ее работы на практическом примере.
Что такое нормализация базы данных?
Нормализация базы данных - это метод создания таблиц БД со столбцами и ключами путем разделения (или декомпозиции) таблицы большего размера на небольшие логические единицы. В данном методе учитываются требования, предъявляемые к среде БД.
Нормализация - это итеративный процесс. Как правило, нормализация БД выполняется через серию тестов. Каждый последующий шаг разбивает таблицу на более легкую в управлении информацию, чем повышается общая логичность системы и простота работы с ней.
Зачем нужна нормализация базы данных?
Нормализация позволяет разработчику БД оптимально распределять атрибуты по таблицам. Данная методика избавляет от:
атрибутов с несколькими значениями;
задвоения или повторяющихся атрибутов;
атрибутов, не поддающихся классификации;
атрибутов с избыточной информацией;
атрибутов, созданных из других признаков.
Необязательно выполнять полную нормализацию БД. Однако она гарантирует полноценно функционирующую информационную среду. Этот метод:
позволяет создать структуру базы данных, подходящую для общих запросов;
сводит к минимуму избыточность данных, что повышает эффективность использования памяти на сервере БД;
гарантирует максимальную целостность данных, устраняя аномалий вставки, обновления и удаления.
Нормализация базы данных преобразует общую целостность данных в удобную для пользователя среду.
Избыточность баз данных и аномалии
Когда вы вносите изменения в таблицу избыточностью, вам придется корректировать все повторяющиеся экземпляры данных и связанные с ними объекты. Если этого не сделать, то таблица станет несогласованной, и при внесении изменений возникнут аномалии.
Так выглядит таблица без нормализации:
Для таблицы характерна избыточность данных, а при изменении этих данных возникают 3 аномалии:
Аномалия вставки. При добавлении нового «Сотрудника» (employee) в «Отдел» (sector) Finance, обязательно указывается его «Руководитель» (manager). Иначе вы не сможете вставить данные в таблицу.
Аномалия обновления. Когда сотрудник переходит в другой отдел, поле «Руководитель» содержит ошибочные данные. К примеру, Джейкоб (Jacob) перешел в отдел Finance, но его руководителем по-прежнему показывается Адам (Adam).
Аномалия удаления. Если Джошуа (Joshua) решит уволиться из компании, то при удалении строки с его записью потеряется информация о том, что отдел Finance вообще существует.
Для устранения подобных аномалий используется нормализация базы данных.
Основные понятия в нормализации базы данных
Простейшие понятия, используемые в нормализации базы данных:
ключи - атрибуты столбцов, которые однозначно (уникально) определяют запись в БД;
функциональные зависимости - ограничения между двумя взаимосвязанными атрибутами;
нормальные формы - этапы для достижения определенного качества БД.
Нормальные формы базы данных
Нормализация базы данных выполняется с помощью набора правил. Такие правила называются нормальными формами. Основная цель данных правил - помочь разработчику БД в достижении нужного качества реляционной базы.
Все уровни нормализации считаются кумулятивными, или накопительными. Прежде чем перейти к следующему этапу, выполняются все требования к текущей форме.
Стадии нормализации:
Стадия
Аномалии избыточности
Ненормализованная (нулевая) форма (UNF)
Это состояние перед любой нормализацией. В таблице присутствуют избыточные и сложные значения
Первая нормальная форма (1NF)
Разбиваются повторяющиеся и сложные значения; все экземпляры становятся атомарными
Вторая нормальная форма (2NF)
Частичные зависимости разделяются на новые таблицы. Все строки функционально зависимы от первичного ключа
Третья нормальная форма (3NF)
Транзитивные зависимости разбиваются на новые таблицы. Не ключевые атрибуты зависят от первичного ключа
Нормальная форма Бойса-Кода (BCNF)
Транзитивные и частичные функциональные зависимости для всех потенциальных ключей разбиваются на новые таблицы
Четвертая нормальная форма (4NF)
Удаляются многозначные зависимости
Пятая нормальная форма (5NF)
Удаляются JOIN-зависимости (зависимости соединения)
База данных считается нормализованной после достижения третьей нормальной формы. Дальнейшие этапы нормализации усложняю структуру БД и могут нарушить функционал системы.
Что такое Ключ?
Ключ БД (key) - это атрибут или группа признаков, которые однозначно описывают сущность в таблице. В нормализации используются следующие типы ключей:
суперключ (Super Key) - набор признаков, которые уникально определяют каждую запись в таблице;
потенциальный ключ (Candidate Key) - выбирается из набора суперключей с минимальным количеством полей;
первичный ключ (Primary Key) - самый подходящий кандидат из набора потенциальных ключей; служит первичным ключом таблицы;
внешний ключ (Foreign Key) - первичный ключ другой таблицы;
составной ключ (Composite Key) - уникальный ключ, образованный двумя и более атрибутами, каждый из которых по отдельности не является ключом.
Поскольку таблицы разделяются на несколько более простых единиц, именно ключи определяют точку ссылки для объекта БД.
Например, в следующей структуре базы данных:
Примерами суперключей являются:
employeeID;
(employeeID, name);
email
Все суперключи служат уникальным идентификатором каждой строки. К примеру, имя сотрудника и его возраст не считаются уникальными идентификаторами, поскольку несколько людей могут быть тезками и одногодками.
Потенциальные ключи выбираются из набора суперключей с минимальным количеством полей. В нашем примере это:
employeeID;
email
Оба параметра содержат минимальное количество полей, поэтому они хорошо подходят на роль потенциальных ключей. Самый логичный выбор для первичного ключа - поле employeeID, поскольку почта сотрудника может измениться. На такой первичный ключ легко ссылаться в другой таблице, для которой он будет считаться внешним ключом.
Функциональные зависимости базы данных
Функциональная зависимость БД отражает взаимосвязь между двумя атрибутами таблицы. Функциональные зависимости бывают следующих типов:
тривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; исходный элемент является частью группы;
нетривиальная функциональная зависимость - зависимость между атрибутом и группой признаков; признак не является частью группы;
транзитивная зависимость - функциональная зависимость между тремя атрибутами: второй атрибут зависит от первого, а третий - от второго. Благодаря транзитивности, третий атрибут зависит от первого;
многозначная зависимость - зависимость, в которой несколько значений зависят от одного атрибута.
Функциональные зависимости - это важный этап в нормализации БД. В долгосрочной перспективе такие зависимости помогают оценить общее качество базы данных.
Примеры нормализации базы данных. Как нормализовать базу данных?
Общие этапы в нормализации базы данных подходят для всех таблиц. Конкретные методы разделения таблицы, а также вариант прохождения или не прохождения через третью нормальную форму (3NF) зависят от примеров использования.
Пример ненормализованной базы данных
В одном столбце ненормализованной таблицы содержится несколько значений. В худшем случае в ней присутствует избыточная информация.
Например:
Добавление, обновление и удаление данных - все это сложные задачи. Выполнение любых изменений текущих данных сопряжено с высоким риском потери информации.
Шаг 1: Первая нормальная форма (1NF)
Для преобразования таблицы в первую нормальную форму значения полей должны быть атомарными. Все сложные сущности таблицы разделяются на новые строки или столбцы.
Чтобы не потерять информацию, для каждого сотрудника дублируются значения столбцов managerID, managerName и area.
Доработанная таблица соответствует первой нормальной форме.
Шаг 2: Вторая нормальная форма (2NF)
Во второй нормальной форме каждая строка таблицы должна зависеть от первичного ключа.
Чтобы таблица соответствовала критериям этой формы, ее необходимо разделить на 2 части:
Manager (managerID, managerName, area)
Employee (employeeID, employeeName, managerID, sectorID, sectorName)
Итоговая таблица во второй нормальной форме представляет собой 2 таблицы без частичных зависимостей.
Шаг 3: третья нормальная форма (3NF)
Третья нормальная форма разделяет любые транзитивные функциональные зависимости. В нашем примере транзитивная зависимость есть у таблицы Employee; она разбивается на 2 новых таблицы:
Employee (employeeID, employeeName, managerID, sectorID)
Sector (sectorID, sectorName)
Теперь таблица соответствует третьей нормальной форме с тремя взаимосвязями. Конечная структура выглядит так:
Теперь база данных считается нормализованной. Дальнейшая нормализация зависит от ваших конкретных целей.
Заключение
В статье рассказывалось, как с помощью нормализации БД можно сократить избыточность информации. В долгосрочной перспективе нормализация БД позволяет свести к минимуму потерю данных и улучшить их общую структуру.
Если же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией БД.
А если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип БД.
В продолжение статьи про Docker, сегодня мы расскажем про Dockerfile — скрипт, который позволяет автоматизировать процесс построения контейнеров — шаг за шагом, используя при этом base образ.
Докерфайлы и синтаксис для их создания
Как уже было сказано выше, каждый Докерфайл — по сути скрипт, который автоматически выполняет определенные действия или команды в base образе, для формирования нового образа.
Все подобные файлы начинаются с обозначения FROM — также как и процесс построения нового контейнера, далее следуют различные методы, команды, аргументы или условия, после применения которых получится Docker контейнер.
Для начала, быстренько пройдемся по синтаксису — он, кстати говоря, крайне простой, с командами, говорящими самими за себя.
В Докер файлах содержится два типа основных блоков — комментарии и команды с аргументами. Причем для всех команд подразумевается определенный порядок — подробнее об этом ниже.
Ниже типичный пример синтаксиса, где первая строка является комментарием, а вторая — командой.
# Print «Hello from Merionet!»
RUN echo «Hello from Merionet!!»
Перед тем, как переходить к собственно написанию собственно Докерфайла, сначала разберем все возможные команды.
Все команды в Докерфайлах принято указывать заглавными буквами — к примеру RUN, CMD и т.д.
Команда ADD — данная команда берет два аргумента, путь откуда скопировать файл и путь куда скопировать файлы в собственную файловую систему контейнера. Если же source путем является URL (т.е адрес веб-страницы) — то вся страница будет скачена и помещена в контейнер.
# Синтаксис команды: ADD [исходный путь или URL] [путь назначения]
ADD /my_merionet_app /my_merionet_app
Команда CMD — довольно таки похожая на команду RUN, используется для выполнения определенных программ, но, в отличие от RUN данная команда обычно применяется для запуска/инициации приложений или команд уже после их установки с помощью RUN в момент построения контейнера.
# Синтаксис команды: CMD %приложение% «аргумент», «аргумент», ..
CMD «echo» «Hello from Merionet!».
Команда ENTRYPOINT устанавливает конкретное приложение по умолчанию, которое используется каждый раз в момент построения контейнера с помощью образа. К примеру, если вы установили определенное приложение внутри образа и вы собираетесь использовать данный образ только для этого приложения, вы можете указать это с помощью ENTRYPOINT, и каждый раз, после создания контейнера из образа, ваше приложение будет воспринимать команду CMD, к примеру. То есть не будет нужды указывать конкретное приложение, необходимо будет только указать аргументы.
#Синтаксис команды: ENTRYPOINT %приложение% «аргумент»
# Учтите, что аргументы опциональны — они могут быть предоставлены командой CMD или #во время создания контейнера.
ENTRYPOINT echo
#Синтаксис команды совместно с CMD:
CMD «Hello from Merionet!»
ENTRYPOINT echo
Команда ENV используется для установки переменных среды (одной или многих). Данные переменные выглядят следующим образом «ключ = значение» и они доступны внутри контейнера скриптам и различным приложениям. Данный функционал Докера, по сути, очень сильно увеличивает гибкость в плане различных сценариев запуска приложений.
# Синтаксис команды: ENV %ключ% %значение%
ENV BASH /bin/bash
Команда EXPOSE используется для привязки определенного порта для реализации сетевой связности между процессом внутри контейнера и внешним миром — хостом.
# Синтаксис команды: EXPOSE %номер_порта%
EXPOSE 8080
Команда FROM — данную команду можно назвать одной из самых необходимых при создании Докерфайла. Она определяет базовый образ для начала процесса построения контейнера. Это может быть любой образ, в том числе и созданные вами до этого. Если указанный вами образ не найден на хосте, Докер попытается найти и скачать его. Данная команда в Докерфайле всегда должна быть указана первой.
# Синтаксис команды: FROM %название_образа%
FROM centos
Команда MAINTAINER — данная команда не является исполняемой, и просто определяет значение поля автора образа. Лучше всего ее указывать сразу после команды FROM.
# Синтаксис команды: MAINTAINER %ваше_имя%
MAINTAINER MerionetNetworks
Команда RUN - является основной командой для исполнения команд при написании Докерфайла. Она берет команду как аргумент и запускает ее из образа. В отличие от CMD данная команда используется для построения образа (можно запустить несколько RUN подряд, в отличие от CMD).
# Синтаксис команды: RUN %имя_команды%
RUN yum install -y wget
Команда USER — используется для установки UID или имени пользователя, которое будет использоваться в контейнере.
# Синтаксис команды: USER %ID_пользователя%
USER 751
Команда VOLUME — данная команда используется для организации доступа вашего контейнера к директории на хосте (тоже самое, что и монтирование директории)
# Синтаксис команды: VOLUME [«/dir_1», «/dir2» ...]
VOLUME [«/home»]
Команда WORKDIR указывает директорию, из которой будет выполняться команда CMD.
# Синтаксис команды: WORKDIR /путь
WORKDIR ~/
Создание своего собственного образа для установки MongoDB
Для начала создадим пустой файл и откроем его с помощью vim:
vim Dockerfile
Затем мы можем указать комментариями для чего данный Докерфайл будет использоваться и все такое — это не обязательно, но может быть полезно в дальнейшем. На всякий случай напомню — все комментарии начинаются с символа #.
########
# Dockerfile to build MongoDB container images
# Based on Ubuntu
########
Далее, укажем базовый образ:
FROM ubuntu
Затем, укажем автора:
MAINTAINER Merionet_Translation
После чего обновим репозитории(данный шаг совершенно необязателен, учитывая, что мы не будем их использовать ) :
RUN apt-get update
После укажем команды и аргументы для скачивания MongoDB (установку проводим в соответствии с гайдом на официальном сайте):
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list
RUN apt-get update
RUN apt-get install -y mongodb-10gen
RUN mkdir -p /data/db
После чего укажем дефолтный порт для MongoDB:
EXPOSE 27017
CMD [«--port 27017»]
ENTRYPOINT usr/bin/mongod
Вот как должен выглядеть у вас финальный файл — проверьте и, затем, можно сохранить изменения и закрыть файл:
#########
# Dockerfile to build MongoDB container images
# Based on Ubuntu
#########
FROM ubuntu
MAINTAINER Merionet_Translation
RUN apt-get update
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list
RUN apt-get update
RUN apt-get install -y mongodb-10gen
RUN mkdir -p /data/db
EXPOSE 27017
CMD ["--port 27017"]
ENTRYPOINT usr/bin/mongod
Запуск контейнера Docker
Итак, мы готовы создать наш первый MongoDB образ с помощью Docker!
sudo docker build -t merionet_mongodb .
-t и имя здесь используется для присваивания тэга образу. Для вывода всех возможных ключей введите sudo docker build —help, а точка в конце означает что Докерфайл находится в той же категории, из которой выполняется команда.
Далее запускаем наш новый MongoDB в контейнере!
sudo docker run -name MerionetMongoDB -t -i merionet_mongodb
Ключ -name используется для присвоения простого имени контейнеру, в противном случае это будет довольно длинная цифро-буквенная комбинация. После запуска контейнера для того, чтобы вернуться в систему хоста нажмите CTRL+P, а затем CTRL+Q.
Заключение
Всем спасибо за внимание, теперь вы можете очень много экспериментировать с созданием Докерфайлов и ваших собственных образов, не бойтесь пробовать упростить привычные вам процессы установки приложений с помощью контейнеров — возможности крайне велики, и мы постараемся охватить их в следующих статьях.