По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, сегодня расскажем что такое база данных и SQL. У современных баз данных куча нюансов - погнали разбираться.
Представь - собираешь ты деньги на подарок корешу, и записываешь на бумажке, кто сколько скинул.
Табличка с денежками организована, разделена по именам и сумме долга, и имеет удобную структуру - ну вот оно, это и есть база данных!
Ага, теперь, перемещаемся в цифровое пространство и заводим целый эксель файл для этого дела. Стало удобнее, можно редактировать, сортировать и даже данные удалять!
Круто! Но достаточно ли этого для роста этой базы данных? Нет. Со временем данных становится так много, что админам приходится связывать их друг с другом, а тут одним эксель файлом уже не обойтись.
Представим, решили вы сделать свой аналог ютуба, как будете хранить инфу о пользователях? Список юзеров, там, каналы, кто на что подписан, лайки и вот это все. Сложить это все в одну таблицу? Будет неудобно и медленно работать. Очевидно, надо разделить сущности на несколько таблиц - юзеры, каналы и видосы:
Теперь свяжем данные между собой и добавим информацию о том, кто создал канал, и на каком канале залили видео.
Ага, получились связанные таблицы. Связанные, от слова связь. А связь, это по-английски relation. А в айти тусовке они так и называются - реляционные базы данных, и это один самых распространенных типов баз данных. Еще есть нереляционные базы данных, о них подробнее можно прочитать в этой статье про NoSQL.
Уф, ну теперь с данными стало гораздо удобнее работать, и мы избежали большой таблицы с повторяющимися строчками, разбив все на несколько табличек. Такой процесс еще называется нормализацией, когда мы избавляемся от избыточных данных. Ну и как раз для этого мы ввели в каждой таблице специальное поле - ID, которое идентифицирует каждую запись. Этот айди называется Primary Key, он же “первичный ключ”. А в таблице которая будет на него ссылаться, он будет называться Foreign Key, или по-русски “внешний ключ”.
Нырнем в детали и поговорим про типы связей между таблицами. Первый тип называется “Один-ко-многим” или “многие-к-одному” (One-to-Many или Many-to-One).
В нашем примере, у каждого видео может быть только один канал, где оно выложено, но на одном канале может быть много видео, поэтому в двух последних строках ID канала у нас повторяется, верно?
Отношения «один-ко-многим» также можно рассматривать как отношения «многие-к-одному», в зависимости от того, с какой стороны вы на это смотрите.
Второй тип связей называется “один-к-одному” (One-to-One) - классические табличные отношения. Вообще, это редко используемый тип связи, обычно его делают для безопасности. Это как если на нашем аналоге ютуба, мы разрешили бы создавать только один канал одному пользователю и в таблице с каналами ID создателя не могло повторяться. Такое себе, согласен? В таком случае вообще можно было бы обойтись и одной таблицей.
Ну и третий тип связей, это “многие ко многим” (Many-to-many). Это когда у нас появляется промежуточная таблица связей, которая как бы соединяет два отношения “один ко многим”, которые мы обсудили в начале разбора типов связей.
Давайте сделаем таблицу с лайками балалайками, где будем хранить ID пользователей и ID видео, к которым они поставили лайк:
А вот так они связан: каждый пользователь может поставить лайк каждому видео.
Теперь вопрос - а где все это хранить? Не в экселе же. И тут на сцену выходит термин СУБД, она же система управления базами данных - это программа, которая позволяет создавать, редактировать и администрировать реляционную базу.
Ну и для управления всей этой петрушкой используется язык структурированных запросов, SQL (Structured Query Language) эскюэль или сиквел, как иногда его называют за рубежом.
Он очень простой и понятный, вот смотри - чтобы найти названия всех видео с одного канала, нам нужно выполнить следующий запрос:
SELECT name FROM videos WHERE channel_id = 201
То есть мы буквально говорим: выбери (SELECT) имена из (FROM) таблицы видео, где (WHERE) айдишник (ID) канала равен 201.
Если вы хотите взять данные из нескольких таблиц и объединить результат, то нужно использовать в запрос параметр JOIN (от английского соединить). Вот такая упрощающая жизнь админам аналогия с разговорным языком.
Так, SQL конечно позволяет добавлять, удалять и изменять данные и сами таблицы. Но важно не забывать про схему базы данных (Database schema), которая служит для описания структуры таблицы, ее полей и ограничений. Прикол в том, что если вам потребуется добавить или убрать столбец в таблице, то это изменение коснется вообще всех данных в таблице, таким образом если мы добавляем новый столбец, то он теперь будет присутствовать в каждой строке.
Окей, а для чего вообще нужны ограничения? Для целостности твоих данных.
Помнишь мы рассказали про первичный и внешний ключ? Так вот, благодаря им мы можем удостовериться, что в таблицу не попадет запись, которая ссылается на несуществующий айдишник. Или различные ограничения полей, которые не дадут записать дублирующие или пустые данные в нашу базу (Not NULL и Unique).
И еще: транзакции. Эта штука, которая позволяет как бы склеить несколько SQL запросов в один.
Ну вот представь такую задачку: вставить данные в первую таблицу, а во второй указать ID вставленной записи. Если ты делаешь это без использования транзакций, а во время второго этапа у тебя отвалится интернет, то первая запись попадет в базу, а вторая нет. Ага, появляется интернет, и ты с улыбкой на лице идешь снова выполнить эти запросы, только на этот раз получишь ошибку, что такая запись уже есть, ибо первая то уже в базе! А в случае использования транзакций, при получении ошибки, мы откатимся до того момента, который был до начала транзакции.
А еще все эти радости помогают реляционным БД (базам данных) соответствовать так называемым требованиям ACID, которые нужны для сохранности данных - это очень важно в банковской отрасли, или любой другой, где целостность и сохранность данных супер важны.
Давай разберемся с аббревиатурой:
Atomicity — атомарность, или же проще говоря, непрерывность: это как раз про транзакции, которые мы обсудили только что. Либо операция выполняется целиком, либо никак.
Consistency — согласованность: данные, записываемые в таблицу должны соответствовать всем выставленным правилам и ограничениям, помнишь, мы говорили про первичный и внешний ключи, а также про уникальность?
Isolation — изолированность: если вы гоняете тонну транзакций одновременно, они не должны пересекаться и влиять друг на друга. Это очень важно для высоконагруженных баз
Durability — надежность: если мы получили подтверждение, что транзакция выполнена, то значит наши данные в сохранности, даже если после этого произошел сбой.
Ну и в качестве примеров таких баз данных назовем: Microsoft SQL Server, Oracle Database, MySQL, MariaDB и PostgreSQL.
Пока не начали, ознакомьтесь с материалом про обнаружение соседей в сетях.
Реактивное распределение достижимости
Возвращаясь к рисунку 9 в качестве справки, предположим, что развернута реактивная плоскость управления, и B хотел бы начать обмен потоками данных с G. Как C может разработать информацию о пересылке, необходимую для правильного переключения этого трафика?
Маршрутизатор может отправить запрос по сети или отправить запрос контроллеру, чтобы обнаружить путь к месту назначения. Например:
Когда B впервые подключается к сети, и C узнает об этом вновь подключенном хосте, C может отправить информацию о B в качестве достижимого пункта назначения на контроллер, подключенный к сети.
Точно так же, когда G подключается к сети и D узнает об этом вновь подключенном хосте, D может отправить информацию о G как о достижимом пункте назначения контроллеру, подключенному к сети.
Поскольку контроллер узнает о каждом хосте (или достижимом месте назначения), подключенном к сети (а в некоторых системах, также обо всей топологии сети), когда C необходимо узнать, как достичь хоста G, маршрутизатор может запросить контроллер, который может предоставить эту информацию.
Примечание. Концепция централизованного контроллера подразумевает, что один контроллер предоставляет информацию для всей сети, но это не то, как термин централизованная плоскость управления обычно используется в мире сетевой инженерии. Однако идея централизации в сетевой инженерии довольно расплывчата. Вместо того, чтобы указывать на отдельное устройство, термин "централизованный" обычно используется для обозначения непереносимых скачков по сети и не вычисляемых каждым сетевым устройством независимо.
Маршрутизатор (или хост) может отправить пакет проводника, который записывает маршрут от источника к месту назначения и сообщает эту информацию источнику проводника, который затем используется как исходный маршрут. Рисунок 10 иллюстрирует это.
Используя рисунок 10 и предполагая исходную маршрутизацию на основе хоста:
Хосту A необходимо отправить пакет H, но у него нет пути.
A отправляет explorer на свой шлюз по умолчанию, маршрутизатор C.
C не имеет маршрута к месту назначения, поэтому он пересылает explorer пакет по всем каналам, кроме того, по которому он получил пакет; следовательно, к B, D и E.
B является хостом, не имеет дополнительных интерфейсов и не является целью explorer, поэтому он игнорирует explorer пакет.
Ни у D, ни у E нет пути к H, поэтому они оба перенаправляют explorer на все интерфейсы, кроме того, на котором они получили пакет; следовательно, на канал с множественным доступом, совместно используемый между ними и F.
F получает две копии одного и того же explorer пакета; он выбирает один на основе некоторых локальных критериев (таких как первый полученный или некоторая политика плоскости управления) и пересылает его на все интерфейсы, на которых он не получил пакет, к G.
G получает пакет и, учитывая, что у него нет пути к H, пересылает его на единственное другое соединение, которое у него есть, что ведет к H.
H принимает explorer и отвечает.
В этой схеме каждое устройство на пути добавляет себя в список пройденных узлов перед пересылкой explorer пакета на все интерфейсы, кроме того, на котором он был получен. Таким образом, когда H получает explorer пакет (который в конечном итоге направлен на поиск пути к H), пакет теперь описывает полный путь от A до H. Когда H отвечает explorer, он помещает этот путь в тело пакета; когда A получит ответ, у него теперь будет полный путь от A до H.
Примечание. В некоторых реализациях A не будет ни генерировать, ни получать ответ на пакет explorer. А с первого роутера, может выполнять эти функции. Точно так же сам H может не отвечать на эти пакеты explorer, а скорее G или любое другое сетевое устройство вдоль пути, имеющее информацию о том, как добраться до G. Однако в этих случаях общая концепция и обработка остаются теми же.
Затем, чтобы отправить пакеты в H, A вставляет этот путь в заголовок пакета в виде исходного маршрута, содержащего путь [A, C, D, F, G, H]. Когда каждый маршрутизатор получает этот пакет, он проверяет исходный маршрут в заголовке, чтобы определить, на какой маршрутизатор перенаправить трафик следующему. Например, C проверит информацию о маршруте от источника в заголовке пакета и определит, что пакет должен быть отправлен в D следующим, в то время как D изучит эту информацию и определит, что ему нужно отправить пакет F.
Примечание. В некоторых реализациях каждый explorer фактически отправляется в пункт назначения, который затем определяет, по какому пути должен идти трафик. На самом деле существует несколько различных способов реализации исходной маршрутизации; процесс, приведенный здесь, является лишь одним примером, объясняющим общую идею исходной маршрутизации.
Упреждающее распределение доступности
Проактивные плоскости управления, в отличие от реактивных плоскостей управления, распределяют информацию о достижимости и топологии по всей сети, когда информация становится доступной, а не тогда, когда она необходима для пересылки пакетов. Основная проблема, с которой сталкиваются плоскости упреждающего управления, заключается в обеспечении надежной передачи информации о доступности и топологии между узлами в сети, в результате чего все устройства имеют одинаковую информацию о доступности.
Удаление информации о плоскости управления может привести к возникновению постоянных петель маршрутизации или к созданию черных дыр маршрутизации (так называемых, потому что они потребляют трафик, передаваемый в пункты назначения без следа), и то и другое серьезно снижает полезность сети для приложений. Существует несколько широко используемых механизмов для обеспечения надежной передачи информации плоскости управления по сети.
Плоскость управления может периодически передавать информацию, задерживая более старую информацию. Это похоже на формирование соседей, поскольку каждый маршрутизатор в сети будет передавать имеющуюся информацию о доступности всем соседям (или на всех интерфейсах, в зависимости от плоскости управления) на основе таймера, обычно называемого таймером обновления или объявления. Информация о доступности, однажды полученная, хранится в локальной таблице и истекает по таймауту в течение некоторого периода времени, часто называемого таймером удержания (опять же, как при обнаружении соседа).
Остальные описанные здесь механизмы полагаются на существующую систему обнаружения соседей, чтобы гарантировать надежную доставку - и постоянную надежность - информации о доступности. Во всех этих системах:
Список соседей используется не только для управления передачей новой информации о доступности, но и для проверки правильности получения информации о доступности.
Список соседей используется не только для управления передачей новой информации о доступности, но и для проверки правильности получения информации о доступности.
В контексте распределения достижимости на основе соседей существует несколько обычно используемых механизмов для передачи определенной информации о доступности с устройства на устройство; часто любая заданная плоскость управления будет использовать более одного из описанных здесь методов.
Плоскость управления может использовать порядковые номера (или какой-либо другой механизм) для обеспечения правильной репликации. Порядковые номера могут фактически использоваться для описания отдельных пакетов и больших блоков информации о доступности; Рисунок 11 иллюстрирует это.
Получив пакет, получатель может отправить подтверждение получения пакета, отметив порядковые номера, которые он получил. Отдельный порядковый номер может использоваться для описания достижимости отдельного сетевого уровня.
Информация (NLRI), передаваемая по сети. Информация NLRI, распределенная по нескольким пакетам, затем может быть описана с использованием одного порядкового номера.
Плоскость управления может описывать базу данных для обеспечения правильной репликации. Например, плоскость управления может описывать информацию в базе данных как:
Список порядковых номеров, соответствующих отдельным записям, содержащий информацию о доступности, содержащуюся в базе данных.
Группы смежных порядковых номеров, содержащиеся в базе данных (несколько более компактный способ представления всех порядковых номеров)
Набор порядковых номеров в паре с хешами информации в каждой записи информации о доступности; это имеет то преимущество, что не только описывает записи в базе данных, но также дает возможность получателю проверять содержимое каждой записи, но без переноса всей базы данных для выполнения проверки.
Хэш по блокам записей о достижимости, содержащихся в базе данных, который может быть вычислен получателем для тех же записей и напрямую сравнен, чтобы определить, отсутствуют ли записи.
Эти типы дескрипторов баз данных могут передаваться периодически, или только при наличии изменений, или даже в других конкретных ситуациях, чтобы не только обеспечить синхронизацию баз данных сетевыми устройствами, но и определить, что отсутствует или находится в ошибке, поэтому дополнительная информация может быть запрошена.
Каждая из этих схем имеет преимущества и недостатки. Как правило, протоколы реализуют схему, которая позволяет реализации не только проверять отсутствующую информацию, но также информацию, которая была случайно повреждена либо в памяти, либо во время передачи.
Конференции помогают оперативно обсуждать важные вопросы внутри компании и эффективно решать проблемы. В данной статье пойдет речь о модуле конференций (Conference) в Elastix 4.0.
Процесс настройки
Для начала процесса настройки данного модуля необходимо пройти по следующему пути в веб-интерфейсе Elastix: PBX → Conference. Появится интерфейс менеджмента конференций:
Соответственно, при клике на “+ New Conference” произойдет создание новой конференции, а при нажатии на “Delete” – удаление уже существующей инстанции. По сути, можно создать бесконечно много конференций, но, как правило, для небольшой организации требуется всего пара-тройка подобных инстанций и то довольно редко.
Так же кнопка «Show Filter» позволяет фильтровать конференции по трем признакам: прошедшие, текущие и будущие.
Ниже на скриншоте приведу пример настроенной конференции:
Рассмотрим поля по порядку:
Conference Name – название конференц-рума
Moderator PIN – пин-код модератора (управляющего) конференцией
User PIN – пин-код пользователя (можно оставить поле пустым)
Start Time – время начала конференции
Conference Number – номер конференции для вызова (экстеншен, по своей сути)
Conference Owner – «владелец» конференции
Moderator Options – опции для модератора, такие как как оповещение о появлении в конференции и запись разговора
User Options – опции пользователя: оповещение, режим слушателя, ожидание владельца конференции
Duration – длительности конференции
Max Participants – максимальное количество участников ( к данному параметру необходимо отнестись внимательно, так как большое количество участников будут очень сильно загружать сильно, что может повлиять на общую функциональность Elastix.
Для завершения и сохранения конференции необходимо нажать на кнопку «Save». Ниже привожу пример трех созданных конференций который запланированы на будущее время (обратите внимание на надпись Filter applied: State = Future Conferences)