amazon DocumentDB

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 23:40, 17 мая 2020.

Amazon DocumentDB
Logo AmazonDB.png
Разработчики: Amazon
Выпущена: 9 January 2019 года; 17 months ago (2019-01-09)
Операционная система: Кросс-платформенная
Локализация: Английский язык
Тип ПО: Документ-ориентированная база данных
Лицензия: Проприетарное
Веб-сайт aws.amazon.com/ru/documentdb/

Сервис Amazon DocumentDB – это быстрая, масштабируемая, высокодоступная и полностью управляемая документная база данных, которая поддерживает рабочие нагрузки MongoDB, упрощает хранение и индексирование данных JSON, а также выполнение запросов к ним.
Является нереляционной базой данных, которая разрабатывалась с целью обеспечить пользователям необходимую производительность, масштабируемость и доступность при обработке критически важных рабочих нагрузок MongoDB в любом масштабе [Источник 1].

История

В Amazon Web Services (AWS) утверждают, что, хотя MongoDB отлично справляется со своими задачами, их клиентам всё же трудно создавать быстрые и высокодоступные приложения на платформе с открытым исходным кодом, которые смогут масштабироваться до нескольких терабайт и сотен тысяч операций чтения и записи в секунду. Поэтому компания создала свою собственную базу данных документов, но сделала ее совместимой с API MongoDB 3.6, распространяющимся под лицензией Apache 2.0.

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

«Подражание — это самая искренняя форма лести, поэтому неудивительно, что Amazon попытается извлечь выгоду из популярности и импульса документной модели MongoDB», — сказал исполнительный директор MongoDB Dev Ittycheria. «Тем не менее, разработчики достаточно технически подкованы, чтобы различать реальную вещь и плохую имитацию. MongoDB будет продолжать превосходить любые подмены на рынке.» - сказал он в заявлении, переданном CNBC.
Клон службы баз данных, созданный для AWS, снизил объем продаж провайдера баз данных более чем на 13%.

Версия DocumentDB от Amazon использует старую версию сервера MongoDB 3.6, которая работает под более широкой лицензией с открытым исходным кодом. Более новая версия лицензируется в рамках общедоступной лицензии на стороне сервера, что означает, что те, кто использует, изменяет и повторно развертывает бесплатную версию Mongo, известную как Community Server, в качестве веб-службы, должны также сделать свою работу свободно доступной для других, так как программное обеспечение с открытым исходным кодом [Источник 2].

Amazon DocumentDB был запущен 9 января 2019 года и с первых дней подвергся критике пользователей. 2019 год разработчики потратили на расширение возможностей, улучшение доступности, масштабируемости и производительности сервиса.

Принцип работы сервиса

Самостоятельное управление базами MongoDB – сложное, трудоемкое и дорогое дело. Amazon DocumentDB позволяет настраивать, защищать и масштабировать совместимые с MongoDB базы данных в облаке без необходимости вручную настраивать кластеры БД, обеспечивать их безопасность, работать с ПО для управления кластерами, настраивать резервное копирование и вести мониторинг процессов в рабочей среде.
В Amazon DocumentDB хранилище и вычислительные ресурсы разделены, что позволяет масштабировать их по отдельности. Можно повысить производительность операций чтения до миллионов запросов в секунду, добавив до 15 реплик чтения с низкой задержкой. Реплика создается за несколько минут вне зависимости от объема данных.

Amazon DocumentDB рассчитан на 99,99% доступности и реплицирует шесть копий ваших данных в трех зонах доступности (availability zone) AWS. Требуемый уровень готовности (availability goal) DocumentDB ниже, когда у вас меньше экземпляров или, когда она развернута менее чем на трёх зонах доступности:

Доступность Amazon DocumentDB
Уровень доступности Экземпляров Реплик Зон доступности
99% 1 0 1
99.9% 2 1 2
99.99% 3 2 3

Кластер Amazon DocumentDB состоит из двух компонентов (структура изображена на рисунке 1):

  1. Том кластера (сluster volume): кластер имеет ровно один том кластера, который может хранить до 64 ТБ данных.
  2. Экземпляры (instances): обеспечивают вычислительную мощность базы данных, запись данных и чтение данных из тома хранилища кластера. Кластер Amazon DocumentDB может иметь от 0 до 16 экземпляров:
    1. Основной экземпляр (primary instance): поддерживает операции чтения и записи и выполняет все модификации данных в томе кластера. Каждый кластер Amazon DocumentDB имеет один основной экземпляр;
    2. Экземпляр реплики (replica instance): поддерживает только операции чтения. Кластер Amazon DocumentDB может иметь до 15 реплик в дополнение к основному экземпляру.
Рисунок 1. Сценарий развертывания

В случае сбоя основного экземпляра реплика Amazon DocumentDB повышается до основного экземпляра. Существует короткое прерывание, во время которого запросы на чтение и запись, сделанные первичному экземпляру, завершаются с ошибкой. По оценкам Amazon, это прерывание составляет менее 120 секунд.

Существует возможность настроить порядок, в котором реплики повышаются до основного экземпляра после сбоя, назначив каждому реплику приоритет, отметив, что настоятельно рекомендуется, чтобы реплики были того же класса экземпляра, что и основной. Также очень важно создать хотя бы одну или несколько реплик Amazon DocumentDB в двух или более разных зонах доступности, чтобы хранилище данных могло выдержать сбой зоны[Источник 3].

Основные особенности

Совместимость

Amazon DocumentDB предназначен для работы с существующими приложениями и инструментами MongoDB. При этом требуется обязательно использовать драйверы, предназначенные для MongoDB 3.4 или новее. Внутренне Amazon DocumentDB реализует API MongoDB 3.6, эмулируя ответы, которые клиент MongoDB ожидает от сервера MongoDB.

Масштабируемость

Объем хранилища может быть увеличен с 10 ГБ до 64 ТБ с шагом 10 ГБ. Предварительное выделение хранилища и контроль свободного места не требуется, Amazon DocumentDB делает это автоматически. Вы можете выбрать один из шести размеров экземпляров (от 15,25 ГБ до 488 ГБ памяти) и создать до 15 реплик чтения. Хранение и вычисления разделены, и вы можете масштабировать каждый независимо и по мере необходимости.

Производительность

Amazon DocumentDB сохраняет изменения базы данных в виде потока журнала, что позволяет обрабатывать миллионы операций чтения в секунду с задержкой в миллисекунды. Модель хранения обеспечивает хорошее повышение производительности без ущерба для надежности данных и значительно повышает общую масштабируемость.

Надежность

6-ти сторонняя репликация хранилища обеспечивает высокую доступность. Amazon DocumentDB может переключаться при сбое с первичной на реплику в течение 30 секунд и поддерживает эмуляцию набора реплик MongoDB, поэтому приложения могут быстро обрабатывать отработки отказа.

Полная управляемость

Как и другие сервисы баз данных AWS, Amazon DocumentDB полностью управляется со встроенным мониторингом, обнаружением неисправностей и отработкой отказа. Пользователь может создавать ежедневные резервные копии, делать ручные копии и использовать любую из них, чтобы создать новый кластер при необходимости. Существует возможность выполнить восстановление на определенный момент времени в любую точку в течение от 1-35-дневного периода хранения резервных копий.

Безопасность

Шифрование активных данных, копий и реплик происходит с помощью выбранного ключа KMS при создании каждого из кластеров Amazon DocumentDB. Аутентификация включена по умолчанию, как и шифрование данных при передаче. Amazon DocumentDB был разработан для того, чтобы соответствовать самым высоким стандартам безопасности. Amazon DocumentDB была оценена на соответствие стандартам PCI DSS, ISO 9001, 27001, 27017 и 27018, а также SOC 1, 2 и 3 в дополнение к тому, что она соответствует требованиям HIPAA[Источник 4].

Оценка совместимости с MongoDB

Amazon утверждает, что переход с MongoDB на DocumentDB «так же прост, как и изменение конечной точки базы данных на новый кластер Amazon DocumentDB». В MongoDB оценили требования совместимости DocumentDB, запустив 6 тестовых пакетов MongoDB, в общей сложности более 1100 тестов, против эмуляции API DocumentDB[Источник 5]. Этот набор, используется для проверки соответствия и корректности MongoDB при каждом выпуске базы данных, и он является лучшим представлением полного API MongoDB:

  • jsCore: более 800 тестов операций MongoDB CRUD и команд базы данных
  • aggregation: более 200 тестов конвейера агрегации MongoDB
  • jsCore_decimal: оценивает правильное поведение приложений, используя десятичный тип данных для высокоточных, дробных числовых данных, типичных для финансовых и научных рабочих нагрузок.
  • change_streams: тестирует потоки изменений MongoDB, используемые разработчиками для создания управляемых событиями конвейеров данных, которые в реальном времени реагируют на изменения базы данных
  • jsCore_txns: оценивает правильное поведение многодокументных транзакций ACID в MongoDB
  • jsonSchema: тестирует средства управления данными, предоставляемые MongoDB

В результате проведённых тестов не удалось выполнить 63% всех тестов на корректность при работе с эмуляцией API DocumentDB. Для разработчиков это означает, что:

  • Любые существующие приложения MongoDB, использующие эту функциональность, должны быть переработаны, если они должны быть перенесены в DocumentDB.
  • Любые новые приложения, написанные с использованием API DocumentDB, поддерживают только часть функциональности MongoDB
  • Любое приложение, написанное для DocumentDB, будет заблокировано в AWS.

MongoDB выделила ключевые пробелы:

  1. Нет поддержки транзакций ACID с несколькими выписками; без поддержки шардинга невозможно включить распределенные транзакции, охватывающие несколько разделов данных.
  2. DocumentDB поддерживает только подмножество языка запросов MongoDB.
  3. Поддерживается менее 50% этапов конвейера агрегации MongoDB 3.6 и операторов языка запросов.
  4. Несмотря на заявленную поддержку потоков изменений, из-за DocumentDB 90% тестов на корректность потоков изменений MongoDB по-прежнему не пройдены:
  5. Не поддерживается открытие потоков изменений для неосновного узла. Без поддержки шардера все записи приложения также должны обслуживаться этим единственным основным узлом DocumentDB, поэтому добавление потоков изменений приведет к потенциально значительному конфликту, влияющему на пропускную способность и задержку приложения.
  6. Не поддерживает события DDL, в том числе drop, rename и dropDatabase, не позволяя разработчикам реагировать на изменения уровня коллекции и базы данных
  7. Не поддерживает конвейеры агрегирования $ replaceRoot, $ replaceWith, $ redact, $ set или $ unset, что ограничивает возможность фильтровать или изменять выходные данные потока изменений.
  8. Resume_after не соответствует API MongoDB, что ограничивает возможности пользователей по переходу приложений между MongoDB и DocumentDB
  9. Нет возможности устанавливать детальные разрешения для каждого пользователя для потоков изменений. Если в базе данных включены потоки изменений, все пользователи с правами на чтение могут видеть все изменения в базе данных.
  10. События изменений сохраняются только по умолчанию в течение 3 часов, а затем удаляются.
  11. Дополнительные расходы будут понесены потоками изменений для хранения и доставки изменений. Смена потоков в MongoDB Atlas не требует дополнительных затрат.
  12. Нет материализованных представлений по требованию
  13. Нет схемы управления для контроля качества данных
  14. Нет десятичного типа данных, поэтому нет способа сохранить точность сложных числовых данных, используемых в финансовых и научных приложениях
  15. Ограниченные параметры курсора: нет поддержки подсказок, сортировки или настраиваемых курсоров
  16. Отсутствие причинной согласованности гарантирует снижение качества данных за счет исключения возможности монотонного чтения по репликам.
  17. DocumentDB не реализует настраиваемые параметры согласованности API MongoDB. Даже в тех случаях, когда требуется более высокая пропускная способность и сниженные гарантии надежности, такие как потоковая передача данных датчика IoT, отслеживание пользователей или крупномасштабные платформы социальных сетей, клиенты должны ждать, пока все записи достигнут большинства этих узлов.

Поддержка управления доступом на основе ролей

В Amazon DocumentDB добавлена ​​поддержка управления доступом на основе ролей (RBAC - role-based access control)[Источник 6]. С помощью RBAC вы можете предоставить пользователям одну или несколько предопределенных ролей (например, read, readWrite или dbOwner), которые определяют, какие операции им разрешено выполнять с одной или несколькими базами данных.

Распространенным вариантом использования RBAC является обеспечение доступа с наименьшими привилегиями в рамках одного приложения.

Другим распространенным вариантом использования является создание мультиарендных приложений. Мультиарендное приложение - это развертывание программного и аппаратного обеспечения, которое обслуживает нескольких клиентов. В контексте Amazon DocumentDB пример мультиарендного приложения - каждый клиент (или арендатор) получает доступ к своим базам данных в кластере.

Amazon DocumentDB использует следующие ключевые концепции RBAC:

  • Пользователь - именованный объект, который может аутентифицировать и выполнять операции
  • Пароль - секретное слово, которое аутентифицирует пользователя
  • Роль - обозначение, которое разрешает пользователю выполнять действия с одной или несколькими базами данных.
  • База данных администратора - специальная база данных для авторизации пользователей против
  • База данных (БД) - пространство имен в кластере, содержащем коллекции

Следующий код создает пользователя с именем app с паролем abc123 и разрешениями на чтение в базе данных foo:

db.createUser({user: "app", pwd: "abc123", roles: [{role: "read", db: "foo"}]})

Вы можете перечислить существующих пользователей и роли в кластере с помощью команды show users. В следующем коде показаны выходные данные этой команды для созданного пользователя:

{
	"_id" : "app",
	"user" : "app",
	"db" : "admin",
	"roles" : [
		{
			"db" : "foo",
			"role" : "read"
		}
	]
}

Вся информация о ролях хранится в специальной базе данных с именем admin. В этом примере кода вы можете видеть, что пользовательское приложение находится в базе данных администратора и имеет роль чтения для базы данных foo.

Обеспечение минимальных привилегий

Рисунок 2 - Пример применения RBAC с обеспечением минимальных привилегий

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

Принцип наименьших привилегий является основополагающим инструментом безопасности. RBAC можно использовать для применения этого принципа, ограничивая доступ пользователей только к тому, что требуется для выполнения их функций. На рисунке 2 приведен пример использования с тремя пользователями приложения (appAdmin, appUser и analytics). Каждый пользователь имеет различную роль в зависимости от функции, которую он должен выполнять. Следующая диаграмма суммирует роли.

Первый пользователь (appAdmin) является администратором приложения и должен создавать индексы, добавлять пользователей, а также читать и записывать данные в любую базу данных. Для этого пользователя назначьте роли dbAdminAnyDatabase, readWriteAnyDatabase и clusterAdmin. Чтобы создать пользователя для appAdmin и предоставить необходимые роли, введите следующий код (чтобы создать этих пользователей, вы должны пройти проверку подлинности в своем кластере как суперпользователь):

db.createUser( { user: "appAdmin", pwd: "abc123",  roles: [{"db":"admin", "role":"dbAdminAnyDatabase" }, {"db":"admin", "role":"readWriteAnyDatabase"}, {"db":"admin", "role":"clusterAdmin"}]})

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

db.createUser( { user: "appUser", pwd: "abc124",  roles: [ { role: "readWrite", db: "products"}]})

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

db.createUser( { user: "analytics", pwd: "abc125",  roles: [ { role: "read", db: "products"}]})

Вы можете подключиться и аутентифицировать свой кластер как appUser с помощью следующей команды CLI:

mongo "mongodb://appUser:abc124@<clusterName>.us-east-1.docdb.amazonaws.com:27017/"

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

Теперь вы можете читать и писать в каталог продукции. Чтобы вставить несколько документов в коллекцию каталога, введите следующий код:

db.catalog.insertMany([
{ "_id":1, "name":"banana", "inventory": 10},
{ "_id":2, "name":"passion fruit", "inventory": 22},
{ "_id":3, "name":"pink laddy apple", "inventory": 78},
])

Вы получите следующий вывод:

{ "acknowledged" : true, "insertedIds" : [ 1, 2, 3 ] }

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

db.catalog.find({"name": "passion fruit"})

Вы получите следующий вывод:

{ "_id" : 2, "name" : "passion fruit", "inventory" : 22 }

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

db.auth("analytics", "abc125")

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

db.catalog.find({"name": "passion fruit"})
{ "_id" : 2, "name" : "passion fruit", "inventory" : 22 }

Однако, вы не авторизованы для записи данных. Например, следующий код пытается вставить новые данные и получает сообщение об ошибке:

db.catalog.insert ({"name": "лимоны", "количество": 99})
WriteResult({ "writeError" : { "code" : 13, "errmsg" : "Authorization failure" } })

Мультиарендное приложение

Рисунок 3 - Пример применения RBAC при работе с мультиарендным приложением

Во втором случае использования у вас есть база данных для поддержки приложения для разработки игр. Для оптимизации затрат вы используете мультиарендный кластер, в котором каждый разработчик игр имеет доступ к своей собственной базе данных в кластере. Четыре игровые студии подписались на вашу игровую платформу: bigCow, raceCar, xQuest и bounce. Чтобы предоставить этим клиентам доступ к их данным, вы создаете четырех пользователей-администраторов базы данных: по одному для каждого клиента. Каждый пользователь-администратор может администрировать свою собственную базу данных для своей игры (схема приведена на рисунке 3).

После того как вы войдете в систему с пользователем, у которого есть роль администратора для всего кластера DocumentDB, вы можете создать пользователя-администратора каждой игровой БД и распределить соответствующие роли по конкретным базам данных в кластере:

db.createUser( { user: "bigCowAdmin", pwd: "abc123",  roles: [ { role: "dbOwner", db: "bigCow"}]})
db.createUser( { user: "raceCarAdmin", pwd: "def456",  roles: [ { role: "dbOwner", db: "raceCar"}]})
db.createUser( { user: "xQuestAdmin", pwd: "ghi789",  roles: [ { role: "dbOwner", db: "xQuest"}]})
db.createUser( { user: "bounceAdmin", pwd: "jkl012",  roles: [ { role: "dbOwner", db: "bounce"}]})

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

Вы можете подключиться и аутентифицировать свой кластер как bigCowAdmin с помощью следующей команды оболочки mongo:

mongo "mongodb://bigCowAdmin:abc123@<clusterName>.us-east-1.docdb.amazonaws.com:27017/"

Затем переключите контекст вашего соединения на базу данных xQuest. Вы можете попытаться записать один документ в коллекцию foo в базе данных xQuest, но получите сообщение об ошибке:

WriteResult({ "writeError" : { "code" : 13, "errmsg" : "Authorization failure" } })

Как и ожидалось, пользователь bigCowAdmin не авторизован для выполнения этой команды.

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

db.runCommand ({listCollections: 1})
{"ok": 0, "errmsg": "Ошибка авторизации", "code": 13}

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

WriteResult({ "nInserted" : 1 })

Точно так же, поскольку у пользователя bigCowAdmin есть роль dbOwner, вы можете перечислить коллекции в базе данных bigCow:

db.runCommand ({listCollections: 1})
{
	"waitedMS" : NumberLong(0),
	"cursor" : {
		"firstBatch" : [
			{
				"name" : "foo",
				"type" : "collection",
				"options" : {
					"autoIndexId" : true,
					"capped" : false
				},
				"info" : {
					"readOnly" : false
				},
				"idIndex" : {
					"v" : 2,
					"key" : {
						"_id" : 1
					},
					"name" : "_id_",
					"ns" : "bigCow.foo"
				}
			}
		],
		"id" : NumberLong(0),
		"ns" : "bigCow.$cmd.listCollections"
	},
	"ok" : 1
}

Начало работы

Для начала работы потребуется создать учетную запись Amazon Web Services.
После этого следует выполнить несколько действий:

  • Создать собственный кластер и произвести его настройку.
  • Чтобы взаимодействовать с кластером Amazon DocumentDB, необходимо запустить приложение Amazon Elastic Compute Cloud (Amazon EC2) в VPC по умолчанию, в том же самом Регион AWS, в котором вы создали свой кластер Amazon DocumentDB.
  • Подключиться к кластеру Amazon DocumentDB с помощью оболочки mongo (действия выполняются с помощью Amazon EC2, созданного на предыдущем шаге).
  • В случае, если кластер больше не нужен, его следует удалить или остановить его работу, чтобы не платить за используемые ресурсы.

В связи с кроссплатформенностью существует множество способов организации работы с Amazon DocumentDB.

Миграция с помощью гибридного метода

Существует три основных подхода для миграции из MongoDB в Amazon DocumentDB: автономный, сетевой и гибридный. Гибридный метод является лучшим вариантом, если вы хотите минимизировать время простоя и ваш исходный набор данных превышает 1 ТБ. Гибридный метод использует преимущества распараллеливания и скорость, которую можно достичь с mongorestore с помощью миграции основной части данных, а затем использует AWS Database Migration Service (DMS) для минимизации времени простоя[Источник 7].

Подготовка

Если исходный код MongoDB использует версию MongoDB более раннюю, чем 3.6, необходимо обновить исходное развертывание и драйверы приложений. Они должны быть совместимы с MongoDB 3.6 для миграции в Amazon DocumentDB. Вы можете определить версию исходного развертывания, введя следующий код в командной консоли mongo:

mongoToDocumentDBOnlineSet1:PRIMARY> db.version()
3.4.4

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

db.adminCommand( { replSetGetStatus : 1 } )

Если выходные данные представляют собой сообщение об ошибке, кластер не настроен как набор реплик:

"errmsg" : "not running with --replSet"

Далее, нужно выбрать размер исходного кластера Amazon DocumentDB (db.r5.large). При определении размера кластера выберите тип экземпляра, который подходит для вашего производственного кластера.

Чтобы подключиться к кластеру Amazon DocumentDB для переноса индексов и выполнения других задач во время миграции создайте экземпляр EC2 в том же VPC, что и ваш кластер, и установите оболочку mongo.

Чтобы проверить подключение к Amazon DocumentDB, введите следующую команду интерфейса командной строки:

[ec2]$ mongo --ssl --host docdb-cluster-endpoint \
--sslCAFile rds-ca-2019-root.pem --username myuser \
--password mypasswordrs0:PRIMARY> db.runCommand('ping')
{ "ok" : 1 }

Если у вас возникли проблемы проблемы с подключением к исходному экземпляру или кластеру Amazon DocumentDB, проверьте конфигурации групп безопасности для обоих, чтобы убедиться, что экземпляр EC2 имеет разрешение на подключение к каждому из них на правильном порту (27017 по умолчанию).

Amazon DocumentDB по умолчанию использует шифрование Transport Layer Security (TLS). Чтобы подключиться через коллекцию с шифрованием TLS, загрузите файл центра сертификации (ЦС), чтобы использовать для подключения оболочку mongo:

[ec2 ]$ curl -O https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem

Для миграции индексов и данных ключевым соображением является обеспечение того, чтобы объем Amazon EBS экземпляра EC2 был достаточно большим для хранения экспортированных данных. Вы можете получить приблизительную оценку размера базы данных в байтах, запустив приложение db.stats() команда в оболочке mongo и глядя на значение storageSize:

mongoToDocumentDBHybridSet1:PRIMARY> db.stats()
{
	"db" : "zips-db",
	"collections" : 1,
	"views" : 0,
	"objects" : 193579,
	"avgObjSize" : 65.97073815367189,
	"dataSize" : 9843917,
	"storageSize" : 8125248,
	"numExtents" : 0,
	"indexes" : 1,
	"indexSize" : 610304,
	"scaleFactor" : 1,
	"fsUsedSize" : 2396921856,
	"fsTotalSize" : 8577331200,
	"ok" : 1,
	"$clusterTime" : 
	{
		"clusterTime" : Timestamp(1582412608, 1),
		"signature" : 
		{
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	},
	"operationTime" : Timestamp(1582412608, 1)
}

Шаги гибридной миграции

  • Приложение продолжает запись в источник

При использовании гибридного метода для миграции в Amazon DocumentDB приложение продолжает запись в исходную базу данных MongoDB. На шаге 7 обсуждается прекращение записи в исходную базу данных и изменение приложения, чтобы оно указывало на целевой кластер Amazon DocumentDB.

  • Сброс индексов с помощью инструмента Amazon DocumentDB Index

Перед началом миграции создайте в целевом кластере Amazon DocumentDB те же индексы, что и в исходном кластере MongoDB. Хотя AWS DMS выполняет миграцию данных, она не выполняет миграцию индексов. Чтобы перенести индексы, в экземпляре EC2, созданном в качестве предварительного условия, используйте инструмент Amazon DocumentDB Index Tool для экспорта индексов из кластера MongoDB. Вы можете получить инструмент, создав его клон Amazon DocumentDB tools GitHub repo и следуя инструкциям в разделе: README.md.

Следующий код сбрасывает индексы из исходного кластера MongoDB в каталог на экземпляре EC2:

python migrationtools/documentdb_index_tool.py --dump-indexes 
--dir ~/index.js/ 
--host ec2-user.us-west-2.compute.amazonaws.com 
--auth-db admin 
--username user
--password password

2020-02-11 21:46:50,432: Successfully authenticated to database: admin
2020-02-11 21:46:50,432: Successfully connected to instance ec2-user.us-west-2.compute.amazonaws.com:27017
2020-02-11 21:46:50,432: Retrieving indexes from server...
2020-02-11 21:46:50,440: Completed writing index metadata to local folder: /home/ec2-user/index.js/

После успешного экспорта индексов следующим шагом является восстановление этих индексов в кластере Amazon DocumentDB.

  • Сброс данных с помощью mongodump

Экспортируйте данные из вашего набора реплик MongoDB в экземпляр миграции EC2 с помощью mongodump инструмент. Установите то –-readPreference параметр вторичный, чтобы заставить дамп подключаться к элементу набора вторичных реплик. Этот шаг уменьшает потенциальное воздействие от mongodump на исходном развертывании. Для того чтобы использовать --readPreference опция, подключиться к реплике установить элемент с помощью формы replicaSetName/ replicasetMember:

[ec2]$ mongodump \
--host mongoToDocumentDBHybridSet1/ec2-x-x-x-x.us-west-2.compute.amazonaws.com 
--username user \
--password password --db zips-db -o .\
--authenticationDatabase admin \
--readPreference secondary
2020-02-03T20:39:05.649+0000 writing zips-db.zips to
2020-02-03T20:39:05.683+0000 done dumping zips-db.zips (29353 documents)

Время, необходимое данным для экспорта, зависит от размера исходного набора данных, скорости сети между экземпляром миграции и источником и ресурсов экземпляра миграции. Запишите время начала работы устройства mongodump процесс; вам нужна эта информация, чтобы знать, когда начать процесс DMS CDC позже.

После успешного экспорта индексов и данных следующим шагом является восстановление данных и индексов в кластере Amazon DocumentDB.

  • Восстановление индексов с помощью инструмента Amazon DocumentDB Index

Чтобы восстановить индексы, экспортированные в целевой кластер на предыдущем шаге, используйте средство индексирования Amazon DocumentDB.

Следующий код восстанавливает индексы в кластере Amazon DocumentDB из экземпляра EC2:

python migrationtools/documentdb_index_tool.py 
--restore-indexes --dir ~/index.js/ 
--host docdb-2x2x-02-02-19-07-xx.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017
--tls --tls-ca-file ~/rds-ca-2019-root.pem 
--username user 
--password password

2020-02-11 21:51:23,245: Successfully authenticated to database: admin
2020-02-11 21:51:23,245: Successfully connected to instance docdb-2x2x-02-02-19-07-xx.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017
2020-02-11 21:51:23,264: zips-db.zips: added index: _id

Чтобы убедиться, что вы восстановили индексы правильно, подключитесь к кластеру Amazon DocumentDB с помощью оболочки mongo и выведите список индексов для данной коллекции. Смотрите следующий код:

mongo --ssl --host docdb-2020.cluster-xxxxxxxx.us-west-2.docdb.amazonaws.com:27017 --sslCAFile rds-ca-2019-root.pem --username documentdb --password documentdb
db.zips.getIndexes()
  • Восстановление данных с помощью mongodump

Чтобы восстановить данные, которые вы сбросили в целевой кластер на Шаге 3, используйте mongodump утилиту.

Следующий код восстанавливает данные в кластере Amazon DocumentDB из вашего экземпляра EC2. Чтобы увеличить скорость и распараллелить восстановление, используйте эту --numInsertionWorkersPerCollectionопцию. Как правило, установите numInsertionWorkersPerCollection значение в число vcpu на основном экземпляре кластера. Используйте опцию --noIndexRestore, чтобы избежать создания индексов дважды, потому что вы восстановили индексы на предыдущем шаге:

[ec2]$ mongorestore --hostdocdb-cluster-endpoint 
--ssl
--sslCAFile rds-combined-ca-bundle.pem 
--username myuser 
--password mypassword 
--numInsertionWorkersPerCollection 64 
--noIndexRestore <dump_dir>

Если mongodump операция включает все базы данных из исходного кластера MongoDB (например, если --dbпараметр option не указывает отдельную базу данных для дампа), удалите каталог admin из результирующего каталога дампа. В противном случае при попытке восстановления в Amazon DocumentDB возникает ошибка.

Обратите внимание на общую продолжительность восстановления. Размер MongoDB oplog должен быть достаточно большим, чтобы хранить данные в течение этого периода, а также время, необходимое для завершения интерактивной миграции, которую охватывает Шаг 6. Задача AWS DMS CDC использует oplog для репликации данных в Amazon DocumentDB.

  • Выполнение полной загрузки и репликация данных с помощью AWS DMS

AWS DMS-это управляемый сервис, который позволяет эффективно и безопасно переносить базы данных в сервисы AWS. AWS DMS включает миграцию баз данных с помощью двух методов: полной загрузки данных и CDC. Гибридный подход миграции использует CDC для репликации изменений в Amazon DocumentDB. Чтобы выполнить гибридную миграцию, выполните следующие действия:

  1. Создайте экземпляр репликации AWS DMS. Инструкции см. В разделе Работа с экземпляром репликации AWS DMS. Для миграции данных эта должность использует dms.Т2.тип экземпляра средний. AWS DMS использует экземпляр репликации для выполнения задачи, которая переносит данные из источника MongoDB в целевой кластер Amazon DocumentDB. Кроме того, AWS DMS предоставляет бесплатные экземпляры репликации на срок до 6 месяцев для определенных типов экземпляров и целей миграции.
  2. Создайте исходную точку MongoDB и конечные точки Amazon DocumentDB. Дополнительную информацию смотрите в разделе Работа с конечными точками AWS DMS.
  3. Создайте задачу репликации для переноса данных между исходной и целевой конечными точками.
    1. Выберите тип задачи реплицировать только изменения данных.
    2. Включите задачу запуска при создании.
  • Изменение конечной точки приложения на кластер Amazon DocumentDB

После завершения полной загрузки и непрерывной репликации процесса CDC можно изменить строку подключения к базе данных приложения для использования кластера Amazon DocumentDB. Дополнительные сведения см. в разделе Общие сведения о конечных точках Amazon DocumentDB

Источники

  1. Amazon DocumentDB (поддерживает совместимость с MongoDB) // Amazon Web Services. URL: https://aws.amazon.com/ru/documentdb/ (дата обращения: 03.05.2020)
  2. Движение Amazon против MongoDB меня не беспокоит - Инвестирование - 2020 // Capital media communications. URL: https://ru.capitalmediacommunications.com/amazons-move-against-mongodb-doesnt-worry-me-298619 (дата обращения: 03.05.2020)
  3. Amazon DocumentDB Review // The Hotels.com Technology Blog. URL: https://medium.com/hotels-com-technology/amazon-documentdb-review-4754e28ac5d2 (дата обращения: 04.05.2020)
  4. 2019: The year in review for Amazon DocumentDB (with MongoDB compatibility) // Amazon Web Services. URL: https://aws.amazon.com/ru/blogs/database/2019-the-year-in-review-for-amazon-documentdb-with-mongodb-compatibility/ (дата обращения: 04.05.2020)
  5. Evaluating Amazon DocumentDB Compatibility with MongoDB // MongoDB. URL: https://www.mongodb.com/atlas-vs-amazon-documentdb/compatibility (дата обращения: 16.05.2020)
  6. Introducing role-based access control for Amazon DocumentDB (with MongoDB compatibility) // idk.dev. URL: https://idk.dev/introducing-role-based-access-control-for-amazon-documentdb-with-mongodb-compatibility/ (дата обращения: 17.05.2020)
  7. Migrating to Amazon DocumentDB with the hybrid method // Amazon Web Services. URL: https://aws.amazon.com/ru/blogs/database/migrating-to-amazon-documentdb-with-the-hybrid-method/ (дата обращения: 17.05.2020)

Ссылки