По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Давно прошли те времена, когда «база данных» представляла собой единую СУБД на основе реляционной модели данных, которую обычно устанавливали на самом мощном сервере в центре обработки данных. Такая база данных могла обслуживать все виду запросов – 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, обеспечивает простой способ масштабирования в случае, если с течением времени возрастает потребность в хранении и анализе данных.
Как видите, вариантов баз данных временных рядов на рынке множество, и это не удивительно. В последнее время, все более популярным становится анализ временных рядов, поскольку он становится все более важных для различных бизнес-операций. К счастью, есть большое количество проектов как с открытым кодом, так и коммерческих. И с большой долей вероятности вы сможете найти инструмент, который полностью удовлетворит ваши потребности.
В нашей прошлой статье мы рассмотрели, как OSPF может автоматически фильтровать маршруты с помощью специальных областей и типов LSA. Но как насчет вариантов ручной фильтрации маршрутов в OSPF? В этой статье мы рассмотрим методы, которые можно использовать в различных точках топологии.
Предыдущие статьи:
Расширенные возможности OSPF: Области
OSPF: создание конкретных типов областей
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Фильтрация на ASBR
Одним из простых и эффективных методов фильтрации на ASBR является использование распределенного списка. Здесь мы определяем правила идентификации маршрута со списком доступа, а затем ссылаемся на этот список доступа в списке распространения.
Рисунок 1. Топология OSPF
В этом примере наша область 1 настроена как нормальная, не являющаяся магистральной областью. Вы можете увидеть это, при просмотре таблицы маршрутизации на ORL.
show ip route
Обратите внимание на два префикса (E2) 192.168.10.0 и 192.168.20.0. Давайте отфильтруем 192.168.10.0 на ASBR ATL.
ATL# configuration terminal
Enter configuration commands , one per line . End with CNTL/Z .
ATL(config)#access-list 1 deny 192.168.10 .0 0.0.0.255
ATL(config)#access-list 1 permit any
ATL(config)#router ospf 1
ATL(config-router)#distribute-list 1 out eigrp 100
ATL(config-router)#end
ATL#
Обратите внимание, насколько проста эта конфигурация. Давайте посмотрим, сработало ли это, еще раз изучив таблицу маршрутов ORL:
show ip route
Конфигурация работет отлично, и 192.168.10.0 больше не доступен на ORL.
Другой простой метод - использовать команду summary-address на ASBR и использовать ключевое слово not-advertise.
Вот пример из нашей топологии. Обратите внимание, что был удален предыдущий список рассылки из конфигурации ATL до этой настройки здесь:
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL(config)#router ospf 1
ATL(config-router)#summary-address 192 .168.10.0 not-advertise
ATL(config-router)#end
ATL#
Проверка на ORL доказывает успешную фильтрацию сети 192.168.10.0.
show ip route
Нет ничего удивительного в том, что вы можете использовать подход route map для фильтрации в ASBR. Ведь route map невероятно полезны и гибки.
Здесь мы определим правила со списком доступа (еще раз) и используем их в логике route map:
ATL#conf t
Enter configuration commands, one per line . End with CNTL/Z .
ATL(config)#access-list 1 deny 192.168.10.0 0.0.0.255
ATL(config)#access-list 1 permit any
ATL(config)#route-map МУМАР permit 10
ATL(config-route-map)#match ip address 1
ATL(config-route-map)#router ospf 1
ATL(config-router)#redistribute eigrp 100 metric 1000 route-map МУМАР subnets
ATL(config-router)#end
ATL#
Как вы можете догадаться, проверка на ORL показывает отличную работу.
show ip route
Фильтрация на ABR
Вы также можете фильтровать на ABR. Наиболее распространенным методом является использование списка префиксов, как показано здесь:
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#ip prefix-list 1 deny 192.168.10.0/24
ATL2 (config)#ip prefix-list 1 permit 0.0.0.0/0
ATL2 (config)#router ospf 1
ATL2 (config-router )#area 1 filter-list prefix 1 out
ATL2 (config-router )#end
ATL2#
show ip route
Мы фильтруем префикс 192.168.10.0, но мы делаем это на ABR, и мы фильтруем по Type 3. Это контрастирует с фильтрацией типа 5 (для того же префикса!) Мы уже делали это раньше в ASBR.
Фильтрация в роутере
Имейте в виду, что вы можете легко фильтровать на любом спикере OSPF внутри самого маршрутизатора. Например, вы можете настроить подход к распределению списка и фильтровать входящие сообщения с его помощью.
В этом примере мы еще раз остановимся на 192.168.10.0. Мы заблокируем его в ACL и будем использовать этот ACL в списке рассылки.
Обратите внимание, что мы находимся на ORL:
ORL#conf t
Enter configuration commands , one per line . End with CNTL/Z .
ORL(config) #access-list 1 deny 192.168.10.0 0.0.0.255
ORL(config) #access-list 1 permit any
ORL(config)#router ospf 1
ORL(config-router)#distribute-list 1 in
ORL(config- router)#end
ORL#
И снова наш желаемый результат проверки:
show ip route
Протокол маршрутизации OSPF (Open Shortest Path First) (про него можно прочитать тут, а про его настройку здесь) для обмена информации о топологии сети использует сообщения LSA (Link State Advertisement). Когда роутер получает LSA сообщение, он помещает его в базу Link-State DataBase (LSDB). Когда все базы между маршрутизаторами синхронизированы, OSPF использует алгоритм Shortest Path First, чтобы высчитать лучший маршрут между сетями.
LSA содержат в себе информацию о маршруте передается внутри Link State Update (LSU) пакета. Каждый LSU пакет содержит в себе один или несколько LSA, и когда LSU отправляется между маршрутизаторами OSPF, он распространяет информацию LSA через сеть. Каждый LSA используется в определенных границах сети OSPF.
Выглядит это вот так:
Типы LSA
OSPF в настоящее время определяет 11 различных типов LSA, однако, несмотря на большое разнообразие LSA, только около половины из них обычно встречаются в сетях OSPF, но мы рассмотрим их все.
LSA Тип 1 – OSPF Router LSA
Пакеты LSA Type 1 (Router LSA) отправляются между маршрутизаторами в пределах одной и той же зоны (area) где они были созданы и не покидают эту зону. Маршрутизатор OSPF использует пакеты LSA Type 1 для описания своих собственных интерфейсов, а также передает информацию о своих соседях соседним маршрутизаторам в той же зоне.
LSA Тип 2 – OSPF Network LSA
Пакеты LSA Type 2 (Network LSA) генерируются Designated Router’ом (DR) для описания всех маршрутизаторов, подключенных к его сегменту напрямую. Пакеты LSA Type 2 рассылаются между соседями в одной и той же зоны где они были созданы и остаются в пределах этой зоны.
LSA Тип 3 – OSPF Summary LSA
Пакеты LSA Type 3 (Summary LSA) генерируются с помощью пограничных маршрутизаторов Area Border Routers (ABR) и содержат суммарное сообщение о непосредственно подключенной к ним зоне и сообщают информацию в другие зоны, к которым подключен ABR. Пакеты LSA Type 3 отправляются в несколько зон по всей сети.
На рисунке показано как маршрутизатор R2 ABR создает Type 3 Summary LSA и отправляет их в зону Area 0. Таким же образом R3 ABR роутер создает пакеты Type 3 и отправляет их в Area 2. В таблице маршрутизации маршруты, полученные таким образом, отображаются как “O IA”
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
LSA Тип 4 – OSPF ASBR Summary LSA
Пакеты LSA Type 4 (ASBR Summary LSA) - это LSA, которые объявляют присутствие автономного пограничного маршрутизатора Autonomous System Border Router (ASBR) в других областях.
На схеме, когда R2 (ABR) принимает пакет LSA Type 1 от R1, он создаст пакет LSA Type 4 (Summary ASBR LSA), который передает маршрут ASBR, полученный из Area 1, и вводит его в Area 0. Хотя пакеты LSA Type 4 используются ABR для объявления маршрута ASBR через их зоны, он не будет использоваться самим ASBR в пределах его локальной зоны (Area 1); ASBR использует LSA Type 1 для информирования своих соседей (в данном случае R2) в своих сетях.
LSA Тип 5 – OSPF ASBR External LSA
Пакеты LSA Type 5 (ASBR External LSA) генерируются ASBR для передачи внешних перераспределенных маршрутов в автономную систему (AS) OSPF. Типичным примером LSA Type 5 будет внешний префикс или маршрут по умолчанию (default router), как показано на схеме.
Этот внешний маршрут/префикс перераспределяется в OSPF-сеть ASBR (R1) и в таблице маршрутизации будет отображаться как "O E1" или "O E2".
LSA Тип 6 – OSPF Group Membership LSA
Пакеты LSA Type 6 (Group Membership LSA) были разработаны для протокола Multicast OSPF (MOSPF) , который поддерживает многоадресную маршрутизацию через OSPF. MOSPF не поддерживается Cisco и не пользуется широкой популярностью.
LSA Тип 7 – OSPF Not So Stubby Area (NSSA) External LSA
Пакеты LSA Type 7 (NSSA External LSA) используются для некоторых специальных типов зон, которые не позволяют внешним распределенным маршрутам проходить через них и таким образом блокируют распространение в них LSA Type 5. LSA Type 7 действуют как маска для LSA Type 5 пакетов, позволяя им перемещаться по этим специальным зоам и достигать ABR, который может переводить пакеты LSA Type 7 обратно в пакеты LSA Type 5.
На схеме ABR R2 переводит LSA Type 7 в LSA Type 5 и рассылает его в сеть OSPF.
LSA Тип 8 – OSPF External Attributes LSA (OSPFv2) / Link Local LSA (OSPFv3)
Пакеты LSA Type 8 в OSPFv2 (IPv4) называются внешними атрибутами LSA и используются для передачи атрибутов BGP через сеть OSPF, в то время как адреса BGP передаются через LSA Type 5 пакеты, однако, эта функция не поддерживается большинством маршрутизаторов. С OSPFv3 (IPv6) , LSA Type 8 переопределяется для передачи информации IPv6 через сеть OSPF.
LSA Тип 9, 10 и 11
Обычно LSA этих типов используются для расширения возможностей OSPF. Практическое применение этих LSA заключается в Traffic Engineering’е MPLS, где они используются для передачи параметров интерфейса, таких как максимальная пропускная способность, незанятая полоса пропускания и т.д.
LSA Тип 9 – OSPF Link Scope Opaque (OSPFv2) / Intra Area Prefix LSA (OSPFv3)
LSA Type 9 в OSPFv2 (IPv4) определяется как Link Scope Opaque LSA для передачи OSPF информации. Для OSPFv3 он переопределяется для обработки префикса связи для специального типа зоны, называемого Stub Area.
LSA Тип 10 – OSPF Area Scope Opaque LSA
Пакеты LSA Type 10 используются для потоковой передачи информации OSPF через маршрутизаторы других областей. Даже если эти маршрутизаторы не обрабатывают эту информацию, чтобы расширить функциональность OSPF, этот LSA используется для Traffic Engineering’а для объявлений MPLS и других протоколов.
LSA Тип 11– OSPF AS Scope Opaque LSA
Пакеты LSA Type 11 выполняют ту же задачу, что и пакеты LSA Type 10, но не пересылаются в специальные зоны (Stub зоны)