По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет рассмотрен модуль Asterisk CLI – Command Line Interface, другими словами – консоль Asterisk. Данный инструмент является многоцелевым и может выполнять следующие функции:
Получение информации о системных компонентах Asterisk
Настройка системной конфигурации
Просмотр логов, ошибок и предупреждений в реальном времени
Генерация звонков в целях проведения тестов
Просмотр расширенной документации – для API, приложений, функций, настройки модулей и так далее.
Далее рассмотрим процесс вызова консоли – есть несколько путей.
Через веб-интерфейс FreePBX
Для этого необходимо открыть веб-интерфейс Вашей АТС и далее пройти по следующему пути: Admin –> Asterisk CLI
После этого откроется страница, на которой можно вводить команды.
По SSH
С помощью удаленного доступа – по SSHTelnet с использованием терминала (к примеру, PuTTy). При таком типе подключения необходимо будет ввести логин и пароль, и затем ввести команду:
[root@localhost ~]#asterisk -rvvvv
Примечание: Количество букв «v» означает уровень логирования в CLI. Т.е чем больше букв – тем больше информации будет «сыпаться» на экран.
Как только был получен доступ, возможно будет вывести следующую информацию:
Телефонные звонки
Регистрацию абонентов
Уведомления о появлении новых абонентов
Запросить перезагрузку системных компонентов (экстеншенов, транков и т.д)
Все команды имеют следующий синтаксис:
module name -> action type -> parameters (Название модуля –> Тип действия -> Параметры)
К примеру – команда sip show peers, которая выведет список зарегистрированных chan_sip абонентов.
Если же ваша АТС работает некорректно – к примеру, Asterisk не стартует вообще, стоит попробовать вызвать консоль с другим набором настроек, которые позволят начать специфическую отладку приложений – логирование порядка загрузки, соединения с базой данной, количества попыток регистрации и прочее.
Кроме того, есть возможность запускать команды CLI без непосредственного ввода команд, описанных выше. Для этого необходимо напрямую обратиться к модулю Asterisk:
[root@localhost ~]#asterisk -rx 'reload now'
К примеру, данная команда перезагрузит весь модуль Asterisk.
Самые нужные команды
Ниже будут приведены описания некоторых часто используемых команд:
localhost*CLI>DIALPLAN SHOW \ вывод вашего диалплана (правила маршрутизации вызовов)
localhost*CLI>CORE SHOW TRANSLATION \ вывод таблицы с методами транскодирования кодеков
localhost*CLI>SIP SET DEBUG PEER PHONE_EXT \ запуск отладки определенного экстеншена (с указанием номера экстеншена)
localhost*CLI>SIP SET DEBUG IP PEER_IP \ запуск отладки определенного абонента по его сетевому адресу
localhost*CLI>SIP SET DEBUG OFF \ отключение режима отладки
localhost*CLI>RELOAD \ перезагрузка модуля Asterisk, не всей АТС целиком. Может использоваться после внесения измерений
localhost*CLI>RESTART NOW \ перезагрузка всей системы в целом, может понадобиться если команды reload недостаточно или в целях регулярной плановой перезагрузки.
Главная команда, которую нужно усвоить – help, она выводит все прочие команды. Очень удобный внутренний инструмент.
Нормализация базы данных (БД) - это метод проектирования реляционных БД, который помогает правильно структурировать таблицы данных. Процесс направлен на создание системы с четким представлением информации и взаимосвязей, без избыточности и потери данных.
В данной статье рассказывается, что такое нормализация базы данных, и объясняются принципы ее работы на практическом примере.
Что такое нормализация базы данных?
Нормализация базы данных - это метод создания таблиц БД со столбцами и ключами путем разделения (или декомпозиции) таблицы большего размера на небольшие логические единицы. В данном методе учитываются требования, предъявляемые к среде БД.
Нормализация - это итеративный процесс. Как правило, нормализация БД выполняется через серию тестов. Каждый последующий шаг разбивает таблицу на более легкую в управлении информацию, чем повышается общая логичность системы и простота работы с ней.
Зачем нужна нормализация базы данных?
Нормализация позволяет разработчику БД оптимально распределять атрибуты по таблицам. Данная методика избавляет от:
атрибутов с несколькими значениями;
задвоения или повторяющихся атрибутов;
атрибутов, не поддающихся классификации;
атрибутов с избыточной информацией;
атрибутов, созданных из других признаков.
Необязательно выполнять полную нормализацию БД. Однако она гарантирует полноценно функционирующую информационную среду. Этот метод:
позволяет создать структуру базы данных, подходящую для общих запросов;
сводит к минимуму избыточность данных, что повышает эффективность использования памяти на сервере БД;
гарантирует максимальную целостность данных, устраняя аномалий вставки, обновления и удаления.
Нормализация базы данных преобразует общую целостность данных в удобную для пользователя среду.
Избыточность баз данных и аномалии
Когда вы вносите изменения в таблицу избыточностью, вам придется корректировать все повторяющиеся экземпляры данных и связанные с ними объекты. Если этого не сделать, то таблица станет несогласованной, и при внесении изменений возникнут аномалии.
Так выглядит таблица без нормализации:
Для таблицы характерна избыточность данных, а при изменении этих данных возникают 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)
Теперь таблица соответствует третьей нормальной форме с тремя взаимосвязями. Конечная структура выглядит так:
Теперь база данных считается нормализованной. Дальнейшая нормализация зависит от ваших конкретных целей.
Заключение
В статье рассказывалось, как с помощью нормализации БД можно сократить избыточность информации. В долгосрочной перспективе нормализация БД позволяет свести к минимуму потерю данных и улучшить их общую структуру.
Если же вы хотите повысить производительность доступа к данным, то воспользуйтесь денормализацией БД.
А если вы испытываете трудности с нормализацией базы данных, то рассмотрите возможность перехода на другой тип БД.
Edge computing (дословно можно перевести как "граничные вычисления") - это сетевая философия, основанная на том, что вычисления должны совершаться как можно ближе к источнику сырых данных. Цель сего действа в сильном сокращении задержек и ширины канала связи. Если говорить проще, то edge computing - это когда меньше всякой всячины вычисляется к облаке или ЦОДе, и больше вычисляется непосредственно на месте - то есть на локальном ПК, IoT устройстве или на граничном сервере. Таким образом сокращается необходимость поддерживать в требуемом состоянии дорогостоящие каналы связи (представьте себе, что для вычислений отправляете очень объемную информацию - к примеру, видео высокой четкости)
Что такое граница сети?
Для устройств, подключенных к сети Интернет, границей будет точка, где это устройства непосредственно подключается к Интернету. Конечно, определение экстремально размытое; к примеру, компьютер пользователя или процессор внутри IoT камеры могут быть теми самыми точками, однако, сетевой маршрутизатор также вполне попадает под это определение. Но важно одно: граница будет гораздо ближе к устройству (с географической точки зрения), нежели к облачным серверам.
Приведем пример edge computing-а
Представим себе некое здание, в котором понаставили десятки IoT камер очень высокого разрешения. Эти камеры относительно безмозглые, т.к они просто отдают сырой видеосигнал на облако. Облако, в свою очередь, пропускает весь этот сырой видео трафик через приложение, которое умеет определять движение, чтобы хранить только максимально полезную информацию. Представьте себе требованию к Интернет-каналу в таком случае: ежесекундно передаются мегабайты информации, и к тому же получается высокая нагрузка на облачные сервера, которые занимаются вычислениями - они обязаны обрабатывать все эти огромные объемы информации.
А теперь представьте себе, что сервер, определяющий движение был помещен на границу сети (той самой, в которой находится наше воображаемое здание). Что если каждая камера будет использовать свои собственные вычислительные мощности для запуска там приложения, которое будет определять движение? Очевидно, тогда в облако будет уходить только "полезный" трафик. Кроме того, на облачные сервера ляжет только задача по хранению важной информации, что де-факто означает возможность этого облака поддерживать связь с гораздо большим количеством камер без перегрузки. Вот примерно так и выглядит пример edge computing.
Преимущества концепции edge computing
Как видно в примере выше, данный концепт позволяет минимизировать загрузку Интернет-канала и нагрузку на вычислительные мощности облака. Полоса пропускания и вычислительные мощности, к сожалению, конечны и стоят реальных денег. С каждым зданием и офисом, которые будут оборудованы "умными" камерами, принтерами, термостатами и даже тостерами, аналитики предсказывают, что к 2025 году в мире будет установлено 75 миллиардов IoT устройств. Чтобы все эти устройства корректно работали, большой процент вычислений должен быть перенесен на edge-и.
Следующее преимущество - это снижение задержки. Каждый раз, когда устройство пытается подключиться к какому-нибудь удаленному серверу, появляется задержка. Гипертрофированный пример: когда двое коллег в одном офисе чатятся в аське, они могут почувствовать сильную задержку, так как каждое сообщение "улетает" во внешний мир, подключается к некому очень удаленному серверу и также возвращается обратно в эту сеть. Если бы весь этот процесс происходил на границе сети, то эта задержка могла бы быть значительно снижена.
Также, когда пользователи используют тонны веб-приложений, которые постоянно подключаются к внешним серверам, они могут чувствовать эти самые задержки. Длительность задержек будет зависеть от того, какова их полоса пропускания и где находятся сервера, но этих задержек можно легко избежать. Правильно, если воткнуть все эти сервера на границу этой сети.
Если подытожить, то общие плюсы этого концепта таковы:
Снижение задержек
Снижение затрат путем использования более дешевых каналов связи
Снижение затрат путем уменьшения нагрузки на удаленные вычислительные ресурсы
Минусы данного подхода
На мой взгляд, есть два основных минуса: первый - это сильное увеличение сложности устройств и повышенный риск компрометации этих устройств - по сути, даже банальный термостат становится полноценным компьютером, который, как мы все знаем, может быть легко подвергнут взлому. Кроме того, из-за увеличения сложности устройств и повышения их вычислительной мощности серьезно возрастает их стоимость. Однако очевидно, что технологии шагают семимильными шагами - компьютер 30 лет назад был в тысячи раз слабее современного смартфона, а стоили они гораздо дороже.