Хранение данных: зачем тратить на это деньги?
Когда компания развивается, растёт штат сотрудников и объём данных. Если в классической схеме хранения данных файл лежит там, куда его “положат” до востребования, то в базах данных дополнительно решаются вопросы с структурированием, обработкой, анализом, одновременным доступом и безопасностью информации. Многие процессы автоматизируют, а пользователь даже не знает, как всё устроено.
В целом, на системах баз данных сейчас работает чуть менее чем всё:
Сайты, интернет-магазины, блоги, социальные сети и другие ресурсы. Кстати, эта статья хранится в базе данных, откуда и загружается для прочтения;
Любые сервисы, сайты и приложения, где нужно регистрировать личный кабинет, так как эти данные должны хранить в безопасности и не смешиваться друг с другом.
Представим ситуацию:
Дюжина архитекторов начала одновременно работать над проектом здания объемом 5 ГБ. Им нужно отредактировать проект, и чтобы изменения отображались в реальном времени у всех сразу, не вызывая противоречий. Такая модель здания называется консолидированной.
Тут нужна система баз данных с клиент-серверной СУБД. У разработчиков (и не только) есть метод управления ресурсами, который отлично показывает, какая каша получается без системы баз данных. Называется он бурёнка COW (Copy-on-Write) — при чтении данных используется оригинал (копия не нужна), но при изменениях создаётся новый экземпляр (snapshot), который не влияет на исходные данные:
Одновременное редактирование по принципу COW.
На практике в работе архитекторов это будет выглядеть так:
Архитектор открывает файл проекта с локального диска — теперь его коллеги могут просматривать оригинал, но не изменять его;
Архитектор редактирует проект — коллеги не видят изменений в реальном времени, а только изначальную версию файла;
Один из коллег также начал вносить изменения в проект — API создаёт новый экземпляр файла, не связанный с оригиналом. Все изменения будут сохраняться в новом файле;
Архитектор сохраняет изменения в исходном файле и закрывает его;
Теперь, если коллеги заново откроют проект, они увидят последние изменения;
Тот, кто первый откроет файл — будет работать с оригиналом.
Если в программировании метод COW может оптимизировать ресурсы, то в примере выше эта логика неудобна: работа архитекторов замедляется; можно запутаться в версиях файлов; тяжело синхронизировать изменения, что, вероятно, приведёт к фатальным несоответствиям (коллизиям) при проектировании зданий и т.д.
Но есть более функциональная альтернатива ПК и проекту на локальном диске — клиент-серверная система баз данных. Рассмотрим её на примере BIM-системы.
В центре у нас сервер (Server), связывающий пользователей, BIM-систему и все данные, он создаёт бэкапы, предоставляет и (или) ограничивает доступ к клиентским приложениям и т.д..
Все 10 архитекторов смогут работать одновременно, не мешая друг другу. Файл проекта один — в актуальной версии (на считая бэкапов). Централизованная BIM-модель здания не даст проектировщикам допустить коллизии. В общем — одни плюсы.
Мы уже 20 лет занимаемся поставками и дистрибуцией серверного и сетевого оборудования от брендов Dell, HPE, Juniper, Arista и др. За это время успели узнать о серверах чуточку больше, чем всё.
Приятные плюсы сотрудничества с нами — бесплатное консультирование, 5-летняя гарантия на все модели и очень… нет, ОЧЕНЬ широкий ассортимент в наличии. Подписывайтесь на наш блог, чтобы не теряться, и оставляйте контакты в заявке на сайте.