Важный момент про базы данных, в продолжении к предыдущим статьям. Большая часть современных приложений, а так же интернет-сайтов, работает с СУБД по принципу клиент-серверной модели. Недавно я рассказывал о такой модели с точки зрения подключения GUI (пользовательский интерфейс для управления базой данных). Сегодня - чуть расширю эту терминологию, дополнив её информацией о взаимодействии нескольких серверов внутри крупных систем.
Как мы уже знаем, клиент-серверная модель - это такая схема, при которой какие-то части приложения могут работать независимо друг от друга, соединяясь например через TCP-IP протокол. То есть, на каком-то одном физическом компьютере живёт и здравствует само приложение (например сайт или серверная логика мобильного приложения, и т.п.) - это называется "клиент". А на другом физическом компьютере, работает программа СУБД, и хранится физическая база данных - это называется "сервер".
Доступ к такому удалённому СУБД осуществляется (капитан очевидность нужна твоя помощь!) именно удалённым образом. То есть, через сетевой протокол TCP-IP - проще говоря, через интернет соединение, и в конечном итоге (на каких-то участках сети) через самые простые кабели типа "витая пара" и разъемы типа Ethernet (Штекер типа RJ45). // Кто помнит наизусть распиновку проводов внутри штекера - добро пожаловать в комменты 😉
Если ты справился с установкой СУБД MySQL / PostgreSQL, а потом был достаточно удачлив чтобы успешно развернуть GUI, то наверное уже видел - что при первом подключении база просит IP адрес сервера, логин и пароль. В этом случае твоё приложение GUI будет "клиентом", в база данных - "сервером", а общение будет происходить через протокол TCP/IP. Хоть обе части (клиент) и (сервер) одновременно располагаются в таком случае на твоём компьютере, они являются отдельными программами, работающими через сетевой протокол.
Почему СУБД так сложно устроена? 🤬
Што, опять? Да, опять. В прошлых статьях я писал первую часть рассуждений о том, почему СУБД устроена столь сложно. Вкратце - всё дело в "Транзакциях". То есть, в отличие от текстового файла, с базой данных могут одновременно работать огромное количество людей. И такой процесс нужно каким-то образом поддерживать и администрировать. Вот тут статья на эту тему.
Но если в прошлой статье я подробно рассматривал клиент-серверную модель с точки зрения "приложений" (и их сепарации друг от друга) - то в этот раз я акцентирую внимание на физическом оборудовании. Сепарация СУБД и базы данных от других серверов является важной особенностью качественной архитектуры. На это есть ряд дополнительных причин.
💽 Во-первых, СУБД реально пилит жёсткие диски. Даже при всех современных, оптимальных и умных алгоритмах, HDD регулярно отгорают, и нуждаются в замене. Для этого придумали "горячую замену" и другие остроумные штуки. Буквально, по дата-центру ходит бородатый мужик, и выдёргивает сгоревшие жесткие диски, заменяя их новенькими и блестящими.
📈 Во-вторых, правильно развёрнутые и настроенные СУБД должны потреблять буквально все доступные ресурсы сервера. И поэтому банально места под какие-то другие программы на таком сервере не остаётся. Лучшая конфигурация для СУБД - это потребление 100% доступной оперативной памяти и ресурсов процессора.
🔐 Ну и конечно-же, в-третьих, это вопросы безопасности. Данные в нашем мире ценны как нефть, и много юных неспокойных умов охотятся за ними денно и ночно. Не далече как сегодня утром, один из моих проектов подвергся жесткой DDoS-атаке, а полгода назад хакеры дня 4 подряд пытались залезть в наши базы (спойлер - у них ничего не получилось, но наследили они ого-го). Так вот, развернуть СУБД на отдельном защищённом сервере, заглушить там всевозможные порты и протоколы кроме нескольких - хорошая практика. Прямой же "взлом" СУБД в таком случае остаётся возможен только банальным методом перебора паролей, но как правило в серьезных конфигурациях и при должной заботе о паролях, это не является проблемой.
В общем и целом, сложность типовой "клиент-серверной схемы" более чем оправдана. Это позволяет защитить систему от сбоев, сделать её более надёжной и предсказуемой. При этом, в некоторых случаях узлы дублируются два и более раз. И при выходе из строя одного узла, он сразу же автоматически подменяется другим узлом, "на лету".
Сервер или группа серверов? ☁️
Когда же речь заходит про крупные проекты - условно 500 тысяч человек в день или миллион человек в день, то под СУБД выделяется группа серверов. В этом случае, СУБД могут настраиваться таким образом, чтобы автоматически распределять данные между отдельными физическими серверами - равномерным образом или потаблично.
Такая система уже является кластером базы данных, ну или "облаком" в более простом понимании. При этом, порядок доступа к такой базе не меняется - для клиента это такое же точно подключение через IP-адрес, логин и пароль. СУБД самостоятельно разруливает "сборку" данных с разных серверов, и работает для внешнего мира как один "единый сервер".
Если мы посмотрим на уровень выше - то обнаружим, что для особо крупных проектов сервера дублируются даже не на уровне локальной инфраструктуры, а на уровне географии. Так например, для обслуживания одного интернет-сайта или приложения, может существовать несколько серверов в Евразии, несколько в Азии, и несколько скажем в Африке. При этом, с точки зрения внешнего наблюдателя это будет целостная система. А вот с точки зрения схемы организации - это будет классическая клиент-серверная модель, в широком смысле.
🔥 Понравилось? Подпишись! Дальше - больше! 🔥
🚀 P.S. Ты можешь круто поддержать меня и проект "Войти в IT" на boosty! Я публикую там более эксклюзивный и профессиональный, иногда немного личный контент. Хочешь посмотреть как я выгляжу в реальной жизни? Тогда жми: Ссылка 🚀
P.S.2 У меня ещё есть Telegram-канал. Там посты чуть попроще, и чуть повеселей. Ссылка
