Scalability and Performance of LiDAR Point Cloud Data Management Systems A State-of-the-Art Review
摘要: 本文探讨了LiDAR点云数据管理（PCDM）系统的可扩展性和性能。点云数据由于其体积大且异质性强，亟需高效的管理解决方案。现有研究主要集中于在不同的并行架构和数据模型上开发PCDM系统，已取得一定的成果。特别是共享内存架构和共享磁盘架构下的PCDM系统表现出色。然而，关于共享无架构和宽列NoSQL数据库在PCDM中的应用研究仍不足。本文还指出，现有的PCDM系统在扩展性和性能评估方面存在显著的研究空白。针对未来研究，本文建议在三方面进行深入探索：点云数据量的变化、流量变化及其他系统需求。同时，强调了开发一个可扩展、灵活的框架以系统化地测试和比较不同PCDM系统的重要性。
〓 Table of Contents 〓
- Introduction
- RelatedWork
- Background
- Parallel Architectures toward Scalability and Performance
- Data Models toward Scalability and Performance
- Analysis of State-of-the-Art PCDM Systems
- Discussion
- Conclusions
Introduction
随着LiDAR点云数据的日益普及，越来越多的研究致力于开发高效的点云数据管理（PCDM）系统。尽管其中一些系统采用基于文件的方法来存储和查询点云数据，但相当多的系统致力于开发依赖数据库技术的PCDM系统。PCDM研究的核心在于应对大量异构点云数据。因此，依赖数据库技术的PCDM解决方案主要集中于实现更大的可扩展性，同时保持可接受的性能水平。
“可扩展性”(Scalability)是一个相对的术语。在本文中，可扩展性是指开发高度可扩展的数据密集型系统，换句话说，是从数据管理的角度来讨论。因此，可扩展性主要关注的是如何在快速增长的数据需求和查询（即流量）需求下，确保高效的存储和数据检索时间。这一定义来源于Kleppmann（2017）。
更具体地说，点云数据的可扩展管理正在设计和开发数据密集型系统方面进行探索。换句话说，PCDM系统正在被开发，以适应不同负载参数的增长，同时确保相应的性能。这些负载参数包括点云数据量的快速增长、单用户和多用户场景中从数据库中检索的点数量的快速增长，以及在必要时高卷的点云数据摄取，用于测量性能指标（例如，管理10亿点时检索100万点所需的响应时间）。
RelatedWork
尽管在科学文献中已经全面介绍了与PCDM相关的多种方法，但许多优秀的过往调查并未完全涵盖这一快速发展的领域中的最新和新兴趋势。因此，本文综合了现有调查、原创研究论文、书籍章节和有关PCDM的学位论文的贡献。这主要可以分为两个领域：(i) 基于文件的PCDM研究，和(ii) 依赖数据库技术的PCDM研究。然后，本文讨论了未来系统选择的问题，并进一步识别出需要解决的主要研究问题。
2.1 基于文件的PCDM
Otepka等人的工作是PCDM背景下的早期调查论文之一。这项调查将地理参考的点云数据模型定义为三维笛卡尔空间中与地理空间参考系统（例如，全球横轴墨卡托投影）相关的一组点 $\mathrm{P} i, i=1, \ldots, n$。点云特征也被描述为两类：(i) 基本特征，和(ii) 派生特征。基本特征是指在点云测量/调查过程中捕获的特征（例如，$x-, y$-和$z$-坐标）。而派生特征是在点云处理阶段生成的特征（例如，分类）。作者强调了保留原始点云的重要性，而不是从插值数据生成的表面模型（这是十年前的常见做法）。为了保持原始格式，该调查讨论了几种用于保留原始点的先进空间索引，包括kD树、八叉树和R树。该调查还强调了在点云文件中组织几何属性（即坐标）和其他属性（例如强度或颜色）的不同技术，用于管理点云数据。还讨论了与点云文件中各个属性组织有关的点云数据管理问题。然而，这些内容并未涵盖面向数据库的PCDM。
Graham的后续工作概述了LiDAR点云数据的结构以及通过不同编码格式（例如二进制、ASCII和基于标记语言的格式（例如XML））进行点记录的利用和传输。作者还详细描述了美国摄影测量与遥感学会（ASPRS）的LAS数据格式。LAS格式是LiDAR数据的主要共享格式。Graham的描述包括LAS 1.4规范的主要亮点、LAS数据格式与LiDAR数据处理的关系，以及不同点属性和LiDAR项目属性如何在LAS格式中反映出来。最重要的是，Graham强烈支持基于文件的PCDM系统，而不是数据库解决方案，并质疑采用数据库解决方案。作者认为，数据库解决方案只有在需要随机访问LiDAR数据时才具有吸引力，并进一步认为PCDM应该基于文件存储，以支持高吞吐量生产操作，假设采用数据库进行PCDM可能带来的弊大于利。
2.2 依赖于数据库技术的PCDM
大多数依赖数据库技术的PCDM研究，包括[3,5,19-24]，讨论了基于文件的PCDM的局限性。这些局限性包括在查询大量LiDAR点时的不可靠性、不足的临时查询支持、较差的水平和垂直可扩展性，以及缺乏数据集成和数据共享的支持。此外，上述论文还详细讨论了采用数据库解决方案进行LiDAR数据管理的好处：(i) 通过数据隔离实现应用独立性，(ii) 有效支持数据的并发访问，(iii) 高可扩展性（例如采用分布式数据库），(iv) I/O优化，(v) 集成其他点云数据和影像数据，(vi) 通过标准化的声明式查询语言进行数据检索的可能性，(vii) 易于管理和建立安全性，(viii) 设计用于点云数据的特殊形式的空间数据类型，(ix) 通过多层次的细节级点云数据表示改善可视化。
点云数据在数据库环境中的组织的领先研究工作之一是[19]中提出的，该工作提出了多种PCDM解决方案的全面评审和基准测试。基准测试包括两个关系数据库管理系统（DBMS）（即Oracle和PostgreSQL/PostGIS）、一个列式数据存储（即MonetDB）和一种使用LAStools的基于文件的方法。此外，作者还研究了通过使用Oracle Exadata数据库机器（OEDBM）采用高性能并行数据库进行PCDM的可行性。每个PCDM的数据加载时间、数据存储和查询响应时间在三个基准（小型、中型和大型）下使用AHN2数据集进行测量和呈现。使用三种不同的数据集大小提供了一种直接且具体的手段来评估可扩展性。可扩展性和性能也可以从理论上考虑（详细信息参见第4和第5节）。然而，在实验场景中，通常通过获得特定工作负载场景的性能结果来确定系统的可扩展性。
在van Oosterom等人的工作中，作者主要研究了不同数据负载量下的可扩展性。他们的分析包括在Oracle和PostgreSQL中使用块模型、点云数据组织（其中一组点作为一个块存储在一起）以及在Oracle、PostgreSQL和MonetDB中使用平面表模型点云组织（其中每个点存储在一个表行中）的比较。作者还解释了在PostgreSQL和Oracle数据库中使用PC_PATCH数据类型和SDO_PC和SDO_PC_BLK数据类型进行点数据组织的情况。
Vo等人的工作提供了这些Oracle和PostgreSQL内置数据类型的更深入评审。在该工作中，详细介绍了航空LiDAR的起源，重点是其在规模、分辨率和受欢迎程度上的增长。此外，作者还详细讨论了在文件和数据库环境中对航空LiDAR数据建模以及在航空LiDAR数据中的空间索引应用，以及LiDAR点记录如何在基于瓦片的索引、层次索引和集成多索引结构中进行分区和组织。最后，Vo等人指出了数据库支持LiDAR全波形数据管理的缺乏。
此外，分布式非关系数据库解决方案在PCDM中的重要性越来越频繁地出现[3,22,27-30]。虽然在[3,24]中阐明了采用分布式解决方案和非关系数据库的好处（即避免单点故障和更好的可扩展性），但迄今为止，已发表的工作并未审查当前PCDM系统的可扩展性和性能。 特别是，是什么使PCDM系统具有可扩展性以及如何实现这一点，是缺乏严格研究的主题。 本节中强调的最重要点总结在表1中。
表1展示了对PCDM系统可扩展性和性能的广泛调查的缺乏。第4-6节详细讨论了这一差距。在本综述中，通过涵盖并行架构和数据模型两个基本领域，探索了当前最先进的PCDM系统，这两个领域有助于使数据系统具有可扩展性和高效性。
Background
Scalability and Performance of Data-Intensive Systems
在当今的数据密集型应用程序开发中，实现更高的可扩展性而不损害相应的性能是一个关键目标。 对于数据密集型应用，可扩展性被定义为系统应对数据量、流量和复杂性增加的能力。 在设计数据密集型应用程序时，首先需要确定和描述上述负载因素及其随时间的预期增长。通过一系列负载实验来评估可扩展性。虽然性能方面通常因领域和应用领域而异，但常见的性能指标涉及存储、查询和数据加载。存储性能通常通过存储数据所需的字节/千字节来衡量。数据加载性能通过吞吐量进行评估。查询性能通常通过吞吐量或响应时间来衡量。在数据密集型应用中，吞吐量通常定义为单位时间内处理的记录数或执行的工作量。例如，在PCDM环境中，数据加载通常以每秒或千点数数据每秒的速度进行测量。响应时间被定义为查询经过的时间。在PCDM中，查询响应时间通常以毫秒、秒或分钟为单位进行衡量。在提供数据的并发访问时，根据目标，数据密集型系统会在响应时间和吞吐量之间进行权衡。目前在PCDM中，不将查询性能评估为吞吐量。
可扩展性和性能是数据密集型系统（例如PCDM）开发中的两个重要维度。可扩展性和性能是相互关联的。可扩展性差通常导致性能不佳，这意味着在不可扩展的系统中，性能通常会随需求（即负载）而降低。此外，可扩展性为获得更好的性能提供了选择。虽然希望同时具备更高水平的可扩展性和性能，但数据密集型系统通常会在性能和可扩展性之间进行权衡。因此，最先进的数据密集型系统通常旨在吸收更高的负载，同时实现可接受的性能。
Scaling Techniques and Parallel Architectures in Data-Intensive Systems
Advent of Parallel Data-Intensive Systems
传统上，计算机系统遵循“经典”的冯·诺依曼体系结构，因此采用单核、单处理器架构。通常，术语“核心”用于表示单个计算单元。因此，历史上，计算机系统每个都只有一个处理器，在该处理器中只有一个计算单元。如今，这些计算单元也被引入为核心。此外，这些核心在上下文中与中央处理单元（CPU）同义（即，一个核心 = CPU）。随着芯片制造商推出了具有多个计算单元的处理器，多核处理器成为计算机系统中的主流元素。与此同时，诸如线程处理等技术的出现使处理器核心能够同时被利用。因此，整个计算机系统中可用的逻辑计算单元（即，逻辑CPU）增加，从而实现并行计算。
为了实现更高的可扩展性和相应的性能，支持大规模数据管理的最先进计算机系统（即数据密集型系统）通过网络化不同的处理元素进行设计。这些处理元素包括多核处理器、多处理器芯片（单核或多核）、RAMS、磁盘甚至完全自治的处理元素（即节点）。因此，现代数据密集型系统具有更多的可用计算单元（即物理和逻辑CPU）。这使得数据密集型系统中的CPU能够与存储在RAM和/或磁盘中的数据并行交互，并且也能够并行执行与数据管理任务相对应的计算。
Architectures of Data-Intensive Systems (Parallel Data System Architectures)
如前所述，当今的数据密集型系统是并行系统。这些最先进的数据密集型系统主要有三种类型：（i）垂直扩展系统（尺度上升系统），（ii）水平扩展系统（尺度外系统），以及（iii）混合采用两者的系统。数据密集型系统可以通过两种方式采用垂直扩展。第一种方法是通过一个快速网络在单个操作系统下连接多个CPU、内存芯片和磁盘。这些系统产生基于共享内存架构的数据密集型系统。第二种方法连接多台计算机，每台计算机都有自己的操作系统、CPU(s)和内存芯片(s)，但使用共享磁盘存储数据，通过快速网络连接。采用这种方法的应用被称为基于共享磁盘架构的数据密集型系统。采用水平扩展的应用被称为基于共享无架构的系统。
Use of Databases in Data-Intensive Systems
如今，在数据密集型应用中普遍采用数据库。这些数据库通常部署在共享内存、共享磁盘或共享无架构的并行架构中。它们提供机制来高效地管理系统的底层数据，可以在磁盘上持久保存或者在主存储器中进行管理。与基于文件的应用相比，这些面向数据库的数据密集型应用能够使数据独立于各自的应用（在基于文件的应用中，文件格式与应用紧密耦合）。
目前，有许多数据库可供数据密集型系统使用。它们服务于多种目的，因此具有不同的数据模型，并部署在各种并行架构中。数据模型是接收和组织输入数据的格式。常见的数据模型包括关系模型、关系列模型、NoSQL模型（如键值模型、宽列模型、图模型）、数组模型以及混合模型（多模型和NewSQL模型）。遵循关系模型的数据库可以部署在所有三种数据密集型系统架构下。NoSQL模型数据库和混合模型数据库主要部署在共享无架构环境中。虽然数组数据库也可以部署在共享内存架构中，但实际上数组数据库主要用于共享磁盘或共享无架构中。
这三种并行架构风格及其在各自架构中的数据库部署都有潜力提供所需的数据管理可扩展性，同时确保相应的性能。然而，在采用数据密集型应用开发（如PCDM）时，理解每种并行架构对可扩展性和性能的影响至关重要。特别是，了解每种并行架构在适应给定的数据密集型任务时的灵活性、技术多样性、可扩展性范围、性能特性和局限性是重要的。这样的理解有助于选择适合当前数据密集型任务的并行架构。同样，还需要理解数据模型对于开发数据密集型应用的影响。因此，第4节和第5节用于讨论架构和数据模型对于PCDM的可扩展性和性能的影响。
Parallel Architectures toward Scalability and Performance
现有的共享内存系统和共享磁盘系统有能力应对不断增加的数据量和流量。然而，这些垂直扩展系统的可扩展性始终受限于各自系统的容量。例如，在共享内存系统中，处理和存储元素的现有容量（如可用的CPU、内存单元和磁盘）决定了系统应对增加的数据量和流量的能力。如果需要进一步扩展共享内存系统以应对超出其容量的数据量和流量，则必须迁移到具有更大存储容量、处理能力和内存的高端机器。类似地，在共享磁盘架构中，可扩展性也依赖于系统的具体特性。特别是，为支持不断增加的数据量，可能需要将共享磁盘系统迁移到具有更大磁盘容量的共享磁盘机器。
相比之下，添加更多处理器-内存（或CPU-内存）节点到现有系统可以提高共享磁盘系统的数据处理能力，而无需进行系统迁移。然而，共享磁盘系统中的另一个问题是，数据写入可以在任何节点上执行。这意味着两个或更多节点可能会同时尝试写入一个数据记录（即元组）。因此，为了确保一致性，管理系统必须使用基于磁盘的锁表或通知系统中其他节点锁定该元组的意图。由于这些额外的开销，在共享磁盘架构中添加更多节点并不总能提高大数据量和流量的可扩展性。
相比之下，在基于无共享架构的系统中管理数据时，可以在无需系统迁移的情况下增加存储、处理和内存需求。更具体地说，在无共享架构的系统中，添加完全自主的节点（包含处理器、内存和磁盘）是容易实现的。此外，与共享磁盘架构系统不同，添加节点通常能提高可扩展性。这是因为在无共享架构中，每个节点独立管理其自己的数据。因此，在将数据写入持久存储时，无需在无共享架构中锁定节点。因此，在数据量需求和流量需求不断增加的情况下，无共享架构被认为是一种有效的方法。
值得注意的是，研究表明，在相同的并行度下，基于共享内存架构的系统通常表现最佳，而基于无共享架构的系统表现最差。在所有三种架构中，增加更多节点/核心或更强大的节点/核心通常会提高系统的并行度。因此，可用于数据管理任务的处理器（和CPU）、内存和磁盘单元也会增加。因此，特别是数据加载和查询性能通常会得到改善。虽然增加节点/核心一般会提高性能，但在并行计算数据管理（PCDM）文献中，这种情况仅在基于无共享架构的PCDM工作中有所体现。当前的基于共享内存和共享磁盘架构的PCDM系统并未显示出在现有PCDM系统中添加更多核心/处理器-内存节点时可以实现的性能提升。可能的原因是，一旦系统配置完成，向现有系统添加更多核心/处理器-内存节点是不可行的。
在某些基于无共享架构的PCDM系统中，添加完全自主的节点到现有系统可以改善数据查询时间。在其他基于无共享架构的空间数据管理系统中（如Hadoop-GIS和VegaGIStore），也可以看到查询响应时间和数据加载的性能提升。然而，向无共享架构系统添加节点仅能以次线性方式改善性能。此外，添加节点并不保证性能提升，因为提升仅能在一定数量的节点内实现，超过这一数量后，通信成本将超过性能收益。
在分析最先进的PCDM研究工作时，大多数数据库导向的PCDM研究努力都基于共享内存架构系统。然而，当前的PCDM文献并未提供采用共享内存架构的直接原因。这些架构主要受到实验中使用的数据库的影响。具体而言，这些PCDM系统基于传统关系数据库（如Oracle、PostgreSQL/PostGIS等）。
据我们所知，目前仅存在一个基于共享磁盘架构的PCDM系统，即Oracle Exadata数据库机器PCDM。与基于共享内存架构的PCDM系统类似，仅有一个基于共享磁盘架构的PCDM系统的原因尚不能严格解释。然而，当今大多数知名的基于共享磁盘架构的数据库解决方案，如Oracle Exadata、IBM Parallel Sysplex以及微软和Sybase的类似解决方案，都是商业数据库解决方案。因此，采用基于共享磁盘架构的数据库解决方案可能需要大量的财务投资。这可以被认为是基于共享磁盘架构的PCDM稀少的潜在原因。
一些最近的PCDM系统基于无共享架构。这些系统使用NoSQL数据库进行实验，并设计为在无共享架构下部署。与关系数据库相比，NoSQL数据库的出现是数据管理范式中的一个新事物。因此，在PCDM文献中采用基于无共享架构的NoSQL系统的努力较少。所有引用的系统在管理不同数据量时都展示了可扩展性和相应的性能。这些数据量从数百万LiDAR点到6400亿不等，现有系统在大或密集的航空点云（如AHN2、都柏林LiDAR数据集等）上进行了测试，但未在实时数据增长和流量增长方面进行测试。
随着大规模和密集的LiDAR数据集日益普及，这对使用共享磁盘或共享内存架构的系统提出了挑战。因此，在实时数据和流量增长对PCDM项目变得重要的情况下，基于无共享架构的PCDM可能提供一个有前景的途径。
综上所述，可以得出以下结论：通过并行化可以实现更高的可扩展性和性能；所有三种并行架构都可以通过增加并行度来实现更好的性能；共享内存架构在数据和流量增长方面的可扩展性最差，而无共享架构具有最大的可扩展性。此外，通过向系统中添加更多节点可以提高无共享架构系统的性能，但在节点饱和后，性能可能会受到负面影响。
所有三种并行架构在PCDM研究中都进行了探索。对于静态点云数据集，足够的并行性可以使任何一种架构都能以可扩展的方式运行。相反，在需要PCDM容纳定期数据和流量增长的情况下，基于无共享架构的PCDM系统提供了更大的潜在可扩展性。除了并行架构外，数据模型是另一个显著影响性能和可扩展性的因素。下一节将讨论数据模型。
Data Models toward Scalability and Performance
数据模型在软件开发中，尤其是在数据库软件系统中，具有深远的重要性。数据模型提供了一种在数据库中表示现实世界实体及其关系的方式（例如，用户及其姓名、地址等，或LiDAR点之间的时间戳和元数据）。最常见的数据模型是Codd于1970年提出的关系模型。基于关系模型的数据库系统，即关系数据库管理系统（RDBMS），在几乎所有应用中已经成功使用了几十年。根据关系模型，数据被组织成具有固定且精确定义模式的关系（即表格）。许多关系数据库管理系统（例如Oracle和PostgreSQL）提供面向对象的功能。此类系统中的数据模型被称为对象关系数据模型。
传统上，大多数关系数据库依赖于垂直扩展。因此，它们在数据量和流量方面的可扩展性是有限的。然而，今天所有主要的关系数据库都提供水平扩展部署，并能够管理大流量和大数据量。关系模型和对象关系模型都被用于PCDM。例如，通过在表中每行存储一个点记录，每列存储一个点属性，van Oosterom等和Psomadaki等使用关系模型（不含面向对象的功能）来存储点云。此类模型被称为平面模型，并已在Oracle和PostGIS数据库管理系统中实现。平面模型允许使用标准DBMS功能直接访问点云中的每个点。然而，这些平面模型的可扩展性主要受到处理过多数据记录的成本限制（例如，管理数十亿记录的非常大的索引结构）。
除了平面模型，Oracle和PostGIS还允许使用对象关系模型存储点云（即Oracle的SDO_PC和PostGIS的PCPATCH，称为块模型）。顾名思义，点被分组成块，每个块表示为存储在数据库行中的二进制大对象（BLOB）。因此，与等效的平面模型相比，数据记录较少。这些系统中定义了专门的数据类型和操作来处理点云BLOB。Van Oosterom等通过实验表明，块模型比平面模型更具可扩展性，且通常允许更快的查询。
列式关系数据库管理系统是另一类在PCDM文献中被考虑的关系数据库系统。与优化用于存储和检索行数据的典型关系数据库不同，列式关系数据库管理系统优化用于快速检索列数据，因此被称为列式数据库。这些列式RDBMS通常设计为利用底层硬件的并行性。MonetDB和Oracle Exadata数据库机器（OEDBM）是两种著名的列式、大规模并行RDBMS。到目前为止，关于OEDBM的PCDM研究很少。在存储层次上，MonetDB和OEDBM都采用平面表方法存储点记录。
另一类数据模型称为NoSQL。与RDBMS不同，许多NoSQL数据库不需要显式预定义模式。相反，数据可以具有任意结构，并由应用程序逻辑隐式编码。这一特性通常被称为无模式，帮助降低模式演化成本，更好地支持半结构化和非结构化数据。NoSQL数据模型的例子包括键值模型（如Redis）、图模型（如Neo4j）、文档模型（如MongoDB）和宽列模型（如HBase、Cassandra、Big Table）。NoSQL数据模型为表示不同类型的数据提供了广泛的选项。每种模型都针对特定应用进行了优化。与关系模型相比，NoSQL模型允许更高的模式灵活性。
在PCDM研究中已经探索了NoSQL数据库的无模式特性。例如，Boehm等在MongoDB（文档模型）中将点云文件建模为文档对象，而Vo等研究了在HBase中使用宽列模型建模点云的四种不同方式。在这些情况下，NoSQL允许在没有预定义固定模式的情况下存储点云。这种灵活性在点云来自多个来源（如不同类型的传感器）、具有异质点属性并且不需要按照预定义标准（如LAS标准）进行摄取和存储时特别有用。与RDBMS相比，NoSQL数据库更容易容纳更高水平的数据复杂性。此外，许多NoSQL数据模型专为比RDBMS实现更高的可扩展性和性能而开发。许多NoSQL系统围绕无共享系统架构演变，因此本质上具有高度可扩展性。数据分区、分布、复制（以最小化网络通信）以及分布式索引、哈希和缓存的战略性使用是许多NoSQL系统实现高查询性能和可扩展性的技术之一。
大多数NoSQL RDBMS通过牺牲RDBMS中的主要标准功能（如ACID属性）来实现更高的性能和可扩展性。ACID属性在需要低延迟且数据库状态持续变化的应用中至关重要。此类应用常见于在线事务处理系统，如银行系统和在线票务系统。为了保证ACID合规性，数据库管理系统可能会妥协其可扩展性。尽管ACID属性对许多应用很重要，但在PCDM中是否需要ACID合规性尚无一致观点。然而，一些研究（如Vo等和van Oosterom等）认识到，大多数点云数据库在摄取后很少更新、插入或删除点云记录。因此，Vo等认为PCDM不严格要求ACID合规性。因此，在PCDM的背景下，像许多NoSQL系统那样以可扩展性和性能为代价放弃ACID合规性是可以接受的。然而，新型乘客车辆和无处不在的iPhone设备的出现可能为创建需要重新思考LiDAR数据集作为伪静态实体的新应用铺平道路，这可能影响对ACID合规性重要性的看法。
值得注意的是，高度可扩展性和ACID合规性并非必须互相排斥。EarthServer是一个ACID合规且可扩展的数据库系统的例子，能够处理点云数据。EarthServer基于Rasdaman的数组数据模型（raster data manager）。EarthServer主要支持的空间数据类型是高维光栅数据。为了在EarthServer中存储点云数据，需要将其转换为光栅表示。可以说，这种情况并不理想，因为光栅化会剥夺点云数据的丰富性，从而降低其价值。例如，在每点处理应用中，这种价值很容易体现出来。
除了EarthServer的特殊情况，现代SQL数据库如NewSQL属于一类关系数据库系统，它们提供NoSQL系统的高可扩展性和关系数据库的强一致性和可用性。然而，目前只有一个PCDM系统是基于NewSQL数据库构建的。研究人员在其中使用了SAP HANA数据库——一个内存中列式关系数据库管理系统，用于PCDM。
大多数性能基准测试的一个关键缺陷是结果仅涵盖现有数据模型中的少数几种。此外，在跨多个数据模型进行性能评估时，实验设置必须一致。在当前的PCDM文献中，这意味着对象关系数据模型和关系列式模型的性能基准测试必须在相似的实验环境下进行。尽管在PCDM中存在关系型、列式、NoSQL和NewSQL模型的采用，但迄今为止，尚未在相同实验设置下对所有模型进行性能基准测试。因此，点云数据中的所有数据模型尚不可能。
然而，据Oszu和Davoudian等人的研究，NoSQL数据库、NewSQL数据库和其他新型数据库技术表现出更好的性能。因此，在相同测试环境下获得不同NoSQL、NewSQL和传统关系数据库的性能结果，将能更好地了解性能高效的PCDM。
传统的关系型和对象关系模型已被广泛用于PCDM。主要的RDBMS（如Oracle和PostGIS）多年来一直提供PCDM解决方案。此外，硬件优化的列式关系数据库管理系统（如MonetDB、Oracle Exadata）在当前的PCDM研究中也有所应用。具体来说，NoSQL提供了传统关系模型的多种替代方案。目前文献中可以找到几种NoSQL PCDM系统和一个NewSQL PCDM系统。非关系型数据模型允许在没有刚性模式的情况下表示点云数据，因此它们能够更好地适应复杂的异构点云数据集。此外，NoSQL和NewSQL都承诺比RDBMS更高的可扩展性和性能。
许多NoSQL数据库通过牺牲ACID合规性来实现可扩展性和性能。虽然PCDM可能不需要严格的ACID合规性，但在选择数据模型时，必须考虑NoSQL模型的缺点。与NoSQL不同，NewSQL系统在不牺牲ACID的情况下提供高可扩展性。PCDM的数据模型选择应考虑实际的系统需求。例如，如果可扩展性比一致性更重要，NoSQL数据模型可能是一个合适的选择。如果必须将点云数据与当前托管在RDBMS中的现有数据集成，则关系或对象关系模型可能是更有效的选择。
Analysis of State-of-the-Art PCDM Systems
如第4和第5部分所述，在讨论可扩展性和性能的理论方面时，可以将并行架构和数据模型视为独立的领域。然而，在分析已经开发的系统时，这种架构和数据模型的分离并不容易实现。这是因为在已实现的数据管理系统中，架构和相应的数据库（包括数据模型）紧密集成。因此，在研究已实现的系统时，必须结合考虑架构和数据模型及其对系统的影响。
为便于理解，本节将最先进的PCDM系统按其各自的并行架构进行分类分析，具体包括：(i) 基于共享内存的PCDM系统，(ii) 基于共享磁盘的PCDM系统，和(iii) 基于无共享架构的PCDM系统。数据模型、相应的数据库以及其他与PCDM系统相关的信息将在每种架构下进行统一展示和讨论。
Shared-Memory Based PCDM Systems
表2展示了最受欢迎的基于共享内存架构的PCDM系统。根据表2，目前的共享内存架构PCDM系统成功测试的数据集范围从7400万个LiDAR点到230亿个LiDAR点。在[19]中，作者指出，即使在具有广泛并行性和更强大硬件的情况下，其实验环境中摄入6400亿个LiDAR点的过程也会影响扩展性并生成无法承受的加载时间。相比之下，230亿个点是[19]中基于共享内存的PCDM系统可以测试的最大点数，而6400亿个点则明显大得多（大约是其26.8倍）。因此，在需要管理极大量点云数据（如数十亿点）且预计数据增长会显著增加（例如达到数千亿点）的场景中，使用共享内存PCDM系统进行实验测试可能会因其动态性而变得困难。
鉴于LiDAR数据集更新的稀少性，即使是处理大规模点云数据集（如数千亿点）可能需要的巨大数据摄取时间（例如数天至数周）也可能是可以接受的，但摄取数万亿LiDAR点（如全国范围的LiDAR扫描）可能会进一步加剧数据加载时间。因此，无论在研究还是非研究场景中，都可能出现更为不利的扩展性情况。此外，共享内存系统中的资源和并行性可用性也可能阻碍管理这些数据集。
根据表2，目前的基于共享内存架构的PCDM系统主要建立在两种类型的关系数据库之上：(i) 提供持久存储的对象关系数据库和(ii) 提供内存存储的列式关系数据库。一般来说，当要管理的数据量与系统主内存大小兼容时，内存数据库是有利的。因此，在采用内存数据库进行PCDM时，系统的主内存应能提供所有可用点云数据的存储需求。此外，还应有足够的主内存用于PCDM操作，如数据加载和数据查询。然而，事先确定内存PCDM系统应具备的主内存大小并不容易，因为总体内存消耗需求受到多种因素的影响，如数据编码技术、点数、索引大小、每个点的属性数量以及常见点云操作所需的内存。
尽管如此，当主内存足够容纳点云数据和操作时，内存系统可以提供更好的性能。例如，根据[19,48]，内存PCDM解决方案（如MonetDB）在数据加载时间方面优于其他基于持久存储的共享内存架构PCDM系统。由于MonetDB中的固有并行执行，这种性能提升也得到了增强。然而，由于内存数据库中的主内存瓶颈，查询大数据量可能导致性能差和扩展性低下。例如，在[48]中，作者指出，当从存储22亿个点的MonetDB PCDM系统查询点云数据时，其查询性能优于存储22亿个点的PostgreSQL/PostGIS PCDM系统。然而，当从存储230亿个点的MonetDB PCDM系统查询点数据时，存储230亿个点的PostgreSQL/PostGIS PCDM系统的查询响应时间显著更好。作者因此得出结论，像PostgreSQL/PostGIS这样的数据库，通过在磁盘存储中将点数据组织成一组块，而不是像MonetDB那样在主内存中单独处理每个点，是管理大量点云数据的可扩展解决方案。
MonetDB和SAP HANA是用于基于共享内存架构PCDM的两种内存数据库，也可以部署在无共享架构中。根据作者的最佳知识，目前没有基于MonetDB或SAP HANA的横向扩展PCDM系统。由于横向扩展提供了有利的可扩展性和性能前景，这可以成为面向无共享架构PCDM的潜在未来研究方向。
现有的基于共享内存架构的对象关系PCDM系统主要基于Oracle或PostgreSQL/PostGIS数据库。这些数据库都遵循固定模式。因此，从可扩展性的角度来看，这些PCDM系统将无法支持从不同传感器获取的异构点云数据集的多样性。然而，如果将点云数据摄入并存储在根据LAS标准定义模式的数据库表中，这种限制可以得到缓解。
从理论角度看，共享内存架构和关系数据模型不足以支持PCDM中不断增长的数据量、流量和数据复杂性。除了表2中列出的研究外，一些PCDM研究人员仍然采用共享内存架构和关系（对象关系）数据模型。例如，在[19]中提倡的需要专门的点云数据空间数据类型，并在[68,69]中进一步研究了基于共享内存架构的PCDM系统中的这一需求。[68,69]的工作基于Oracle数据库，主要关注识别PCDM的新共享内存索引策略。类似的尝试也可以在[20,31,46,52]中找到。从可扩展性和性能的角度来看，空间索引起着关键作用。例如，在管理大量点云数据时，高效过滤或检索所需的LiDAR点是至关重要的。因此，由于减少磁盘读取次数或减轻数据库负载的正面影响，空间索引在提高查询吞吐量和查询响应时间方面非常有吸引力。由于[5]中已经对共享内存架构PCDM系统中采用的索引策略进行了相当全面的回顾，本文将不再进一步讨论这些内容。
Shared-Disk Oriented PCDM Systems
Oracle Exadata PCDM系统（见[19]）似乎是唯一采用共享磁盘架构的PCDM系统，并且已在超过230亿个点的规模下进行了测试。在[19]中，作者测试了包含6400亿个LiDAR数据点的OEDBM PCDM系统，没有出现不利的数据加载或处理时间。这一示例展示了共享磁盘架构在处理前所未有的数据量方面的能力，相较于共享内存架构具有显著优势。这主要归因于OEDBM固有的大量内存使用和优化的硬件并行处理。因此，目前在PCDM文献中，评估共享磁盘架构与共享内存架构PCDM系统的可扩展性和性能仍然是一个开放的研究问题。
在基于共享内存架构和无共享架构的PCDM系统中，索引的使用以辅助点云数据检索是一个广泛讨论的话题。然而，在[19]中，OEDBM没有为点云数据检索实现任何索引。这是因为OEDBM不实现额外的数据结构或索引进行数据检索。相反，为了数据检索和减少磁盘I/O，OEDBM采用了反向索引的概念。反向索引通常通过元数据管理来实现。通过使用不同列中的最小值和最大值等元数据，OEDBM可以在无需人工干预的情况下执行数据检索。
此外，与大多数基于共享内存架构的PCDM系统类似，OEDBM主要基于关系模型（见第5节；OEDBM使用面向列的关系模型）。因此，当在OEDBM中管理点云数据时，数据必须符合固定的模式。结果是，数据复杂性方面的可扩展性受到限制。
在其计算技术方面，OEDBM利用消息传递接口（MPI）库进行分布式多节点计算。MPI主要用于具有多个节点且计算任务之间需要高度同步的系统。这是通过高效利用底层硬件中的并行性来实现的。因此，采用OEDBM进行PCDM可以充分利用底层硬件中的并行性。然而，这需要在有效分割任务（即数据加载、数据查询等）方面具备广泛的专业知识。因此，这种增加的复杂性可能成为高度可扩展的PCDM研究实验的潜在障碍。
从上述对基于共享内存和共享磁盘架构的PCDM系统的讨论来看，这些系统在最大测试规模分别为230亿和6400亿LiDAR点方面取得了成功。然而，如第4节和第5节所述，与无共享架构的系统相比，共享内存和共享磁盘系统的可扩展性受限。因此，研究基于无共享架构的PCDM系统的可扩展性是一个合乎逻辑的下一步，并且将成为下一个小节的讨论内容。
Shared-Nothing Architecture-Oriented PCDM Systems
最早采用无共享架构的PCDM尝试之一在[22]中讨论。作者使用文档导向的NoSQL数据库MongoDB加载和管理了4480亿个LiDAR点。在该实验中，大型LiDAR文件被分割成一系列较小的文件，然后这些较小的文件被存储在部署在GridFS文件系统上的MongoDB集合中。作者声称在大数据量方面具有高可扩展性，因为该系统可以采用Hadoop分布式文件系统（HDFS）进行分布式存储、扩展性以及更高容量的数据管理，并支持MapReduce并行数据处理框架。然而，该解决方案仅限于文件选择，因为数据是在文件系统级别管理的。
Li等人[29]提出了一个用于LiDAR PCDM的通用框架，该框架也建立在HDFS和MapReduce之上，但仅测试了41.7亿个点（相对于之前测试的共享内存架构和共享磁盘架构系统的数据量而言，这只是一个小部分）。作者的主要动机是PCDM固有的大规模存储和数据处理需求。为此，空间组织的LAS文件被存储在HDFS中，并使用MySQL数据库来索引这些LAS文件。其解决方案还在每个节点中集成了LAStools，以生成与MapReduce框架的兼容性，从而实现LAS文件操作并支持机器学习工作。
虽然[22,29]构建了无共享架构的解决方案，但这些解决方案采用了一种混合方法，在同一系统中共存了LAS文件格式和数据库解决方案。因此，完全的数据独立性这一采用数据库进行PCDM的主要目标并未得到保证。因此，本评论的其余部分将专注于纯数据库存储解决方案。
Database-Oriented Shared-Nothing Architecture-Based PCDM
一些关于无共享架构的PCDM的重要研究包括[3,33,34]。从理论上讲，这些系统对大数据量具有高度可扩展性。然而，这些基于无共享架构的PCDM系统仅在最多14亿个点上进行了评估。具体而言，文献[3,33,34]分别测试了最多14亿、2.73亿和8.12亿个点，但明确展示了无共享架构PCDM系统的潜在可扩展性。在某些情况下，横向扩展的PCDM相比于基于共享内存架构的PostgreSQL/PostGIS PCDM系统，表现出了更好的可扩展性和性能，这归因于无共享架构中资源的更高可用性。
除上述基于无共享架构的PCDM研究外，GeoWave、EarthServer/RASDAMAN和TileDB也在无共享架构环境中提供PCDM支持。表3概述了现有的基于无共享架构的PCDM解决方案。根据表3，采用无共享架构的PCDM系统主要基于宽列模型或数组模型。此外，基于MPI的高度同步计算主要应用于基于数组模型的PCDM系统。这些系统（如TileDB和EarthServer/RASDAMAN）分别使用HDFS/S3和PostgreSQL作为数据存储介质。相比之下，基于宽列模型的PCDM系统使用HBase和Accumulo数据库。此外，与MPI不同，这些基于HBase和Accumulo的PCDM系统采用Hadoop/MapReduce或Hadoop/Spark数据处理框架作为其多节点计算框架。
与MPI相比，Hadoop/MapReduce和Hadoop/Spark中的计算并非高度同步。重要的是，Hadoop/MapReduce和Hadoop/Spark提供了更高层次的编程抽象，使程序员无需掌握底层硬件的专业知识。然而，了解底层硬件将使Hadoop/MapReduce和Hadoop/Spark程序更高效地利用底层硬件的并行性。因此，从实际角度来看，基于无共享架构的PCDM使用Hadoop/MapReduce和Hadoop/Spark相较于基于MPI的PCDM来说更为简单。
如6.2节所述，MPI可以在关系模型之上使用（例如在共享磁盘架构中的OEDBM）。然而，根据表3，基于MPI和关系模型的PCDM并不普遍。因此，在横向扩展架构中采用MPI和关系数据模型可能是一个具有潜力的方向，特别是在数据复杂性方面可扩展性微不足道的情况下。
如第5节和6.2节所述，采用数组模型需要放弃点云的原生格式。然而，如第5节所述，点云数据必须被视为主要数据集，其保留以及与任何后处理的连接需要保留。这种思维模式的价值已经在太阳能潜力分析的背景下得到验证，其中中间输出是阴影分析所需的最终输出。在数组模型中，原生点云格式被转换为栅格格式。因此，尽管EarthServer/RASDAMAN和TileDB等系统可以横向扩展到多个独立节点以高效管理所需的数据量和流量，但处理数据复杂性仍然具有挑战性。
值得注意的是，由于HBase和Accumulo NoSQL数据库放宽了遵循严格模式的要求，构建在HBase和Accumulo之上的系统可以在适应数据复杂性方面提供更大的可扩展性。因此，[69]认为在HBase或Accumulo基础上的系统，如GeoWave，管理点云数据将有助于满足异构点云数据的需求。此外，基于HBase和Accumulo构建的系统提供了灵活性，可以扩展到大量节点。因此，从理论上讲，采用HBase或Accumulo的系统，如用于PCDM的宽列数据库，可以在数据量和流量以及数据复杂性方面实现更大的可扩展性。
另外，键值数据库和宽列数据库针对写密集型工作负载进行了优化。这些数据库通常建立在基于日志结构合并树（LSM tree）的存储引擎之上，而非通常建立在B树结构上的读优化存储引擎。通常，一旦点云数据被摄取，PCDM系统预计将主要执行读密集型任务。因此，采用写密集型数据库在系统设计目标方面看似矛盾。然而，在LSM树数据库（如HBase）中期待读优化的场景下，可以调整布隆过滤器。然而，现有的采用HBase的PCDM研究尚未探索布隆过滤器调整可能带来的潜在收益。
与基于共享内存架构的PCDM系统类似，基于无共享架构的PCDM系统也致力于实现高效的空间索引策略以便检索点云数据。表3显示，除TileDB，[34]和EarthServer/RASDAMAN系统外，其他使用HBase或Accumulo等数据库的研究工作在点云数据上实现了空间索引。这些努力主要测试了两种变体的空间填充曲线（SFCs）：Hilbert SFC和Morton曲线。在基于宽列数据库的PCDM中实现其他基于空间的点访问技术（如四叉树等层次索引）并未出现在同行评审的PCDM文献中。然而，已经有尝试在MD-HBase上实现四叉树，作者展示了使用磁盘上的持久四叉树数据结构来执行一系列范围和k近邻查询中的2D点数据检索。因此，在宽列数据库上实现如四叉树这样的数据结构用于PCDM可以被视为未来的潜在研究方向，特别是针对3D点云数据的空间查询。
无共享架构的采用也扩展到全波形（FWF）-LiDAR数据管理。与点云数据中的离散点不同，FWF-LiDAR包括原始信号的全波形版本。这包括脉冲组件，即表示激光束位置和方向的线段；波组件，即一系列信号幅度值；以及点组件，即脉冲和波组件处理的衍生物。FWF-LiDAR中的丰富信息提供了对扫描场景的更深入了解，但需要更多的存储和计算能力。为应对这一需求，Vo等人开发了一种新的时空索引技术和可扩展的数据管理解决方案，通过采用HBase数据库管理FWF-LiDAR数据。Vo等人的空间索引策略采用了六维Hilbert索引，该索引基于FWF-LiDAR的脉冲组件的两个边缘的x、y和z坐标。时间索引基于飞行线ID，每个脉冲组件在FWF-LiDAR数据中都是唯一的。
如第4节所述，在采用无共享架构时，增加节点是提高性能的一种手段。例如，在[51,78,80,81]的工作中，增加节点在各自的空间数据管理系统中改善了数据查询和数据加载性能。然而，在PCDM的背景下，到目前为止，只有[33]提供了在3、5和9个节点下这一潜力的充分证据。尽管该实验清楚地描绘了无共享架构在性能提升方面的益处，但仍需通过多数据集、各种标准查询和其他预期操作（如数据加载和并发数据查询）进行更系统的测试。
Comparison of Scalability and Performance of Current PCDM Systems
在本节中，将全面概述当前PCDM解决方案的基础架构和数据模型，以及其他相关的关键信息，重点介绍它们在存储、查询和加载方面的可扩展性潜力和显著性能特点。
在PCDM研究中，实现可扩展性并确保可接受的性能是最终目标。 到目前为止，几乎所有的PCDM实验都展示了一定程度的数据量可扩展性，但由于使用了不同的硬件、各种数据集和不同的查询，因此不容易进行比较。可以说，最可靠的实验比较方法是进行类似于van Oosterom等人所做的系统基准测试。这样的方法可以直接比较具有不同数据模型和不同索引技术的系统。
目前尚缺乏此类实验，这大大增加了PCDM系统之间进行有意义比较的复杂性。尽管存在这些已知的限制，现有比较的评估仍能提供一些见解。因此，提供了表4来进行参考。
Inspect Performance Results of Current PCDM Systems
表4和图1总结了目前主要PCDM系统在存储性能、数据加载性能和窗口查询性能方面的结果。重点放在窗口查询上，因为它们在所有PCDM实验中广泛使用，尽管存在一些差异。例如，参考文献[19]主要基于2D窗口查询和kNN查询，而参考文献[3]则采用3D窗口查询。
由于将所有实验结果汇总在一个表中需要广泛的整合，因此在构建表4时做了具体的考虑，包括：
- 在测试不同数据集大小的情况下，报告最大的结果。
- 提供适当的附加信息，如加载时使用的线程数量、窗口查询的性质、使用的空间索引和实施的存储模型。
- 数据存储主要通过考虑总磁盘/内存使用情况来确定，即在分别提供索引和数据大小的实验中，报告两者的总和（即总存储消耗）。
- 尽管报告的结果受到数据异质性的影响，但由于没有简单的方法进行表征，因此必须将其视为报告中的不确定性。
关于图1，几个PCDM系统的数据加载速度和存储成本显著较高（即为离群值）。为了在图1中保持空间和清晰度，离群数据点显示在主绘图区域之外。
基于表4和图1的当前实验场景，可以得出以下观察结果：
- OEDBM PCDM系统（基于多节点共享磁盘架构的关系数据库导向的PCDM系统）具有最高的点/秒比。
- OEDBM PCDM系统在字节/点比（即每点的字节数）方面也表现最好，得益于内置的压缩机制（即查询高压缩模式）。
- 在PostgreSQL/PostGIS导向的PCDM系统中：
- 参考文献[19]中实现的块模型在字节/点比方面表现最低（使用3000点的块）。
- 该系统在PostgreSQL/PostGIS系统中具有最高的点/加载时间比。
- 在Oracle数据库导向的PCDM系统中：
- 参考文献[19]中实现的Oracle平面模型具有最高的点/加载时间比。
- 实现的Oracle块模型在字节/点比方面表现最好。
- 在基于MonetDB的系统中：
- Morton-relaceXY实现的字节/点比更好。
- Imprints索引实现的点/加载时间比更好。
- 对于LiDAR点云数据，2D窗口查询的研究比3D范围或kNN查询更为普遍。
- 数据加载和并发数据查询可以并行进行。然而，许多研究人员并未明确探索加载和查询中的并行性。
在汇总表4的数据加载结果、查询结果和存储结果的过程中，发现了一些基于共享无架构的PCDM研究实验报告中的显著差距，这些差距应在未来的报告中出现，包括：
- 数据库中的复制因子（例如，在HBase中，默认的复制因子为3，即在数据库中存储三份数据）。
- 数据加载过程中使用的节点数量。
- 数据检索过程中产生的通信成本（这是一种开销）。
- 索引大小。
- 点云数据在节点间的分布。
这些信息非常重要。例如，根据参考文献[3]，PostgreSQL/PostGIS消耗21.0字节存储一个LiDAR点记录，而HBase模型-4消耗28.4字节每点。假设参考文献[3]中的HBase数据库配置了默认的复制因子3，可以认为28.4字节值代表3个点的存储需求，而不是一个点。如果是这样，那么参考文献[3]的最佳场景的存储性能几乎比PostreSQL/PostGIS系统高出100％的效率。然而，由于这些信息不可用，无法在没有进一步实验的情况下得出这样的结论。同样，参与数据加载过程的节点数量、索引大小和数据通信所花费的时间等信息，对于深入分析基于共享无架构的PCDM系统的可扩展性和性能至关重要。
当前最先进的PCDM系统是基于并行架构实现的。迄今为止发表的实验表明，基于共享内存架构的PCDM系统在处理大数据量时可能会导致可扩展性和性能不佳。此外，当前基于共享内存架构的PCDM系统无法支持数据的异质性，因为这些系统基于关系数据模型。同样，基于共享磁盘架构的PCDM系统在面对数据复杂性时展示了有限的可扩展性。然而，在当前的PCDM文献中，基于共享磁盘架构的PCDM系统是唯一经过测试的大规模数据集（即高达6400亿点）的数据库导向的PCDM系统；相比之下，当前基于共享无架构的PCDM系统最多测试了14亿点。
在支持数据复杂性方面，利用HBase和Accumulo的基于共享无架构的系统展示了很大的潜力。对于并发数据访问或流量可扩展性方面的可扩展性，PCDM [19]强调这是一个重要的方面。然而，PCDM可扩展性（关于不同流量量）研究不足，到目前为止的查询都是2D窗口查询，较少尝试3D窗口和kNN查询。
Discussion
讨论开发新的可扩展、高性能PCDM系统时出现的问题以及强调PCDM研究领域的关键差距是至关重要的。因此，本节提供了在特定需求出现时选择并行架构和数据模型的指导，同时也提出了未来研究的方向。
Guide to Selecting Parallel Architectures and Data Models for PCDM
图2展示了实现高度可扩展、高性能PCDM系统的途径。从并行架构的角度来看，共享无架构相比共享内存和共享磁盘架构在数据模型选择上提供了更多的灵活性。同样，从数据模型的角度来看，关系数据模型（包括对象-关系、列式关系等）提供了更多的灵活性，因为它们可以部署在任何并行架构中。
此外，如果主要选择共享内存架构，可用的数据模型将是关系模型和NewSQL模型。而共享磁盘架构则限于数组和关系模型。
虽然如前所述，NoSQL模型在可扩展性和性能方面本质上优于关系模型，但NoSQL模型主要设计用于部署在共享无架构中。因此，采用宽列和/或键值数据库将要求PCDM系统开发者坚持使用共享无架构，这可能会限制某些类型的查询。
图2提供了选择PCDM并行架构和数据模型的一些广泛指南。然而，基于本文提供的评审，选择特定的并行架构和数据模型需要仔细考虑，以确保在数据规模和复杂性方面的可接受性能和未来可用性。
具体来说，选择并行架构和数据模型应通过对预期PCDM系统的特定需求进行仔细调查来进行。从决策的角度来看，这些需求可以主要分为三个领域，即：(i) 预期点云数据量的变化，(ii) 预期流量量的变化，以及 (iii) 其他PCDM系统需求（例如，与数据模型/数据库和点云数据固有特性相关的需求）。
图3和图4提供了关于预期流量和点云数据量变化的决策工作流程。从评审来看，所有并行架构都能够为PCDM提供可扩展性和相应的性能。然而，正如评审中所强调的，PCDM系统的可扩展性和性能已经在明确定义的数据规模上进行了测试。因此，每个实验中要管理的最大数据规模是预先已知的。在这种情况下，采用任何并行架构都是可能的。这种灵活性是允许的，因为所需的存储和数据处理能力可以明确地设计到并行架构中，并且可以考虑更广泛的数据模型（如图2所示）。
在预期数据和/或流量未知但预计会有显著变化的情况下，共享无并行架构似乎更为合适。确实，如图3和图4所示，共享内存或共享磁盘并行架构的能力可能成为潜在的障碍。
虽然对并行架构的直觉可以基于PCDM系统中点云数据量和流量需求的预期变化，但其他与系统相关的需求可以为选择最合适的数据模型提供更好的见解。为此，表5概述了可用于特定PCDM系统开发需求的数据模型（请注意，表5中的列名为宽列，而不是NoSQL。原因是，在当前的PCDM阶段，宽列是唯一在完整数据库导向PCDM中实验的NoSQL模型）。例如，如果更高的可扩展性和性能是基本需求，NewSQL模型和宽列NoSQL模型可能提供具有竞争力的解决方案。虽然数组数据模型是可扩展的，但据我们所知，数组数据库的可扩展性尚未直接与NewSQL和NoSQL模型进行比较。同样，如果ACID需求和/或固定模式需求和/或点云数据或数据集之间的关系是优先考虑的，关系、NewSQL和数组模型可能提供更可行的解决方案。另一方面，如果异构点云数据集合是优先需求，应该考虑宽列导向的NoSQL数据模型。图2-4和表5中描述的基本指南将促进高度可扩展高效能PCDM系统的战略决策。
Further Research Avenues
除了关于现有PCDM系统的差距和PCDM系统可扩展性与性能评估的讨论外，本综述还确定了PCDM研究可以投入更多精力的方向。以下分别讨论了现有PCDM系统和开发新PCDM系统的研究方向。
现有PCDM系统：
- 针对不断增长的流量量进行可扩展性和性能的实验。
- 设计展示数据复杂度下可扩展性和性能的实验。
开发新PCDM系统：
- 在共享无架构中部署行导向和列导向的关系数据库，并探索其可扩展性和性能。
- 探索NewSQL数据库在共享无架构中用于PCDM的途径。这包括探索图数据库、文档数据库和键值数据库（宽列之外的NoSQL数据库）的适用性。
如前所述，PCDM系统的可扩展性和性能主要通过不断增长的数据量来评估。在少数情况下，已探讨了并行加载。然而，在开发高度可扩展的数据密集型PCDM系统时，其他维度的可扩展性实验（即流量量和数据复杂度）同样重要。同样，新的数据模型的出现和这些新数据模型在共享无架构中的部署，承诺了更好的可扩展性和性能。因此，在开发新型PCDM系统时（例如，通过结合新数据模型和未探索的并行架构），务实的分析对未来PCDM研究至关重要。
最后，强调需要一个可扩展、灵活的框架来进行系统的测试、评估和比较异构PCDM系统的可扩展性和性能是重要的。如第6节所述，目前还没有系统的方法来评估现有PCDM系统的可扩展性和性能。因此，覆盖所有并行架构和数据模型的灵活可扩展框架是必要的。这样的框架需要涵盖点云数据的特征，以便不同的数据集可以直接比较。此外，还应纳入存储性能、查询性能和数据加载性能等性能维度。我们相信，这样的框架需要仔细分析PCDM实验和数据密集型系统特征化所涉及的步骤。
Conclusions
LiDAR点云数据是3D地理空间科学研究的重要来源。目前，这些本质上庞大且异质的数据集正在以前所未有的规模和密度被收集。当前，有越来越多的研究尝试开发高度可扩展且性能高效的PCDM解决方案。这些尝试基于不同的并行架构和特定数据模型，已经产生了展示可扩展性和相应性能的结果。
在容量方面，通过采用符合关系模型和NewSQL模型的数据库，基于共享内存架构的PCDM系统已经成功被探索。另一方面，到目前为止，只有一个系统在管理共享磁盘架构中的点云数据方面展示了可扩展性和性能结果。展示共享磁盘PCDM系统的可扩展性和性能结果可以为PCDM研究提供重要的见解。最近，采用共享无架构和宽列NoSQL数据库的趋势逐渐显现。虽然共享无架构和宽列模型（以及一般的NoSQL模型）在理论上能够实现高性能和高可扩展性，但当前的结果不足以验证这些关于PCDM的理论主张。
对PCDM系统中并行架构和数据模型的可扩展性和性能的回顾，以及对最先进PCDM系统的评估，有助于识别在系统层面和核心研究层面上的关键研究空白。本次调查中确定的主要研究空白与现有PCDM系统的差距以及开发新型PCDM系统的差距有关。
本研究可以作为开发可扩展PCDM系统时战略决策的指南，涵盖三个主要领域：(i) 预期的点云数据量变化，(ii) 预期的流量量变化，(iii) 其他系统要求。最后，本研究确定了一个关键需求，即需要一个可扩展、灵活的框架，用于系统的测试、评估和比较异构PCDM系统的可扩展性和性能，这应在未来的研究中进行探索。
Scalability and Performance of LiDAR Point Cloud Data Management Systems A State-of-the-Art Review