Бизнес любого направления деятельности сопровождается сбором, обработкой и анализом большого объема информации. Он начинается с интернет-продаж, где необходимо повышение конверсии, и платежных сервисов с обработкой транзакций и заканчивается крупными производственными концернами, где прогнозируется простой техники, загруженность маршрутов транспорта и выполняется масса других задач, деятельность связана с хранением и структурированием профильных данных.
Создание базы данных для предприятия – ключевая задача уже на начальном этапе работы. По мере развития бизнеса количество задач, связанных с обработкой информации, возрастает. Если фирма планирует создать надежную, стабильно работающую IT-инфраструктуру, удовлетворяющую все профильные потребности, приходится выбирать один из двух способов решения задачи:
размещение СУБД на собственных технических ресурсах (или взятых в аренду);
использование управляемых облачных БД.
У каждого из этих способов есть положительные и отрицательные стороны. Один и тот же вариант может подойти конкретной компании и быть абсолютно нерациональным для фирмы иного масштаба.
Многие компании изначально рассматривают, как оптимальный вариант, аренду сервера в дата-центре, и это вполне понятный и объяснимым приоритет, поскольку иметь собственные программные разработки – это обеспечить полную независимость и безопасность. Но не для всех приемлемо обходиться в этом плане собственными силами и ресурсами. Чтобы вы могли сделать правильный выбор, рассмотрим плюсы и минусы обоих вариантов.
Какие действия необходимы для создания полноценной СУБД
На начальном этапе при выборе первого варианта необходима тщательная и скрупулезная подготовка инфраструктуры. Подготовительные мероприятия включают:
размещение оборудования в дата-центре или аренда;
загрузку операционной системы;
коммутацию сети;
развертывание СУБД;
настройку безопасности;
обеспечение резервного копирования;
организацию мониторинга.
Выполнив эти действия в разовом порядке, компания может в течение длительного периода пользоваться всеми сервисами. Но при необходимости использования новой БД для очередного проекта потребуется повторить весь алгоритм уже для другой конфигурации. При использовании эффективных инструментов управления задача несколько упрощается.
Для развертывания управляемой БД времени затрачивается намного меньше. В web-интерфейсе настраивается нужный сервис, выбирается тип базы, указывается объем ресурсов, число хостов, настраивается график создания резервных копий, поэтому для правильного выбора варианта необходимо иметь четкий бизнес-план и представлять наглядно картину ближайшего будущего (расширение структуры, новые проекты, предполагаемая срочность создания новой базы данных, достаточность собственных ресурсов и т. д.).
Экономически обосновано размещение базы данных на собственном сервере в том случае, когда оборудование уже имеется в наличии и не требуются крупные затраты на его приобретение. При наличии достаточных ресурсов реально развернуть хранилище данных в средние сроки, но при этом важным условием является качественное и регулярное обслуживание техники, соблюдение правил эксплуатации. Ответственность за эти факторы лежит на штатных специалистах.
Поддержка СУБД осуществляется непрерывно и сразу после внедрения в деятельность фирмы. Суть мероприятий заключается для аппаратной части в профилактике и своевременной замене изношенных комплектующих оборудования, контроле сетевых сбоев и потерь пакетов. Программная поддержка предполагает управление нагрузкой, реакцию на снижение производительности, регулярную установку обновлений СУБД и операционной системы, контроль безопасности.
Работа с обновлениями – сложный и ответственный процесс, поэтому к выполнению задачи целесообразно допускать не администратора общей специализации, загруженного текущими задачами, а отдельного сотрудника соответствующей квалификации. Такой специалист занимается тестированием новых версий, решает возникающие проблемы, устанавливает обновленные версии с минимальными потерями рабочего времени на миграцию данных.
При выборе управляемой облачной БД эти действия производит представитель провайдера, а клиенты управляют своими пользователями. Копии хостов создаются практически в один клик.
Все хранилища данных интегрируются с различными программными сервисами: ETL, Redis, Rabbit, Kafka и подобным программным обеспечением. Если информация размещается в базе самостоятельно, администратор разрабатывает механизм интеграции DWH (data warehouse) с системой BI и с сервисами трансформации, и загрузки информации. В арсенале эффективных средств упрощения создания приложений – технологии Low code и No Code, которые позволяют настраивать и модифицировать системы практически без написания программных кодов. При помощи интуитивно понятного инструмента создаются разнообразные приложения для узких профессиональных задач.
При выборе варианта размещения базы данных учитывается множество сопутствующих факторов, а также затраты на владение, использование и техподдержку.
Факторы целесообразности выбора размещения СУБД своими силами:
компания владеет собственными серверами и ВМ, на которые уже совершены необходимые расходы;
предпринимательская деятельность не связана со скоростным запуском новых проектов;
в компании работают узкоспециализированные администраторы, отвечающие за работу отдельных СУБД.
Облачные управляемые СУБД целесообразно использовать следующим категориям фирм:
компаниям, деятельность которых предусматривает оперативное развертывание новых проектов;
фирмам, работающим в режиме интеграции хранилища информации с другими программными компонентами.
У многих пользователей возникают обоснованные опасения внедрения облачной управляемой СУБД. Проблемными факторами являются безопасность персональной информации, которая хранится в облаке, и недостаточное качество связи облачных баз с другими системами. Информация, представляющая собой коммерческую тайну, личные данные, финансовые отчеты требуют надежной защиты конфиденциальности. Если компания выбрала вариант облачного провайдера, необходимо проверить наличие сертификата на хранение данных, а также уровень доступа к информации.
Как обеспечить стабильность работы СУБД
Отказоустойчивость системы является одним из ключевых показателей. Чтобы обеспечить бесперебойный и непрерывный режим работы, создаются специальные кластеры. При выходе из строя одного хоста работа других продолжается. Расположение хостов в разных центрах обработки данных повысит безопасность проекта в случае возникновения общего сбоя на дата-центре.
Стабильно функционирующую СУБД можно сконструировать и настроить самостоятельно. Специалист, которому компания доверит эту задачу, должен обладать экспертным уровнем знаний и навыком. Фирме потребуется дорогостоящее оборудование в большом объеме. Задачи ответственного администратора:
наладка связи между хостами;
настройка автоматического переноса нагрузки с одного на другой узел;
отладка процесса репликации информации.
Если хосты будут распределены по разным ЦОД, потребуются дополнительные расчеты, вычисление оптимального местонахождения серверов и аренда техники в разных областях доступности.
В управляемых облачных хранилищах создаются реплики в трех зонах доступа для кластерной базы.
Для быстрого восстановления информации при сбое необходима функция резервного копирования. Для корректной работы выбирается либо функция создания полной копии, либо создание инкремента. Дополнительные задачи – составление расписания копирования, поиск места хранения и организация быстрого восстановления. Эффективные средства запуска функции – механизмы PITR и back-up. При использовании Point-in-time Recovery восстановление последней копии осуществляется автоматически по указанным параметрам точного времени. Сервис применяет все транзакции, совершенные после создания копии.
Настройка механизма PITR в самостоятельно установленной СУБД производится на этапе создания продукта. Восстановление данных осуществляет системный администратор. Управляемые базы данных работают с уже настроенным PITR.
Доступ к базам данных
В управляемых облачных базах клиент получает доступ пользователя, может работать с информацией, создавать различные таблицы, но ROOT-доступа для управления виртуальными машинами и смены настроек ему не предоставляется.
В СУБД, созданной под конкретные задачи своими силами, доступ получает клиент или администратор. В его руках все рычаги и инструменты управления.
Как выбрать базу
Проанализировав все плюсы и минусы, можно отметить, что самостоятельное создание системы управления информацией требует много ресурсов и времени, но вместе с тем пользователи получают абсолютную гарантию безопасности данных и полную возможность управления. При грамотном и серьезном подходе компания обретает максимальную независимость хранения и обработки информации от сторонних ресурсов.
Самостоятельное создание СУБД особенно актуально на текущем этапе геополитики и экономического развития страны, когда практически все сферы жизнедеятельности направлены на импортозамещение.
Комментарии (7)
VasilichLift
22.09.2022 17:26+2Не хочется выступать в роли неконструктивного критика, поэтому не буду придираться к каждому пунту (все не без греха), но вот фразы,
Какие действия необходимы для создания полноценной СУБД
В СУБД, созданной под конкретные задачи своими силами, доступ получает клиент или администратор. В его руках все рычаги и инструменты управления.
Самостоятельное создание СУБД особенно актуально на текущем этапе геополитики и экономического развития страны, когда практически все сферы жизнедеятельности направлены на импортозамещение.
если честно, глобально режут глаз, когда применяются в контексте проектирования и разработки платформы данных предприятия (построенной на базе в т.ч. и СУБД) с дальнейшим ее развертыванием и конфигурированием. Все-таки создание собственной СУБД - "это другое".
fire64
22.09.2022 19:44Вот к чему эти вот эти много букв?
MySQL, если что-то для веба, самый удобный и привычный вариант, можно кластеризацию сделать, с бекапкми и прочим проблем тоже не будет.
Не любите закрытость, не беда, есть прекрасный PostgreSQL, с огромным количеством всевозможных модулей и низкими требованиями.
Кто-то выбирает себе MariaDB, кто-то MSSql.
В любом случае статья не о чем и не даёт конкретного понимания, в каких случаях и для каких целей, каку базу лучше выбрать. Одна вода...
RigelGL
22.09.2022 22:24+1MySQL, PostgreSQL, MongoDB, Redis, Cassandra:
- Мы для тебя какая-то шутка?
JordanCpp
23.09.2022 17:38Статья абстрактна. Настройка даже реляционных баз между собой будут отличаться. Установка, эксплуатация и т.д Буквы есть, предложения составлены. Но конкретики нет.
AirLight
24.09.2022 00:57Ну а в реальности сначала выбирают постгрес, потом делают кэширование на редисе, потом внедряют sqrs с чтением из документного хранилища типа монги или эластика. А для аналитических запросов потом берут колоночные базы типа кликхауса.
LuggerFormas
Postgre. Всё. /thread
Сертифицировано, не имеет страны прописки. Бесплатно, есть постгряпро, если кому надо с сертами. Легко разворачивает пару-тройку кластеров на дохлом серваке из подсобки.
Статья высосана из пальца.