OpenHarmony 源码解析之分布式数据库

OpenHarmony 源码解析之分布式数据库

作者:卞绍雷 2021-12-14 10:16:00

系统

分布式 本文基于OpenHarmonyOS 3.0 LTS 来讲解分布式数据服务(Distributed Data Service,DDS) 提供不同设备间数据库数据分布式的能力。

[[440154]]

想了解更多内容,请访问:

51CTO和华为官方合作共建的鸿蒙技术社区

https://harmonyos.IDC.NET

1 简介

本文基于OpenHarmonyOS 3.0 LTS 来讲解分布式数据服务(Distributed Data Service,DDS) 提供不同设备间数据库数据分布式的能力。从架构上来说,分布式数据服务是开源鸿蒙底层服务的基础服务,与分布式任务调度同层。然而在使用分布式任务调度功能时,基本上都需要进一步要求数据交互功能,完成完整的分布式功能,因此在学习分布式任务调度的同时,不可避免的需要学习分布式数据服务相关的功能与底层服务。

本文在写作时,调试JS的DEMO时发现了更底层的方舟JS运行层的BUG,提交了ISSUE,并试图提交了PR。如果大家在运行DEMO时发现问题,请先尝试合并上述PR并重新全部编译系统并刷机再试。

1.1 分布式相关

  • 《OpenHarmony 源码解析之分布式任务调度》
  • 《OpenHarmony 源码解析之分布式数据库》

1.2 OpenHarmony架构图

2 基础知识

2.1 概述

先看开源鸿蒙官方文档对分布式数据服务的描述:

分布式数据服务(Distributed Data Service,DDS) 提供不同设备间数据库数据分布式的能力。通过结合帐号、应用和数据库三元组,分布式数据服务对数据进行隔离。在通过可信认证的设备间,分布式数据服务支持数据相互同步,为用户提供在多种终端设备上一致的数据访问体验。

目前开源鸿蒙还没有整合账号功能,因此测试的时候账号可以自由选择,填写一致即可。应用和数据库则必须保持一致,才能进行完整的分布式数据数据隔离,提供数据在多种终端设备上一致的访问体验。

2.2 源码结构

  1. ├── BUILD.gn 
  2. ├── figures 
  3. │   ├── en-us_image_0000001162536643.png 
  4. │   └── zh-cn_image_0000001162536643.png 
  5. ├── frameworks 
  6. │   ├── innerkitsimpl 
  7. │   │   └── distributeddatafwk # 框架层实现 
  8. │   │       ├── include 
  9. │   │       ├── src 
  10. │   │       └── test 
  11. │   └── jskitsimpl 
  12. │       └── distributeddata    # JS接口实现 
  13. │           ├── include 
  14. │           └── src 
  15. ├── interfaces 
  16. │   ├── innerkits                # 内部接口,主要是头文件 
  17. │   │   ├── app_distributeddata  
  18. │   │   │   ├── BUILD.gn 
  19. │   │   │   └── include 
  20. │   │   └── distributeddata 
  21. │   │       ├── BUILD.gn 
  22. │   │       └── include 
  23. │   └── jskits                   # JS接口,BUILD用 
  24. │       └── distributeddata 
  25. │           └── BUILD.gn 
  26. ├── LICENSE 
  27. ├── OAT.xml 
  28. ├── ohos.build 
  29. ├── README.md 
  30. ├── README_zh.md 
  31. ├── services 
  32. │   └── distributeddataservice 
  33. │       ├── adapter              # 适配实现 
  34. │       │   ├── account          # 账号适配 
  35. │       │   ├── autils           # 实用库,包括任务、线程、目录等 
  36. │       │   ├── broadcaster      # 发送广播 
  37. │       │   ├── BUILD.gn 
  38. │       │   ├── communicator     # 通讯适配 
  39. │       │   ├── dfx              # 日志、统计、错误等相关处理 
  40. │       │   ├── include 
  41. │       │   ├── LICENSE 
  42. │       │   ├── permission        # 权限 
  43. │       │   ├── security          # 安全相关 
  44. │       │   ├── test 
  45. │       │   └── utils 
  46. │       ├── app                   # 用户程序实现 
  47. │       ├── libs 
  48. │       │   └── distributeddb 
  49. │       │       ├── BUILD.gn 
  50. │       │       ├── common 
  51. │       │       ├── communicator  # 设备间通讯 
  52. │       │       ├── include 
  53. │       │       ├── interfaces 
  54. │       │       ├── storage   # 存储实现,包括单版本KV、多版本KV、SQLITE3等 
  55. │       │       ├── syncer    # 同步 
  56. │       │       └── test 
  57. │       ├── sa_profile 
  58. │       └── test 
  59. └── test 

2.3 分布式数据服务架构设计图

2.4 数据同步

官方文档是这么描述的:

通过调用分布式数据服务接口实现分布式数据库创建、访问、订阅功能,服务接口通过操作服务组件提供的能力,将数据存储至存储组件,存储组件调用同步组件实现将数据同步,同步组件使用通信适配层将数据同步至远端设备,远端设备通过同步组件接收数据,并更新至本端存储组件。

2.5 分布式数据

最终一致性:是指某一设备成功增、删、改数据后,组网内设备可能读取不到本次更新数据,但在某个时间窗口之后组网内设备的数据能够达到一致状态。

强一致性对分布式数据的管理要求非常高,在服务器的分布式场景可能会遇到。因为移动终端设备的不常在线、以及无中心的特性,分布式数据服务不支持强一致,只支持最终一致性。

目前分布式数据的数据模型仅支持KV数据模型,不支持外键、触发器等关系型数据库中的技术点。虽然开源鸿蒙底层支持基于SQLITE3的关系型数据库,但是并不在分布式数据层面支持。

当前KV数据模型的限制:

  • 设备协同数据库,Key最大支持896Byte,Value最大支持4MB。
  • 单版本数据库,Key最大支持1KB,Value最大支持4MB。
  • 每个程序最多支持同时打开16个DB。
  • 当前流控机制针对KvStore的接口1秒最大访问1000次,1分钟最大访问10000次。
  • KvManager的接口1秒最大访问50次,1分钟最大访问500次。

2.6 使用前提

从开源鸿蒙的分布式数据源代码中,可以看到目前只有手机(phone)、穿戴式设备(wearable)、车载系统(ivi)会搭载,其它更轻量的设备可能暂时不支持,或者需要剪裁定制支持。

目前在两台标准设备的开源系统鸿蒙上,是默认集成了该功能,可以直接使用的。

开源鸿蒙的分布式数据如果只在单机使用,那么无需前提条件。如果需要其分布式功能,那么就需要设备之间完成组网;而组网的前提条件是完成设备认证。具体步骤,请参考OpenHarmony 源码解析之分布式任务调度。

3 编程接口

3.1 导入模块

  1. import distributedData from '@ohos.data.distributedData'

 下面各个接口大多有callback和promise两种异步方式,本文均以promise方式为例,callback方式大同小异,请自行查阅文档。

3.2 创建管理器

  1. distributedData.createKVManager 
  2. createKVManager(config: KVManagerConfig, callback: AsyncCallback<KVManager>): void 
  3. createKVManager(config: KVManagerConfig): Promise<KVManager> 

 创建一个KVManager对象实例,用于管理数据库对象,并通过Promise方式返回,此方法为异步方法。

示例:

  1. let kvManager; 
  2. try { 
  3.     const kvManagerConfig = { 
  4.         bundleName : 'com.example.datamanagertest'
  5.         userInfo : { 
  6.             userId : '0'
  7.             userType : 0 
  8.         } 
  9.     } 
  10.     distributedData.createKVManager(kvManagerConfig).then((manager) => { 
  11.         console.log("createKVManager success"); 
  12.         kvManager = manager; 
  13.     }).catch((err) => { 
  14.         console.log("createKVManager err: "  + JSON.stringify(err)); 
  15.     }); 
  16. } catch (e) { 
  17.     console.log("An unexpected error occurred. Error:" + e); 

3.3 获取存储实例

  1. kvManager.getKVStore 
  2. getKVStore<T extends KVStore>(storeId: string, options: Options): Promise<T> 

通过指定Options和storeId,创建并获取KVStore数据库,并通过Promise方式返回,此方法为异步方法。

示例:

  1. let kvStore; 
  2. try { 
  3.     const options = { 
  4.         createIfMissing : true
  5.         encrypt : false
  6.         backup : false
  7.         autoSync : true, //手动同步、自动同步 
  8.         kvStoreType : 1, //当前只能使用0(默认):表示多设备协同数据库,1:单版本数据库 
  9.         securityLevel : 3, 
  10.     }; 
  11.     kvManager.getKVStore('storeId', options).then((store) => { 
  12.         console.log("getKVStore success"); 
  13.         kvStore = store; 
  14.     }).catch((err) => { 
  15.         console.log("getKVStore err: "  + JSON.stringify(err)); 
  16.     }); 
  17. } catch (e) { 
  18.     console.log("An unexpected error occurred. Error:" + e); 

3.4 存、取、删除、同步

  1. kvStore.put(key: string, value: Uint8Array | string | number | boolean): Promise<void> 
  2. kvStore.get(key: string): Promise<Uint8Array | string | boolean | number> 
  3. kvStore.delete(key: string): Promise<void> 
  4. kvStore.sync(deviceIdList: string[], mode: SyncMode, allowedDelayMs?: number): void 

3.5 注册事件通知回调

SubscribeType 描述订阅类型。

  • 0: SUBSCRIBE_TYPE_LOCAL 表示订阅本地数据变更。
  • 1: SUBSCRIBE_TYPE_REMOTE 表示订阅远端数据变更。
  • 2: SUBSCRIBE_TYPE_ALL 表示订阅远端和本地数据变更。
  1. kvStore.on(event: 'dataChange', type: SubscribeType, observer: Callback<ChangeNotification>): void 
  2. kvStore.on(event: 'syncComplete', syncCallback: Callback<Array<[string, number]>>): void 

4 小结

以上步骤,均已在DevEco Studio 3.0.0.600 x64中编写成功,并且在两台Hi3516D设备间成功运行,附代码(分布式任务调度和分布式数据测试.zip)。

再次提醒,分布式数据底层依赖ARK JS引擎,目前发现字符串处理有BUG,如运行出现问题,请先合并PR,然后重新编译全系统并刷机后再运行DEMO。

想了解更多内容,请访问:

51CTO和华为官方合作共建的鸿蒙技术社区

https://harmonyos.IDC.NET

 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/259122.html<

(0)
管理的头像管理
上一篇2025-05-02 13:26
下一篇 2025-05-02 13:27

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注