По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Давно прошли те времена, когда «база данных» представляла собой единую СУБД на основе реляционной модели данных, которую обычно устанавливали на самом мощном сервере в центре обработки данных. Такая база данных могла обслуживать все виду запросов – OLTP (On-Line Transaction Processing – обработка транзакций в режиме реального времени), OLAP (On-Line Analytical Processing – аналитическая обработка данных в режиме реального времени) – все, что нужно для бизнеса. В настоящее время базы данных работают на самом обычном оборудовании, они также стали более сложными с точки зрения высокой доступности и более специализированными для обработки определенного типа трафика. Специализация позволяет добиться гораздо большей производительности баз данных – все оптимизировано для работы с определенным типом данных: оптимизатор, механизм хранения, даже язык может быть не SQL, как это бывает обычно. Он может быть основан на SQL с некоторыми расширениями, которые позволяют более эффективно манипулировать данными, или может быть чем-то абсолютно новым, созданным с нуля. На сегодня мы имеем аналитические столбчатые базы данных, такие как ClickHouse или MariaDB AX, платформы обработки и анализа больших данных, такие как Hadoop, решения NoSQL, такие как MongoDB или Cassandra, хранилища данных типа «ключ-значение», такие как Redis. Мы также имеем базы данных временных рядов, такие как Prometheus или TimeScaleDB. Это именно то, на чем мы акцентируем внимание в данной статье. Базы данных временных рядов (Time Series Databases) – что это такое и зачем вам нужно еще одно хранилище данных в своей среде. Для чего нужны базы данных временных рядов? Как видно из названия, базы данных временных рядов предназначены для хранения данных, которые изменяются со временем. Это могут быть абсолютно любые данные, собранные с течением времени. Это могут быть метрические показатели, собранные из некоторых систем – все системы трендов являются примерами данных временных рядов. Каждый раз, когда вы смотрите на информационные панели в ClusterControl, на самом деле вы видите визуальное представление временных рядов, хранящихся в Prometheus – базе данных временных рядов. Временные ряды не ограничиваются метрическими показателями базы данных. Метриками может быть что угодно – изменение потока людей, входящих в торговый центр, с течением времени, изменение трафика в городе, использование общественного транспорта в течение дня, течение воды в реке или ручье, количество энергии, вырабатываемое водной установкой – все это и все остальное, что можно измерить во времени, является примером временных рядов. Такие данные можно запросить, построить, проанализировать, чтобы найти корреляционную зависимость между различными метриками. Структура данных в базе данных временных рядов Как вы понимаете, самая важная составляющая данных в базе данных временных рядов – это время. Существует два основных способа хранения данных. Первый способ чем-то похож на хранилище «ключ-значение» и выглядит так: Метка времени Метрика 1 2019-03-28 00:00:01 2356 2019-03-28 00:00:02 6874 2019-03-28 00:00:03 3245 2019-03-28 00:00:04 2340 Проще говоря, для каждой метки времени имеется некоторое значение метрики. Второй способ подразумевает хранения большего числа показателей. Вместо того, чтобы хранить каждую метрику в отдельной таблице или коллекции, их можно хранить вместе. Метка времени Метрика 1 Метрика 2 Метрика 3 Метрика 4 Метрика 5 2019-03-28 00:00:01 765 873 124 98 0 2019-03-28 00:00:02 5876 765 872 7864 634 2019-03-28 00:00:03 234 7679 98 65 34 2019-03-28 00:00:04 345 3 598 0 7345 Такая структура данных, когда все метрики связаны, позволяет более эффективно запрашивать данные. Вместо того, чтобы читать несколько таблиц и объединять их для получения всех метрик, достаточно прочитать лишь одну единственную таблицу, чтобы подготовить данные к обработке и представлению. У вас может возникнуть вопрос – что же здесь нового? Чем эта база данных отличается от обычной таблицы в MySQL или в любой другой реляционной базе данных? Да, действительно, конструкция таблиц очень похожа. Однако есть существенные различия в рабочей нагрузке, которые могут существенно повысить производительность, если хранилище данных предназначено для использования такого рода таблиц, Временные ряды, как правило, только растут. Маловероятно, что вы будете обновлять старые данные. Чаще всего строки в таблице не удаляются, однако вам может понадобиться какая-то агрегация данных с течением времени. Если принять это при проектировании внутреннего устройства базы данных, то этот факт будет иметь существенное расхождение в сравнении со «стандартными» реляционными (и не реляционными) базами данных, предназначенными для обработки транзакций в режиме реального времени. Что здесь является наиболее важным, так это способность последовательно хранить большие объемы данных, поступающих со временем. Можно, конечно, использовать РСУБД для хранения временных рядов, но она не оптимизирована для этого. Данные и индексы, сгенерированные на ее основе, могут стать слишком большими, и запросы будут проходить очень медленно. Механизмы хранения данных, используемые в СУБД, предназначены для хранения различных типов данных. Обычно они оптимизированы для рабочей нагрузки обработки транзакций в режиме реального времени, которая включает в себя частое изменение и удаление данных. В реляционных базах данных также часто отсутствуют специализированные функции и функции, предназначенные для обработки временных рядов. Мы уже упоминали, что вы вероятно столкнетесь с необходимостью агрегировать данные, полученные ранее какой-то временной метки. Вы также можете иметь возможность легко запускать некоторые статистические функции для ваших временных рядов, чтобы сглаживать их, определять и сравнивать тренды, интерполировать данные и многое другое. Здесь, например, вы можете найти некоторые функции, которые Prometheus предоставляет пользователям. Примеры баз данных временных рядов На рынке существует множество баз данных временных рядов, поэтому, естественно, что рассмотреть все мы не сможем. Но мы все же хотели привести несколько примеров баз данных временных рядов, которые, возможно, вам уже знакомы или которые вы уже, возможно, используете (сознательно или нет). InfluxDB InfluxDB была разработана компанией InfluxData. Это база данных временных рядов с открытым исходным кодом, написанная языке программирования Go. Хранилище данных позволяет вводить запросы данных на языке, подобном SQL, что позволяет разработчикам легко интегрировать эту базу данных в свои приложения. InfluxDB также может работать как часть коммерческого решения, которое охватывает весь стек, предназначенный для обеспечения процесса обработки данных временных рядов, полнофункциональной высоко доступной средой. Prometheus Prometheus – это еще один проект с отрытым исходным кодом, который также написан на языке программирования Go. Он обычно используется в качестве серверной части для различных инструментов и проектов с открытым исходным кодом, например, Percona Monitoring and Management. Prometheus также является наилучшим вариантом для ClusterControl. Prometheus можно развернуть из ClusterControl с целью хранения данных временных рядов, собранных на серверах баз данных, контролируемых и управляемых ClusterControl: Prometheus широко используется в мире Open Source, поэтому его довольно легко интегрировать в уже существующую среду с помощью нескольких экспортеров. RRDtool Это один из примеров базы данных временных рядов, которую многие используют, даже не подозревая об этом. RRDtool – это достаточно популярный проект с открытым исходным кодом для хранения и визуализации временных рядов. Если вы хоть раз использовали Cacti, то и RRDtool вы тоже использовали. Если вы разработали свое собственное решение, вполне вероятно, что и здесь вы тоже использовали RRDtool в качестве серверной части для хранения данных. Сейчас RRDtool, возможно, не так популярен, как это было в 2000-2010 годах. В те годы это был самый распространенный способ хранения временных рядов. Забавный факт – ранние версии ClusterControl использовали именно RRDtool. TimeScale TineScale – это база данных временных рядов, разработанная на основе PostgreSQL. Это расширение для PostgreSQL, которое использует основное хранилище данных для предоставления доступа к ним, что означает, что оно поддерживает все разновидности SQL, доступные для использования. Поскольку это расширение, то оно использует все функции и расширения PostgreSQL. Вы можете совмещать временные ряды с другими типами данных, например, объединять временные ряды с метаданными, пополняя информацией выходные данные. Вы также можете выполнить более сложную фильтрацию, используя JOIN и таблицы без временных рядов. Геоинформационное обеспечение в PostgreSQL TimeScale можно использовать для отслеживания географических местоположений с течением времени, а также использовать все возможности масштабирования, предлагаемые PostgreSQL, включая репликацию. Timestream Amazon Web Services также предлагает базы данных временных рядов. О Timestream было объявлено совсем недавно, в ноябре 2018 года. Она добавляет еще одно хранилище данных в портфель AWS, помогая пользователям обрабатывать временные ряды, поступающие из таких источников, как устройства Интернет вещей или отслеживаемые сервисы. Его также можно использовать для хранения метрических данных, полученных из журналов, созданных несколькими службами. Это позволяет пользователям выполнять аналитические запросы к ним, помогая понять закономерности и условия, в которых работают службы. Tiemstream, как и большинство сервисов AWS, обеспечивает простой способ масштабирования в случае, если с течением времени возрастает потребность в хранении и анализе данных. Как видите, вариантов баз данных временных рядов на рынке множество, и это не удивительно. В последнее время, все более популярным становится анализ временных рядов, поскольку он становится все более важных для различных бизнес-операций. К счастью, есть большое количество проектов как с открытым кодом, так и коммерческих. И с большой долей вероятности вы сможете найти инструмент, который полностью удовлетворит ваши потребности.
img
gRPC — это мощная платформа для работы с удаленными вызовами процедур (Remote Procedure Calls). RPC позволят писать код так, как будто он будет выполняться на локальном компьютере, даже если он может выполняться на другом компьютере. Что такое RPC? RPC — это форма взаимодействия клиент-сервер, в которой используется вызов функции, а не обычный вызов HTTP. Идея в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальная функция. Он использует IDL (Interface Definition Language - язык описания интерфейса) как форму контракта на вызываемые функции и тип данных. RPC — это протокол "запрос-ответ", т.е. он следует модели "клиент-сервер": Клиент делает запрос на выполнение процедуры на удаленном сервере. Как и при синхронном локальном вызове, клиент приостанавливается до тех пор, пока не будут возвращены результаты процедуры. Параметры процедуры передаются по сети на сторону сервера. Процедура выполняется на сервере и, наконец, результаты передаются обратно клиенту. gRPC воспроизводит этот архитектурный стиль взаимодействия клиент-сервер через вызовы функций. Таким образом, gRPC технически не является новой концепцией. Скорее, он был заимствован из этой старой техники и улучшен, что сделало ее очень популярной. Что такое gRPC? В 2015 году Google открыл исходный код своего проекта, который в конечном итоге получил название gRPC. Но что на самом деле означает буква «g» в gRPC? Многие люди могут предположить, что это для Google, потому что Google это сделал, но это не так. Google меняет значение «g» для каждой версии до такой степени, что они даже сделали README, чтобы перечислить все значения. С момента появления gRPC он приобрел довольно большую популярность, и многие компании используют его. Есть много причин, по которым gRPC так популярен: простая абстракция, он поддерживается во многих языках и он очень эффективный. И помимо всех вышеперечисленных причин, gRPC популярен потому, что очень популярны микросервисы и имеется большое количество взаимодействий между ними. Именно здесь gRPC помогает больше всего, предоставляя поддержку и возможности для решения типичных проблем, возникающих в таких ситуациях. А поскольку разные сервисы могут быть написаны на разных языках, gRPC поставляется с несколькими библиотеками для их поддержки. Архитектура gRPC Мы сказали что производительность gRPC очень высока, но что делает ее такой хорошей? Что делает gRPC намного лучше, чем RPC, если их дизайн очень похож? Вот несколько ключевых отличий, которые делают gRPC столь эффективным. HTTP/2 HTTP был с нами очень долго. Сейчас почти все серверные службы используют этот протокол. HTTP/1.1 долгое время оставался актуальным, затем в 2015 году, появился HTTP/2, который фактически заменил HTTP/1.1 как самый популярный транспортный протокол в Интернете. Если вы помните, что 2015 год был также годом выхода gRPC, и это было вовсе не совпадение. HTTP/2 также был создан Google для использования gRPC в его архитектуре. HTTP/2 — одна из важных причин, почему gRPC может работать так хорошо. И в следующем разделе вы поймете, почему. Мультиплексирование запроса/ответа В традиционном протоколе HTTP невозможно отправить несколько запросов или получить несколько ответов вместе в одном соединении. Для каждого из них необходимо создать новое соединение. Такой вид мультиплексирования запроса/ответа стал возможен в HTTP/2 благодаря введению нового уровня HTTP/2, называемого binary framing. Этот двоичный уровень инкапсулирует и кодирует данные. На этом уровне HTTP-запрос/ответ разбивается на кадры (они же фреймы). Фрейм заголовков (HEADERS frame) содержит типичную информацию заголовков HTTP, а фрейм данных (DATA frame) содержит полезные данные. Используя этот механизм, можно получить данные из нескольких запросов в одном соединении. Это позволяет получать полезные данные из нескольких запросов с одним и тем же заголовком, тем самым идентифицируя их как один запрос. Сжатие заголовка Вы могли столкнуться со многими случаями, когда заголовки HTTP даже больше, чем полезная нагрузка. И HTTP/2 имеет очень интересную стратегию под названием HPack для решения этой проблемы. Во-первых, все в HTTP/2 кодируется перед отправкой, включая заголовки. Это помогает повысить производительность, но это не самое важное в сжатии заголовков. HTTP/2 сопоставляет заголовок как на стороне клиента, так и на стороне сервера. Из этого HTTP/2 может узнать, содержит ли заголовок одно и то же значение, и отправляет значение заголовка только в том случае, если оно отличается от предыдущего заголовка. Как видно на картинке выше, запрос № 2 отправит только новый путь, так как другие значения точно такие же как и были. И да, это значительно сокращает размер полезной нагрузки и, в свою очередь, еще больше повышает производительность HTTP/2. Что такое Protocol Buffer (Protobuf)? Protobuf — это наиболее часто используемый IDL для gRPC. Здесь вы храните свои данные и функциональные контракты в виде так называемого прото-файла. По сути это протокол сериализации данных, такой как JSON или XML. Выглядит это так: message Person { required string name = 1; required int32 id = 2; optional string email = 3; } Так мы определили сообщение Person с полями name, id и email Поскольку это форма контракта то и клиент, и сервер должны иметь один и тот же прото-файл. Файл proto действует как промежуточный контракт для клиента, чтобы вызвать любые доступные функции с сервера. Protobuf также имеет собственные механизмы, в отличие от обычного REST API, который просто отправляет строки JSON в виде байтов. Эти механизмы позволяют значительно уменьшить полезную нагрузку и повысить производительность. Что еще может предложить gRPC? Метаданные Вместо обычного заголовка HTTP-запроса в gRPC есть то, что называется метаданными (Metadata). Метаданные — это тип данных «ключ-значение», которые можно установить как на стороне клиента, так и на стороне сервера. Заголовок может быть назначен со стороны клиента, в то время как серверы могут назначать заголовок и трейлеры, если они оба представлены в виде метаданных. Потоковая передача Потоковая передача (Streaming) — это одна из основных концепций gRPC, когда в одном запросе может выполняться несколько действий. Это стало возможным благодаря упомянутой ранее возможности мультиплексирования HTTP/2. Существует несколько видов потоковой передачи: Server Streaming RPC: когда клиент отправляет один запрос, а сервер может отправить несколько ответов. Например, когда клиент отправляет запрос на домашнюю страницу со списком из нескольких элементов, сервер может отправлять ответы по отдельности, позволяя клиенту использовать отложенную загрузку. Client Streaming RPC: когда клиент отправляет несколько запросов, а сервер отправляет обратно только один ответ. Например, zip/chunk, загруженный клиентом. Bidirectional Streaming RPC: клиент и сервер одновременно отправляют сообщения друг другу, не дожидаясь ответа. Перехватчики gRPC поддерживает использование перехватчиков для своего запроса/ответа. Они перехватывают сообщения и позволяют вам изменять их. Это звучит знакомо? Если вы работали с HTTP-процессами в REST API, перехватчики очень похожи на middleware (оно же промежуточное ПО). Библиотеки gRPC обычно поддерживают перехватчики и обеспечивают простую реализацию. Перехватчики обычно используются для: Изменения запроса/ответа перед передачей. Это можно использовать для предоставления обязательной информации перед отправкой на клиент/сервер. Позволяет вам манипулировать каждым вызовом функции, например, добавлять дополнительные логи для отслеживания времени отклика. Балансировки нагрузки Если вы еще не знакомы с балансировкой нагрузки, это механизм, который позволяет распределять клиентские запросы по нескольким серверам. Но балансировка нагрузки обычно делается на уровне прокси (например, nginx). Так причем это здесь? Дело в том, что gRPC поддерживает метод балансировки нагрузки клиентом. Он уже реализован в библиотеке Golang и может быть легко использован. Хотя это может показаться какой-то магией, это не так. Там есть что-то типа преобразователя DNS для получения списка IP-адресов и алгоритм балансировки нагрузки под капотом. Отмена вызова Клиенты gRPC могут отменить вызов gRPC, когда им больше не нужен ответ. Однако откат на стороне сервера невозможен. Эта функция особенно полезна для потоковой передачи на стороне сервера, когда может поступать несколько запросов к серверу. Библиотека gRPC оснащена шаблоном метода наблюдателя, чтобы узнать, отменен ли запрос, и позволить ей отменить несколько соответствующих запросов одновременно.
img
Дорогой читатель! В поисках полезной автоматизации и кастомизации своего Asterisk продвинутые администраторы прибегают к использованию различных скриптов. Это может быть PHP, Perl C, Pascal или Shell. Для использования скриптов, написанных на одном из перечисленных языков программирования в диалплане Asterisk используется AGI (Asterisk Gateway Interface) – о нем и поговорим. Как это работает? AGI - это прослойка между скриптом и диалпланом (планом набора) в Asterisk. В скрипт мы можем передавать различные переменные, а можем получать какие - то значения из скрипта. Когда Asterisk инициирует запуск скрипта через AGI, он передает в него набор переменных. Все переменные обладают префиксом agi_: Переменная Описание Пример agi_request Имя файла исполняемого скрипта trunk.php agi_channel Канал, инициирующий звонок Local/89123456789@from-internal-00000002;2 agi_language Языковой код en agi_type Тип канала, инициирующий вызов Local agi_uniqueid Уникальный идентификатор звонка 1497364935.15 agi_version Версия Asterisk 13.10.0 agi_callerid Номер звонящего (CID Number) 89123456789 agi_calleridname Имя звонящего (CID Name) 89123456789 agi_dnid Набранный номер unknown agi_context Контекст обработки вызова macro-dialout-trunk Как вызвать AGI в диалплане? Вызвать AGI скрипт очень просто: предварительно, загрузите скрипт в директорию /var/lib/asterisk/agi-bin/. После этого, скрипту необходимо дать права и собственника. Предположим, наш скрипт называется trunk.php: chmod 755 /var/lib/asterisk/agi-bin/trunk.php chown asterisk:asterisk /var/lib/asterisk/agi-bin/trunk.php Теперь, чтобы скрипт был вызван в диалплане, просто добавьте следующую конструкцию: exten => 1333,n,AGI(trunk.php) Просто, не правда ли? А если мы хотим передать переменную в скрипт? Просто добавьте ее после запятой: exten => 1333,n,AGI(trunk.php, ${CALLERID(number)}) А как же написать скрипт? Теперь к самому скрипту – напишем его на PHP. Пусть нам нужно отправлять письмо с номером звонящего. Выглядеть скрипт будет так: #!/usr/bin/php -q <?php require('phpagi.php'); $agi = new AGI(); //подключаем файл phpagi.php – 1 и 2 строки обязательны в любом скрипте $cid = $agi->request['agi_callerid']; // берем из AGI номер звонящего mail("info@merionet.ru", 'Привет!', 'Вот и номер звонящего:', $cid); //отправляем в письме Вот и все. Нам будет приходить на почту письмо с номером звонящего – прокачав данный функционал можно отслеживать пропущенные вызовы, например.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59