Как данные размещены по компьютерам в распределенной базе данных

Обновлено: 07.07.2024

Информационная система, состоящая из нескольких информационных баз 1С: Предприятия (узлов), обладающих идентичными конфигурациями и обменивающихся данными в офлайн-режиме. Характеризуется жесткой иерархической структурой узлов и наличием одного главного узла. Для более гибких схем обмена, в том числе между разнородными системами, используется универсальный механизм обмена данными.

Механизм

Механизм распределенных информационных баз предназначен для создания территориально распределенных систем на основе идентичных конфигураций 1С: Предприятия 8. Этот механизм позволяет переносить как изменения данных, так и изменения конфигурации информационной базы.

Возможности:

интерактивное создание распределенной системы и выполнение обмена данными без дополнительного программирования;

обеспечение идентичности конфигураций информационных баз, входящих в состав распределенной системы;

подключение новых и отключение существующих узлов;

создание начального образа информационной базы для нового узла;

реализация различных способов разрешения коллизий при одновременном изменении данных в разных узлах распределенной системы;

в рамках одной распределенной информационной базы может быть создано несколько схем обмена;

распределенная информационная база может содержать схемы обмена с другими информационными системами, в том числе с информационными базами 1С:Предприятия, не являющимися распределенными информационными базами;

задание условий на передачу и прием изменений на уровне отдельных элементов данных;

реализация восстановления обмена данными в таких случаях, как восстановление информационных баз из резервных копии и т.д.;

Особенности:

распределенная система должна иметь древовидную структуру, в которой существует корневой узел и определено отношение "главный – подчиненный" для каждой пары связанных узлов;

обмен данными выполняется в формате ХML документов;

внесение изменений в конфигурацию возможно только в одном (корневом) узле распределенной системы;

изменения конфигурации передаются от главного узла к подчиненным;

внесение изменений в данные возможно в любом узле системы;

изменения данных передаются между любыми связанными узлами.

Недостатки:

на каждом компьютере необходима лицензия платформы и основная лицензия СЛК;

каждое рабочее место должно соответствовать минимальным системным требованиям, для работы в 1С.

При росте предприятия, рано или поздно встает вопрос, о консолидации данных. И тут главное правильно сделать выбор в пользу той или иной схемы. Надеюсь, что данная статья поможет вам в этом не простом выборе.

Давайте определим общую схему которую будем иметь до организации взаимодействия.

Цетр — это основная база данных в которой происходит анализ. Она должна содержать все необходимые данные для анализа.

Перифирия1, Перифирия2, Перифирия3 — Базы в которых происходит ввод данных.

Конечно, это все условно. Т. к. и в Центральной базе может происходить ввод информации, и в периферийных базах требуется информация по компании в целом (например, информация о заблокированных клиентах).

Красный — информация которая должна присутствовать во всех базах и не требующаяся для анализа состояния.

Зеленый — информация которая должна присутствовать во всех базах и требующаяся для анализа.

Желтый — информация которая требуется для анализа, но специфична для каждой базы.

Синий — информация специфичная для каждой базы не требующаяся для анализа.

Теперь можно поговорить о топологии. Топологии:

Топология кольцо.

Кроме простоты организации обмена, данная схема, преимуществ не содержит. Хотя и простота организации обмена, то же является спорным преимуществом. Недостатков же напротив, хоть отбавляй.

Топология звезда.

Наверное самая распространенная топология. Из минусов ,только объем трафика проходящего через центральную базу. Плюс ко всему центральная база становится критичным ресурсом.

Смешанная топология.

Из плюсов: отказоустойчивость и снижение нагрузки на центральную базу, но сложность реализации перекрывает все плюсы от данного решения.

После определения нашей будущей топологии, можно переходить к следующему вопросу о транспорте, но сначала давайте классифицируем наш будущий обмен.

Классификация обмена.

Во первый можно разделить обмен, по степени участия в нём человека.

Автообмен. Под автообменом будем понимать такой обмен, при котором не требуется вмешательство человека, при отсутствии внештатных ситуаций. Хотя присутствие человека, для слежения за обменом, допускается.

Полуавтоматический обмен. Под ним будем подразумевать обмен при котором требуется вмешательство человека. Либо для его инициализации, либо для внесения исправлений которые накапливаются в процессе автообмена (то есть, когда вроде бы все автоматически, но без периодического вмешательства человека обмен встаёт, при отсутствии внештатных ситуаций).

Ручной обмен. Когда для обмена информацией постоянно требуется человек. Даже на этапе перемещения файлов обмена из точки А, в точку Б.

Примечание. В любом случае, даже если вы организуете автообмен с высокой степенью доступности ресурсов (каналы передачи, базы данных). Все равно предусмотрите третий вариант, а именно:

Кто в случаи внештатной ситуации должен производить ручной обмен.

Как часто он должен происходить.

Должен ли производящий ручной обмен заниматься другими делами и если должен, то какой приоритет у обмена.

Что делать если недоступен ответственный за ручной обмен.

Рекомендую начать реализацию обмена именно с этого, так как в противном случае велика вероятность того, что это не будет реализовано.

Виды транспорта.

Под транспортом будем понимать протоколы передачи данных, с помощью которых можно передать информацию из точки А в точку Б.

Физический носитель (Флеш-карта, CD-R(CD-RW), HDD и т.д.).

Телефонная линия (модем).

Давайте попробуем определить плюсы и минусы.

Плюсы первого варианта:

Практически всегда отказывает последним.

Минусы первого варианта:

Скорость передачи информации.

Не позволяет организовать обмен кроме как в ручном режиме.

Плюсы второго варианта:

Высокая степень отказоустойчивости.

Минусы второго варианта:

Скорость передачи информации.

Плохое качество канала передачи.

Плюсы третьего варианта:

Скорость передачи информации.

Минусы третьего варианта:

Цена реализации пропорциональна квадрату расстояния.

Плюсы четвертого варианта:

Цена прямо пропорциональна расстоянию от провайдера.

Минусы четвертого варианта:

Информация проходит через неконтролируемую территорию.

Выводы: Первые два варианта транспортировки подходят только для ручного режима обмена информацией или как дублирующие варианты третьего и четвертого варианта. Третий вариант подходит, до тех пор пока цена его реализации не превысит стоимости четвертого варианта умноженного на коэффициент цены скорости передачи.

Варианты передачи информации через интернет.

Первые три варианта не рассматриваю, из-за их тривиальности. Так же не будут рассмотрены бесплатные интернет-сервисы. А сводить задачу мы будем к синхронизации двух каталогов. Какие же тут есть варианты?

SOAP/REST (веб сервисы)

VPN (Virtual Private Network).

Начнем с конца. Вариант организации VPN, я считаю, самым простым и дешевым, так-как для его организации требуется то, что должно быть у каждой организации подключенной к сети интернет. А именно это качественный брандмауэр. Цены на брандмауэр могу привести только свои, так-как другие не сравнивал. Это либо порядка 3 000 рублей за D-Link, либо 2 500 рублей за настройку брандмауэра и подключение точки к интернет плюс стоимость компьютера (вполне подойдет Pentium III 500 256 ОЗУ

1 000 рублей). Как минус — это необходимость настройки каждой точки присутствуя физически.

Вариант с SOAP, для настройки обмена, является, наверное, самым дорогим из вариантов. Хотя я его и реализовывал, но затруднюсь ответить на вопрос о том за сколько бы я его реализовал. Скорее мой ответ был бы 1 500 рублей (за установку системы) плюс 1 500 рублей (за установку и настройку web сервера) плюс 750 рублей в час за разработку программы обмена плюс стоимость компьютера под эти цели (примерно от 15 000 до 300 000 рублей в зависимости от нагрузки). Из преимуществ можно отметить минимальные задержки перед началом передачи данных.

Из варианта номер два я бы выделил только SFTP. Так как При равной с FTP вариантом стоимостью, имеет перед FTP, два неоспоримых преимущества. Первое это данные не передаются в открытом виде (шифруются), а второе реализовать его очень просто. Вариант с WebDAV имеет право на жизнь, но встречается редко и скорее является экзотикой. Цены для первых двух вариантов это 3 000 рублей за настройку плюс компьютер (примерно 7 000 рублей, хотя при малой нагрузке можно и удешевить).

Электронная почта — это один из сложнейших вопросов администрирования. Ее настройка требует высокой квалификации специалиста, так как тут нет шаблонов. Так что цена этого варианта может превысить стоимость веб сервисов. Но в отличии от веб-сервисов эта цена более-менее предсказуема (6 000-12 000 рублей за настройку почтового сервера плюс компьютер от 1 000 до 180 000 рублей в зависимости от нагрузки). Имеет смысл если электронная почта или уже есть, или планируется.

Я специально не стал рассматривать другие варианты, так как рассмотренных вполне достаточно, для организации транспортировки.

Заключение.

Как-то неожиданно, скажете вы? Да, но все вопросы для расчета вариантов реализаций мы рассмотрели. Осталось выбрать приемлемый по цене и функционалу, и нанять специалистов для реализации (как вариант реализовать самому сэкономив/заработав деньги).

Размещение данных в распределенных БД характеризуется следующими понятиями:

• фрагментация. Любая запись (отношение в случае реляционных моделей данных) может быть разделено на некоторое количество частей, называемых фрагментами, которые затем могут распределяться по различным узлам. Как отмечалось ранее, существуют два основных типа фрагментации: горизонтальная и вертикальная. В первом случае фрагменты представляют собой подмножества строк, а во втором — подмножества столбцов (атрибутов);
• размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа;
• репликация. Распределенная СУБД может поддерживать актуальную копию некоторого фрагмента на нескольких различных узлах.

Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных (в частности, на основе анализа транзакций).

Существуют четыре стратегии размещения данных в системе.

1. Централизованное размещение. Данная стратегия предусматривает создание на одном из узлов единственной базы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети.
2. Фрагментированное размещение. В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из узлов системы.
3. Размещение с полной репликацией. Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из узлов системы. Стоимость устройств хранения данных и уровень затрат на передачу информации об обновлениях в этом случае также будут самыми высокими. Для преодоления части этих проблем в некоторых случаях используется технология снимков. Снимок представляет собой копию базы данных в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени, например 1 раз в час или в сутки.
4. Размещение с избирательной репликацией. Данная стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локализации ссылок, тогда как другие, используемые на многих узлах, но не подверженные частым обновлениям, подвергаются репликации. Все остальные данные хранятся централизованно.

Доступ к данным в распределенных БД [1] [2]

• приложения загружают JDBC-драйвер динамически, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места;
• JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно проблемы с переносимостью приложений практически снимаются;
• использование Java-приложений и связанной с ними идеологии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.

Прикладные интерфейсы OLE DB и ADO — это прикладные интерфейсы доступа к данным с использованием SQL.

OLE DB (object linking and embedding data base) специфицирует взаимодействие, обеспечивая единый интерфейс доступа к данным через провайдеров — поставщиков данных не только из реляционных БД. OLE DB предоставляет приложениям общее решение обеспечения доступа к информации независимо от типа источника данных.

OLE DB включает два базовых компонента: провайдер данных и потребитель данных. Потребитель (клиент) — это приложение или компонент, обращающийся к OLE DB. Провайдер (сервер) — это приложение, отвечающее на вызовы OLE DB и возвращающее запрашиваемый объект — обычно данные в табличном виде.

ADO (active data object) — это универсальный интерфейс высокого уровня. Модель объекта ADO не содержит таблиц, среды или машины БД. Здесь основными объектами являются следующие: объект Соединение, создающий связь с провайдером данных; объект Набор данных и объект Команда — выполнение процедуры, SQL-строки. В общем случае ADO можно рассматривать как язык программирования, позволяющий выбирать, модифицировать и удалять записи.

CAP-теорема является краеугольным камнем теории распределённых систем. Конечно, споры вокруг неё не утихают: и определения в ней не канонические, и строгого доказательства нет… Тем не менее, твёрдо стоя на позициях бытового здравого смысла™, мы интуитивно понимаем, что теорема верна.

Единственное, что не очевидно, так это значение буквы «P». Когда кластер разделился, он решает – то ли не отвечать, пока не будет набран кворум, то ли отдавать те данные, которые есть. В зависимости от результатов этого выбора система классифицируется либо как CP, либо как AP. Cassandra, например, может вести себя и так и так, в зависимости даже не от настроек кластера, а от параметров каждого конкретного запроса. Но если система не «P», и она разделилась, тогда – что?

Ответ на этот вопрос несколько неожиданный: CA-кластер не может разделиться.
Что же это за кластер, который не может разделиться?

Непременный атрибут такого кластера – общая система хранения данных. В подавляющем большинстве случаев это означает подключение через SAN, что ограничивает применение CA-решений крупными предприятиями, способными содержать SAN-инфраструктуру. Для того, чтобы несколько серверов могли работать с одними и теми же данными, необходима кластерная файловая система. Такие файловые системы есть в портфелях HPE (CFS), Veritas (VxCFS) и IBM (GPFS).

Oracle RAC

Опция Real Application Cluster впервые появилась в 2001 году в релизе Oracle 9i. В таком кластере что несколько экземпляров сервера работают с одной и той же базой данных.
Oracle может работать как с кластерной файловой системой, так и с собственным решением – ASM, Automatic Storage Management.

Каждый экземпляр ведёт свой журнал. Транзакция выполняется и фиксируется одним экземпляром. В случае сбоя экземпляра один из выживших узлов кластера (экземпляров) считывает его журнал и восстанавливают потерянные данные – за счёт этого обеспечивается доступность.

Все экземпляры поддерживают собственный кэш, и одни и те же страницы (блоки) могут находиться одновременно в кэшах нескольких экземпляров. Более того, если какая-то страница нужна одному экземпляру, и она есть в кэше другого экземпляра, он может получить его у «соседа» при помощи механизма cache fusion вместо того, чтобы читать с диска.

Но что произойдёт, если одному из экземпляров потребуется изменить данные?

Особенность Oracle в том, что у него нет выделенного сервиса блокировок: если сервер хочет заблокировать строку, то запись о блокировке ставится прямо на той странице памяти, где находится блокируемая строка. Благодаря такому подходу Oracle – чемпион по производительности среди монолитных баз: сервис блокировок никогда не становится узким местом. Но в кластерной конфигурации такая архитектура может приводить к интенсивному сетевому обмену и взаимным блокировкам.

Как только запись блокируется, экземпляр оповещает все остальные экземпляры о том, что страница, в которой хранится эта запись, захвачена в монопольном режиме. Если другому экземпляру понадобится изменить запись на той же странице, он должен ждать, пока изменения на странице не будут зафиксированы, т. е. информация об изменении не будет записана в журнал на диске (при этом транзакция может продолжаться). Может случиться и так, что страница будет изменена последовательно несколькими экземплярами, и тогда при записи страницы на диск придётся выяснять, у кого же хранится актуальная версия этой страницы.

Случайное обновление одних и тех же страниц через разные узлы RAC приводит к резкому снижению производительности базы данных – вплоть до того, что производительность кластера может быть ниже, чем производительность единственного экземпляра.

Правильное использование Oracle RAC – физическое деление данных (например, при помощи механизма секционированных таблиц) и обращение к каждому набору секций через выделенный узел. Главным назначением RAC стало не горизонтальное масштабирование, а обеспечение отказоустойчивости.

Если узел перестаёт отвечать на heartbeat, то тот узел, который обнаружил это первым, запускает процедуру голосования на диске. Если и здесь пропавший узел не отметился, то один из узлов берёт на себя обязанности по восстановлению данных:

«замораживает» все страницы, которые находились в кэше пропавшего узла;
считывает журналы (redo) пропавшего узла и повторно применяет изменения, записанные в этих журналах, попутно проверяя, нет ли у других узлов более свежих версий изменяемых страниц;
откатывает незавершённые транзакции.

IBM Pure Data Systems for Transactions

Кластерное решение для СУБД появилось в портфеле Голубого Гиганта в 2009 году. Идеологически оно является наследником кластера Parallel Sysplex, построенным на «обычном» оборудовании. В 2009 году вышел продукт DB2 pureScale, представляющий собой комплект программного обеспечения, а в 2012 года IBM предлагает программно-аппаратный комплект (appliance) под названием Pure Data Systems for Transactions. Не следует путать его с Pure Data Systems for Analytics, которая есть не что иное, как переименованная Netezza.

Архитектура pureScale на первый взгляд похожа на Oracle RAC: точно так же несколько узлов подключены к общей системе хранения данных, и на каждом узле работает свой экземпляр СУБД со своими областями памяти и журналами транзакций. Но, в отличие от Oracle, в DB2 есть выделенный сервис блокировок, представленный набором процессов db2LLM*. В кластерной конфигурации этот сервис выносится на отдельный узел, который в Parallel Sysplex называется coupling facility (CF), а в Pure Data – PowerHA.

PowerHA предоставляет следующие сервисы:

менеджер блокировок;
глобальный буферный кэш;
область межпроцессных коммуникаций.

Если узлу нужна страница, и этой страницы нет в кэше, то узел запрашивает страницу в глобальном кэше, и только в том случае, если и там её нет, читает её с диска. В отличие от Oracle, запрос идёт только в PowerHA, а не в соседние узлы.

Если страница, в которой находится изменяемая строка, уже заблокирована, то менеджер блокировок прочитает изменённую страницу из памяти узла, сделавшего изменения, снимет блокировку, инвалидирует изменённую страницу в кэшах других узлов и отдаст блокировку страницы узлу, который её запросил.

«Грязные», то есть изменённые, страницы могут быть записаны на диск как с обычного узла, так и с PowerHA (castout).

При отказе одного из узлов pureScale восстановление ограничено только теми транзакциями, которые в момент сбоя ещё не были завершены: страницы, изменённые этим узлом в завершившихся транзакциях, есть в глобальном кэше на PowerHA. Узел перезапускается в урезанной конфигурации на одном из серверов кластера, откатывает незавершённые транзакции и освобождает блокировки.

PowerHA работает на двух серверах, и основной узел синхронно реплицирует своё состояние. При отказе основного узла PowerHA кластер продолжает работу с резервным узлом.
Разумеется, если обращаться к набору данных через один узел, общая производительность кластера будет выше. PureScale даже может заметить, что некоторая область данных обрабатываются одним узлом, и тогда все блокировки, относящиеся к этой области, будут обрабатываться узлом локально без коммуникаций с PowerHA. Но как только приложение попытается обратиться к этим данным через другой узел, централизованная обработка блокировок будет возобновлена.

Внутренние тесты IBM на нагрузке, состоящей из 90% чтения и 10% записи, что очень похоже на реальную промышленную нагрузку, показывают почти линейное масштабирование до 128 узлов. Условия тестирования, увы, не раскрываются.

HPE NonStop SQL

Своя высокодоступная платформа есть и в портфеле Hewlett-Packard Enterprise. Это платформа NonStop, выпущенная на рынок в 1976 году компанией Tandem Computers. В 1997 году компания была поглощена компанией Compaq, которая, в свою очередь, в 2002 году влилась в Hewlett-Packard.

NonStop используется для построения критичных приложений – например, HLR или процессинга банковских карт. Платформа поставляется в виде программно-аппаратного комплекса (appliance), включающего в себя вычислительные узлы, систему хранения данных и коммуникационное оборудование. Сеть ServerNet (в современных системах – Infiniband) служит как для обмена между узлами, так и для доступа к системе хранения данных.

В ранних версиях системы использовались проприетарные процессоры, которые были синхронизированы друг с другом: все операции исполнялись синхронно несколькими процессорами, и как только один из процессоров ошибался, он отключался, а второй продолжал работу. Позднее система перешла на обычные процессоры (сначала MIPS, затем Itanium и, наконец, x86), а для синхронизации стали использоваться другие механизмы:

Вся база данных делится на части, и за каждую часть отвечает свой процесс Data Access Manager (DAM). Он обеспечивает запись данных, кэшировние и механизм блокировок. Обработкой данных занимаются процессы-исполнители (Executor Server Process), работающие на тех же узлах, что и соответствующие менеджеры данных. Планировщик SQL/MX делит задачи между исполнителями и объединяет результаты. При необходимости внести согласованные изменения используется протокол двухфазной фиксации, обеспечиваемый библиотекой TMF (Transaction Management Facility).

NonStop SQL умеет приоритезировать процессы так, чтобы длинные аналитические запросы не мешали исполнению транзакций. Однако её назначение – именно обработка коротких транзакций, а не аналитика. Разработчик гарантирует доступность кластера NonStop на уровне пять «девяток», то есть простой составляет всего 5 минут в год.

SAP HANA

Первый стабильный релиз СУБД HANA (1.0) состоялся в ноябре 2010 года, а пакет SAP ERP перешёл на HANA с мая 2013 года. Платформа базируется на купленных технологиях: TREX Search Engine (поиска в колоночном хранилище), СУБД P*TIME и MAX DB.

Само слово «HANA» – акроним, High performance ANalytical Appliance. Поставляется эта СУБД в виде кода, который может работать на любых серверах x86, однако промышленные инсталляции допускаются только на оборудовании, прошедшем сертификацию. Имеются решения HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Некоторые конфигурации Lenovo допускают даже эксплуатацию без SAN – роль общей СХД играет кластер GPFS на локальных дисках.

В отличие от перечисленных выше платформ, HANA – СУБД в памяти, т. е. первичный образ данных хранится в оперативной памяти, а на диск записываются только журналы и периодические снимки – для восстановления в случае аварии.

Каждый узел кластера HANA отвечает за свою часть данных, а карта данных хранится в специальном компоненте – Name Server, расположенном на узле-координаторе. Данные между узлами не дублируются. Информация о блокировках также хранится на каждом узле, но в системе есть глобальный детектор взаимных блокировок.

Клиент HANA при соединении с кластером загружает его топологию и в дальнейшем может обращаться напрямую к любому узлу в зависимости от того, какие данные ему нужны. Если транзакция затрагивает данные единственного узла, то она может быть выполнена этим узлом локально, но если изменяются данные нескольких узлов, то узел-инициатор обращается к узлу-координатору, который открывает и координирует распределённую транзакцию, фиксируя её при помощи оптимизированного протокола двухфазной фиксации.

Узел-координатор дублирован, поэтому в случае выхода координатора из строя в работу немедленно вступает резервный узел. А вот если выходит из строя узел с данными, то единственный способ получить доступ к его данным – перезапустить узел. Как правило, в кластерах HANA держат резервный (spare) сервер, чтобы как можно быстрее перезапустить на нём потерянный узел.

Читайте также: