По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перед тем как начать, почитайте материал про топологию сетей.
Обнаружение соседей позволяет плоскости управления узнать о топологии сети, но как узнать информацию о достижимых пунктах назначения? На рисунке 8 показано, как маршрутизатор D узнает о хостах A, B и C?
Существует два широких класса решений этой проблемы - реактивные и упреждающие, которые обсуждаются в следующих статьях.
Реактивное изучение
На рисунке 8 предположим, что хост A только что был включен, а сеть использует только динамическое обучение на основе передаваемого трафика данных. Как маршрутизатор D может узнать об этом недавно подключенном хосте? Одна из возможностей для A - просто начать отправлять пакеты. Например, если A вручную настроен на отправку всех пакетов по назначению, он не знает, как достичь к D, A должен отправить в хотя бы один пакет, чтобы D обнаружил его существование. Узнав A, D может кэшировать любую релевантную информацию на некоторое время - обычно до тех пор, пока A, кажется, отправляет трафик. Если A не отправляет трафик в течение некоторого времени, D может рассчитать запись для A в своем локальном кэше.
Этот процесс обнаружения достижимости, основанный на фактическом потоке трафика, является реактивным открытием. С точки зрения сложности, реактивное обнаружение торгует оптимальным потоком трафика против информации, известной и потенциально переносимой в плоскости управления.
Потребуется некоторое время, чтобы сработали механизмы реактивного обнаружения, то есть чтобы D узнал о существовании A, как только хост начнет посылать пакеты. Например, если хост F начинает посылать трафик в сторону а в тот момент, когда A включен, трафик может быть перенаправлен через сеть на D, но D не будет иметь информации, необходимой для пересылки трафика на канал, а следовательно, и на A. В течение времени между включением хоста A и обнаружением его существования пакеты будут отброшены-ситуация, которая будет казаться F в худшем случае сбоем сети и некоторым дополнительным джиттером (или, возможно, непредсказуемой реакцией по всей сети) в лучшем случае.
Кэшированные записи со временем должны быть отключены. Обычно для этого требуется сбалансировать ряд факторов, включая размер кэша, объем кэшируемой информации об устройстве и частоту использования записи кэша в течение некоторого прошедшего периода времени.
Время ожидания этой кэшированной информации и любой риск безопасности какого-либо другого устройства, использующего устаревшую информацию, являются основой для атаки. Например, если A перемещает свое соединение с D на E, информация, которую D узнал об A, останется в кэше D в течение некоторого времени. В течение этого времени, если другое устройство подключается к сети к D, оно может выдавать себя за A. Чем дольше действительна кэшированная информация, тем больше вероятность для выполнения этого типа атаки.
Упреждающее изучение
Некоторая информация о доступности может быть изучена заранее, что означает, что маршрутизатору не нужно ждать, пока подключенный хост начнет отправлять трафик, чтобы узнать об этом. Эта возможность имеет тенденцию быть важной в средах, где хосты могут быть очень мобильными; например, в структуре центра обработки данных, где виртуальные машины могут перемещаться между физическими устройствами, сохраняя свой адрес или другую идентифицирующую информацию, или в сетях, которые поддерживают беспроводные устройства, такие как мобильные телефоны. Здесь описаны четыре широко используемых способа упреждающего изучения информации о доступности:
Протокол обнаружения соседей может выполняться между граничными сетевыми узлами (или устройствами) и подключенными хостами. Информация, полученная из такого протокола обнаружения соседей, может затем использоваться для введения информации о доступности в плоскость управления. Хотя протоколы обнаружения соседей широко используются, информация, полученная через эти протоколы, не используется широко для внедрения информации о доступности в плоскость управления.
Информацию о доступности можно получить через конфигурацию устройства. Почти все сетевые устройства (например, маршрутизаторы) будут иметь доступные адреса, настроенные или обнаруженные на всех интерфейсах, обращенных к хосту. Затем сетевые устройства могут объявлять эти подключенные интерфейсы как достижимые места назначения. В этой ситуации доступным местом назначения является канал (или провод), сеть или подсеть, а не отдельные узлы. Это наиболее распространенный способ получения маршрутизаторами информации о доступности сетевого уровня.
Хосты могут зарегистрироваться в службе идентификации. В некоторых системах служба (централизованная или распределенная) отслеживает, где подключены хосты, включая такую информацию, как маршрутизатор первого прыжка, через который должен быть отправлен трафик, чтобы достичь их, сопоставление имени с адресом, услуги, которые каждый хост способен предоставить, услуги, которые каждый хост ищет и/или использует, и другую информацию. Службы идентификации распространены, хотя они не всегда хорошо видны сетевым инженерам. Такие системы очень распространены в высокомобильных средах, таких как беспроводные сети, ориентированные на потребителя.
Плоскость управления может извлекать информацию из системы управления адресами, если она развернута по всей сети. Однако это очень необычное решение. Большая часть взаимодействия между плоскостью управления и системами управления адресами будет осуществляться через локальную конфигурацию устройства; система управления адресами назначает адрес интерфейсу, а плоскость управления выбирает эту конфигурацию интерфейса для объявления в качестве достижимого назначения.
Объявление достижимости и топология
После изучения информации о топологии и доступности плоскость управления должна распространить эту информацию по сети. Хотя метод, используемый для объявления этой информации, в некоторой степени зависит от механизма, используемого для расчета путей без петель (поскольку какая информация требуется, где рассчитывать пути без петель, будет варьироваться в зависимости от того, как эти пути вычисляются), существуют некоторые общие проблемы и решения, которые будут применяться ко всем возможным системам. Основные проблемы заключаются в том, чтобы решить, когда объявлять о доступности и надежной передаче информации по сети.
Решение, когда объявлять достижимость и топологию
Когда плоскость управления должна объявлять информацию о топологии и доступности? Очевидным ответом может быть "когда это будет изучено", но очевидный ответ часто оказывается неправильным. Определение того, когда объявлять информацию, на самом деле включает в себя тщательный баланс между оптимальной производительностью сети и управлением объемом состояния плоскости управления. Рисунок 9 будет использован для иллюстрации.
Предположим, хосты A и F отправляют данные друг другу почти постоянно, но B, G и H вообще не отправляют трафик в течение некоторого длительного периода. В этой ситуации возникают два очевидных вопроса:
Хотя для маршрутизатора C может иметь смысл поддерживать информацию о доступности для B, почему D и E должны поддерживать эту информацию?
Почему маршрутизатор E должен поддерживать информацию о доступности хоста A?
С точки зрения сложности существует прямой компромисс между объемом информации, передаваемой и удерживаемой в плоскости управления, и способностью сети быстро принимать и пересылать трафик. Рассматривая первый вопрос, например, компромисс выглядит как способность C отправлять трафик из B в G при его получении по сравнению с C, поддерживающим меньше информации в своих таблицах пересылки, но требующимся для получения информации, необходимой для пересылки трафика через некоторый механизм при получении пакетов, которые должны быть переадресованы. Существует три общих решения этой проблемы.
Проактивная плоскость управления: плоскость управления может проактивно обнаруживать топологию, вычислять набор путей без петель через сеть и объявлять информацию о достижимости.
Упреждающее обнаружение топологии с реактивной достижимостью: плоскость управления может проактивно обнаруживать топологию и рассчитывать набор путей без петель. Однако плоскость управления может ждать, пока информация о доступности не потребуется для пересылки пакетов, прежде чем обнаруживать и / или объявлять о доступности.
Реактивная плоскость управления: плоскость управления может реактивно обнаруживать топологию, вычислять набор путей без петель через сеть (обычно для каждого пункта назначения) и объявлять информацию о доступности.
Если C изучает, сохраняет и распределяет информацию о доступности проактивно или в этой сети работает проактивная плоскость управления, то новые потоки трафика могут перенаправляться через сеть без каких-либо задержек. Если показанные устройства работают с реактивной плоскостью управления, C будет:
Подождите, пока первый пакет в потоке не направится к G (к примеру)
Откройте путь к G с помощью некоторого механизма
Установите путь локально
Начать пересылку трафика в сторону G
Тот же процесс должен быть выполнен в D для трафика, перенаправляемого к A от G и F (помните, что потоки почти всегда двунаправленные). Пока плоскость управления изучает путь к месту назначения, трафик (почти всегда) отбрасывается, потому что сетевые устройства не имеют никакой информации о пересылке для этого достижимого места назначения (с точки зрения сетевого устройства достижимый пункт назначения не существует). Время, необходимое для обнаружения и создания правильной информации о пересылке, может составлять от нескольких сотен миллисекунд до нескольких секунд. В это время хост и приложения не будут знать, будет ли соединение в конечном итоге установлено, или если место назначения просто недоступно.
Плоскости управления можно в целом разделить на:
Проактивные системы объявляют информацию о доступности по всей сети до того, как она понадобится. Другими словами, проактивные плоскости управления хранят информацию о доступности для каждого пункта назначения, установленного на каждом сетевом устройстве, независимо от того, используется эта информация или нет. Проактивные системы увеличивают количество состояний, которые передаются и хранятся на уровне управления, чтобы сделать сеть более прозрачной для хостов или, скорее, более оптимальной для краткосрочных и чувствительных ко времени потоков.
Реактивные системы ждут, пока информация о пересылке не потребуется для ее получения, или, скорее, они реагируют на события в плоскости данных для создания информации плоскости управления. Реактивные системы уменьшают количество состояний, передаваемых на уровне управления, делая сеть менее отзывчивой к приложениям и менее оптимальной для кратковременных или чувствительных ко времени потоков.
Как и все компромиссы в сетевой инженерии, описанные здесь два варианта, не являются исключительными. Можно реализовать плоскость управления, содержащую некоторые проактивные и некоторые реактивные элементы. Например, можно построить плоскость управления, которая имеет минимальные объемы информации о доступности, описывающей довольно неоптимальные пути через сеть, но которая может обнаруживать более оптимальные пути, если обнаруживается более длительный или чувствительный к качеству обслуживания поток.
Что почитать дальше? Советуем материал про реактивное и упреждающее распределение достижимости в сетях.
YUM (Yellowdog Updater, Modified) это менеджер пакетов, используемый в Red Hat, CentOS и других дистрибутивах Linux, использующих RPM Package Manager. Yum используется для установки, обновления, удаления или других манипуляций с пакетами, установленными на этих Linux-системах.
В этом руководстве мы расскажем вам о команде yum update - что она собой представляет, как ее использовать, и о различных командах, которые могут вам пригодиться, для обновления установленных пакетов в вашей системе.
Как работает команда Yum Update?
Yum update - это команда, используемая для обновления приложений, установленных в системе. Если команда выполняется без указания имён пакетов, она обновит все установленные в системе пакеты.
$ yum update
При выполнении этой команды, yum начнёт с проверки своих репозиториев на наличие обновленных версий программного обеспечения, установленных в вашей системе на данный момент. На приведенном ниже Рисунке А показан тип вывода, который вы обычно видите при первом запуске команды yum update.
Как вы можете увидеть,на выводе yum сначала перечисляет запрашиваемые репозитории, которые являются стандартными репозиториями по умолчанию для CentOS: AppStream, Base и Extras.Ниже, приводится список различных пакетов, для которых были найдены обновления.
В конце этого вывода yum отобразит "Сводку транзакций", которая показывает общее количество пакетов, которые должны быть установлены и обновлены.
В данном примере на Рисунке Б, идёт обновление 166 пакетов и установка 6 новых пакетов.
На случай, если вам интересно почему устанавливаются новые пакеты, когда мы должны были только обновить приложения, некоторые новые пакеты программного обеспечения могли стать частью этого дистрибутива Linux, или некоторые обновленные приложения могут полагаться на дополнительные пакеты, которые еще не установлены.
После просмотра списка программного обеспечения, которое yum планирует обновить, вы можете подтвердить эти изменения, набрав "y" и нажав клавишу Enter.
Затем Yum начнёт выполнять обновления, которые могут занять некоторое время в зависимости от скорости вашего соединения и самой системы.
После его завершения вы получите итоговую сводку, как показано на рисунке В, в которой будут перечислены все пакеты, которые были успешно обновлены, а также все ошибки, которые могли возникнуть.
Обновление без проверки gpg
В Linux для проверки подлинности RPM пакетов используются GPG ключи. Если при запуске обычной команды обновления yum вы столкнётесь с ошибкой типа "Package NameOfPackage.rpm is not signed .. install failed!", вы можете с лёгкостью пропустить проверку подлинности RPM пакетов с помощью опции -nogpgcheck.
$ yum update --nogpgcheck
Данный параметр указывает команде yum игнорировать проверку GPG подписей пакетов. И будет полезен в тех случаях, когда у вас есть неподписанный пакет или просто нет ключа GPG.
Обновление из локального репозитория
Можно настроить локальные репозитории для команды yum при выполнении обновлений. Это зачастую делается, если вам нужно использовать yum для обновления пакетов, которые не включены в репозитории по умолчанию, или если вам нужно обновить автономную систему.
Прежде всего, поместите все ваши обновленные RPM-файлы в новую папку. В этом примере мы будем использовать /root/rpms. Затем перейдите в следующую директорию, где вы можете увидеть все файлы репозитория для yum:
$ cd /etc/yum.repos.d
Чтобы настроить собственный репозиторий, создадим новый файл в этом каталоге.
$ vi MyRepo.repo
Непосредственно в вашем repo-файле задайте параметры в указанном формате, меняя строки по мере необходимости:
[MyRepo]
name=My Local Repo
baseurl=file:///root/rpms
enabled=1
gpgcheck=0
Большая разница между локальным и удаленным repo заключается в строке "baseurl", где протокол file:// указывает на локальный файл, в то время как удаленный на протоколы http:// или ftp://.
Как только файл будет сохранен, примените правильные права доступа как показано ниже:
$ chmod 644 MyRepo.repo
Теперь репозиторий может быть готов к использованию. Перед тем, как пытаться выполнить команду yum update убедитесь, что вы очистили кэш yum использую команду:
$ yum clean all
Просмотр обновлений
Yum может отображать доступные обновления безопасности без их установки, с помощью этой команды:
$ yum updateinfo list security
Если в результатах данные не возвращаются, как на рисунке выше, это означает отсутствие обновлений безопасности для всех установленных в вашей системе программных продуктов.
Обновление конкретного пакета
Если вам нужно обновить определенный пакет без запуска обновления для каждого установленного приложения, просто укажите имя пакета в вашей команде yum update.
$ yum update name-of-package
Можно указать несколько пакетов, разделенных пробелом. Вам нужно, чтобы название пакета было указано идеально, чтобы yum смог найти его в своих репозиториях; если вы не уверены в наименовании пакета, сначала проверьте, какие пакеты в настоящее время доступны для обновлений:
$ yum check-update
Обновить все, кроме одного пакета
Если вам нужно выполнить команду yum update, но вы хотите исключить какой-либо пакет из списка обновляемых, вы можете указать опцию -exclude.
Распространённая ситуация, когда администраторы могут счесть это необходимым, связана с обновлениями ядра, так как это основные обновления, которые могут привести к непредсказуемым ошибкам на рабочем сервере. Однако, они всё же могут выполнить команду для обновления менее критичных приложений.
Чтобы исключить пакет (в данном примере связанные с ядром):
$ yum update --exclude=kernel*
Звездочка действует как подстановочный знак, в случае, если существует несколько взаимосвязанных пакетов или вы не знаете полного имени пакета.
В качестве альтернативы:
$ yum update -x 'kernel*'
Исключение нескольких пакетов
Вы можете исключить несколько пакетов с большим количеством опций -exclude.
$ yum update --exclude=kernel* --exclude=httpd
Используйте этот символ, как в примере выше, или же символ -x, столько раз, сколько потребуется.
Проверить, когда было запущено последнее обновление
Для того чтобы увидеть список транзакций с датой и временем их выполнения, воспользуйтесь командой yum history.
$ yum history
На приведенном выше скриншоте, вы можете видеть, что последний раз обновление программного обеспечения yum было 4 января.
Откатить (отменить) обновления
Отличительной особенностью "yum" является то, что она позволяет отменить последнее обновление, тем самым восстанавливая обновленные пакеты до их предыдущих версий.
Каждому действию yum (установка, обновление, удаление и т.д.) присваивается идентификатор транзакции, и этот идентификатор следует указывать при отмене обновления yum.Чтобы посмотреть список идентификаторов операций для недавних действий Yum, воспользуйтесь этой командой:
$ yum history
На скриншоте выше вы можете видеть, что последней операцией, выполненной с помощью yum, была установка пакета httpd. Отмена установки или обновления работает таким же образом, поэтому в этом примере мы отменим последнюю установку httpd. Как показано на скриншоте, эта операция имеет ID 7.
Чтобы отменить это изменение и откатить программу на предыдущую версию, выполните эту команду:
$ yum history undo 7
Как обычно, yum подведёт итоги внесённых изменений и спросит, хотите ли вы продолжить с помощью подсказки Y/N.Если ввести Y, то указанная транзакция будет отменена.
Чистка неудачного обновления Yum
Если не удалось успешно обновить один или несколько пакетов при выполнении команды "yum update", в систему могут быть установлены дубликаты пакетов (2 версии одной и той же программы). Иногда, следуя вышеописанным инструкциям по откату, можно устранить проблему.
Если это не сработает, вы можете удалить дубликаты пакетов вашей системы с помощью данной команды:
$ package-cleanup --dupes
Yum хранит в кэше информацию для пакетов, метаданных и заголовков. Если вы столкнулись с ошибкой,очистка кэш-памяти yum является хорошим первым шагом в устранении неполадок. Для этого используйте следующую команду:
$ yum clean all
Игнорирование ошибок
При обновлении или установке пакета для его корректной работы может потребоваться дополнительное программное обеспечение. Yum знает об этих зависимостях и попытается разрешить их во время обновления, устанавливая или обновляя необходимые дополнительные пакеты.
Если у вас возникнут проблемы с установкой необходимых компонентов, это приведёт к ошибке и не позволит продолжить работу. Это может стать проблемой, если у вас есть другие пакеты, которые необходимо обновить.
Чтобы дать инструкции yum продолжить обновление других пакетов и пропустить пакеты с поврежденными зависимостями, вам следует указать параметр -skip-broken в команде yum update.
$ yum update --skip-broken
Вывести список пакетов, которые нужно обновить.
Выполнение команды Yum update в обычном режиме без дополнительных опций выведет список всех доступных обновлений.
$ yum update
Если вы хотите посмотреть дополнительную информацию о доступных обновлениях пакета, введите эту команду:
$ yum updateinfo
Чтобы посмотреть информацию касательно обновлений безопасности, которые доступны для системы, введите эту команду:
$ yum updateinfo security
Разница между командами yum check update и yum list update
Хотя эти две команды звучат одинаково, но есть разница между проверкой обновлений и списком обновлений в yum.
$ yum list updates
Команда list updates, показанная выше, перечислит все пакеты в репозиториях, для которых доступны обновления. Имейте в виду, что некоторые пакеты в репозиториях могут быть вообще не установлены в вашей системе.
$ yum check-update
Указанная выше команда check-update позволяет проверять наличие обновлений без вмешательства пользователя. Это команда подойдёт в тех случаях, если вы пишите скрипт для проверки обновлений.
Если есть пакеты с доступными обновлениями, команда check-update вернёт значение 100, а если нет доступных обновлений, то значение 0. При обнаружении ошибки возвращается значение 1. Используйте эти значение чтобы надлежащим способом написать свой скрипт.
Уведомление о наличии доступных обновлений
Есть несколько пакетов, которые могут помочь управлять обновлениями yum в вашей системе.Некоторые из них могут даже уведомлять администраторов, если есть обновления, которые можно установить.Один из таких сервисов называется yum-cron.
Для начала установите yum-cron используя yum:
$ yum install yum-cron
Установите службу yum-cron для запуска при загрузке:
$ systemctl enable yum-cron.service
$ systemctl start yum-cron.service
Настройте параметры yum-cron внутри конфигурационного файла с помощью vi или предпочитаемого вами текстового редактора:
$ vi /etc/yum/yum-cron.conf
В этом файле вы можете указать, должны ли обновления применяться автоматически или нет. Если вы хотите только получать уведомления, введите данные электронной почты в файле конфигурации. В любое время, когда появятся обновления для вашей системы, yum-cron отправит вам электронное письмо.
apply_updates = no #don’t apply updates automatically
email_from = root@localhost
email_to = admin@example.com
email_host = localhost
Какой порт использует yum update
При проверке обновлений yum использует порт 80. Если вы загляните внутрь файлов репозитория в вашей системе, то вы увидите, что все ссылки внутри начинаются с http. Таким образом, для нормального функционирования yum на брандмауэре нужно прописать правило и открыть порт 80.
Yum update против upgrade
До сих пор в этом руководстве мы говорили только о команде yum update, но есть и другая очень похожая команда: yum upgrade.
$ yum upgrade
Существует небольшая разница между этими двумя командами. Yum update обновит пакеты в системе, но пропустит удаление устаревших пакетов. Yum upgrade тоже обновит все пакеты в вашей системе, но также удалит устаревшие пакеты.
Это по своей сути более безопасный вариант команды yum update, поскольку вам не нужно беспокоиться о случайном удалении необходимого пакета при обновлении программного обеспечения.
Будьте внимательны при вводе команды yum upgrade, так как она может не сохранить некоторые пакеты, которые вы всё ещё используете. Я надеюсь, что вы найдете это руководство полезным при работе с утилитой yum.
Базы данных — это ключевой компонент современных информационных систем, благодаря которому мы можем информацию храненить (заметьте, что не хоронить), управлять и изменять. Проще говоря, БД используются для удобной работы с некоторыми данными, которые нужны нам для проекта. Например, при оформлении заказа через приложение доставка использует базу данных для хранения информации о адресе, предпочтениях и истории заказов. В более сложных системах, таких как социальные сети, интернет-магазины или банковские платформы, объёмы данных значительно увеличиваются, что требует выбора подходящей технологии для их обработки.
Вот тут и возникает главный вопрос: SQL или NoSQL? В чем-то это можно сравнить с выбором чая или кофе — оба варианта хороши, но каждый подходит для своих целей. SQL — это про строгий порядок и чёткую структуру, как таблицы в Excel. NoSQL — это про гибкость и скорость, когда данные могут выглядеть, как угодно, например, JSON-документы или даже графы. Понимание разницы между ними важно, чтобы не пытаться забивать гвозди микроскопом. Собственно, чтобы разобраться тонкостях SQL и NoSQL, мы здесь сегодня и собрались.
Что такое SQL?
SQL (Structured Query Language) — это язык для работы с базами данных, который позволяет создавать, изменять и извлекать данные. Если представить базу данных как библиотеку, то SQL — это библиотекарь, который знает, где лежит каждая книга, как её найти и что с ней можно сделать, вот только с таким библиотекарем надо общаться на его языке. SQL используется в реляционных базах данных, где информация хранится в виде таблиц с чёткой структурой: строки — это записи, а столбцы — свойства этих записей.
Реляционные базы данных основаны на принципе отношений (relation) и обладают ключевыми особенностями: чёткая структура данных, возможность связывать таблицы через ключи (например, первичный и внешний ключи), а также поддержка транзакций. С их помощью можно уверенно управлять большими объёмами данных, сохраняя порядок. Среди популярных SQL-баз данных можно выделить MySQL (любимец разработчиков за простоту), PostgreSQL (гибкий и мощный инструмент), Microsoft SQL Server (корпоративный стандарт для Windows-систем) и Oracle Database (монстр для серьёзных задач).
Главные преимущества SQL — это строгая структура, которая помогает избежать хаоса в данных, возможность писать сложные запросы для анализа и обработки информации, а также поддержка ACID-принципов (атомарность, согласованность, изолированность и долговечность). Это значит, что данные будут надёжно защищены от ошибок и останутся целыми даже при сбоях.
Что такое NoSQL?
NoSQL (или *Not Only SQL*) — это подход к базам данных, который не ограничивается реляционной моделью. Если SQL — это строгий учитель математики, который всё записывает в таблички, то NoSQL — это творческий художник, который говорит: «А зачем нам таблицы? Давайте просто хранить данные так, как удобно!» NoSQL-базы созданы для работы с огромными объёмами данных, где гибкость и скорость важнее строгой структуры.
Существует несколько основных типов NoSQL-баз данных, каждая из которых заточена под свои задачи. Документные базы (например, MongoDB и CouchDB) хранят данные в виде документов (обычно JSON или BSON). Колонночные базы (Cassandra, HBase) организуют данные в столбцы, а не строки. Они идеально подходят для аналитики больших данных, где важно быстро обрабатывать миллионы записей. Графовые базы (Neo4j) хранят данные в виде узлов и связей между ними — это выбор номер один для задач вроде построения социальных сетей или рекомендаций (например, кто кого знает или что купить дальше). А базы типа ключ-значение (Redis, DynamoDB) — это как словарь: запрашиваешь значение по ключу. Они невероятно быстры и отлично подходят для кэширования или хранения сессий.
Основные преимущества NoSQL: во-первых, гибкость. Не нужно заранее продумывать структуру таблиц — добавляй новые поля на лету! Во-вторых, масштабируемость. NoSQL-базы легко растут горизонтально (добавляй новые серверы и не переживайте). И наконец, высокая производительность. Для многих задач NoSQL быстрее реляционных баз, потому что они избавлены от лишних проверок и строгих правил. Так что, если данные больше похожи на хаотичный поток, чем на аккуратный Excel-файл, NoSQL может стать отличным помощником.
Так, мы поняли общие различия между SQL и NoSQL, но в большей степени нас всех ведь интересует, когда и что использовать, так что остановимся на этом поподробнее.
Когда использовать SQL, а когда NoSQL?
Каждая БД по сути дела отвечает разным требованиям потребностям при разработке. Когда нам нужен молоток – мы используем молоток, однако, когда отвёртка – мы используем её. И использовать что-то взамен, наверное, можно, при большом желании, но всё же не нужно.
Итак, в случае, если проект — это что-то, где данные должны быть идеально структурированы, как бухгалтерский отчёт или банковская система, то SQL — твой лучший друг. Банковские транзакции, например, требуют соблюдения строгих правил: деньги не могут «исчезнуть» из одной таблицы и «не появиться» в другой (хотя иногда очень хотелось бы). Здесь на помощь приходит транзакционность (ACID-свойства). Если не вдаваться в подробности, то это набор принципов, которые обеспечивают надёжность операций в реляционных базах данных. В случаях, когда нам важно иметь структурированные данные, важна целостность данных и возможность выполнять сложные запросы, вроде «покажи мне все операции за последние три месяца по клиентам с балансом выше 100000 рублей». Если же речь идёт о разработке CRM-системы для небольшой компании или создания сайта-визитки с базой пользователей, SQL тоже подойдёт идеально. Реляционные базы данных, такие как MySQL или PostgreSQL, хорошо работают с небольшими и средними объёмами данных, обеспечивая простоту настройки и поддержки.
Другой случай, что нам надо построить высоконагруженное приложение, которое ежедневно обрабатывает миллионы запросов. Например, социальная сеть, где пользователи постят фотографии, ставят лайки и пишут комментарии. Или интернет-магазин с миллионами товаров и отзывов. Здесь NoSQL становится незаменимым. Почему? Потому что он позволяет быстро масштабироваться: если нагрузка растёт, нужно просто добавить новые серверы в кластер. К тому же NoSQL отлично справляется с гибкими структурами данных. Например, в документной базе MongoDB можно хранить информацию о товарах так: у одного товара есть описание и отзывы, а у другого — только цена и дата выпуска. Никаких ошибок из-за несоответствия структуры! А если завтра вам нужно будет добавить поле «рейтинг», это можно сделать без каких-либо проблем и головной боли.
Ещё один пример использования NoSQL — системы реального времени. Например, это подходит для какой-нибудь онлайн-игры, где миллионы игроков взаимодействуют друг с другом. Здесь скорость важнее всего: Redis или DynamoDB помогут мгновенно доставлять данные игрокам. Или возьмём IoT (интернет вещей): миллионы датчиков отправляют данные каждую секунду — хранить их в реляционной базе было бы слишком медленно.
И так, мы поняли, при четкости и структурированности используем SQL, в случаях, где нам нужно быстродействие и разнообразие используем NoSQL. А что, если их… Сложить? А почему нет? Можно использовать сразу все. Разберемся?
Можно ли использовать SQL и NoSQL вместе?
В мире возможно почти все, а потому рассмотрим гибридный подход — это способ объединить сильные стороны SQL и NoSQL, чтобы получить лучшее из двух миров. Например, реляционные базы данных (SQL) отлично подходят для работы с критически важными данными, где важна строгая структура, транзакционность и согласованность. А NoSQL прекрасно справляется с задачами, где важна масштабируемость, гибкость или высокая скорость работы, например, при хранении логов, кэшей или данных IoT.
Как пример, возьмем интернет-магазин. Для управления заказами, клиентами и платежами используем SQL-базу, например PostgreSQL, где всё строго: таблицы, связи, транзакции. Но вот для рекомендаций товаров или хранения истории просмотров пользователей лучше подойдёт NoSQL-решение, такое как MongoDB или Redis. Почему? Потому что данные здесь не требуют жёсткой структуры и меняются очень быстро.
Или же как еще один пример возьмем приложение для доставки еды (это самые любимые приложения, пожалуй). Заказы клиентов могут храниться в MySQL — это важно для финансовой отчётности и аналитики. Но для хранения геолокации курьеров в реальном времени используем Redis: данные обновляются каждую секунду, а не нужно сохранять их навсегда. А ещё можно добавить Elasticsearch для быстрого поиска ресторанов по ключевым словам — вот вам уже три разные базы данных в одном проекте!
Гибридный подход помогает использовать преимущества каждой технологии там, где они действительно нужны. Главное — не перегружать архитектуру и помнить: если есть молоток, это ещё не значит, что все задачи — гвозди, еще есть и гайки, и шурупы и болты. Собственно, в больших проектах в основном и используются сразу и SQL, и NoSQL, просто для разных задач. В маленьких же проектах уже необходимо смотреть на потребности.