Собственно, блокировки будут и при использовании централизованной базы данных. Пресловутый онлайн – мечта всех управленцев – означает всего лишь уменьшение задержки при передаче информации. Кстати, если определить, при передаче какой информации нужно минимизировать эти задержки, может выясниться, что это далеко не весь массив данных. Если еще начать выяснять, какова же все-таки максимально допустимая задержка, то может оказаться, что необходимо, например, иметь актуальную информацию об остатках товара один раз в день, а все остальное достаточно обновлять раз в неделю. Так мы приходим уже к периодической репликации.
Конечно же, бывают случаи, когда задержка даже в секунды может дорого стоить (классический пример – биржевая торговля), но чаще всего управленец, требующий непременно данных в режиме реального времени, не будет ими пользоваться чаще одного раза в сутки. И возможно, эти данные ему можно предоставить и более дешевыми средствами, нежели прокладкой каналов до каждого ларька и установкой многомиллионной системы на рабочем месте каждой уборщицы. Понимание этого позволяет значительно сэкономить средства – именно так получаются вполне успешные внедрения маломощных систем в огромных компаниях.
Именно системам с синхронной репликацией посвящено наибольшее количество теоретических работ по распределенным системам. Но такие системы страшно дороги и относительно редки, и, если вы работаете не в корпорации уровня Газпрома, а всего лишь в небольшом холдинге, включающем пару-тройку заводов и сотню магазинов, то вряд ли вам это нужно.
Основные проблемы с распределенной системой начинаются, когда производительности каналов не хватает, чтобы данные обрабатывались удаленно, а результаты посылались клиентам, или каналы связи не слишком надежны, а с системой нужно продолжать работать на всех площадках, даже когда каналы не работают из-за повышенной солнечной активности, пьяного экскаваторщика, перерубившего кабель, или урагана.
Собственно, не так давно «каналом связи» между двумя площадками в Москве в компании, где я работал, служил курьер, который перевозил винчестер с изменениями базы данных с площадки на площадку два раза в день.
В таких случаях пользователи на каждой площадке работают со своей местной (локальной) базой данных, а сами базы выравниваются или периодически, или когда возникает такая возможность.
Урюпинский пользователь в такой системе может хладнокровно править наименование организации в соответствии с ИНН в тот самый момент, когда арзамасец начнет изменять в своей копии той же записи ИНН организации в соответствии с названием. Эта шутка носит высоконаучное название коллизии. Понятно, что попытка свести воедино арзамасско-урюпинские результаты (то есть разрешить коллизию) вызовет определенные проблемы.
Такие системы называются системами с асинхронными репликациями, а сам комплект изменений, за один раз передаваемый от одной локальной базы к другой, – репликой. Те, кому не нравится импортное слово «репликация», используют слово «тиражирование», которое почему-то считают более русским. На мой взгляд, больше подходит «выравнивание», но не хочется путать читателя еще больше.
Механизмы корректной работы систем с асинхронными репликациями наиболее сложные, и, как я уже писал, если они не заложены в проект и не продуманы на начальной его стадии, все заканчивается достаточно плохо.