По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.
Управление компьютерной сетью процесс довольно трудоемкий и динамичный. Поэтому разработка инструментов по обслуживанию компьютерных сетей не менее важный процесс, чем, собственно, расширение самих сетей. На сегодняшний момент в распоряжении сетевых администраторов представлены несколько наборов инструментов, позволяющих существенно облегчить развертывание, настройку и обновление конфигурации как небольших локальных сетей, так и достаточно масштабных объединений кластеров, насчитывающих десятки тысяч машин. Самые популярные из них это Salt, Ansible, Puppet и Chef, преимущества и недостатки которого мы и разберем в этой статье.
Что же такое Chef? Это система конфигурирования сети, которая "заточена" под кулинарную тематику. Вкратце, система основана на "рецептах" файлах конфигурации, которые администратор объединяет в "кукбуки", или "кулинарные книги" сценарии поведения сети. Эти сценарии помещаются в хранилище, или "книжный шкаф", откуда актуальный набор конфигураций извлекается и устанавливается на клиентские машины в автоматическом режиме. Все операции исполняются с помощью консольного инструмента, который создатели ласково окрестили "шефским ножом".
Что же хорошего можно ожидать от томного итальянского шеф-повара?
Быстрота развертывания: При правильном прописывании параметров конфигурации, добавление в сеть нового устройства, или даже целого кластера достаточно простая и не требующая долгого времени операция. То, что еще лет пять назад требовало ручных настроек и двух-трех дней работы, с помощью Chef выполняется автоматически в течении считанных минут.
Гибкость настроек: Благодаря Bookshelf’ам, Chef позволяет создать несколько сценариев поведения сети, которые позволяют за короткое время переконфигурировать сеть оптимальным образом для выполнения определенного рода задач. Такая возможность актуальна для тех сетей, которые требуют быстрой адаптации под нужды компании. Оперативное перераспределение ресурсной мощности сети один из главных козырей данного решения
Доступность: Решение Chef широко распространено и доступно для широкого круга пользователей. Любой интересующийся человек может скачать ознакомительную версию и попробовать писать свои рецепты, и если дело пойдет можно приобрести лицензию и внедрять решения Chef непосредственно в рабочий процесс.
Мультиплатформенность: Рецепты Chef можно адаптировать под любую операционную систему, и менять конфигурациии ОС клиентских машин независимо от того, какая ОС на них установлена.
А где этот любитель женщин и хорошего вина слабоват?
Человеческий фактор: Применение решений Chef требует от оператора внимательности и хорошего знания конфигурирования сети. Если ошибиться в коде и применить некорректные настройки можно столкнуться с рядом проблем, от потери соединения до полной потери данных с выходом удаленного оборудования из строя.
Безопасность: Важнейшей задачей при работе с Chef является защищенность рабочей станции. Если не обеспечить защиту сети должным образом, то проникновение в систему злоумышленника и перехват управления системой может привести к серьезному ущербу, особенно в сетях крупных корпораций.
Громоздкость: Рецепты Chef зачастую достаточно объемны, и это порождает некоторые сложности в их применении. Каждая строка настроек конфигурации должна быть выверена, и это требует от оператора особого внимания при создании и при проверке рецептов и кукбуков.
Прожорливость: Данное решение на текущий момент несколько уступает конкурентам в производительности и потреблении ресурсов рабочей станции. Однако, работы над оптимизацией Chef ведутся непрерывно, поэтому продукт в ближайших версиях обещает быть более оптимизированным и эффективным.
Итак, если сравнивать Chef с аналогичными продуктами от других разработчиков (а именно Ansible, Salt и Puppet), то данное решение будет несколько уступать в управляемости, за счет сложности описания рецептов (но это дело привычки), а также по производительности. По заявлениям специалистов Chef Enterprise идеальный инструмент именно для сферы разработки ПО. Работы над оптимизацией программы ведутся, и новые версии обещают быть более эффективными и производительными.
Вывод
Несмотря на наличие минусов, Chef остается одним из наиболее популярных и востребованных инструментов администратора сети. Данное решение имеет свои достоинства, а недостатки, как очевидно, легко устранимы. Поэтому данная программа имеет множество сторонников применения в самых разных компаниях.
Хеширование находит широкое применение не только для аутентификации юзера в системе, но также и для проверки целостности файлов. Если у вас имеется контрольная сумма, вы можете сравнить ее с контрольной суммой имеющегося файла, убедившись таким образом в его подлинности. Способных вычислять хэш файлов программ существует более чем достаточно, но не все они стоят внимания. Что, если имеющаяся у вас программа не поддерживает тот алгоритм, с помощью которого был получен хэш файла?
Бесплатная программа GtkHash имеет в этом плане преимущество, поддерживая 23 разных алгоритма хэширования и отличаясь в то же время простотой и удобством использования. Процедура установки утилиты несколько отличается от процедуры инсталляции большинства других приложений. В процессе установки мастером будет открыто окно командной строки для автоматической установки фреймворка MinGW, кроме того, вам нужно будет закрыть окно установщика нажатием кнопки "Close".
Настройка утилиты
По умолчанию в GtkHash включена поддержка только четырех алгоритмов - MD5, SHA1, SHA256 и CRC32. Чтобы добавить другие алгоритмы, зайдите в параметры программы и отметьте галочками нужные вам пункты. Обратите внимание на опцию HMAC, она позволяет использовать секретные ключи (как в MacOS), но включать ее необязательно, равно как и менять формат дайджеста. После сохранения настройки в окне программы у вас появится дополнительные поля.
Допустим, у вас есть некий файл и его контрольная сумма. Путь к файлу укажите в поле "Файл", контрольную сумму вставьте в поле "Сравнить" и нажмите "Хэш". В результате программой будут вычислены разные типы хэшей, причем совпавшие будут отмечены зеленым значком. Кстати, если вам нужно просто получить контрольную сумму объекта, поле сравнения можно вообще не заполнять. Хотелось бы также отметить, что утилитой поддерживается хэширования не только файлов, но и текста. Причем вычисление контрольной суммы производится в режиме реального времени.
А еще инструментом можно вычислять хэши целой группы файлов, перетащив их на окно программы и нажав "Хэш". Правда, просматривать результаты работы программы в этом случае не очень удобно, так как данные выводятся длинной строкой. Поэтому будет лучше экспортировать данные в файл через меню "Save Digest File". Файл дайджеста не имеет расширения, но его содержимое без проблем можно просмотреть Notepad++ или другим текстовым редактором.