【许晓笛】EOS 数据库与持久化 API —— 架构

简介:

EOS 数据库结构详解

在 EOS 中,智能合约执行完毕后,所占用的内存会释放。程序中的所有变量都会丢失。如果智能合约里要持久地记录信息,比如游戏智能合约要记录每位用户游戏记录,本次合约执行完毕后数据不能丢失,就需要将数据存储到 EOS 数据库中。与数据库交互的 API 被官方称为 Persistence API,中文可以叫做持久化 API。下图说明了 EOS 智能合约在执行 Action 时,与数据库的交互过程。

pic1

为了方便智能合约与 EOS 数据库的交互,EOS 仿造了 Boost 库中的 Multi-Index Containers,开发了 C++ 类:eosio::multi_index(以下简称 multi_index`),中文可以叫做多索引列表类。

multi_index 头文件地址:
https://github.com/EOSIO/eos/blob/master/contracts/eosiolib/multi_index.hpp

在 EOS 见证人硬盘中,为每个账户都预留了数据库空间(大小与代币持有量有关),每个账户名下可以建立多个数据表。智能合约无法直接操作存储在见证人硬盘中的数据表,需要使用multi_index作为中间工具(或者叫容器),每个multi_index实例都与一个特定账户的特定数据表进行交互(取决于实例化时的参数)。EOS智能合约与EOS数据库的数据交互如下图所示。

pic2

数据表

multi_index是一个非常方便的数据库交互容器,可以存储任何 C++ 数据类型。每一个multi_index都相当于传统数据库的一个数据表(table),但将传统数据库的行与列的形式改为了单纯的列。也就是说multi_index是一个线性排列的表,只有一列,每一行都只存储一个对象。但是一般来说multi_index存储的对象都是结构体或者类,里面含有多个成员变量,所以multi_index存储数据的灵活性也是不亚于传统数据库的。

我们使用官方的“汽车维修店”示例,我们建立一个数据表,储存每个汽车维修店客户的账户名、保养时间、车辆里程。那么multi_index数据表储存的项目中,每个都是如下的结构体:

struct service_rec {
    uint64_t        pkey;           // 主键
    account_name    customer;       // 车主用户名
    uint32_t        service_date;   // 维修保养时间
    uint32_t        odometer;       // 车辆里程
};

在传统数据库中,需要建立一个 4 列的数据表,用来储存每个用户的这个 4 个数据,而multi_index的每个数据表只有一列,只存储每个用户的 service_rec 整个结构体即可。下图为multi_index数据结构。

pic3

多索引

首先,每个数据表要有一组主键,主键必须是无符号 64 位整数类型(64-bit integer),这就是上面的service_rec结构体中第一个变量为uint64_t类型的原因。在数据表中,所有的对象就是按照主键升序排列的,小的在前,大的在后。主键可以是有意义的,也可以是没有意义的,让系统产生一个在这个数据表中没有被使用的主键即可。为了设置主键,我们需要在之前的service_rec结构体添加一个叫做primary_key()的成员函数函数的返回值为主键。

    auto    primary_key()const { return pkey; }

这样就将pkey这个变量设置成了主键。

multi_index从字面上看就是能使用多个索引的数据表。EOS 中,每个multi_index或者说每个数据表都可以设置最多16个索引。索引相当于使用特定的方式给数据表中的对象重新排序。比如在我们经常使用的 windows 文件管理器中,可以按照文件名排序、按照文件修改时间排序、按照文件大小排序,这就有了3个索引。EOS 数据库索引更加灵活,可以单独按照结构体中的某个变量索引,也可以将变量之间的运算结果(函数输出)进行索引。如果我们想使用车主用户名进行索引,需要在结构体中添加一个get_customer()成员函数,函数的返回值为索引变量。

account_name    get_customer()const { return customer; }

这样就将customer这个变量设置成了数据表的一个索引,下图右侧为customer索引。

pic4

迭代器

multi_index是如何操作数据表中的每个对象的呢?答案是 Iterators(迭代器)。大家可以搜索 “C++ 迭代器”或者设计模式中的“迭代器模式”来了解迭代器的设计思路。在 EOS 数据库中,我更愿意将迭代器比喻为一个“电梯”,在整个数据表中上下穿梭。所有对数据的操作必须通过迭代器完成。典型的数据修改过程是这样的:首先使用迭代器的find()方法,在特定的索引中寻找需要的数据,比如在车主用户名索引中寻找某个用户。迭代器会移动到需要的数据对象上。然后就可以使用迭代器的modify()方法修改当前迭代器对应的数据。下图为迭代器指向用户 Sue 的情况。

pic5

本篇文章介绍了 EOS 数据库的基本结构,以后的文章会详细介绍 EOS 数据库使用实战,敬请期待。

相关文章
|
6天前
|
负载均衡 Java API
构建高效微服务架构:API网关与服务熔断策略
【5月更文挑战第2天】 在微服务架构中,确保系统的高可用性与灵活性是至关重要的。本文将深入探讨如何通过实施有效的API网关和设计合理的服务熔断机制来提升分布式系统的鲁棒性。我们将分析API网关的核心职责,包括请求路由、负载均衡、认证授权以及限流控制,并讨论如何利用熔断器模式防止故障传播,维护系统的整体稳定性。文章还将介绍一些实用的技术和工具,如Netflix Zuul、Spring Cloud Gateway以及Hystrix,以帮助开发者构建一个可靠且高效的微服务环境。
|
9天前
|
运维 负载均衡 监控
软件体系结构 - 关系数据库(3)主从架构
【4月更文挑战第26天】软件体系结构 - 关系数据库(3)主从架构
23 0
|
11天前
|
设计模式 Java API
Java 可扩展 API 设计:打造灵活的应用架构
【4月更文挑战第27天】设计可扩展的 API 是构建灵活、易于维护的应用程序架构的关键。Java 提供了丰富的工具和技术来实现这一目标,使开发者能够构建具有高度可扩展性的应用程序。
32 4
|
13天前
|
缓存 安全 API
构建高效可扩展的RESTful API:后端架构的艺术
【4月更文挑战第25天】 在数字化时代的浪潮中,一个稳定、高效且易于扩展的后端系统是企业成功的关键。本文将探讨如何构建一个满足现代业务需求的RESTful API。我们将深入分析关键设计原则,如模块化、服务分层、缓存策略以及数据库优化,并讨论这些原则如何融入实际开发流程中。通过具体案例和最佳实践,我们的目标是为读者提供一套实用的工具和方法,以支持他们自己的后端开发工作。
|
14天前
|
存储 SQL 数据库
软件体系结构 - 架构风格(10)数据库系统架构风格
【4月更文挑战第21天】软件体系结构 - 架构风格(10)数据库系统架构风格
30 0
|
14天前
|
SQL 关系型数据库 API
从API获取数据并将其插入到PostgreSQL数据库:步骤解析
使用Python处理从API获取的数据并插入到PostgreSQL数据库:安装`psycopg2`,建立数据库连接,确保DataFrame与表结构匹配,然后使用`to_sql`方法将数据插入到已存在的表中。注意数据准备、权限设置、性能优化和安全处理。
|
15天前
|
API 数据库
ionic4 接收API数据库传值并显示
ionic4 接收API数据库传值并显示
23 0
|
23天前
|
监控 JavaScript 安全
构建微服务架构下的API网关
【4月更文挑战第15天】在微服务架构中,API网关扮演着至关重要的角色。它作为系统的唯一入口,不仅负责请求的路由、负载均衡和认证授权,还涉及到监控、日志记录和服务熔断等关键功能。本文将探讨如何构建一个高效且可靠的API网关,涵盖其设计原则、核心组件以及实现策略,旨在为后端开发人员提供一套实用的指导方案。
40 4
|
26天前
|
前端开发 API 数据库
Django(五):如何在Django中通过API提供数据库数据给前端
Django(五):如何在Django中通过API提供数据库数据给前端
|
2月前
|
负载均衡 监控 安全
构建高效微服务架构:API网关的作用与实践
在当今的软件开发中,微服务架构因其灵活性和可扩展性而受到青睐。然而,随之而来的复杂性也给维护和性能带来了挑战。本文探讨了API网关在微服务架构中的关键作用,包括请求路由、负载均衡、安全性控制以及限流熔断等方面。通过具体案例分析,我们展示了如何实现一个高性能的API网关,以支持动态的后端服务,并确保系统的高可用性和安全性。
27 2