пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Десятая часть тут.
Вы входите в комнату и кричите: «Игорь!» Ваш коллега Игорь оборачивается и начинает разговор о будущем IT-индустрии. Эта способность использовать один носитель (воздух, по которому движется ваш голос) для обращения к одному человеку, даже если многие другие люди используют этот же носитель для других разговоров в одно и то же время, в сетевой инженерии называется мультиплексированием. Более формально:
Мультиплексирование используется, чтобы позволить нескольким объектам, подключенным к сети, обмениваться данными через общую сеть.
Почему здесь используется слово объекты, а не хосты? Возвращаясь к примеру «разговор с Игорем", представьте себе, что единственный способ общения с Игорем — это общение с его ребенком-подростком, который только пишет (никогда не говорит). На самом деле Игорь-член семьи из нескольких сотен или нескольких тысяч человек, и все коммуникации для всей этой семьи должны проходить через этого одного подростка, и каждый человек в семье имеет несколько разговоров, идущих одновременно, иногда на разные темы с одним и тем же человеком. Бедный подросток должен писать очень быстро, и держать много информации в голове, например: "Игорь имеет четыре разговора с Леной", и должен держать информацию в каждом разговоре совершенно отдельно друг от друга. Это ближе к тому, как на самом деле работает сетевое мультиплексирование- рассмотрим:
К одной сети могут быть подключены миллионы (или миллиарды) хостов, и все они используют одну и ту же физическую сеть для связи друг с другом.
Каждый из этих хостов на самом деле содержит много приложений, возможно, несколько сотен, каждое из которых может связываться с любым из сотен приложений на любом другом хосте, подключенном к сети.
Каждое из этих приложений может фактически иметь несколько разговоров с любым другим приложением, запущенным на любом другом хосте в сети.
Если это начинает казаться сложным, то это потому, что так оно и есть. Вопрос, на который должен ответить эта лекция, заключается в следующем:
Как эффективно мультиплексировать хосты через компьютерную сеть?
Далее рассматриваются наиболее часто используемые решения в этом пространстве, а также некоторые интересные проблемы, связанные с этой основной проблемой, такие как multicast и anycast.
Адресация устройств и приложений
Компьютерные сети используют ряд иерархически расположенных адресов для решения этих проблем. Рисунок 1 иллюстрирует это. На рисунке 1 показаны четыре уровня адресации:
На уровне физического канала существуют адреса интерфейсов, которые позволяют двум устройствам обращаться к конкретному устройству индивидуально.
На уровне хоста существуют адреса хостов, которые позволяют двум хостам напрямую обращаться к конкретному хосту.
На уровне процесса существуют номера портов, которые в сочетании с адресом хоста позволяют двум процессам обращаться к конкретному процессу на конкретном устройстве.
На уровне диалога (разговора) набор порта источника, порта назначения, адреса источника и адреса назначения может быть объединен, чтобы однозначно идентифицировать конкретный разговор или поток.
Эта схема и объяснение кажутся очень простыми. В реальной жизни все гораздо запутаннее. В наиболее широко развернутой схеме адресации - интернет-протоколе IP отсутствуют адреса уровня хоста. Вместо этого существуют логические и физические адреса на основе каждого интерфейса.
Идентификаторы (адреса) мультиплексирования и мультиплексирование иерархически расположены друг над другом в сети.
Однако есть некоторые ситуации, в которых вы хотите отправить трафик более чем на один хост одновременно. Для этих ситуаций существуют multicast и anycast. Эти два специальных вида адресации будут рассмотрены в следующих лекциях.
О физических каналах, Broadcasts, и Failure Domains
Простая модель, показанная на рисунке 1, становится более сложной, если принять во внимание концепцию широковещательных доменов и физического подключения. Некоторые типы мультимедиа (в частности, Ethernet) разработаны таким образом, что каждое устройство, подключенное к одной и той же физической линии связи, получает каждый пакет, передаваемый на физический носитель—хосты просто игнорируют пакеты, не адресованные одному из адресов, связанных с физическим интерфейсом, подключенным к физическому проводу. В современных сетях, однако, физическая проводка Ethernet редко позволяет каждому устройству принимать пакеты любого другого устройства. Вместо этого в центре сети есть коммутатор, который блокирует передачу пакетов, не предназначенных для конкретного устройства, по физическому проводу, подключенному к этому хосту.
В этих протоколах, однако, есть явные адреса, отведенные для пакетов, которые должны передаваться каждому хосту, который обычно получал бы каждый пакет, если бы не было коммутатора, или что каждый хост должен был получать и обрабатывать (обычно это некоторая форма версия адреса все 1 или все 0). Это называется трансляцией (broadcasts). Любое устройство, которое будет принимать и обрабатывать широковещательную рассылку, отправленную устройством, называется частью широковещательной рассылки устройства. Концепция широковещательного домена традиционно тесно связана с областью сбоев, поскольку сбои в сети, влияющие на одно устройство в широковещательном домене, часто влияют на каждое устройство в широковещательном домене.
Не удивляйтесь, если вы найдете все это довольно запутанным, потому что на самом деле это довольно запутанно. Основные понятия широковещания и широковещательных доменов все еще существуют и по-прежнему важны для понимания функционирования сети, но значение этого термина может измениться или даже не применяться в некоторых ситуациях. Будьте осторожны при рассмотрении любой ситуации, чтобы убедиться, что вы действительно понимаете, как, где и, что такие широковещательные домены действительно существуют, и как конкретные технологии влияют на отношения между физической связью, адресацией и широковещательными доменами.
Многомерные системы управления данными (МСУБД) объединяют несколько систем баз данных в одну. Вместо работы с несколькими моделями и поиска возможностей для их объединения, МСУБД предлагает общий механизм для различных типов данных.
В данной статье приводится подробный обзор многомерных баз данных.
Что такое многомерные базы данных?
Многомерная база данных (Multi-Model Database) – это система управления, которая сочетает несколько типов БД в одну серверную систему. Большинство СУБД поддерживает одну модель БД, а в МСУБД можно хранить, запрашивать и индексировать данные из нескольких моделей.
Важное преимущество многомерных БД заключается в многоязычной сохранности, когда не нужно искать способы для объединения различных моделей. Гибкий подход позволяет хранить данные разными способами. В результате вы получаете:
Гибкое и динамичное программирование
Снижение избыточности данных
Например, изучать взаимосвязи между точками данных или создавать систему рекомендаций гораздо проще с помощью графовых БД, а реляционные БД лучше подходят для определения связи между столбцами данных.
Ключевая функция МСУБД заключается в ее способности преобразовывать данные из одного формата в другой. К примеру, данные в формате JSON быстро преобразуются в XML. Преобразование форматов данных обеспечивает дополнительную гибкость и упрощает соответствие определенным требованиям проекта.
Примеры использования МСУБД
Варианты использования СУБД позволяют лучше понять принципы работы данной модели. Анализируя практические примеры, вам становится ясно, как несколько моделей работают в единой системе.
Хранение и управление несколькими источниками данных
Классическая IT-система использует различные источники данных. Информация не всегда хранится в том же формате или в той же базе данных. Несколько форматов складываются в сложную систему – трудную для поддержания и поиска данных.
Хранение данных в МСУБД облегчает администрирование систем. Все находится в одной базе, поэтому на хранение и управление данными из разных источников тратится меньше времени.
Расширение возможностей модели
Многомерные базы данных предлагают расширения для моделей. Особенности одних моделей перекрывают недочеты других.
Например, очень просто запрашивать данные в JSON-формате через SQL-запросы. Нет необходимости корректировать исходный источник данных. Расширяемость сокращает время обработки данных и устраняет необходимость в ETL-системах (извлечение, преобразование, загрузка).
Гибридные среды данных
Классическая среда данных разграничивает операционные данные от аналитических. Данные для анализа необходимо преобразовать и хранить отдельно от операционных.
Происходит задвоение, и качество данных снижается. Разделенное пространство повышает затраты на техническое обслуживание. Всем базам данных необходимо администрирование и управление резервным копированием.
Многомерная БД использует гибридный подход к хранению данных. Унифицированные узлы, в которых хранятся транзакционные данные и из которых извлекаются аналитические, намного проще поддерживать.
Централизация данных
У данных в организации есть определенные ограничения. Такие ограничения нужны, но они усложняют работу с информацией внутри компании.
Многомерные БД хранят данные в формате as-is («как есть»), поэтому никакие преобразования не нужны. Централизация данных дает ценную информацию о существующих данных и предлагает возможности для создания новых вариантов использования.
Поиск больших данных
Hadoop отлично справляется с обработкой больших объемов данных в разных моделях. Основная причина – скорость получения, обработки и хранения данных. Единственное, чего не хватает Hadoop, – это эффективного механизма поиска.
Если взять вычислительные мощности Hadoop и объединить их с возможностями поиска по многомерной БД, то получится функциональная система. Процесс работы становится масштабируемым и удобным для выполнения задач над большими данными.
Плюсы и минусы многомерной базы данных
В многомерных базах данных есть свои плюсы и минусы. В таблице ниже перечислены ключевые пункты:
Плюсы
Минусы
Постоянство данных
Сложность
Динамичность
Все еще в стадии разработки
ACID-совместимость
Не хватает методов моделирования
Подходят для сложных проектов
Не подходят для простых проектов
Такая модель подходит для корпоративных настроек с множеством данных. Разные секторы пользуются данными для разных задач. Но детализированной и уже настроенной структуре многоязычной сохранности может не хватать возможностей многомерной системы.
Плюсы
Преимущества многомерных баз данных:
согласованность данных между моделями за счет единой серверной системы
динамичная среда с использованием различных типов данных на одной платформе
отказоустойчивость, из-за ACID-совместимости
подходят для сложных проектов с множественным представлением данных
Минусы
Недочеты многомерных баз данных:
сложность МСУБД, из-за чего с ними трудно работать
модель БД все еще развивается и не имеет окончательной формы
ограниченная доступность различных методов моделирования
не подходит для более простых проектов или систем
Какие многомерные базы данных считаются самыми лучшими?
На рынке представлено огромное множество многомерных типов БД. Их самой примечательной особенностью является поддержка нескольких моделей на одном сервере.
Некоторые БД накладывают несколько моделей на сервер через компоненты. Но такие типы БД не считаются подлинными многомерными базами.
Еще одно важное отличие – доступные методы моделирования. Этот аспект крайне важен для того, чтобы получать максимальную пользу от доступных данных.
MarkLogic Server
MarkLogic Server – это многомерная нереляционная база данных. Она появилась как хранилище XLM, а затем была доработана для хранения различных моделей:
документной
графовой
текстовой
пространственной
типа «ключ – значение»
реляционной
Это универсальная, эффективная и безопасная база данных. Возможности сервера MarkLogic:
Безопасность и управление. Интегрированное управление безопасностью данных и пользователей.
ACID-совместимость. Обеспечивает строгую согласованность данных.
Расширенный поиск. Доступ к данным обеспечивает встроенная поисковая система с семантическим поиском.
Разноплановая аналитика. Вам доступны настраиваемые инструменты для аналитики и бизнес-аналитики.
Встроенное машинное обучение. Интеллектуальное автоматизированное курирование данных с помощью встроенных алгоритмов машинного обучения обеспечивает более быстрый доступ к данным.
Отказоустойчивость. Mark Logic предлагает высокую доступность и систему аварийного восстановления, помогающую избегать любого рода сбоев.
Поддержка гибридного облака. База данных позволяет самостоятельно управлять развертыванием с помощью гибридных облачных решений.
ArangoDB
ArangoDB – это нативная многомерная система управления базами данных. Она поддерживает следующие форматы данных:
документные
графовые
«ключ-значение»
База данных извлекает и изменяет данные с помощью унифицированного языка запросов AQL. К другим важным особенностям относятся:
Расширенные соединения. Позволяет соединять данные с помощью гибких запросов, что снижает их избыточность.
Транзакции. Выполнение запросов к нескольким документам с доступной изоляцией и согласованностью транзакций.
Сегментирование. Синхронная репликация путем сегментирования позволяет снижать внутреннюю кластерную связь, повышая при этом производительность и скорость соединения.
Репликация. Репликация обеспечивает распределенную БД в пределах одного центра обработки данных.
Многопоточность. Благодаря многопоточности, БД может использовать несколько ядер.
OrientDB
OrientDB – это многомерная нереляционная база данных с открытым кодом, написанная на Java. Эта БД поддерживает следующие модели:
документную
графовую
тип «ключ-значение»
объектную
пространственную
OrientDB первая ввела несколько моделей на уровне ядра. Эта база данных поставляется с рядом уникальных функций, к которым относятся:
Поддержка SQL. БД поддерживает SQL-запросы, благодаря чему программистам легче переключиться с реляционных моделей на OrientDB.
ACID-совместимость. База данных полностью транзакционна; таким способом достигается ее надежность.
Распределенная. Полная поддержка репликации с множеством master на разных выделенных серверах.
Портативная. Позволяет быстро импортировать реляционные базы данных.
Заключение
Существует великое множество методов моделирования баз данных, и в каждом решении можно найти свои плюсы и минусы. Многомерные БД стремятся объединить различные базы данных в единую серверную систему, благодаря чему при разрастании системы ее сложность и потребление ресурсов не увеличиваются.
Мир VoIP (Voice over IP) многогранен. На рынке существует целое множество решений для построения корпоративных систем связи – IP – АТС. Нас интересуют программные «open source» решения, поэтому, сегодня мы сравним две популярные телефонные платформы и ответим на вопрос: что круче, FreeSWITCH или Asterisk? :)
Про Asterisk
Давайте немного теории: Asterisk - программная автоматическая телефонная станция (АТС) на базе протокола IP, которая способна предложить богатый, с точки зрения телефонии, инструментарий для офиса. Asterisk, будучи одной из первых программных IP-АТС был создан в 1999 году как решение с открытым кодом (open source). При поддержке компании Digium в 2005 году IP – АТС увидела свет и была выпущена в «продакшн». Реализация происходит под двумя лицензиями: GNU GPL (General Public License) и патентная лицензия для разработки собственных решений на базе Asterisk, рассчитанных на дальнейшую продажу. Более миллиона пользователь радуются IP – АТС Asterisk каждый день по всему миру :)
Но не все так гладко (удар молнии за окном). Исторически, Asterisk имеет ряд проблем, связанных с масштабируемостью, нестабильностью работы при повышении нагрузки. С учетом особенностей лицензирования, многие пользователи (в том числе компании - разработчики) искали новый продукт.
Про FreeSWITCH
В 2006 году группа бывших разработчиков Asterisk приняли решение разработать альтернативное решение – на свет появился FreeSWITCH. Вдохновленные модульной структурой веб – сервера Apache, команда разработчиков преследовала цель улучшить параметры масштабируемости и стабильности работы на разных платформах.
FreeSWITCH создан по модели состояний, вследствие чего, каждый вызов(канал) работает по отдельному потоку данных. Для построения структуры, использовались компоненты open – source решений, такие как, например, Sofia SIP – SIP UA с открытым исходным кодом, созданный компанией Nokia.
Что под капотом?
Asterisk – модульная структура. Во время работы, Asterisk использует общие ресурсы, включая программные потоки – это главная проблема при большой интенсивности вызовов.
Несмотря на сложность и многогранность программного кода, на котором написан Asterisk, он находит огромное множество применений в сети. С другой стороны, FreeSWITCH написан на C, структура которого более понятна и прозрачна. Потоки процессов выполняются последовательно и отдельно для каждого канала, что безусловно отличает Фрисвитч от Asterisk. При этом, как правило, по этой причине FreeSWITCH требует больший объем оперативной памяти (RAM)
Отметим, что FreeSWITCH имеет хорошо документированный API (Application Programming Interface), сегментированный по ролям. Такая структура обеспечивает безопасное подключение к API в отличие от Asterisk, где более открытая конструкция API допускает вероятность внесения багов и ошибок.
Asterisk базируется на текстовых конфигурационных файлах, в то время как FreeSWITCH использует файлы формата .xml. Безусловно, с точки зрения работы с конфигами для админа, файлы текстового формата проще редактировать, однако, плюсы формата .xml всплывают на этапе автоматизации различных процессов.
Требования к железу
Оценить общие требования к IP – АТС достаточно сложно, так как в каждой инсталляции используется разный набор фичей и целей эксплуатации. Однако, в таблице ниже сконцентрированы минимальные требования к серверу, на котором будет развернут Asterisk и FreeSWITCH для работы 15 телефонными аппаратами и 5 одновременными вызовами. Сравните их:
Параметр
FreeSWITCH
Asterisk
CPU
Одно ядро, частота процессор 1 гГц
Одно ядро, частота процессор 700 мГц
RAM
1 ГБ
512 МБ
HDD
10 ГБ
10 ГБ
OS
Linux, 32/64 бит
Linux, 64 бит
Как видно, FreeSWITCH потребляет больше RAM. О причине этого мы писали ранее – это связано с архитектурой.
Функционал
С точки зрения базового набора функций, АТС идентичны. Голосовая почты, IVR, маршрутизация, intercom и другие опции доступны для обоих лагерей пользователей.
Рассмотрим преимущества, которые интересны для профессионального и более глубокого использования платформ. Начнем, пожалуй, с возможности FreeSWITCH создавать мульти – площадки. Фрисвич нативно (из коробки) умеет сегментировать площадки пользователей, разные домены и суб – домены. Это означает, что пользователи одной площадки не смогут дозвониться до пользователей другой по внутренним номерам. Другими словами, обеспечивается полнофункциональная сегрегация пользователей.
Так же, безусловным преимуществом FreeSWITCH стоит отметить возможность кластеризации (объединения нескольких серверов), где каждый хост в кластере будет выполнять свою определенную роль.
Итог
Подведем итоги. Мы составили таблицу с результатами, чтобы вам было проще ориентироваться:
Функция
FreeSWITCH
Asterisk
Малое потребление ресурсов сервера, включая ресурсы процессора и оперативной памяти
✕
✓
Документация и поддержка: решение проблем, форму, гайды, сильное комьюнити проекта
✕
✓
Богатый базовый функционал: конференции, видеозвонки, IVR, голосовая почта и так далее
✓
✓
Возможность реализации функций мульти - площадок (поддержка отдельных телефонных доменов с полной сегрегацией пользователей)
✓
✕
Внутренние механизмы устойчивости к повышению нагрузки, связанной с повышением количества одновременных вызовов
✓
✕
Объединение серверов в кластер, с последующим разделением ролей
✓
✕