总体结构

数据存储是 AiiDA 系统的一个重要方面。该子系统的设计如下图所示。

图 26 存储架构的 UML 图。

蓝色表示前台类，红色表示后台类，绿色表示单子。

每个 Profile 存储不同的数据，形成一个 provenance 图形。Profile 实例代表一个字典，其中包括访问该配置文件存储的配置细节，如数据库 URI 等。多个 Profile 可存储在一个 Config 实例中，该实例存储在配置文件 (config.json) 中。

在单个 Python 进程中，可以加载单个 Manager 实例，以管理对全局加载的 Profile 及其 StorageBackend 实例的访问。

存储 API 子系统基于对象关系映射器（ORM），分为两个主要部分：前台和后台。前端负责用户界面，与任何特定的存储技术无关；后端负责实现与特定技术（如 SQL 数据库）的接口。

前端 ORM

前端 ORM 由多个 Collection 和 Entity 子类组成，代表对单一 ORM 类型的访问。

User

代表某个实体的作者。

Node

代表 provenance 图形中的 node，包含特定进程 (ProcessNode) 或进程输入/输出 (Data) 的数据。Node 由链接连接，形成非循环图。Node 也有一个 Repository 实例，用于存储 node 的二进制数据（另见 存储库）。

Comment

代表某个用户对 node 的评论。

Log

代表特定用户在 ProcessNode 上的日志信息。

Group

代表一组 node。单个 node 可以是多个组的一部分（即 one-to-多关系）。

Computer

代表执行进程的计算资源。一台计算机可连接多个 ProcessNode （即 one-to-多关系）。

AuthInfo

代表特定计算机和用户的身份验证信息。

QueryBuilder 允许查询特定实体及其相关数据。

后台实施

后端实施必须实施 aiida.orm.implementation 中概述的类。

目前有两种核心后台实现方式：

• psql_dos 作为主存储后端实施，参见 psql_dos 格式。

• sqlite_zip 用作 AiiDA 存档的存储后端，参见 sqlite_zip （档案） 格式。

存储维护和配置文件锁定

maintain() 方法允许对存储进行维护操作（例如，优化内存使用），由 verdi storage maintain 调用。

在 “full” 维护期间，为保证其程序的安全，可能有必要禁止其他进程访问存储。get_profile_storage() 内调用 :py:class`~aiida.manage.profile_access.ProfileAccessManager` allows for profile access requests, and locking of profiles during such procedures. request_access()。