Zero-Cost NDV Estimation from Columnar File Metadata
本文提出利用现有文件元数据估计列式文件中列的distinct values数量，通过逆向字典编码存储大小方程和统计极值值提供稳健估计，适用于排序或分区数据，适用于查询优化、GPU内存分配和数据分析。
2026-03-16 cs.DB
Bullion: A Column Store for Machine Learning
University of Maryland（马里兰大学）；ByteDance（字节跳动）
本文提出面向机器学习工作负载的列式存储系统 Bullion，通过优化稀疏特征编码、宽表投影管理、特征量化、质量感知顺序读取及级联编码框架，显著降低 I/O 成本并节省存储空间，为广告、推荐系统和生成式 AI 等场景提供高效数据基础设施支撑。
2024-11-19 cs.DB cs.LG
Fast Access to Columnar, Hierarchically Nested Data via Code Transformation
大数据查询系统以列式格式表示数据，以实现快速、有选择的访问，在某些情况下（例如Apache Drill），直接对列式数据执行计算，而无需行物化，从而避免运行时成本。然而，许多分析过程不能容易地或有效地表示为SQL。在高能物理中，大多数数据处理需要具有复杂依赖关系的嵌套循环。当面对这样的任务时，传统的方法是将列式数据转换回对象形式，通常需要付出一定的性能代价。本文描述了一种新的技术来转换过程代码，使其操作层次嵌套，列数据本机，没有行物化。它可以被看作是编译器在类型化抽象语法树上的传递，将对对象的引用重写为列数组查找。我们还将介绍转换后的代码和传统的面向对象的代码在高能物理上下文中的性能比较。
2017-11-03 cs.DB cs.IR cs.PL
Evolution of the ROOT Tree I/O
ROOT TTree数据格式编码数百PB的高能和核物理事件。它的列式布局驱动了快速分析，因为只有那些在给定分析中真正使用的部分（“分支”）才需要从存储中读取。它的独特功能是无缝的C++集成，允许用户直接存储他们的事件类，而无需显式定义数据模式。在这篇文章中，我们介绍了未来ROOT 7事件I/O的现状和计划。随着ROOT 7接口的现代化，我们的目标是健壮的，在可能的编译时安全的C++接口读取和写入事件数据。在性能方面，我们展示了使用ROOT新的实验I/O子系统的第一个基准测试，该子系统将最好的TTrees与列式数据格式的最新进展相结合。一个核心要素是高级逻辑数据布局（C++类）与低级物理数据布局（简单类型的存储支持嵌套向量）的强大分离。我们展示了新的，优化的物理数据布局如何加快串行化和并行化，并促进并行，矢量化和批量操作。这使得ROOT I/O能够在即将推出的超快NVRAM存储设备以及对象存储等无文件存储系统上以最佳方式运行。
2020-03-17 cs.DB hep-ex
A Storage Advisor for Hybrid-Store Databases
借助SAP HANA数据库，SAP提供了一个高性能的内存混合存储数据库。混合存储数据库--即支持面向行和面向列的数据管理的数据库--正变得越来越突出。虽然列式管理提供了分析大量数据的高性能功能，但面向行的存储可以更有效地处理事务点查询以及插入和更新。为了同时有效地利用这两种存储，出现了一个新的问题，即是面向行还是面向列存储给定的数据。我们使用存储顾问工具来解决这个问题，该工具支持数据库管理员做出这一决定。我们提出的存储顾问建议基于数据和查询特征的最佳存储;其核心是一个成本模型，用于估计和比较不同存储的查询执行时间。除了按表决策之外，我们的工具还考虑对数据进行水平和垂直分区并管理不同存储上的分区。我们评估了存储顾问在SAP HANA数据库中的使用情况;我们展示了建议的质量以及将数据存储在最佳存储中对于提高查询性能的好处。
2012-08-21 cs.DB
Breaking Database Lock-in: Agentic Regeneration of High Performance Storage Readers for Database Bypass
Cornell University（康奈尔大学）
研究分析工作负载面临的数据访问瓶颈问题，提出Jailbreak方法，利用大语言模型辅助代码合成绕过数据库引擎直接读取存储文件，在PostgreSQL和MySQL上评估，性能显著提升，证明该方法可打破数据库系统数据锁定。
2026-07-09 cs.AI cs.DB
GraphAr: An Efficient Storage Scheme for Graph Data in Data Lakes
本文提出 GraphAr 存储方案，通过创新的数据组织与编解码技术增强数据湖对 LPG 模型图数据的管理能力，在邻居检索、标签过滤和端到端工作负载上分别实现 4452 倍、14.8 倍和 29.5 倍加速。
2024-09-25 cs.DB
LST-Bench: Benchmarking Log-Structured Tables in the Cloud
本文提出 LST-Bench 框架及配套指标与基准包，用于系统评估云端 Delta Lake、Iceberg、Hudi 等日志结构表与处理引擎的协同性能。
2024-01-19 cs.DB
Compression and In-Situ Query Processing for Fine-Grained Array Lineage
本文提出DSLog存储系统及ProvRC压缩算法，用于高效存储和查询细粒度数组血统，实现最高2000倍存储压缩和20倍查询加速。
2024-05-27 cs.DB
Six Dimensions of Benchmarking Time-Series Databases
Karlsruhe Institute of Technology（卡尔斯鲁厄理工学院）
本文提出时序数据库基准测试框架SciTSv2，从六个维度评估四款不同存储引擎的TSDB，揭示单轴基准掩盖的架构行为，为架构师提供性能诊断与存储引擎选择依据。
2026-08-04 cs.DB
TSDF: A simple yet comprehensive, unified data storage and exchange format standard for digital biosensor data in health applications
数字传感器越来越多地用于监测生物健康和疾病中生理过程随时间的变化，通常使用可穿戴设备。这产生了非常大量的数字传感器数据，尚未就共同的存储、交换和存档数据格式标准达成共识。为了解决这一差距，我们提出了时间序列数据格式（TSDF）：一个统一的，标准化的格式存储所有类型的生理传感器数据，在不同的疾病领域。我们提出了一系列的格式设计标准，并详细审查目前的存储和交换格式。当根据这些标准进行判断时，我们发现这些当前格式缺乏，并提出了一个非常简单，直观的标准，用于数字传感器数据和元数据，基于原始二进制数据和JSON格式的文本文件，分别用于传感器测量/时间戳和元数据。通过关注不同生物传感器数据的共同特征，我们定义了一组必要且足够的元数据字段，用于存储、处理、交换、存档和可靠地解释多通道生物时间序列数据。我们的目标是这种标准化的格式，以提高数据的可解释性和可交换性，从而有助于科学的再现性，在研究中，数字生物传感器数据形成一个关键的证据基础。
2022-11-22 cs.DB
Thallus: An RDMA-based Columnar Data Transport Protocol
针对 Apache Arrow 列式数据在 TCP/IP 传输中的序列化与内存拷贝开销，本文基于 Thallium 和 RDMA over Infiniband 设计实现零拷贝协议 Thallus，并证明其相较纯 RPC 方案有显著性能提升。
2024-12-03 cs.DB cs.DC cs.OS
Exploring Object Stores for High-Energy Physics Data Storage
在过去的二十年里，ROOT TTree已被用于存储超过1 EB的高能物理（HEP）事件。已经证明，TTree列式磁盘布局对于通常需要访问许多事件但仅访问为每个事件存储的信息的子集的HEP数据的分析是理想的。未来的对撞机，特别是HL-LHC，将使生成的数据量增加至少一个数量级。因此，使用现代存储硬件，如低延迟高带宽NVMe设备和分布式对象存储变得更加重要。然而，TTree并没有被设计成最佳地利用现代硬件，并且可能成为数据检索的瓶颈。ROOT RNTuple I/O系统旨在克服TTree的局限性，并为现代存储系统提供更高的效率。在本文中，我们通过使用英特尔DAOS作为底层存储的后端来扩展RNTuple，从而证明RNTuple架构可以容纳高性能的对象存储。从用户的角度来看，只需对代码进行最小的更改就可以访问数据，也就是说，通过用DAOS URI替换文件系统路径。我们的性能评估表明，新的后端可以用于现实的分析，同时优于DAOS项目提供的兼容性解决方案。
2021-07-15 cs.DB hep-ex
ParquetDB: A Lightweight Python Parquet-Based Database
ParquetDB是一种基于Parquet的轻量级Python数据库，通过列式存储和谓词下推提升大数据处理效率，优于SQLite和MongoDB，并在Alexandria 3D材料数据库中高效管理约480万条复杂记录。
2025-04-21 cs.DB physics.data-an
VSS: A Storage System for Video Analytics [Technical Report]
我们提出了一种新的视频存储系统（VSS），旨在解耦高层次的视频操作所需的低层次的细节存储和有效地检索视频数据。VSS被设计为视频数据管理系统（VDBMS）的存储子系统，并且负责：（1）以高效的粒度格式透明地和自动地在磁盘上排列数据;（2）以最有用的格式缓存频繁检索的区域;以及（3）消除从具有重叠视场的多个摄像机捕获的视频中发现的冗余。我们的研究结果表明，VSS可以提高VDBMS读取性能高达54%，降低存储成本高达45%，并使开发人员能够专注于应用程序逻辑，而不是视频存储和检索。
2021-03-30 cs.DB
Spatial Parquet: A Column File Format for Geospatial Data Lakes [Extended Version]
现代数据分析应用程序更喜欢使用列存储格式，因为它们通过编码和压缩提高了存储效率。Parquet是最流行的列数据存储文件格式，它提供了几个开箱即用的好处。然而，Parquet并不支持地理空间数据。本文介绍了Spatial Parquet，一个有效支持地理空间数据的Parquet扩展。Spatial Parquet继承了Parquet对非空间数据的所有优点，例如丰富的数据类型、压缩和列/行过滤。此外，它还增加了三个新功能，以适应地理空间数据。首先，它引入了一种地理空间数据类型，可以将所有标准空间数据类型编码为与Parquet兼容的列格式。其次，它增加了一种新的无损和高效的编码方法，称为FP-delta，该方法可定制为有效地存储以浮点格式存储的地理空间坐标。第三，它添加了一个轻量级的空间索引，允许读者跳过文件的非相关部分，以提高阅读效率。在大规模真实数据上的实验表明，SpatialParquet可以将数据大小减少三分之一，即使没有压缩。压缩可以进一步减小存储大小。此外，当应用轻量级索引时，Spatial Parquet可以将阅读时间减少两个数量级。这个初始原型可以打开新的研究方向，以进一步改善列格式的地理空间数据存储。
2022-09-05 cs.DB
Benchmarking Apache Arrow Flight -- A wire-speed protocol for data transfer, querying and microservices
在不同的大数据框架和/或数据仓库/存储系统之间移动结构化数据通常会导致显著的开销。大多数情况下，访问数据所花费的总时间的80%以上都是在序列化/反序列化步骤中花费的。列式数据格式在分析数据库和事务数据库中越来越流行。Apache Arrow是一种统一的列式内存数据格式，它承诺提供高效的数据存储、访问、操作和传输。此外，通过引入构建在gRPC之上的Arrow Flight通信功能，Arrow可以通过TCP网络实现高性能数据传输。Arrow Flight允许以平台和语言独立的方式通过网络进行并行Arrow RecordBatch传输，并基于开源标准提供高性能，并行性和安全性。在本文中，我们汇集了一些最近实现的Arrow Flight用例及其基准测试结果。这些用例包括批量Arrow数据传输，查询子系统和Flight作为微服务集成到不同的框架中，以显示该协议的吞吐量和可扩展性结果。我们表明，飞行是能够实现高达6000 MB/s和4800 MB/s的吞吐量分别为DoGet（）和DoPut（）操作。在Mellanox ConnectX-3或Connect-IB互连节点上，Flight可以利用高达95%的总可用带宽。Flight是可扩展的，可以有效地使用多达一半的可用系统核心进行双向通信。对于像Dremio这样的查询系统，Flight比ODBC和turbodbc协议快一个数量级。与turbodb…
2022-04-08 cs.DB cs.DC cs.NI
OASIS: Object-based Analytics Storage for Intelligent SQL Query Offloading in Scientific Tabular Workloads
针对现有支持计算的对象存储系统在输出格式灵活性、算子支持范围、深层存储层级优化上的不足，本文提出OASIS系统，实现灵活输出、复杂算子支持与动态路径选择，在HPC科学查询场景下较现有方案最高提升32.7%的性能。
2025-09-02 cs.DB cs.DC
Optimizing Tensor Programs on Flexible Storage
张量程序通常需要处理大型张量（向量，矩阵或高阶张量），这些张量需要专门的存储格式用于其内存布局。在文献中已经提出了几种这样的布局，例如坐标格式，压缩稀疏行格式和许多其他格式，这些格式专门设计用于最佳地存储具有特定稀疏属性的张量。然而，现有的张量处理系统需要专门的扩展，以便利用每一种新的存储格式。在本文中，我们描述了一个系统，允许用户定义灵活的存储格式的声明性张量查询语言，类似于张量程序所使用的语言。程序员只需要编写存储映射，它以声明的方式描述张量在主存中的布局。然后，我们描述了一个基于成本的优化器，优化张量程序的特定内存布局。我们证明经验显着的性能改进相比，最先进的张量处理系统。
2022-10-12 cs.DB cs.PL
Do GPUs Really Need New Tabular File Formats?
TU Darmstadt（达姆施塔特工业大学）；DFKI（德国人工智能研究中心）
研究 Parquet 配置对 GPU 扫描性能的影响，发现通过 GPU 感知的配置优化，无需修改格式即可大幅提升有效读取带宽。
2026-05-26 cs.DB cs.DC
Dynamic and Scalable Data Preparation for Object-Centric Process Mining
本文针对对象中心化过程挖掘中现有事件日志格式在流式数据场景下灵活性、可扩展性和可维护性不足的问题，提出了一种基于中心辐射型架构的中间数据存储枢纽数据库格式及新型关系模式，并通过轻量级开源数据栈实现端到端方案加以验证。
2024-10-01 cs.DB
VStore: A Data Store for Analytics on Large Videos
我们提出VStore，一个数据存储，用于支持对大型归档视频进行快速，资源高效的分析。VStore管理视频摄取、存储、检索和消费。它控制视频数据路径上的视频格式，面临着以下挑战：i）视频格式旋钮的巨大组合空间; ii）这些旋钮的复杂影响及其高配置成本; iii）针对多种资源类型进行优化。它探索了一种称为配置的反向推导的想法：沿着视频数据路径的相反方向，VStore将分析所期望的视频数量和质量反向传递到检索，存储和摄取。在这个过程中，VStore会导出一组最佳的视频格式，以渐进的方式针对不同的资源进行优化。VStore自动导出大型复杂的配置，包括超过100个旋钮和数十种视频格式。响应于查询，VStore选择迎合所执行的操作符和目标准确性的视频格式。它将视频数据从磁盘通过解码器传输到操作员。它运行查询的速度是视频实时的362倍。
2019-02-17 cs.DB
Storage, Indexing, Query Processing, and Benchmarking in Centralized and Distributed RDF Engines: A Survey
语义网和关联数据的最新进展已经改变了传统网络的工作方式。资源描述框架（RDF）格式被广泛采用，用于保存基于网络的数据。这种大规模的采用为各种集中式和分布式RDF处理引擎的开发铺平了道路。这些引擎采用各种机制来实现查询处理引擎的关键组件，例如数据存储、索引、语言支持和查询执行。所有这些组件都控制查询的执行方式，并对查询运行时产生重大影响。例如，以各种方式存储RDF数据会显著影响所需的数据存储空间和查询运行时性能。RDF引擎中使用的索引方法类型对于快速数据查找至关重要。底层查询语言的类型（例如，SPARQL或SQL）是RDF存储解决方案的关键优化组件。最后，涉及不同联接顺序的查询执行会显著影响查询响应时间。本文从存储、索引、语言支持和查询执行等方面对集中式和分布式RDF引擎进行了全面的综述。
2020-09-23 cs.DB
Column-Oriented Storage Techniques for MapReduce
MapReduce的用户在扩展工作负载时经常会遇到性能问题。他们遇到的许多问题都可以通过应用从三十多年的并行DBMS研究中学到的技术来克服。然而，将这些技术转换为MapReduce实现（如Hadoop）带来了独特的挑战，可能会导致新的设计选择。本文描述了如何将面向列的存储技术以保留其流行编程API的方式并入Hadoop中。我们表明，在Hadoop中简单地使用二进制存储格式可以提供3倍的性能提升，而不是简单地使用文本文件。然后，我们介绍了一种面向列的存储格式，它与Hadoop的复制和调度约束兼容，并表明它可以在实际工作负载上加速MapReduce作业。我们还表明，处理复杂的列类型，如数组，映射和嵌套记录，这是常见的MapReduce作业，可以产生显着的CPU开销。最后，我们引入了一种新颖的跳表列格式和惰性记录构造策略，避免了重复不需要的记录，从而提供了额外的1.5倍性能提升。一个真正的内联网爬行的实验表明，我们的面向列的存储技术可以提高Hadoop中的地图阶段的性能多达两个数量级。
2011-05-21 cs.DB cs.DC
Space- and Time-Efficient Storage of LiDAR Point Clouds
LiDAR设备获得空间的3D表示。由于所得到的数据集的大尺寸，已经存在使用压缩并且呈现类似于紧凑数据结构的那些属性的一些属性的存储方法。具体地说，LAZ格式允许访问给定的数据或数据的一部分，而不必存储整个数据集，并提供所存储数据的不确定性。然而，LAZ格式仍然有一些缺点，应该面对的。在这项工作中，我们提出了一个新的紧凑的数据结构表示云的激光雷达点，支持高效的查询，提供索引功能，优于LAZ格式。
2019-12-26 cs.DB cs.DS
Storage Solutions for Big Data Systems: A Qualitative Study and Comparison
大数据系统开发充满了挑战，因为该技术承诺服务于各种应用领域和领域。通常，大数据系统设计中涉及的基本设计决策包括选择适当的存储和计算基础设施。在这个异构系统集成不同技术以优化解决特定现实问题的时代，大数据系统也不例外。就任何大数据系统的存储方面而言，这方面的主要方面是存储基础设施，NoSQL似乎是满足其需求的正确技术。然而，每个大数据应用程序都具有可变的数据特征，因此，相应的数据适合不同的数据模型。本文对面向文档、键值、图和宽列这四种主要数据模型的特点和用例进行了分析和比较。此外，还提供了80个NoSQL解决方案的功能分析，详细说明了开发人员在做出可能的选择时必须考虑的标准和要点。通常，大数据存储需要与执行引擎以及其他处理和可视化技术进行通信，以创建全面的解决方案。这就引出了大数据存储的第二个方面，即大数据文件格式。研究论文的后半部分比较了Hadoop可用的大数据文件格式的优点、缺点和可能的用例，Hadoop是大多数大数据计算技术的基础。分散存储和区块链被视为下一代大数据存储，其挑战和未来前景也被讨论。
2019-04-25 cs.DB cs.DC
Research on the efficiency of data loading and storage in Data Lakehouse architectures for the formation of analytical data systems
Ternopil Ivan Puluj National Technical University（捷尔诺波尔伊万普鲁日国立技术大学）
本文研究了三种主流数据湖系统在不同数据规模下的加载和存储效率，通过Apache Spark分析其处理结构化和半结构化数据的表现，确定最优架构以构建分析数据系统。
2026-04-23 cs.DB cs.DC
A self-contained and self-explanatory DNA storage system
目前DNA存储的研究主要集中在通过开发有效的编码和解码方案来提高存储密度，而缺乏对超长期数据存储和保留的不确定性的考虑。因此，目前的DNA存储系统往往不是独立的，这意味着它们必须求助于外部工具来恢复所存储的DNA数据。这可能会导致数据丢失的高风险，因为由于未来的高度不确定性，所需的工具可能无法使用。为了解决这个问题，我们在本文中提出了一个自包含的DNA存储系统，它可以在不依赖任何外部工具的情况下对其存储的数据进行自我解释。为此，我们设计了一个特定的DNA文件格式，从而开发了一个单独的存储方案，以减少数据冗余，而一个有效的索引是专为随机读取操作存储的数据文件。我们通过实验数据验证，所提出的自包含和自解释的方法不仅可以摆脱对外部工具的数据恢复的依赖，而且还可以最小化当要存储的数据量达到一定规模时所带来的数据冗余。
2022-08-09 cs.DB cs.ET cs.MM
