По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
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
Привет, мир! Сегодня говорим про то, в чем разница между маршрутизатором, коммутатором и хабом. Для сетевого специалиста это можно объяснить просто - хаб работает на первом уровне модели OSI, коммутатор на втором, а маршрутизатор на третьем. На этом все, спасибо, пока! Ладно - ладно, шутка, сейчас попробуем перевести это на человеческий язык. Видеопособие Хаб Хаб, или как его еще называют концентратор, самое простое устройство для соединения нескольких девайсов в одну сеть. В хабе есть несколько портов, в которые подключаются устройства и, хаб - это максимально примитивное устройство, без мозгов. Его задача заключается в том, что когда на вход одного порта приходят данные, он их копирует и рассылает их по всем своим портам. Единственное, что он знает - к каким портам подключены устройства. В итоге все в сети получают эти данные и смотрят на адрес получателя, кому они предназначены. Если ему - то принимают, если не ему, то уничтожают данные. Это как если бы почту вашего соседа получали все жильцы дома, открывали письмо, а если оно не для них, выкидывали бы. Не самый продуктивный и безопасный способ передачи информации. В современных сетях хабы уже не используются. Коммутатор Коммутатор, или как в профессиональной среде его называют свитч, это устройство уже поумнее. К нему также подключаются сетевые устройства в порты для того чтобы образовать сеть, однако, он отличается от хаба тем, что пришедший к нему траффик он высылает уже не на все порты, а непосредственно получателю. Исключения - бродкаст или мультикаст сообщения, которые рассылаются на все порты. Если кратко, бродкаст - широковещательное сообщение. Его получают все устройства в текущей подсети. Пример из жизни - массовая почтовая рассылка всем клиентам компании или надпись баллончиком на входной двери квартиры "Верни долг". Во втором примере кажется, что, она предназначается только одному человеку, но мы то с вами понимаем. Мультикаст - отправляется на специальный адрес, который получат те, кто его слушают. Это как настроить свой приемник на определенную радиоволну и слушать только ее. Откуда он знает куда пересылать данные? У него есть специальная таблица, в которой есть соответствие физического адреса устройства или, как говорят MAC - адреса, (выглядит примерно вот так: 50-46-5D-6E-8C-20) и к какому порту оно подключено. Ориентируясь на эту информацию коммутатор принимает решения о том, куда направить данные. Хабы и коммутаторы используются для построения своей локальной сети, например, дома или в офисе, а вот для того, чтобы соединять сети и передавать данные наружу из этой сети, как, например, в интернет, нам уже понадобятся маршрутизаторы. Маршрутизаторы Маршрутизаторы или роутеры, в отличии от коммутаторов и хабов умеют работать с IP - адресами. Как понятно из названия, машрутизатор занимается тем, что машрутизирует данные из одной сети в другую, основываясь на IP - адресе приходящих к нему данных. Когда к нему приходит пакет с данными, он смотрит на адрес назначения и затем в свою таблицу маршрутизации и после этого принимает решение, что сделать с данными - перенаправить данные в свою сеть или отправить дальше в другую сеть. Это самый умный девайс из нашего сегодняшнего списка, так сказать, сын маминой подруги среди активных сетевых устройств, и он знает топологию сети и куда нужно слать данные, чтобы они достигли цели. Ну и помимо этих основных задач, маршрутизатор также может выступать в качестве DHCP и DNS сервера, иметь настройки безопасности и кучу разных дополнительных функций.
img
Партнер данного материала Telegram-канал Админим с Буквой Тема статьи небольшая, но информация данная необходима для понимания ограничений на дисках в операционной системе Linux. В данной статье рассмотрим: Установка квоты Редактирование квоты Просмотр отчетов по квотам Квоты – это ограничения, налагаемые системным администратором на использование дискового пространства в операционных системах. Они позволяют гибко управлять ограниченным ресурсом для сервера свободным местом на жестком диске. Квоты можно устанавливать, как на отдельных пользователей, так и на группы пользователей. Для конфигурации и управления квотами используются следующие команды: quotaon – включение квоты quotaoff – выключение квоты edquota – редактирование квоты repquota - отчет по квотам У Windows Server, конечно намного богаче инструментарий по работе с квотами. Для этого выделена целый File Server Resource Manager, но в данной статье мы посмотрим, как это работает в Linux системах на примере Ubuntu Server. У меня есть смонтированый раздел /dev/sdc1 в папку /mnt/hard. Для того, чтобы работать с квотами, необходимо поставить пакет apt-get install quota. Для того, чтобы использовать квоты, нам необходимо добавить монтирование данного раздела в файл /etc/fstab. Добавляем следующую строчку: /dev/sdc1 /mnt/hard auto rw,user,auto,usrquota,grpquota 0 0 Где, раздел, куда монтируем, автоопределение файловой системы, раздел для записи, разрешаем монтирование пользователям, раздел будет монтироваться автоматически при старте системы и включаем пользовательскую квоту и групповую. Строка будет выглядеть как на картинке. Сохраняем и перезагружаем. Для начала выключаем все квоты, если они когда-нибудь ставились, для чистоты настройки quotaoff /mnt/hard. Следующая команда quotacheck – которая создаст квоту для пользователей и групп, у нее большой функционал, но мы ее используем именно в таком ключе. Квоту мы можем создать только полностью на примонтированный раздел – это связанно с файловой системой ext4. Существуют и другие файловые системы, в которых мы можем ставить квоты на папки и работать более гибко, например xfs. quotacheck –cug /mnt/hard. В данном случае мы квоту ставим полностью на раздел, который смонтирован в /mnt/hard. И как видим команда создала 2 файла aquota.group и aquota.user. Это файлы с настройками квот. Это двоичные файлы и при попытке их посмотреть, например, cat aquota.user мы увидим, нечто не читаемое. Для редактирования данных фалов настройки текстовый редактор не подойдет, и мы будем использовать отдельную команду edquota – u siadmin. Т.е команда -u указывает , что мы редактируем для пользователя и далее указывается непосредственно пользователь. Вот так выглядит редактирование. Мы видим, что здесь есть blocks – число 1К блоки, soft – мягкая квота, это квота, которую пользователь может превысить, но не более чем на неделю, hard – жесткая квота, это квота которую пользователь не сможет превысить вообще. Получается так, если пользователь siadmin поставит soft 10 и hard 30, и запишу файлик в 15КБ, то неделю моя квота терпит, а через неделю система скажет, что квота превышена и будет требовать очистки. Если создать сразу файл 40 КБ, то квота скажет, что нету места на жестком диске. Так же можно поставить квоту на inodes, т.е на уникальные идентификаторы файлов, каждому файлу присваивается уникальный идентификатор, следовательно, пользователь не может превысить их количество по квоте. Когда мы выполняем команду edquota, то для открытия открывается редактор, установленный по умолчанию. В данном случае редактор nano. Как было уже написано мягкая квота устанавливается на неделю и после чего начинает блокировать, если мы не уменьшили размер файлов или не уменьшили их количество, смотря какая квота была выставлена. Мы можем данный параметр изменить, выполнив sudo edquota –t. Думаю, открытый файл на редактирование, тут все интуитивно понятно. Меняем и сохраняем. Мы в файле /etc/fstab указали, что файловая система монтируется с применением квот, потом командой quotacheck создали квоты, а затем указали ограничения edquota. Но до сих пор квоты не включены, квоты не работают! Для того, чтобы квоты заработали используется команда sudo quotaon /mnt/hard. И как только мы эту команду дали, файлы созданные aquota.group и aquota.user будут отредактированы и квоты заработают. Чтобы посмотреть, как работают квоты, создадим файл текстовый. Но т.к монтировался раздел из под root, то необходимо сменить владельца папки /mnt/hard/. Это можно сделать командой chown siadmin:root /mnt/hard. И теперь спокойно можно создать файл touch test.txt. Теперь добавим в файл информацию несколько слов. edquota – u siadmin выполняем и видим, что число блоков изменилось. Добавим еще информации, еще раз поменяется количество блоков. Создадим еще один файл – изменится число inodes. Далее простым копирование увеличиваем количество файлов, пока не сработает квота. Соответственно мы одновременно можем использовать квоты и по размеру, и по inodes. Очень важный момент. Поднимаемся в корневую папку /. Команда sudo repqouta /mnt/hard покажет отчет по квотам. Есть еще интересная команда - man warnquota. Команда отправляет e-mail при превышении квоты. Но для этого необходимо настроить почтовый smtp сервер, который будет отправлять почту.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59