1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/openharmony-distributeddatamgr_datamgr_service

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Распределённая система управления данными (DDS)

Введение

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

DDS управляет данными OpenHarmony распределённым образом. Он состоит из следующих частей:

  • Интерфейсы служб

    DDS предоставляет API для других модулей для создания баз данных, доступа к данным и подписки на данные. Поддерживая модель данных KV и общие типы данных, API обладают высокой совместимостью и простотой использования, а также могут быть выпущены.

  • Компонент службы

    Компонент службы управляет метаданными, разрешениями, резервным копированием и восстановлением, а также несколькими пользователями. Он также инициализирует компоненты хранения и синхронизации и уровень адаптации связи распределённой базы данных.

  • Хранилище данных

    Хранилище данных обеспечивает доступ к данным, сокращение данных, транзакции, моментальные снимки, объединение данных и разрешение конфликтов.

  • Синхронизация данных

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

  • Уровень адаптации связи

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

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

Рисунок 1. Как работает DDS

Структура каталогов

/foundation/distributeddatamgr/datamgr_service
├── interfaces                    # APIs
│   └── innerkits                 # Native APIs
│   └── jskits                    # JavaScript APIs
├── services                      # Service code
│   └── distributeddataservice    # DDS implementation
└── test                          # Test case resources

Ограничения

  • Для использования всех функций DDS необходимо получить разрешение ohos.permission.DISTRIBUTED_DATASYNC.

  • DDS поддерживает модель данных KV, но не внешние ключи или триггеры реляционной базы данных.

  • Спецификации модели данных KV, поддерживаемые DDS:

    • для хранилища ключей и значений устройства максимальный размер ключа составляет 896 байт, а значения — 4 МБ;
    • для единого хранилища ключей и значений максимальный размер ключа — 1 КБ, а значения — 4 МБ.
    • каждое приложение может одновременно открывать не более 16 баз данных.
  • DDS не может полностью заменить базу данных в изолированной программной среде службы для хранения данных, поскольку поддерживаемые ими типы хранилищ не полностью совпадают. Необходимо определить данные, подлежащие синхронизации в распределённом режиме, и сохранить их в DDS.

  • В настоящее время DDS... Не допускается настройка политик разрешения конфликтов.

DDS поддерживает максимум 1000 вызовов API KvStore в секунду и 10 000 в минуту. Поддерживается максимум 50 вызовов API KvManager в секунду и 500 в минуту.

Описание

Некоторые основные концепции, связанные с DDS:

  • Модель данных KV

    KV — это сокращение от «ключ-значение». База данных KV — это тип базы данных NoSQL. Данные в этом типе базы данных организованы, проиндексированы и хранятся в виде пар ключ-значение.

    Модель данных KV подходит для хранения служебных данных, которые не включают слишком много данных или служебных отношений. Она обеспечивает лучшую производительность чтения и записи, чем база данных SQL. Модель данных KV широко используется в распределённых сценариях, поскольку она легче справляется с конфликтами в совместимости версий баз данных и синхронизации данных. Распределённая база данных основана на модели данных KV и предоставляет интерфейсы доступа на основе KV.

  • Транзакции распределённой базы данных

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

  • Согласованность распределённой базы данных

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

    • Строгая согласованность: после того как данные вставлены, удалены или обновлены на устройстве, другие устройства в той же сети получат обновлённые данные.
    • Слабая согласованность: после того, как данные вставлены, удалены или обновлены на одном устройстве, другие устройства в той же сети могут получить или не получить обновлённые данные. Время, когда все устройства имеют одни и те же данные, неопределённо.
    • Окончательная согласованность: после того, как данные вставлены, удалены или обновлены на одном устройстве, другие устройства в той же сети могут не сразу получить обновлённые данные. Однако данные на всех устройствах станут согласованными через некоторое время.

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

  • Синхронизация распределённой базы данных

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

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

  • Одно хранилище KV

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

  • Хранилище KV устройства

    Хранилище KV устройства основано на едином хранилище KV и добавляет идентификаторы устройств перед ключами пар ключ-значение. Это гарантирует, что данные, созданные каждым устройством, изолированы друг от друга и централизованно управляются системой. С хранилищем KV устройства вы можете запрашивать данные указанного устройства, но не можете изменять данные, синхронизированные с удалённых устройств.

  • Политика разрешения конфликтов для распределённой базы данных

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

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

Управление базой данных на основе схемы и запрос данных на основе предикатов

При создании или открытии единого хранилища KV можно указать схему. База данных определяет формат значений пар «ключ-значение» на основе схемы и проверяет структуру значения. Кроме того, база данных предоставляет функции создания индекса и запроса на основе предиката на основе полей в значениях.

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

DDS предоставляет возможность резервного копирования базы данных. Установив для параметра backup значение true, вы можете запускать ежедневное резервное копирование базы данных. Если распределённая база данных повреждена, DDS удаляет базу данных и восстанавливает самые последние данные из резервной базы данных. Если резервная база данных недоступна, DDS создаёт её. DDS также может создавать резервные копии зашифрованных баз данных.

Репозитории

Подсистема управления распределёнными данными:

  • distributeddatamgr_datamgr_service;
  • third_party_sqlite.

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Описание недоступно Развернуть Свернуть
Apache-2.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/openharmony-distributeddatamgr_datamgr_service.git
git@api.gitlife.ru:oschina-mirror/openharmony-distributeddatamgr_datamgr_service.git
oschina-mirror
openharmony-distributeddatamgr_datamgr_service
openharmony-distributeddatamgr_datamgr_service
master