边缘数据库

① 互联网如何海量存储数据

目前存储海量数据的技术主要包括NoSQL、分布式文件系统、和传统关系型数据库。随着互联网行业不断的发展，产生的数据量越来越多，并且这些数据的特点是半结构化和非结构化，数据很可能是不精确的，易变的。这样传统关系型数据库就无法发挥它的优势。因此，目前互联网行业偏向于使用NoSQL和分布式文件系统来存储海量数据。

下面介绍下常用的NoSQL和分布式文件系统。
NoSQL
互联网行业常用的NoSQL有：HBase、MongoDB、Couchbase、LevelDB。

HBase是Apache Hadoop的子项目,理论依据为Google论文 Bigtable: A Distributed Storage System for Structured Data开发的。HBase适合存储半结构化或非结构化的数据。HBase的数据模型是稀疏的、分布式的、持久稳固的多维map。HBase也有行和列的概念，这是与RDBMS相同的地方，但却又不同。HBase底层采用HDFS作为文件系统，具有高可靠性、高性能。

MongoDB是一种支持高性能数据存储的开源文档型数据库。支持嵌入式数据模型以减少对数据库系统的I/O、利用索引实现快速查询，并且嵌入式文档和集合也支持索引，它复制能力被称作复制集（replica set），提供了自动的故障迁移和数据冗余。MongoDB的分片策略将数据分布在服务器集群上。

Couchbase这种NoSQL有三个重要的组件：Couchbase服务器、Couchbase Gateway、Couchbase Lite。Couchbase服务器，支持横向扩展，面向文档的数据库，支持键值操作，类似于SQL查询和内置的全文搜索;Couchbase Gateway提供了用于RESTful和流式访问数据的应用层API。Couchbase Lite是一款面向移动设备和“边缘”系统的嵌入式数据库。Couchbase支持千万级海量数据存储
分布式文件系统
如果针对单个大文件，譬如超过100MB的文件，使用NoSQL存储就不适当了。使用分布式文件系统的优势在于，分布式文件系统隔离底层数据存储和分布的细节，展示给用户的是一个统一的逻辑视图。常用的分布式文件系统有Google File System、HDFS、MooseFS、Ceph、GlusterFS、Lustre等。

相比过去打电话、发短信、用彩铃的“老三样”，移动互联网的发展使得人们可以随时随地通过刷微博、看视频、微信聊天、浏览网页、地图导航、网上购物、外卖订餐等，这些业务的海量数据都构建在大规模网络云资源池之上。当14亿中国人把衣食住行搬上移动互联网的同时，也给网络云资源池带来巨大业务挑战。

首先，用户需求动态变化，传统业务流量主要是端到端模式，较为稳定；而互联网流量易受热点内容牵引，数据流量流向复杂和规模多变：比如双十一购物狂潮，电商平台订单创建峰值达到58.3万笔，要求通信网络提供高并发支持；又如优酷春节期间有超过23亿人次上网刷剧、抖音拜年短视频增长超10倍，需要通信网络能够灵活扩充带宽。面对用户动态多变的需求，通信网络需要具备快速洞察和响应用户需求的能力，提供高效、弹性、智能的数据服务。

“随着通信网络管道十倍百倍加粗、节点数从千万级逐渐跃升至百亿千亿级，如何‘接得住、存得下’海量数据，成为网络云资源池建设面临的巨大考验”，李辉表示。一直以来，作为新数据存储首倡者和引领者，浪潮存储携手通信行业用户，不断 探索 提速通信网络云基础设施的各种姿势。

早在2018年，浪潮存储就参与了通信行业基础设施建设，四年内累计交付约5000套存储产品，涵盖全闪存储、高端存储、分布式存储等明星产品。其中在网络云建设中，浪潮存储已连续两年两次中标全球最大的NFV网络云项目，其中在网络云二期建设中，浪潮存储提供数千节点，为上层网元、应用提供高效数据服务。在最新的NFV三期项目中，浪潮存储也已中标。

能够与通信用户在网络云建设中多次握手，背后是浪潮存储的持续技术投入与创新。浪潮存储6年内投入超30亿研发经费，开发了业界首个“多合一”极简架构的浪潮并行融合存储系统。此存储系统能够统筹管理数千个节点，实现性能、容量线性扩展；同时基于浪潮iTurbo智能加速引擎的智能IO均衡、智能资源调度、智能元数据管理等功能，与自研NVMe SSD闪存盘进行系统级别联调优化，让百万级IO均衡落盘且路径更短，将存储系统性能发挥到极致。

“为了确保全球最大规模的网络云正常上线运行，我们联合用户对存储集群展开了长达数月的魔鬼测试”，浪潮存储工程师表示。网络云的IO以虚拟机数据和上层应用数据为主，浪潮按照每个存储集群支持15000台虚机进行配置，分别对单卷随机读写、顺序写、混合读写以及全系统随机读写的IO、带宽、时延等指标进行了360无死角测试，达到了通信用户提出的单卷、系统性能不低于4万和12万IOPS、时延小于3ms的要求，产品成熟度得到了验证。

以通信行业为例，2020年全国移动互联网接入流量1656亿GB，相当于中国14亿人每人消耗118GB数据；其中春节期间，移动互联网更是创下7天消耗36亿GB数据流量的记录，还“捎带”打了548亿分钟电话、发送212亿条短信……海量实时数据洪流，在网络云资源池(NFV)支撑下收放自如，其中分布式存储平台发挥了作用。如此样板工程，其巨大示范及拉动作用不言而喻。

② NoSQL会取代SQL数据库吗

对此，前Google工程师，Milo（本地商店搜索引擎）创始人Ted Dziuba最近发表标题惊人的博客“I Can't Wait for NoSQL to Die”，对NoSQL的适用范围进行了分析。他认为，
NoSQL也会带来一连串的新问题，并不会成为主流，无法取代关系型数据库。
他的理由是：Cassandra等NoSQL数据库在使用上并不方便，比如，修改column family定义时就需要重启。而且NoSQL更适合Google那样的规模，而一般的互联网公司都不是Google，早早地去考虑Google那样的规模的可扩展性，纯粹是浪费时间，存在巨大的商业风险。
他还透露，即使在Google，AdWords这样的关键产品也是基于MySQL实现的。
他在文中最后表示，NoSQL当然死不了，但是
它最终会被边缘化，就像Rails被NoSQL边缘化一样
Dziuba的文章因为言辞激烈，在社区里引起了强烈反应。
SQL数据库阵营赞同者大有人在。craigslist工程师、着名的MySQL专家Jeremy Zawodny表示，在读此文的时候，不时会心一笑。他说，
NoSQL运动只是软件不断进化进程中的正常现象
。关系型数据库也会继续发展，MySQL社区不断推出的XtraDB或InnoDB插件, PBXT, Drizzle都是证据。各种技术竞争的结果是，我们获得了更多解决问题的选择。
drizzle项目开发者Eric Day也表示，NoSQL有很多值得学习的，但是目前大部分实际项目的最佳选择还是关系型数据库。
NoSQL阵营当然不会坐视不理，Cassandra项目组的Eric Evans表示，Dziuba提到Cassandra修改column family定义的问题其实很容易解决。而且，NoSQL并不是要取代MySQL，事实上Twitter仍然在用MySQL。如果关系型数据库能够承担负荷，那就用好了；如果不行，请考虑NoSQL。
而德国知名博客Code Monkeyism则嘲笑Dziuba看起来并没有用MySQL做过真实项目，因为MySQL如果没有memcache，基本上无法应付网站项目。他认为，NoSQL将使SQL数据库边缘化，而且一个重要理由恰恰是可以节省DBA的开销。
digg的前任首席架构师现在也在创业的Joe Stump说，自己现在的创业项目就是用NoSQL，而且列举了一系列问题挑战SQL阵营。

③ 我想查中文文献，请问常用数据库有哪些

国内3大中文文献数据库系统：中国知网、万方、中国期刊网。

万方数据资源系统(China Info)由中国科技信息研究所，万方数据股份有限公司研制。该数据库收录的期刊学科范围广，包括了学术期刊于非学术期刊，提供约2 000种的电子期刊的全文检索。

被收录的学术期刊都获得了“中国核心期刊(遴选)数据库来源期刊”的收录证书。个别期刊甚至将“遴选”改成“精选”，或者干脆去掉。很多作者因此误以为这就是核心期刊。

中国知网收录1994年以来国内6 600种期刊,包括了学术期刊于非学术期刊,涵盖理工、农业、医药卫生、文史哲、政治军事与法律、教育与社会科学综合、电子技术与信息科学、经济与管理。

收录的学术期刊同时作为“中国学术期刊综合评价数据库统计源期刊”。但是收录的期刊不很全面,一些重要期刊未能收录。

(3)边缘数据库扩展阅读：

多次引用的文献，每处的页码或页码范围（有的刊物也将能指示引用文献位置的信息视为页码）分别列于每处参考文献的序号标注处，置于方括号后（仅列数字，不加“p”或“页”等前后文字、字符）并作上标。

所列参考文献的要求是：

1、所列参考文献应是正式出版物，以便读者考证。

2、所列举的参考文献要标明序号、着作或文章的标题、作者、出版物信息。

④ 如何用 Python 实现一个图数据库（Graph Database）

本文章是 重写 500 Lines or Less 系列的其中一篇，目标是重写 500 Lines or Less 系列的原有项目：Dagoba: an in-memory graph database。

Dagoba 是作者设计用来展示如何从零开始自己实现一个图数据库（ Graph Database ）。该名字似乎来源于作者喜欢的一个乐队，另一个原因是它的前缀 DAG 也正好是有向无环图 （ Directed Acyclic Graph ） 的缩写。本文也沿用了该名称。

图是一种常见的数据结构，它将信息描述为若干独立的节点（ vertex ，为了和下文的边更加对称，本文中称为 node ），以及把节点关联起来的边（ edge ）。我们熟悉的链表以及多种树结构可以看作是符合特定规则的图。图在路径选择、推荐算法以及神经网络等方面都是重要的核心数据结构。

既然图的用途如此广泛，一个重要的问题就是如何存储它。如果在传统的关系数据库中存储图，很自然的做法就是为节点和边各自创建一张表，并用外键把它们关联起来。这样的话，要查找某人所有的子女，就可以写下类似下面的查询：

还好，不算太复杂。但是如果要查找孙辈呢？那恐怕就要使用子查询或者 CTE(Common Table Expression) 等特殊构造了。再往下想，曾孙辈又该怎么查询？孙媳妇呢？

这样我们会意识到，SQL 作为查询语言，它只是对二维数据表这种结构而设计的，用它去查询图的话非常笨拙，很快会变得极其复杂，也难以扩展。针对图而言，我们希望有一种更为自然和直观的查询语法，类似这样：

为了高效地存储和查询图这种数据结构，图数据库（ Graph Database ）应运而生。因为和传统的关系型数据库存在极大的差异，所以它属于新型数据库也就是 NoSql 的一个分支（其他分支包括文档数据库、列数据库等）。图数据库的主要代表包括 Neo4J 等。本文介绍的 Dagoba 则是具备图数据库核心功能、主要用于教学和演示的一个简单的图数据库。

原文代码是使用 JavaScript 编写的，在定义调用接口时大量使用了原型（ prototype ）这种特有的语言构造。对于其他主流语言的用户来说，原型的用法多少显得有些别扭和不自然。

考虑到本系列其他数据库示例大多是用 Python 实现的，本文也按照传统，用 Python 重写了原文的代码。同样延续之前的惯例，为了让读者更好地理解程序是如何逐步完善的，我们用迭代式的方法完成程序的各个组成部分。

原文在 500lines 系列的 Github 仓库中只包含了实现代码，并未包含测试。按照代码注释说明，测试程序位于作者的另一个代码库中，不过和 500lines 版本的实现似乎略有不同。

本文实现的代码参考了原作者的测试内容，但跳过了北欧神话这个例子——我承认确实不熟悉这些神祇之间的亲缘关系，相信中文背景的读者们多数也未必了解，虽然作者很喜欢这个例子，想了想还是不要徒增困惑吧。因此本文在编写测试用例时只参考了原文关于家族亲属的例子，放弃了神话相关的部分，尽管会减少一些趣味性，相信对于入门级的代码来说这样也够用了。

本文实现程序位于代码库的 dagoba 目录下。按照本系列程序的同意规则，要想直接执行各个已完成的步骤，读者可以在根目录下的 main.py 找到相应的代码位置，取消注释并运行即可。

本程序的所有步骤只需要 Python3 ，测试则使用内置的 unittest , 不需要额外的第三方库。原则上 Python3.6 以上版本应该都可运行，但我只在 Python3.8.3 环境下完整测试过。

本文实现的程序从最简单的案例开始，通过每个步骤逐步扩展，最终形成一个完整的程序。这些步骤包括：

接下来依次介绍各个步骤。

回想一下，图数据库就是一些点（ node ）和边（ edge ）的集合。现在我们要做出的一个重大决策是如何对节点/边进行建模。对于边来说，必须指定它的关联关系，也就是从哪个节点指向哪个节点。大多数情况下边是有方向的——父子关系不指明方向可是要乱套的！

考虑到扩展性及通用性问题，我们可以把数据保存为字典（ dict ），这样可以方便地添加用户需要的任何数据。某些数据是为数据库内部管理而保留的，为了明确区分，可以这样约定：以下划线开头的特殊字段由数据库内部维护，类似于私有成员，用户不应该自己去修改它们。这也是 Python 社区普遍遵循的约定。

此外，节点和边存在互相引用的关系。目前我们知道边会引用到两端的节点，后面还会看到，为了提高效率，节点也会引用到边。如果仅仅在内存中维护它们的关系，那么使用指针访问是很直观的，但数据库必须考虑到序列化到磁盘的问题，这时指针就不再好用了。

为此，最好按照数据库的一般要求，为每个节点维护一个主键（ _id ），用主键来描述它们之间的关联关系。

我们第一步要把数据库的模型建立起来。为了测试目的，我们使用一个最简单的数据库模型，它只包含两个节点和一条边，如下所示：

按照 TDD 的原则，首先编写测试：

与原文一样，我们把数据库管理接口命名为 Dagoba 。目前，能够想到的最简单的测试是确认节点和边是否已经添加到数据库中：

assert_item 是一个辅助方法，用于检查字典是否包含预期的字段。相信大家都能想到该如何实现，这里就不再列出了，读者可参考 Github 上的完整源码。

现在，测试是失败的。用最简单的办法实现数据库：

需要注意的是，不管添加节点还是查询，程序都使用了拷贝后的数据副本，而不是直接使用原始数据。为什么要这样做？因为字典是可变的，用户可以在任何时候修改其中的内容，如果数据库不知道数据已经变化，就很容易发生难以追踪的一致性问题，最糟糕的情况下会使得数据内容彻底混乱。

拷贝数据可以避免上述问题，代价则是需要占用更多内存和处理时间。对于数据库来说，通常查询次数要远远多于修改，所以这个代价是可以接受的。

现在测试应该正常通过了。为了让它更加完善，我们可以再测试一些边缘情况，看看数据库能否正确处理异常数据，比如：

例如，如果用户尝试添加重复主键，我们预期应抛出 ValueError 异常。因此编写测试如下：

为了满足以上测试，代码需要稍作修改。特别是按照 id 查找主键是个常用操作，通过遍历的方法效率太低了，最好是能够通过主键直接访问。因此在数据库中再增加一个字典：

完整代码请参考 Github 仓库。

在上个步骤，我们在初始化数据库时为节点明确指定了主键。按照数据库设计的一般原则，主键最好是不具有业务含义的代理主键（ Surrogate key ），用户不应该关心它具体的值是什么，因此让数据库去管理主键通常是更为合理的。当然，在部分场景下——比如导入外部数据——明确指定主键仍然是有用的。

为了同时支持这些要求，我们这样约定：字段 _id 表示节点的主键，如果用户指定了该字段，则使用用户设置的值（当然，用户有责任保证它们不会重复）；否则，由数据库自动为它分配一个主键。

如果主键是数据库生成的，事先无法预知它的值是什么，而边（ edge ）必须指定它所指向的节点，因此必须在主键生成后才能添加。由于这个原因，在动态生成主键的情况下，数据库的初始化会略微复杂一些。还是先写一个测试：

为支持此功能，我们在数据库中添加一个内部字段 _next_id 用于生成主键，并让 add_node 方法返回新生成的主键：

接下来，再确认一下边是否可以正常访问：

运行测试，一切正常。这个步骤很轻松地完成了，不过两个测试（ DbModelTest 和 PrimaryKeyTest ）出现了一些重复代码，比如 get_item 。我们可以把这些公用代码提取出来。由于 get_item 内部调用了 TestCase.assertXXX 等方法，看起来应该使用继承，但从 TestCase 派生基类容易引起一些潜在的问题，所以我转而使用另一个技巧 Mixin ：

实现数据库模型之后，接下来就要考虑如何查询它了。

在设计查询时要考虑几个问题。对于图的访问来说，几乎总是由某个节点（或符合条件的某一类节点）开始，从与它相邻的边跳转到其他节点，依次类推。所以链式调用对查询来说是一种很自然的风格。举例来说，要知道 Tom 的孙子养了几只猫，可以使用类似这样的查询：

可以想象，以上每个方法都应该返回符合条件的节点集合。这种实现是很直观的，不过存在一个潜在的问题：很多时候用户只需要一小部分结果，如果它总是不计代价地给我们一个巨大的集合，会造成极大的浪费。比如以下查询：

为了避免不必要的浪费，我们需要另外一种机制，也就是通常所称的“懒式查询”或“延迟查询”。它的基本思想是，当我们调用查询方法时，它只是把查询条件记录下来，而并不立即返回结果，直到明确调用某些方法时才真正去查询数据库。

如果读者比较熟悉流行的 Python ORM，比如 SqlAlchemy 或者 Django ORM 的话，会知道它们几乎都是懒式查询的，要调用 list(result) 或者 result[0:10] 这样的方法才能得到具体的查询结果。

在 Dagoba 中把触发查询的方法定义为 run 。也就是说，以下查询执行到 run 时才真正去查找数据：

和懒式查询（ Lazy Query ）相对应的，直接返回结果的方法一般称作主动查询（ Eager Query ）。主动查询和懒式查询的内在查找逻辑基本上是相同的，区别只在于触发机制不同。由于主动查询实现起来更加简单，出错也更容易排查，因此我们先从主动查询开始实现。

还是从测试开始。前面测试所用的简单数据库数据太少，难以满足查询要求，所以这一步先来创建一个更复杂的数据模型：

此关系的复杂之处之一在于反向关联：如果 A 是 B 的哥哥，那么 B 就是 A 的弟弟/妹妹，为了查询到他们彼此之间的关系，正向关联和反向关联都需要存在，因此在初始化数据库时需要定义的边数量会很多。

当然，父子之间也存在反向关联的问题，为了让问题稍微简化一些，我们目前只需要向下（子孙辈）查找，可以稍微减少一些关联数量。

因此，我们定义数据模型如下。为了减少重复工作，我们通过 _backward 字段定义反向关联，而数据库内部为了查询方便，需要把它维护成两条边：

然后，测试一个最简单的查询，比如查找某人的所有孙辈：

这里 outcome/income 分别表示从某个节点出发、或到达它的节点集合。在原作者的代码中把上述方法称为 out/in 。当然这样看起来更加简洁，可惜的是 in 在 Python 中是个关键字，无法作为函数名。我也考虑过加个下划线比如 out_.in_ 这种形式，但看起来也有点怪异，权衡之后还是使用了稍微啰嗦一点的名称。

现在我们可以开始定义查询接口了。在前面已经说过，我们计划分别实现两种查询，包括主动查询（ Eager Query ）以及延迟查询（ Lazy Query ）。

它们的内在查询逻辑是相通的，看起来似乎可以使用继承。不过遵循 YAGNI 原则，目前先不这样做，而是只定义两个新类，在满足测试的基础上不断扩展。以后我们会看到，与继承相比，把共同的逻辑放到数据库本身其实是更为合理的。

接下来实现访问节点的方法。由于 EagerQuery 调用查询方法会立即返回结果，我们把结果记录在 _result 内部字段中。虽然 node 方法只返回单个结果，但考虑到其他查询方法几乎都是返回集合，为统一起见，让它也返回集合，这样可以避免同时支持集合与单结果的分支处理，让代码更加简洁、不容易出错。此外，如果查询对象不存在的话，我们只返回空集合，并不视为一个错误。

查询输入/输出节点的方法实现类似这样：

查找节点的核心逻辑在数据库本身定义：

以上使用了内部定义的一些辅助查询方法。用类似的逻辑再定义 income ，它们的实现都很简单，读者可以直接参考源码，此处不再赘述。

在此步骤的最后，我们再实现一个优化。当多次调用查询方法后，结果可能会返回重复的数据，很多时候这是不必要的。就像关系数据库通常支持 unique/distinct 一样，我们也希望 Dagoba 能够过滤重复的数据。

假设我们要查询某人所有孩子的祖父，显然不管有多少孩子，他们的祖父应该是同一个人。因此编写测试如下：

现在来实现 unique 。我们只要按照主键把重复数据去掉即可：

在上个步骤，初始化数据库指定了双向关联，但并未测试它们。因为我们还没有编写代码去支持它们，现在增加一个测试，它应该是失败的：

运行测试，的确失败了。我们看看要如何支持它。回想一下，当从边查找节点时，使用的是以下方法：

这里也有一个潜在的问题：调用 self.edges 意味着遍历所有边，当数据库内容较多时，这是巨大的浪费。为了提高性能，我们可以把与节点相关的边记录在节点本身，这样要查找边只要看节点本身即可。在初始化时定义出入边的集合：

在添加边时，我们要同时把它们对应的关系同时更新到节点，此外还要维护反向关联。这涉及对字典内容的部分复制，先编写一个辅助方法：

然后，将添加边的实现修改如下：

这里的代码同时添加正向关联和反向关联。有的朋友可能会注意到代码略有重复，是的，但是重复仅出现在该函数内部，本着“三则重构”的原则，暂时不去提取代码。

实现之后，前面的测试就可以正常通过了。

在这个步骤中，我们来实现延迟查询（ Lazy Query ）。

延迟查询的要求是，当调用查询方法时并不立即执行，而是推迟到调用特定方法，比如 run 时才执行整个查询，返回结果。

延迟查询的实现要比主动查询复杂一些。为了实现延迟查询，查询方法的实现不能直接返回结果，而是记录要执行的动作以及传入的参数，到调用 run 时再依次执行前面记录下来的内容。

如果你去看作者的实现，会发现他是用一个数据结构记录执行操作和参数，此外还有一部分逻辑用来分派对每种结构要执行的动作。这样当然是可行的，但数据处理和分派部分的实现会比较复杂，也容易出错。

本文的实现则选择了另外一种不同的方法：使用 Python 的内部函数机制，把一连串查询变换成一组函数，每个函数取上个函数的执行结果作为输入，最后一个函数的输出就是整个查询的结果。由于内部函数同时也是闭包，尽管每个查询的参数形式各不相同，但是它们都可以被闭包“捕获”而成为内部变量，所以这些内部函数可以采用统一的形式，无需再针对每种查询设计额外的数据结构，因而执行过程得到了很大程度的简化。

首先还是来编写测试。 LazyQueryTest 和 EagerQueryTest 测试用例几乎是完全相同的（是的，两种查询只在于内部实现机制不同，它们的调用接口几乎是完全一致的）。

因此我们可以把 EagerQueryTest 的测试原样不变拷贝到 LazyQueryTest 中。当然拷贝粘贴不是个好注意，对于比较冗长而固定的初始化部分，我们可以把它提取出来作为两个测试共享的公共函数。读者可参考代码中的 step04_lazy_query/tests/test_lazy_query.py 部分。

程序把查询函数的串行执行称为管道（ pipeline ），用一个变量来记录它：

然后依次实现各个调用接口。每种接口的实现都是类似的：用内部函数执行真正的查询逻辑，再把这个函数添加到 pipeline 调用链中。比如 node 的实现类似下面：

其他接口的实现也与此类似。最后， run 函数负责执行所有查询，返回最终结果；

完成上述实现后执行测试，确保我们的实现是正确的。

在前面我们说过，延迟查询与主动查询相比，最大的优势是对于许多查询可以按需要访问，不需要每个步骤都返回完整结果，从而提高性能，节约查询时间。比如说，对于下面的查询：

以上查询的意思是从孙辈中找到一个符合条件的节点即可。对该查询而言，主动查询会在调用 outcome('son') 时就遍历所有节点，哪怕最后一步只需要第一个结果。而延迟查询为了提高效率，应在找到符合条件的结果后立即停止。

目前我们尚未实现 take 方法。老规矩，先添加测试：

主动查询的 take 实现比较简单，我们只要从结果中返回前 n 条记录：

延迟查询的实现要复杂一些。为了避免不必要的查找，返回结果不应该是完整的列表（ list ），而应该是个按需返回的可迭代对象，我们用内置函数 next 来依次返回前 n 个结果：

写完后运行测试，确保它们是正确的。

从外部接口看，主动查询和延迟查询几乎是完全相同的，所以用单纯的数据测试很难确认后者的效率一定比前者高，用访问时间来测试也并不可靠。为了测试效率，我们引入一个节点访问次数的概念，如果延迟查询效率更高的话，那么它应该比主动查询访问节点的次数更少。

为此，编写如下测试：

我们为 Dagoba 类添加一个成员来记录总的节点访问次数，以及两个辅助方法，分别用于获取和重置访问次数：

然后浏览代码，查找修改点。增加计数主要在从边查找节点的时候，因此修改部分如下：

此外还有 income/outcome 方法，修改都很简单，这里就不再列出。

实现后再次运行测试。测试通过，表明延迟查询确实在效率上优于主动查询。

不像关系数据库的结构那样固定，图的形式可以千变万化，查询机制也必须足够灵活。从原理上讲，所有查询无非是从某个节点出发按照特定方向搜索，因此用 node/income/outcome 这三个方法几乎可以组合出任意所需的查询。

但对于复杂查询，写出的代码有时会显得较为琐碎和冗长，对于特定领域来说，往往存在更为简洁的名称，例如：母亲的兄弟可简称为舅舅。对于这些场景，如果能够类似 DSL （领域特定语言）那样允许用户根据专业要求自行扩展，从而简化查询，方便阅读，无疑会更为友好。

如果读者去看原作者的实现，会发现他是用一种特殊语法 addAlias 来定义自己想要的查询，调用方法时再进行查询以确定要执行的内容，其接口和内部实现都是相当复杂的。

而我希望有更简单的方法来实现这一点。所幸 Python 是一种高度动态的语言，允许在运行时向类中增加新的成员，因此做到这一点可能比预想的还要简单。

为了验证这一点，编写测试如下：

无需 Dagoba 的实现做任何改动，测试就可以通过了！其实我们要做的就是动态添加一个自定义的成员函数，按照 Python 对象机制的要求，成员函数的第一个成员应该是名为 self 的参数，但这里已经是在 UnitTest 的内部，为了和测试类本身的 self 相区分，新函数的参数增加了一个下划线。

此外，函数应返回其所属的对象，这是为了链式调用所要求的。我们看到，动态语言的灵活性使得添加新语法变得非常简单。

到此，一个初具规模的图数据库就形成了。

和原文相比，本文还缺少一些内容，比如如何将数据库序列化到磁盘。不过相信读者都看到了，我们的数据库内部结构基本上是简单的原生数据结构（列表+字典），因此序列化无论用 pickle 或是 JSON 之类方法都应该是相当简单的。有兴趣的读者可以自行完成它们。

我们的图数据库实现为了提高查询性能，在节点内部存储了边的指针（或者说引用）。这样做的好处是，无论数据库有多大，从一个节点到相邻节点的访问是常数时间，因此数据访问的效率非常高。

但一个潜在的问题是，如果数据库规模非常大，已经无法整个放在内存中，或者出于安全性等原因要实现分布式访问的话，那么指针就无法使用了，必须要考虑其他机制来解决这个问题。分布式数据库无论采用何种数据模型都是一个棘手的问题，在本文中我们没有涉及。有兴趣的读者也可以考虑 500lines 系列中关于分布式和集群算法的其他一些文章。

本文的实现和系列中其他数据库类似，采用 Python 作为实现语言，而原作者使用的是 JavaScript ，这应该和作者的背景有关。我相信对于大多数开发者来说， Python 的对象机制比 JavaScript 基于原型的语法应该是更容易阅读和理解的。

当然，原作者的版本比本文版本在实现上其实是更为完善的，灵活性也更好。如果想要更为优雅的实现，我们可以考虑使用 Python 元编程，那样会更接近于作者的实现，但也会让程序的复杂性大为增加。如果读者有兴趣，不妨对照着去读读原作者的版本。

⑤ 网络进步下的产物——边缘云计算

随着虚拟人等应用不断发展成熟，对于计算的容量和实时性的要求不断提高。在这种趋势下，我们认为，边缘云计算有望成为元宇宙的重要支撑。作为云计算的延伸，边缘云计算被视为新一轮 科技 革命中必不可少的驱动因素。我们认为，元宇宙对网络传输提出了更大带宽、更低时延、更广覆盖的要求，需要借助边缘计算技术，以保障所有用户获得同样流畅的体验。

1.全球数据增长迅速，集中式云计算已无法全面应对，边缘刚需场景涌现，目前中国物联网连接量将从2019年的55亿个增长至2023年的148亿个，年复合增长率达到28.1%。物联网感知数据量激增，数据类型愈发复杂多样，IDC预测到2025年中国每年产生的数据量将增长48.6ZB。

2.芯片：FPGA同时满足边缘侧对性能、能耗及延迟的要求与集中式云计算不同，边缘云计算所处的物理环境复杂多样，很多时候空间、温度、电源系统都不是最佳的状态。但同时，边缘侧又要求极高的实时性和计算性能，传统CPU架构难以胜任边缘云的需求。英特尔、赛灵思等国际芯片巨头持续加码FPGA芯片，并推出支持CPU+FPGA异构计算的硬件平台，底层芯片产业的繁荣将支撑边缘云计算在各领域的应用，并不断迸发出新的活力。

3.5G技术的升级加码，Wi-Fi在室内场景形成互补，工信部数据显示，截至2020年中国已开通5G基站超71.8万个，实现地级以上城市及重点县市的覆盖。预计边缘云计算也会随着5G行业应用的普及分阶段落地。此外，Wi-Fi技术也在向着更高的吞吐量、更大的覆盖面积和更低的时延发展，Wi-Fi在室内场景中的优势使其成为5G的重要补充，两者将共同助力边缘云应用。

4.云计算：企业上云常态化，云原生下沉实现云边端一体化，近年来云原生的热度持续高涨，包括容器、微服务、DevOps等在内的云原生技术和理念强调松耦合的架构和简单便捷的扩展能力，旨在通过统一标准实现不同基础设施上一致的云计算体验。相比于虚拟主机，云原生更适合边缘云计算的场景，可以为云边端提供一体化的应用分发与协同管理，解决边缘侧大规模应用交付、运维、管控的问题。

5.“新基建”加码，工业互联网等标杆应用引领产业融合，“新基建”是十四五规划的重点方向，通过优化算力资源结构，将高频调用、低时延业务需求分配至边缘数据中心，推动5G承载网络的边缘组网建设，为将算力和网络下沉到边缘创造条件。同时，工业互联网、车联网、远程医疗等产业政策明确提及边缘计算，推动关键技术研究、标准体系建设及软硬件产品研发，促进边缘云在典型产业的融合应用。

应用场景

1.视频加速及 AR/VR 渲染

基于移动边缘计算的智能视频加速可以改善移动内容分发效率低下的情况：于无线接入网移动边缘计算服务器部署无线分析应用（Radio Analyticsapplication），为视频服务器提供无线下行接口的实时吞吐量指标，以助力视频服务器做出更为科学的 TCP（传输控制协议）拥塞控制决策，并确保应用层编码能与无线下行链路的预估容量相匹配。另外，由于 AR/VR 信息（用户位置及摄像头视角）是高度本地化的，对这些信息的实时处理最好是在本地（移动边缘计算服务器）进行而不是在云端集中进行，以最大程度地减小 AR 延迟/时延、提高数据处理的精度。

2.车联网（智能交通）

将移动边缘计算技术应用于车联网之后，可以把车联网云下沉至高度分布式部署的移动通信基站。移动边缘计算应用直接从车载应用（APP）及道路传感器实时接收本地化的数据，然后进行分析，并将结论（危害报警信息）以极低延迟传送给临近区域内的其他联网车辆，整个过程可在毫秒级别时间内完成，使驾驶员可以及时做出决策。

3.工业互联网

边缘计算一直与工业控制系统有密切的关系，具备工业互联网接口的工业控制系统本质上就是一种边缘计算设备，解决工业控制高实时性要求与互联网服务质量的不确定性的矛盾。在基础设施层，通过工业无线和有线网络将现场设备以扁平互联的方式联接到工业数据平台中；在数据平台中，根据产线的工艺和工序模型，通过服务组合对现场设备进行动态管理和组合，并与 MES等系统对接。工业 CPS系统能够支撑生产计划灵活适应产线资源的变化，旧的制造设备快速替换与新设备上线。

4.IoT（物联网）网关服务

采取边缘计算技术，边缘计算汇聚节点将被部署于接近物联网终端设备的位置，提供传感数据分析及低延迟响应。其中边缘计算服务器的计算能力和存储能力可为以下5个方面提供服务：业务的汇聚及分发；设备消息的分析；基于上述分析结果的决策逻辑；数据库登录；对于终端设备的远程控制和接入控制。

市场规模

预计2025年规模将超500亿元，年复合增长率达43.3%，信通院2020年5月调研数据显示，中国企业中仅有不足5%使用了边缘计算，但计划使用的比例高达44.2%。可以见得，虽然边缘云计算尚处在发展的萌芽期，但未来成长空间非常广阔。根据艾瑞咨询测算，2020年中国边缘云计算市场规模为91亿元，其中区域、现场、IoT三类边缘云市场规模分别达到37亿元、38亿元及16亿元。预计到2025年整体边缘云规模将以44.0%的年复合增长率增长至550亿元，其中区域边缘云将凭借互动直播、vCDN、车联网等率先成熟的场景实现增速领跑。2030年，中国边缘云计算市场规模预计达到接近2500亿元，2025年至2030年的年复合增长率相比前五年有所下降，现场边缘云中工业互联网、智慧园区、智慧物流等场景将在这一期间快速走向成熟。

相关上市公司

中兴通讯

中兴通讯面向运营商提供全场景MEC解决方案，打破传统封闭的电信网络架构，将移动接入网与互联网深度融合，在网络边缘满足客户的个性化需求。中兴通讯Common Edge边缘计算解决方案包括MEP能力开放平台、轻量化边缘云及面向边缘的全系列服务器和边缘加速硬件，提供通用硬件、专用集成硬件等多种硬件选择，深度融合OpenStack与Kubernetes，为上层MEC应用提供统一的边缘云管理系统，方便运营商因地制宜部署MEC。

网宿 科技

公司的边缘计算平台以云主机、容器、函数计算和网络四大平台作为技术底座，在边缘计算节点上部署边缘云主机、边缘云容器、边缘云函数、SD-WAN、边缘云安全等基础服务，以及内外部的各类应用模块，结合客户的业务场景及需求，尝试进行解决方案的整合和输出。

初灵信息

公司在 5G、AI 技术高速发展的背景下，持续构建以固移智能连接（5G+Fixed）+数据处理（DPI）+AI 为代表的三大边缘计算核心能力。公司多年深耕企业（行业）智能连接网络、垂直行业边缘应用型 DPI（安全、物联网类）、视频及其他行业（企业）的智能应用等技术，初步构成“云边端”协同的边缘计算生态。在市场端，公司除聚焦传统运营商市场外，积极拓展政企行业和大中企业市场，中标多个项目。公司三季度显示，公司与中国联通就边缘计算展开合作，开展了CUNOS在5G环境下的承载能力测试。

引用内容

1. 研报《中国边缘云计算行业展望报告》

2. 研报《边缘计算：算力网络重要环节，产业方兴未艾》

风险提示

1.底层相关技术发展缓慢，边缘计算需求不及预期。

2.5G 进度不达预期。

⑥ 什么是边缘服务器

随着互联网及其应用的快速发展,绝大多数企业都建桐铅立自己的网站,增强对外联络,加速业务流程,客户对网站系统访问的响应时间,网站内容以及所提供服务的可靠性,即时性等要求也越来越高,使得以单台服务器来支撑整个网站的系统已无法满足客户需求,取而代之的是采用两到三层架构的一组服务器.第一层是跟用户直接发生联系的前端服务器,也称为边缘服务器。x0dx0ax0dx0a 边缘服务器为用户提供一个进入网络的通道和与其它服务器设备通讯的功能,通常边缘服务器是一组完成单一功能的服务器,如防火墙服务器,高速缓存服务器,负载均衡服务器,DNS服务器等。第二层是中间层,也称为应用服务器,包括Web表现服务器,Web应用服务器等.第三层是后端数据库服务器。x0dx0ax0dx0a 在当今企业庞大的网络中,网络安全一直是管理人员担心的问题,病毒传播和黑客入侵已成为企业网络受到外来攻击的最主要的威胁,网站的安全是网站建设必须考虑的内容,所以所有的网站都或多或少的有网络安全措施&网络防火墙.在访问量不高的情况下,防火墙功能可以跟Web服务共存在一台服务器上,但访问网站的客户数量的增多枯灶必然增加服务器的负载,防火墙的运行必然影响访问速度,因此为了不降低访问速度甚至提高访问速度,同时保持或提高网络安全性,就有必要采用专用的防火墙服务器. 不论一个客户是如何使用互联网的, 快速持续地传送客户所需的Web内容都是非常重要的。x0dx0ax0dx0a 针对电子商务, 用户的等待时间会导致收入的损失.研究显示,在每页标准的8秒装载时间之前, 25%的站点访问者会变得不耐烦而转向其它站点.下降的生产率会给那些其雇员不愿意访问互联网上有关工作信息的企业带来同样的成本.为了提高网站访问响应速度和效率,在web服务器之前增加高速缓存服务器,把客户经常访问的内容放在高速缓存服务器上,这样客户在访问这些内容时就可以直接在高速缓存服务器上获得,降低了网络拥塞,这样就有更多的带宽用于其它请求,极大地提高了响应时间. 随着网站通信量的增加,一台服务器已不能满足业务需求,需要不断增加新的局败好服务器,并要跨越这些服务器分发负载,同时还不能造成站点访问者的任何中断.这些访问应该连接到相同的URL- 不管实际上是由哪一台服务器来满足了请求.因此需要有一个专用服务器动态分配各服务器之间的访问流量,这种专用服务器就是负载均衡服务器,负载服务器通过特定的负载均衡技术,将外部客户请求视同一功能的服务器组中各服务器上的负载状况合理分配到某台服务器上,籍此大幅提高获取数据的速度,解决海量并发访问问题.负载均衡服务器不仅可以平衡各服务器的负载,还可以检测服务器的使用情况,在某台服务器发生故障的情况下及时把该服务器的工作分配到其他服务器上,保证系统正常运行的高可用性和高可靠性.如果访问量超出了服务器的响应能力,只需增加服务器数目就可平滑升级。