HighLoad.org – блог о высоких нагрузках
HighLoad.org > 4 уровня технологии репликации

4 уровня технологии репликации
2010-03-11 18:56 my_fess  
Репликации широко используются для достижения различных целей в информационных системах, например для лучшей производительности, устойчивости к ошибкам, резервного копирования и т. д. Доступно 4 класса технологий репликации. Ваше решение о том какую технологию использовать будет зависить от логического представления данных которые вы пытаетесь реплицировать.

Репликация на уровне хранилища

На уровне хранилища, репликация фокусируется на блоке бинарных данных. Репликация может быть произведена на уровне файловой системы или уровне устройств. В обоих случаях репликация имеет дело с нестуруктурированными бинарными данными. Диапазон технологий для репликации на уровне хрнилища очень широк начиная от RAID-массивов до сетевых файловых систем и NAS.

Репликация на уровне базы данных

Обычно приложение не использует напрямую файловое хранилище, а использует вместо этого базы данных. Базы данных работают с структурированными данными. Технологии репликации на уровне базы данных также оперируют структурированными данными (например записи в реляционных СУБД, объекты в объектных базах данных). Существует 2 главных приема для репликации базы данных:
  • Репликация, основанная на записях. Базы данных используют минимальный распознаваемый кусок данных для правильного функционирования (например, в реляционной СУБД это запись в таблице). В репликации, основанной на записях, каждый раз как только запись модифицируется, к парнтеру по репликации передается событие логического изменения записи для поддержания синхронности.
  • Репликация, основанная на запросах. Иногда один запрос может модифицировать большое число записей. В этом случае будет более эфективным передавать сам запрос партнеру по репликации, чем копировать все модифицированные записи. Это подход на основе запросов. Все мэйнстримные СУБД имеют встроенную функциональность реплицирования. Иногда у вас даже есть возможность выбрать тип репликации (например, основанную на записях или на запросах) с помощью конфигурирования базы данных. MySQL - один из тех продуктов который позволяет сделать это.

Репликация с сообщениями

Часто мы хотим реплицировать не данные а реплицировать состояние приложения. Например, при репликации основанной на запросах вы можете реплицировать поток бизнес-событий, которые изменяют состояние приложения, вместо того чтобы реплицировать изменение данных. Заново выполнение тех же самых действий должно привести к тому же состоянию приложения (по крайней мере к бизнес-эквивалентному состоянию). Репликация с сообщениями имеет несколько практических преимуществ. Во-первых, репликация обычно выполняется в рамках бизнес-транзакции, которые могут отличаться от границ транзакций базы данных. Во-вторых, репликация независима от структуры данных в базе данных. Это может быть очень полезным когда вы производите обновления схемы базы данных — различные схемы могут сосуществовать в репликационной топологии. Репликация с сообщениями тесно связана с логикой приложения. Нет общего решения для этого типа репликации. Но широко используется промежуточная очередь сообщений для передачи сообщений между партнерами по репликации.

Репликация состояния приложения (грид-технологии)

Конвертирование данных из представления в оперативной памяти в базу данных — дорогая операция и это может быть узким местом в некоторых ситуациях. Репликация состояния приложения решает эту проблему реплицированием структур данных в оперативной памяти между процессами приложения (и серверами). Существуют 2 главных подкласса такой технологии:
  • Грид данных в оперативной памяти (In-memory data grid ). Грид данных в оперативной памяти предлагает сервис общей памяти наподобие хранилища (все участники имеют согласованное представление этого хранилища и могут получать равный доступ к нему). Грид предоставляет API, которое используется приложениями для управления общим хранилищем. Хранилище используется для хранения объектов уровня приложения (в сериализованной форме). Приложение грида за нас делает репликацию/распределение хранимого контента на серверах и процессах.
  • Прозрачная кластеризация приложения. Данный подход пытается скрыть вещи, касающиеся репликации, максимально, насколько это возможно и минимизировать изменения в коде приложения. Обычно для этого класса технгологий, процессы разделены на рабочие процессы (выполняющие код приложения) и управляющие процессы. В простейшем случае, эти два процесса могут быть соединены в один. Управляющие процессы не выполняют код приложения; они координируют репликацию состояний между инстансами рабочих процессов. Примером продукта использующего эту парадигму является Terracotta, которая реализует кластеризацию для среды выполненяия Java и GemStone – кластеризованная среда выполнения для Smalltalk (и скоро появится поддержка длля Ruby).

Автор статьи: Alexey Ragozin Дата: 26 февраля 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD