CN106021268B - 文件系统块级分层与协同分配 - Google Patents

文件系统块级分层与协同分配 Download PDF

Info

Publication number
CN106021268B
CN106021268B CN201610177924.8A CN201610177924A CN106021268B CN 106021268 B CN106021268 B CN 106021268B CN 201610177924 A CN201610177924 A CN 201610177924A CN 106021268 B CN106021268 B CN 106021268B
Authority
CN
China
Prior art keywords
block
file
sub
blocks
column
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610177924.8A
Other languages
English (en)
Other versions
CN106021268A (zh
Inventor
R·考什克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of CN106021268A publication Critical patent/CN106021268A/zh
Application granted granted Critical
Publication of CN106021268B publication Critical patent/CN106021268B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0685—Hybrid storage combining heterogeneous device types, e.g. hierarchical storage, hybrid arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/113—Details of archiving
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer Security & Cryptography (AREA)

Abstract

本申请涉及文件系统块级分层与协同分配。本发明的实施例涉及块内组织的存储放置。一种实施例包括获得文件系统中的文件。文件被分成多个块。所述多个块被分成至少两个相关的子块。在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设备上的文件内块组织的存储放置。

Description

文件系统块级分层与协同分配
技术领域
本发明的实施例涉及块内存储组织，并且，更具体而言，涉及文件块内分层和协同定位存储组织。
背景技术
术语“大数据”被用作又大又复杂以至于变得难以利用手边的数据库管理工具或传统数据处理应用来处理的数据集的任何集合的概括性术语。挑战包括捕获、策展(curation)、存储、搜索、共享、传送、分析和可视化。与具有相同数据总量的单独的较小集合相比，到更大数据集的趋势是由于可从单个大的相关数据集的分析得出的附加信息，从而允许找出发现业务趋势的相关性、确定科研质量、预防疾病、链接法律引用、打击犯罪以及确定实时道路交通情况。
大数据难以利用大多数关系数据库管理系统以及桌面统计和可视化包进行工作，而是代替地需要在数十、数百或者甚至数千台服务器上运行的大规模并行软件。什么被认为是“大数据”依赖于组织管理数据集的能力、并依赖于传统上在其领域中被用来处理和分析数据集的应用的能力而变化。大数据通常包括尺寸超过在容许的经过时间内管理和处理数据的常用软件工具的能力的数据集。
如本文所使用的，大型数据库是列式或混合列式数据库，其存储数据表作为数据列而不是作为数据行的部分并且包括至少一千兆兆字节的数据。这种大型数据库目前被用于其中非常大量的数据被存储、查询、聚集、分析和搜索的各种应用，诸如业务数据分析应用。现代业务数据分析应用对大量的数据计算聚集，以便沿越来越多的维度逐渐积累(roll-up)信息，诸如地域、人口、用户、产品，等等。传统上，在线业务分析数据库通过对数据库的重要部分执行顺序扫描来执行这种查询。由于日益增加的尺寸和维度，以及如今大型分析数据库的交互式查询响应时间的日益增加的重要性，通过扫描整个大型数据库来查询数据库是不可行的。除了大型数据库的尺寸，其它因素也使得利用已知技术对大型数据库进行低等待时间查询是困难的。例如，在在线分析数据库中，本质上特设(ad hoc)的数据库查询的百分比高，这使得难以为大型数据库建立索引。大量的维度使得诸如预先计算立方体的技术在空间和计算上都非常昂贵。
目前，这些大型分析数据库被存储在传统的数据存储设备上，诸如硬盘驱动器等。最近，在改善大型列式数据库的性能的尝试中，一些大型数据库已经被存储在高性能的存储设备上，诸如固态设备或闪速存储器等。虽然在高性能存储设备上存储大型数据库提高了对大型数据库的一些查询的速度，但是提高的性能是以高成本得到的，因为高性能存储设备要比传统的数据存储设备昂贵得多。
发明内容
本发明的实施例涉及文件内块存储组织。一种实施例包括一种方法，该方法包括获得文件系统中的文件。将文件分成多个块。将所述多个块分成至少两个相关的子块。在文件系统元数据布局中为所述至少两个子块确定在不同存储器设备上的文件内块组织的存储放置。
另一实施例包括用于块内存储器管理的计算机程序产品。该计算机程序产品包括具有体现在其中的程序代码的计算机可读存储介质。程序代码可由处理器执行，以便由处理器获得文件系统中的文件。处理器将文件分成多个块。处理器将多个块中的每个块分成至少两个相关的子块。由处理器在文件系统元数据布局中为所述至少两个相关子块确定在不同存储器设备上的文件内块组织的存储放置。
一种实施例包括一种方法，该方法包括获得文件系统中的文件的块。将块分成至少两个子块。在文件系统元数据布局中为所述至少两个子块确定在不同存储器设备上的文件内块分层和协同定位存储放置。
本发明的这些和其它特征、方面和优点将参考下面的描述、所附权利要求和附图变得被理解。
附图说明
图1示出了根据实施例的云计算节点。
图2示出了根据实施例的云计算环境。
图3示出了根据实施例的一组抽象模型层。
图4示出了根据实施例的在计算机系统/服务器中的特征的更多细节。
图5示出了表如何跨节点/集群中的计算机系统/服务器被逻辑地表示为分布式文件系统(DFS)块中的单个FlashQueryFile文件/布局。
图6示出了具有表中的数据值的行和列的原始关系。
图7示出了用于选择列的选择优化布局。
图8示出了预测模型的离线和运行时创建以引导运行时列数据放置的流程图。
图9示出了根据实施例的将块分割成子块。
图10示出了根据一种实施例的将来自图6的表的子块放置在闪存和HDD上。
图11示出了根据实施例的子块的文件内块分层和协同定位。
图12示出了根据实施例的用于文件内块组织的存储放置的过程的框图。
具体实施方式
以下参考根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图说明和/或框图来描述本发明的各方面。将理解，流程图说明和/或框图的每个方框及流程图说明和/或框图中方框的组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或者其它可编程数据处理装置的处理器，来产生一种机器，使得经由计算机或者其它可编程数据处理装置的处理器执行的指令产生用于实现在所述流程图和/或框图的一个或多个方框中所指定的功能/动作的装置。
大多数已知的数据库存储分层技术旨在在高性能、可随机存取的诸如“闪存层”的层上放置流行的、经常存取的数据。数据的流行程度以反应方式确定，由此，模块记录工作负荷的存取模式，并且，如果数据集开始被存取很多，则它被认为是流行的并且被移动到高性能层。这种反应技术遭受确定存取模式的反应时间和不能提供前期(upfront)性能保证之害。此外，这些技术当中大多数处于低得多的块级并且没有关于在列级处的数据的语义知识。
一种实施例提供包括获得文件系统中的文件的方法。文件被分成多个块。所述多个块中的每个块被分成至少两个相关的子块。在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设备上的文件内块组织的存储放置。应当指出的是，文件系统元数据具有文件系统元数据结构，也被称为“文件系统元数据布局”。文件系统元数据结构或文件系统元数据布局是指被文件系统用于存储文件系统元数据的布局或格式。文件系统元数据与文件系统元数据布局相关联。如果存储介质(例如，系统储存器34(图1))利用一个或多个盘实现，则文件系统元数据布局被称为文件系统盘布局。文件系统元数据布局可以改变，以支持添加到文件系统的新功能，或者支持不同的文件尺寸(例如，更大)。文件系统元数据包括描述用户数据的各种特性的信息字段。
在一种实施例中，文件内块组织的存储放置基于不同存储器设备(例如，固态驱动器(SSD)和硬盘驱动器(HDD))上的文件内块分层或协同定位。在一种实施例中，实现了由应用将通告(advisory)传递到文件系统以便将进入的文件块放置在特定的层/存储池上的机制。在一种实施例中，机制指定对文件块协同定位的约束。索引节点(inode)结构被修改来支持文件内分层并且两个块之间的关系被在索引节点结构中指定。应当指出的是，索引节点存在于文件系统中，或其上，并且表示关于文件的元数据。索引节点包含诸如所有权(用户、组)、存取模式(读、写、执行许可)和文件类型的信息。
云计算是一种服务交付模式，用于对共享的可配置计算资源池进行方便、按需的网络访问。可配置计算资源是能够以最小的管理成本或与服务提供者进行最少的交互就能快速部署和释放的资源，例如可以是网络、网络带宽、服务器、处理、内存、存储、应用、虚拟机和服务。这种云模式可以包括至少五个特征、至少三个服务模型和至少四个部署模型。
特征包括：
按需自助式服务：云的消费者在无需与服务提供者进行人为交互的情况下能够单方面自动地按需部署诸如服务器时间和网络存储等的计算能力。
广泛的网络接入：计算能力可以通过标准机制在网络上获取，这种标准机制促进了通过不同种类的瘦客户机平台或厚客户机平台(例如移动电话、膝上型电脑、个人数字助理PDA)对云的使用。
资源池：提供者的计算资源被归入资源池并通过多租户(multi-tenant)模式服务于多重消费者，其中按需将不同的实体资源和虚拟资源动态地分配和再分配。一般情况下，消费者不能控制或甚至并不知晓所提供的资源的确切位置，但可以在较高抽象程度上指定位置(例如国家、州或数据中心)，因此具有位置无关性。
迅速弹性：能够迅速、有弹性地(有时是自动地)部署计算能力，以实现快速扩展，并且能迅速释放来快速缩小。在消费者看来，用于部署的可用计算能力往往显得是无限的，并能在任意时候都能获取任意数量的计算能力。
可测量的服务：云系统通过利用适于服务类型(例如存储、处理、带宽和活跃用户帐号)的某种抽象程度的计量能力，自动地控制和优化资源效用。可以监测、控制和报告资源使用情况，为服务提供者和消费者双方提供透明度。
服务模型如下：
软件即服务(SaaS)：向消费者提供的能力是使用提供者在云基础架构上运行的应用的能力。可以通过诸如网络浏览器的瘦客户机接口(例如基于网络的电子邮件)从各种客户机设备访问应用。除了有限的特定于用户的应用配置设置外，消费者既不管理也不控制包括网络、服务器、操作系统、存储、乃至单个应用能力等的底层云基础架构。
平台即服务(PaaS)：向消费者提供的能力是在云基础架构上部署消费者创建或获得的应用，这些应用利用提供者支持的程序设计语言和工具创建。消费者既不管理也不控制包括网络、服务器、操作系统或存储的底层云基础架构，但对其部署的应用具有控制权，对应用托管环境配置可能也具有控制权。
基础架构即服务(IaaS)：向消费者提供的能力是消费者能够在其中部署并运行包括操作系统和应用的任意软件的处理、存储、网络和其他基础计算资源的能力。消费者既不管理也不控制底层的云基础架构，但是对操作系统、存储和其部署的应用具有控制权，对选择的网络组件(例如主机防火墙)可能具有有限的控制权。
部署模型如下：
私有云：云基础架构单独为某个组织运行。云基础架构可以由该组织或第三方管理并且可以存在于该组织内部或外部。
共同体云：云基础架构被若干组织共享并支持有共同利害关系(例如任务使命、安全要求、政策和合规考虑)的特定共同体。共同体云可以由共同体内的多个组织或第三方管理并且可以存在于该共同体内部或外部。
公共云：云基础架构向公众或大型产业群提供并由出售云服务的组织拥有。
混合云：云基础架构由两个或更多部署模型的云(私有云、共同体云或公共云)组成，这些云依然是独特的实体，但是通过使数据和应用能够移植的标准化技术或私有技术(例如用于云之间的负载平衡的云突发流量分担技术)绑定在一起。
云计算环境是面向服务的，特点集中在无状态性、低耦合性、模块性和语意的互操作性。云计算的核心是包含互连节点网络的基础架构。
现在参考图1，示出了根据实施例的云计算节点/群集的例子的示意图。云计算节点/群集10只是可以在存储/处理大数据中被使用的合适的云计算节点/群集的一个例子，并且不是要暗示关于本文所述实施例的使用范围或功能的任何限制。不管怎样，云计算节点/群集10都能够被实现和/或执行本文所阐述的任何功能。
在云计算节点/群集10中，存在多个计算机系统/服务器12，它们可以与众多其它通用或专用计算系统环境或配置一起进行操作。多个计算机系统/服务器12通过连接82(诸如光纤，等等)来连接。虽然在图1中示出一个计算机系统/服务器12的具体细节，但是所述细节适用于计算节点/群集10中的其它计算机系统/服务器12。可以适合与计算机系统/服务器12一起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于，个人计算机系统、服务器计算机系统、瘦客户端、胖客户端、手持或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络PC、小型计算机系统、大型机计算机系统以及包括任何以上系统或设备的分布式云计算环境，等等。
计算机系统/服务器12可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括执行特定的任务或者实现特定的抽象数据类型的例程、程序、目标程序、组件、逻辑、数据结构等。计算机系统/服务器12可以在通过通信网络链接的远程处理设备执行任务的分布式云计算环境中实施。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。
如图1所示，云计算节点10中的计算机系统/服务器12以通用计算设备的形式表现。计算机系统/服务器12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
处理器单元16包括处理电路(处理器电路)，以读取、处理和执行计算机可执行指令，如本领域技术人员理解的。
总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、图形加速端口、处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介质可以是能够被计算机系统/服务器12访问的任意可获得的介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)30和/或高速缓存存储器32。计算机系统/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图1未显示，通常称为“硬盘驱动器”、“硬盘”和/或“硬盘磁盘驱动器”)。尽管图1中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM，DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
作为例子但不是限制，存储器28可以包括操作系统、一个或多个应用程序、其它程序模块以及程序数据。操作系统、一个或多个应用程序、其它程序模块以及程序数据(或它们的某种组合)可以包括联网环境的实现。
此外，计算机系统/服务器12包括闪速存储器75(也被称为闪存)。如本文根据实施例所讨论的，闪速存储器75连同硬盘驱动器34一起存储大数据。闪速存储器75包括FlashQueryFile(闪存查询文件)80。FlashQueryFile 80可以存储在存储器28的其它部分中。FlashQueryFile 80具有执行如本文所描述的实施例的功能和/或方法的程序模块42(其可以是一个或多个软件应用)。FlashQueryFile 80可以实现本文进一步讨论的算法。虽然FlashQueryFile 80的特征在单个计算机系统/服务器12中被突出，但是FlashQueryFile80(及其功能)可以跨计算节点/群集10中的其它计算机系统/服务器12分布。FlashQueryFile 80被配置为具有实现本文讨论的实施例所需的所有软件元素。
计算机系统/服务器12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该计算机系统/服务器12交互的设备通信，和/或与使得该计算机系统/服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。并且，计算机系统/服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与计算机系统/服务器12的其它模块通信。应当明白，尽管图中未示出，其它硬件和/或软件模块可以与计算机系统/服务器12一起操作，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
现在参考图2，其中显示了示例性的云计算环境50。如图所示，云计算环境50包括云计算消费者使用的本地计算设备可以与其相通信的一个或者多个云计算节点10，本地计算设备例如可以是个人数字助理(PDA)或移动电话54A，台式电脑54B、笔记本电脑54C和/或汽车计算机系统54N。云计算节点10之间可以相互通信。可以在包括但不限于如上所述的私有云、共同体云、公共云或混合云或者它们的组合的一个或者多个网络中将云计算节点10进行物理或虚拟分组(图中未显示)。这样，云的消费者无需在本地计算设备上维护资源就能请求云计算环境50提供的基础架构即服务(IaaS)、平台即服务(PaaS)和/或软件即服务(SaaS)。应当理解，图2显示的各类计算设备54A-N仅仅是示意性的，云计算节点10以及云计算环境50可以与任意类型网络上和/或网络可寻址连接的任意类型的计算设备(例如使用网络浏览器)通信。
现在参考图3，其中显示了云计算环境50(图2)提供的一组功能抽象层。首先应当理解，图3所示的组件、层以及功能都仅仅是示意性的，本发明的实施例不限于此。如图3所示，提供下列层和对应功能：
硬件和软件层60包括硬件和软件部件。硬件部件的例子包括：大型机61；基于RISC(精简指令集计算机)体系架构的服务器62；服务器63；刀片服务器64；存储设备65；以及网络和联网部件66。在一些实施例中，软件部件包括网络应用服务器软件67和数据库软件68。
虚拟层70提供一个抽象层，该层可以提供下列虚拟实体的例子：虚拟服务器71、虚拟存储72、虚拟网络73(包括虚拟私有网络)、虚拟应用和操作系统74，以及虚拟客户端75。
在一个示例中，管理层80可以提供下述功能：资源供应功能81：提供用于在云计算环境中执行任务的计算资源和其它资源的动态获取；计量和定价功能82：在云计算环境内对资源的使用进行成本跟踪，并为此提供帐单和发票。在一个例子中，该资源可以包括应用软件许可。安全功能：为云的消费者和任务提供身份认证，为数据和其它资源提供保护。用户门户功能83：为消费者和系统管理员提供对云计算环境的访问。服务水平管理功能84：提供云计算资源的分配和管理，以满足必需的服务水平。服务水平协议(SLA)计划和履行功能85：为根据SLA预测的对云计算资源未来需求提供预先安排和供应。
工作负荷层90提供如下功能的例子：云计算环境可以用于该功能。从这个层可以提供的工作负荷和功能的例子包括：地图绘制与导航91；软件开发及生命周期管理92；虚拟教室教学提供93；数据分析处理94；事务处理95；以及块级分层和协同分配处理96。如以上所提到的，关于图3描述的所有前面的例子都仅仅是说明性的，并且本发明不限于这些例子。
应当理解，如本文所描述的一个或多个实施例的所有功能通常都由图4中所示的系统执行，其可以被有形地体现为程序/实用程序40的程序代码42的模块(图1)。但是，情况不必如此。更确切地说，本文所描述的功能可以由图3中所示的层60、70、80和90当中任何一个执行/实现和/或启用。
重申一遍，虽然本公开内容包括关于云计算的详细描述，但是本文所描述的教导的实现不限于云计算环境。更确切地说，本发明的实施例意在利用现在已知或以后开发的任何类型的群集计算环境来实现。
在大数据SQL分析中，数据库表被存储为专门的文件格式(例如，Parquet，ORCFile，等等)的文件。每种文件格式具有对文件进行读和写的相关联的IO串行器和解串器(串行解串器)。对于大数据，用于查询处理的存储性能可以通过以下来增强：通过使用IO高效的串行器/解串器(串行解串器)和列式布局来减少每个查询需要被扫描的数据、依靠用于更高IO吞吐量的向外扩展(scale-out)并行化，和/或充分利用更快的介质，诸如用于对数据快速存取的存储器或闪存。
现有技术的大数据SQL分析文件格式以及关联的串行器和解串器是为HDD设计的，其中所有的体系架构决策、数据结构、投影算法(projection algorithm)、选择算法(selection algorithm)和加入算法(join algorithm)，连同参数一起，都基于HDD的基本性能特性。给定HDD中固有的高寻道时间，尽可能多地避免随机I/O，并且强调顺序存取，因为顺序存取比HDD上的随机存取快几个数量级。充分利用更快和可随机存取的存储介质(诸如存储器层次结构中的闪存)的一种途径曾经是经由反应式分层。在反应式分层中，存储模块监视对数据的存取模式并将被频繁存取的数据移动到高性能闪存层(即，闪速存储器)。这种移动是透明地进行的，而没有任何应用察觉。其结果是，应用利用为硬盘固有地设计的相同算法、预取机制、应用程序接口(API)继续存取现在驻留在闪存上的数据。其结果是，所获得的性能只是可利用闪存优化算法和代码实现的性能的一小部分。如在现有技术中所使用的，当利用HDD-优化的算法和假设的同时在闪存中的现有结构化英语查询语言(SQL)文件格式中的一种的简单数据放置能够充分利用非常小的性能增益(performance gain)和细粒度数据跳过(data skipping)，而这种性能增益和细粒度数据跳过可利用此类可随机存取介质以其它方式实现。为了提取最佳每美元性能以证明(justify)闪存的更高成本是有道理的，从顺序存取HDD到诸如闪存的可随机存取的存储介质的过渡要求重新检查串行解串器的基本设计决定、数据布局、选择和投影算子。
图4示出了根据一种实施例的具有块级处理410的存储器28。一种优化技术涉及用于跨存储在计算机节点/群集10中的大数据的SQL的被称为FlashQueryFile 80的闪存优化的串行解串器。FlashQueryFile的选择算法104、投影算法106、摄入算法(ingestionalgorithm)102、由FlashRCFile提供的数据布局(布局)304以及元数据为诸如闪存(闪速存储器75)的可随机存取存储器进行优化，以产生提高的每美元性能。FlashQueryFile 80是存储分层察觉部，并且以应用察觉方式提供适合闪存的、流行列的子集在闪存层(闪速存储器75)中的预测放置(经由放置算法108)的机制。这允许FlashQueryFile 80对特设(adhoc)分析查询提供前期性能保证。通过借助于从根本上重新设计数据结构和元数据以允许细粒度的数据跳过并且通过充分利用谓词下推和晚期物化(late materialization)，从而在选择和投影期间只读取用于查询绝对必需的数据，FlashQueryFile 80减少了查询处理等待时间。FlashQueryFile 80还在其选择算法中采用数据存取并行化，这是通过闪存允许的内部IO并行化而成为可能的。FlashQueryFile 80仔细考虑在平衡扫描算法中的顺序和随机存取时闪存75的特性，这是非常重要的，因为每个随机存取也具有与之关联的API开销。如果API调用开销变成主导，则单纯地(Naively)制做多个小的随机存取而不是一个大的顺序存取实际上会损害性能。FlashQueryFile 80可以显示利用高性能IO API、对象串行化和解串以及能够得出闪存的性能优势的数据结构的重要性。使用固有地为硬盘设计的API，诸如积极地缓冲和预取的API，实际会否定闪存75的性能优点。如下面进一步描述的，根据一种或多种实施例，FlashQueryFile 80可以利用用于文件内块分层和/或文件内块协同定位的块级处理410来改进。
按照惯例，现有研究主要着眼于将闪存结合在更新繁重(update-heavy)、在线交易处理(OLTP)工作负荷当中。对于在分析处理(OLAP)工作负荷中充分利用闪存，已经做了一些工作。根据一种或多种实施例，FlashQueryFile 80为大数据分析查询处理提供闪存优化的串行解串器，并且通过文件内块放置和协同定位处理410来增强。
闪存没有容量受限的RAM那么贵并且对于被用作二级高速缓存也比添加额外的RAM好。关于使Hadoop对查询和迭代计算更快的大量最近的工作在很大程度上依赖于非常大的RAM尺寸。闪存可以比RAM实现高得多的每美元性能，因为它允许以低得多的成本得到比RAM高得多的容量。闪存也比硬盘节能和与能源成比例得多；另外，在能量成本的降低对总体拥有成本具有显著影响的地方，使之成为用于在大数据群集中进行存储的有吸引力的选择。此外，对于存储映射化简作业(Map Reduce job)的映射输出，闪存是非常期望的，并且使得导致显著数量中间数据的排序和其它基准的性能增加3倍。总体而言，闪存的高性能、小占用面积、低功耗、下降的价格和非易失性使其作为大数据集群中的存储层/高速缓存是非常期望的。
图5示出了根据实施例的表如何可以被逻辑地表示为单个FlashQueryFile文件/布局304，其(由FlashQueryFile 80)被分割(存储)成跨节点/群集10中的计算机系统/服务器12散布的多个分布式文件系统(DFS)块。虽然图5示出了存储在存储器28中的文件块301，但文件块301代表跨节点/群集10中的多个计算机系统/服务器12分布的各种文件块301。如下面所讨论的，图5还强调存储在闪速存储器75中的元数据标头。
因此，FlashQueryFile文件/布局304中的列被水平地划分成多个行组，每个行组都包含可配置数量的行。文件块301包含多个行组。FlashQueryFile 80在三个不同的层次维护元数据标头：1)称为RCHeader的块级标头，2)称为RGHeader的行组级标头，以及3)称为ColHeader的列级标头。标头(即，RCHeader 310、RGHeader 315和ColHeader 320)维护用于方便对必要数据的快速随机存取并允许细粒度的数据跳过的数据结构。元数据标头RCHeader 310、RGHeader 315和ColHeader 320每个都包括如下元数据：该元数据可以被FlashQueryFile 80读取以便在执行查询时(例如，查询的选择阶段/部分)确定何时跳过整个文件块(以及然后移到下一个文件块)、跳过行组(以及然后移到下一个行组)和/或跳过列(以及然后移到下一列)。作为例子，示出选择列325、低基数投影列330和非常高基数投影列335。
(文件块)RCHeader 310包含文件块中行组的个数(n_rgs)和版本号，版本号在部署的生命期间帮助FlashQueryFile 80软件跨文件块结构的各种版本维护向后和向前的兼容性。RGHeader 315标头包括文件块中行组的开始的偏移量(rg_offset)(或者rg_偏移量)和文件块中行组的尺寸(rg_size)(或者rg_尺寸)。RGHeader 315还包含行组中存在的行和列的数量。例如，如果行组的尺寸被配置为对文件块是1000万，则rg_rows(rg_行)字段将包含1000万作为值。
ColHeader 320维护用于文件块中各种可能的列布局的文件偏移量指针。列的字典的文件偏移量和尺寸被分别维护在u_offset(u_偏移量)和u_size(u_尺寸)中。对于为快速投影和选择而充分利用字典(例如，选择字典和/或投影字典)的FlashQueryFile布局填充u_offset和u_size字段。l_offset(l_偏移量)和l_size(l_尺寸)字段包含在投影优化布局中使用的查找结构的文件偏移量。字段d_offset(d_偏移量)和d_size(d_尺寸)包含被原样存储的列的数据的文件偏移量(例如，具有基数＝1的列被原样存储而无任何字典)。如由FlashQueryFile 80执行的，箭头341、342、343、344、345、346、347、348、349、350、351、352、353、354示出了元数据标头的关系和使用。箭头341-354示出了在文件块301中偏移量字段和该偏移量字段指向的数据结构之间的关系。
所有结构中的数据类型都已经被仔细地选择，从而保持合理的空间效率。FlashQueryFile 80在FlashQueryFile文件304中维护(由摄取算法102决定的)两个数据布局：一个优化用于查询的选择阶段/部分并且另一个优化用于查询的投影阶段/部分。虽然谓词值以及列的次序和数量跨特设查询变化，但一些列往往作为投影或选择列是流行的。例如，在TPCH数据集中，两个列，L_EXTENDEDPRICE(未示出)和L_DISCOUNT，是最流行的投影列。它们的流行是直观的，因为TPCH被建模为金融基准；这些数值列处理金钱并且聚合只能对数值发生。具有日期类型的列，诸如L_SHIPDATE，作为选择列是非常流行的，因为日期通常是分析查询中的重要方面。类似地，主键(primary key)和外键(foreign key)是流行的选择列。FlashQueryFile 80为列数据提供三种数据格式：优化用于流行的选择列的快速选择的一种格式，优化用于流行的投影列的快速投影的另一种格式，以及第三种格式是用于被用作投影和/或选择列的列的混合布局(在查询中不同的时间)。缺省布局是混合格式，其中，为了比混合布局更好的空间效率，管理员和/或(FlashQueryFile 80中的)预测器模块可以选择“仅选择”或“仅投影”布局。行业跟踪的早期分析已经发现，即使在特设分析查询中，选择列的集合也保持非常可预测。通过这种观察的指导，FlashQueryFile 80(经由摄取算法102)可选地允许用户和/或查询引擎将表中的一些列标记为如下列：仅投影列、仅选择列和/或投影列和选择列的组合。因此，FlashQueryFile80(经由摄取算法102)为了(在FlashQueryFile文件304中)空间效率而在其数据布局决定中充分利用用于这种信息的因素(即，在表中被标记为仅投影列、仅选择列和/或其组合的列的那些列)。摄取时间算法102在下面的表1中描述。应当指出的是，主键是唯一识别行的一列或一组列。每个表应当有主键，并且表不能有多于一个主键。主键特性可以被指定为列定义的一部分，如在表的第一列中，或者它可以被指定为CREATE TABLE语句的单独子句。外键是一个表中的一列或一组列，其值必须匹配另一(或同一)表的主键中的值。外键被认为是引用其主键。外键是用于维护数据完整性的机制。
表1：闪存优化的摄取算法
Figure GDA0002264959410000161
Figure GDA0002264959410000171
Figure GDA0002264959410000181
图6示出了表中具有数据值的列和行的原始关系401(数据库表“lineitem”)。该表被FlashQueryFile 80摄取到计算机系统/服务器10中，以便为闪速存储器进行优化。该表不存储在原始关系中。该表的块作为文件lineitem 601存储。当行被摄取到计算机系统/服务器10中时，串行器构建块，并且文件系统跨一个或多个系统/服务器10在群集上散布块。
图7示出了用于可变尺寸的流行投影列的(基本)选择优化布局。从图6中的表的原始关系401，图7中所示的选择优化数据布局402(通过用于存储的FlashQueryFile 80)已被设计为在选择子句/部分期间(例如，包含谓词的子句)方便快速谓词匹配并减少数据读取。对于每个可能的选择列，FlashQueryFile 80提取在列的每个行组中出现的独特值并且在选择字典403中连续存储独特值。列标头维护到独特值的起始的偏移量(off)。接下来，对于每个值，FlashQueryFile 80存储其中每个独特值在列中出现的行位置的集合的偏移量450(缩写为off和/或O)和长度(即，尺寸)(未在图7中示出，但在图5中示出)。最后，FlashQueryFile 80在行位置指定405中存储用于每个独特值的行位置的集合。偏移量450对应于用于个别独特值的行位置的每个收集/分组的位置。在元数据标头中，FlashQueryFile 80还对每个行组的列中的条目的maximum、minimum、mid、average和count保持跟踪(存储)。maximum指最大值，minimum指最小值，mid指中间值，average指列的每个行组中出现的平均值。count指列的行组中行的数量。与图6中原始关系表401相比，选择优化数据布局402是存储列C1而不必重复相同数据值的存储的不同方式。
大数据文件系统群集通常具有充当数据节点的多个服务器并且文件在摄取时被分割成块并跨该群集散布。每个块在数据集中包含可配置数量的行。在一种实施例中，FlashQueryFile 80将块分割为两个子块，其中一个子块包含被确定为合适闪存的流行列的子集，并且第二个子块包含剩余的列。
诸如闪存(Flash)的高性能、可随机存取的存储设备比HDD昂贵得多并且具有更小的容量。而且，闪存提供比HDD高10-1000倍的随机IOP，而顺序带宽只比HDD高3-7倍。因此，在闪存上放置仅要被顺序存取的数据比放置要被更多地随机存取的数据会实现更低的每美元性能。不是所有的流行数据都会通过放置在高性能、可随机存取的层上而产生高的每美元性能。实施例涉及仔细选择要放置在最有益的层上的列数据块以便获得最佳每美元性能的放置决策机制，其中块可以针对不同存储器类型(即，HDD和SDD/闪存)的索引节点(inode)数据结构而被协同定位。
用于大型数据库的历史和运行时查询信息也可被用来选择列的每个块存储在其上的存储设备。历史查询信息包括查询中列的每个块的使用类型(例如，select子句(即，投影)，where子句(即，选择)，加入(join)，等等)，查询的选择性，等等。历史查询信息被用来创建查询间和查询内列块关系图，其中边定义查询中任意两列之间的选择/投影/加入关系。每个关系边具有与之关联的权重，该权重是通过使用寻求最大化接受容量约束的查询的每美元性能的优化算法来确定的。在其中不存在历史查询日志的实施例中，(基于列块的)列关系图是基于进入的查询在运行时构建的。在摄取时，列关系图被排名并且每个列块被分配得分。得分越高的列块被放在越高性能的存储设备上。
用于存储大型数据库的多层企业存储系统可以包括与第一存储设备和第二存储设备通信的计算机系统(例如，计算机系统/服务器12(图1))。第一存储设备可以包括一个或多个高性能、可随机存取的存储设备，诸如闪存，而第二存储设备可以包括一个或多个低性能的存储设备，诸如HDD。计算机系统被配置为接收包括例如大型数据库的工作负荷，并且还被配置为在第一存储设备和第二存储设备每一个上面存储大型数据库的至少一列的块。在一种示例性实施例中，块可以在(lineitem 601的)索引节点1110(图11)上协同定位并且在第一存储器设备(例如，SDD数据块1121)和第二存储器设备(例如，HDD数据块1120)上分层。在示例性实施例中，基于列块的属性和基于任何可用的历史和运行时查询信息来确定列的每个块应当存储在第一存储设备和第二存储设备当中哪一个上。
在示例性实施例中，对于更有可能被随机存取的大型数据库的列的数据块被存储在第一存储设备中并且更有可能被顺序存取的列的数据块被存储在第二存储设备中。例如，如果列(即，查询的选择子句中的列)的一个或多个数据块具有低基数，则它将主要受益于被顺序存取，因为大量的行位置会匹配谓词并且因此应当被存储在第二存储设备中。另一方面，列的具有高基数的一个或多个数据块只会匹配几行，因此具有更多机会被随机存取并且被存储在第一存储设备上。在一种或多种实施例中，通过将更可能被随机存取的大型数据库的列的数据块仅存储在第一存储设备中，由第一存储设备实现的每美元性能增益可以被最大化。
在示例性实施例中，也可以基于第一存储设备和第二存储设备的特性来确定大型数据库的列的哪些块要存储在第一存储设备上。第一存储设备和第二存储设备的特性可以包括但不限于，顺序存取时间、随机存取时间、容量、等待时间，等等。在一种实施例中，如果大型数据库的列的数据块有可能被随机存取，那么，如果确定数据块将超过第一存储设备的容量的阈值百分比，则它们不能被存储在第一存储设备上。在一种或多种实施例中，第一存储设备和第二存储设备的性能特性是非常不同的，并且选择在哪个设备上存储列的每个数据块被设计为利用这些差异。
在一种或多种实施例中，大型数据库的列的每个数据块可以被计算机系统基于查询内和查询间加权列关系图的排名给予得分。在一种或多种实施例中，得分表示通过将列的数据块存储在第一存储设备而不是第二存储设备上将会实现的每美元的可能性能增益。然后，基于对于列的每个数据块的得分、每个列数据块的尺寸和第一存储设备的容量来选择要被存储在第一存储设备上的列的数据块。采用高性能存储设备的常见方法是将经常存取的、流行的数据块放置在这种设备上。但是，这种单纯的
Figure GDA0002264959410000211
技术不产生最佳的每美元性能。因此，在一种或多种实施例中，并不是所有流行的列数据块都将被放在第一存储设备中。例如，如果第一存储设备是闪存，则被非常频繁地但是以顺序方式存取的列的数据块可能不具有被选择用于将其存储在第一存储设备中的足够高的得分。通常被投影的列数据块比通常在查询的选择侧的列数据块被分配更高的权重。通常在选择子句中出现的列数据块的信息的部分(诸如独特值的字典)缺省地保存在第一存储设备上。排名将仅确定列数据块的包含用于每个独特值的行位置的剩余部分的放置。
图8示出了根据实施例的用于生成可被用来指引运行时列块数据放置决定的预测模型的过程800的流程图。在一种或多种实施例中，可以基于用于大型数据库的历史和运行时查询信息来确定列的每个数据块应当存储在多层企业存储系统的哪个存储设备上。如在方框802处所示，过程800通过接收包括要存储在多层企业存储系统中的大型数据库的工作负荷开始。接下来，如在决定方框804处所示，过程800包括确定对该工作负荷是否存在历史查询日志。如果存在历史查询日志，则过程800前进到方框806，并且分析针对该大型数据库的历史查询的查询日志。接下来，如在方框808处所示，过程800包括基于分析创建查询间和查询内加权列关系图。在一种或多种实施例中，查询中的每列基于其在“selection”(选择)、“projection”(投影)或“join”(加入)子句中的出现而连接到同一查询中的其它列。例如，都出现在投影子句中的两列将由“select-select”(选择-选择)关系进行连接。如果一列出现在“selection”子句中而另一列出现在“projection”子句中，则它们将由“select-where”(选择-地点)关系进行连接。如在方框810处所示，过程800还包括基于旨在对训练窗口中的查询最大化每美元性能的优化算法向列关系图分配权重。
如果历史查询日志不存在，则过程800前进到方框812，并且在运行时期间通过解析进入的查询而创建列关系图形式的预测模型。在一种或多种实施例中，对于“select”(选择)子句(即，正被投影的列)，将评估由具有该选择子句中的列的历史和运行时查询检查/投影的行的分布。如果由选择子句检查的行的百分比低，则其指示列仅在期望的行位置处可以通过被随机存取而获得性能。但是，如果由选择子句检查的行的百分比高于选择性阈值，则其指示该列应当被顺序存取。如在方框814处所示，过程800还包括利用新进入的查询信息更新列关系图。
因此，在一种或多种实施例中，有可能(stand to)通过被随机存取而获得性能的投影列将被分配更高的权重，使得它们具有让其数据块存储在第一存储设备上的更高机会。另一方面，将被顺序存取的列将被分配较低的权重，使得其数据块将具有被存储在第二存储设备上的更低机会。
在一种或多种实施例中，分析查询日志包括在大型数据库的列之间建立查询内关系图并且基于关系对性能的贡献向每个关系或者所连接的列之间的边分配权重。一旦权重被分配，列就基于得分被排名，该得分是进入的边的权重之和。在一种或多种实施例中，通过建模由历史日志中每个查询中的每列所经历的性能并最大化接受约束(诸如第一存储设备的尺寸)的性能来确定权重的值。
在一种实施例中，如果列被认为作为投影列是流行的并且查询日志指示在涉及该列的查询中通常检查低百分比的行，则将该列的数据块放置在第一存储设备中相较于将该列的数据块放置在第二存储设备中将导致性能提高。此外，如果第一存储设备允许高IO并行化，则将列的数据块放置在第一存储设备中相较于将该列的数据块放置在第二存储设备中将导致甚至更多的性能提高。在另一实施例中，如果列被认为作为投影列是流行的并且查询日志指示在涉及该列的查询中检查高百分比的行，则与将该列的数据块放置在第二存储设备中相比，将该列的数据块放置在第一存储设备中将导致较少性能增益(即，作为第一存储设备的闪存与作为第二存储设备的HDD相比的顺序带宽中的差异因子)。这种试探法指导由放置算法使用的查询内列图中的权重分配。
在一种实施例中，用于在大型数据库创建过程中将该大型数据库的列的数据块预测性地放置在多层企业存储系统中的过程包括接收包含要存储在多层企业存储系统中的大型数据库的工作负荷。该过程包括评估大型数据库的列的一个或多个属性。加权列关系图被排名并且列的关联排名被用来指导将其数据块放置在存储层次结构中。该过程还包括基于一个或多个属性确定大型数据库的列的每个数据块是应当存储在多层企业存储系统的第一还是第二存储设备上。在一种或多种实施例中，还可以基于该多层企业存储系统的存储设备的一个或多个特性确定列的每个数据块应当存储在多层企业存储系统的哪个存储设备上。
在一种或多种实施例中，在大型数据库已加载到多层企业存储系统之后，计算机系统将监视大型数据库的使用并且将周期性地在第一存储设备与第二存储设备之间移动大型数据库的列的数据块。因此，计算机系统将会基于进入的分析查询对列数据块的流行性以及运行时中列之间的关系的变化作出反应。列内关系图和列排名将对由运行时查询呈现出的模式作出反应而改变。未来的数据块放置决定也将相应地改变。
预测列放置闪存比HDD更昂贵并且具有更小的空间。为了证明闪存的较高成本是有道理的，重要的是将列的数据块的正确子集放在产生最高每美元性能的闪存中。不是所有列数据块都一样，并且通过放置在闪存中不会产生相同每美元性能。因为对于随机IOP，闪存比HDD快40-1000倍，而对于顺序存取只快2-7倍，因此当数据被随机存取时，闪存产生最高的每美元性能。与将只被顺序存取的列的数据块相比，放置将有可能被随机存取的列的数据块对利用闪存将更划算(bang for the buck)。
跨闪存层和HDD层分割列数据块的单纯方式是将流行的列数据块放置在闪存层中。即使在具有高百分比的特设查询的工作负荷中，一些列数据块也固有地跨查询或者作为选择或者作为投影列数据块更流行。虽然谓词值以及列的次序和数目跨查询而改变，但是一些列确实往往比其它列作为投影或选择列出现更多。
在一种或多种实施例中，本文所述的过程在多层存储系统中使用预测列数据块放置模型，该预测列数据块放置模型除了考虑列数据块的流行性，还考虑到几个额外的因素，以便跨查询产生最佳的每美元性能。考虑列数据块的各种属性，诸如它们的基数、排序次序、稀疏性及其列数据块分层决定中的尺寸。此外，通过分析历史(如果可用的话)和运行时查询日志来执行训练放置模型。如果历史查询日志不存在，则过程利用运行时查询的可配置窗口来训练运行时模型。利用查询日志创建查询内和查询间加权列关系图并且利用优化算法分配权重，该优化算法考虑列数据块特性及其通过被放置在闪存上而对增强每美元性能的影响。
或者在历史或者在运行时查询日志中的可配置数量的查询可被用于训练预测列数据块放置模型。针对查询窗口内的所有查询创建查询内和查询间列关系图。列之间的关系可以是选择-选择、投影-选择或者投影-投影。因为选择算法有可能从被放在闪存中获益最大，因此较高的权重被分配给投影-投影关系，并且如果任何一个投影列不放在闪存上，则放慢(bring down)查询。因为将一些列数据块部分地放置在闪存中不影响性能，所以选择-选择中的列获得最低的权重。
每个列的排名的被特征化为：
Figure GDA0002264959410000251
其中，cardinality是列中的独特值的百分比，如果该列被排序，则sort_order是1，否则是0，popularity是在所考虑的窗口内的查询中该列出现的次数，column_type指定列在查询中被使用的方式并且对于选择列是0，对于投影列是1，并且如果列以两种方式都使用则是2。在求和中，j属于与i处于对应关系(SS表示选择-选择，SP表示选择-投影，并且PP表示投影-投影)的邻居的列表。关系的权重依赖于训练数据中查询的选择性。
在一种或多种实施例中，如果查询的选择性低(即，很少行位置匹配谓词)，则投影算法对该行位置的文件偏移量进行点存取，以读取投影列的值。这变换成随机存取以及将投影列数据块放置在闪存中产生每美元高性能增益。另一方面，如果查询的选择性高，并有大量行位置匹配谓词，则投影算法回到顺序模式，其中投影算法群集行位置并且从投影列读取大块的数据。将投影列数据块放置在闪存中将不产生如前一场景中那么高的每美元性能增益。因此，查询的选择性对闪存中列数据块的性能有影响。
对于每个查询，列放置的所有可能组合的矩阵被用作独立的变量。例如，如果查询具有7列，则有128种可能的列数据放置组合，甚至具有更多的列数据块组合。列被表示为二进制，其中1表示放在闪存上并且0表示放在盘上。在查询等待时间(即，基线查询等待时间/分层查询等待时间)中观察到的加速和放置的成本构成从属变量。列放置组合的成本简单地就是闪存中其用于列放置的尺寸＊闪存存储器/GB的成本和假设要放在盘上的列的尺寸＊盘/GB的成本的因子。每种列组合对查询性能的影响(即，加速)针对查询窗口内的每个查询建模。除了列的特性和查询的选择性，在建模时还考虑硬盘和闪存的性能特性(例如，带宽)。
为简单起见，假设查询等待时间是存取查询中每个个别列所需的预期时间之和。令C＝c1，c2，...，ck是查询中出现的列。
Figure GDA0002264959410000261
令yi是表示列ci是放置在闪存中还是放置在HDD中的标记。
Figure GDA0002264959410000262
性能建模是基于早先讨论过的选择和投影算法。如果ci驻留在闪存上并且是选择列，则查询等待时间如下计算：
E[ci]＝(cardinalityi*RGsize+selectivity(q)*4/BWflash
(4)
根据选择算法，每个行组被并行处理，并且首先从每个行组读取对应于cardinalityi＊RG size的独特值，并且然后读取对应于selectivity(q)＊4的匹配行位置，其中selectivity(q)是被建模的查询的选择性并且4是每个行位置的尺寸。基线查询性能是通过利用盘带宽数顺序读取查询中的每一列来确定的。
如果c_{i}驻留在闪存上并且是投影列，则查询等待时间如下计算：
E[ci]＝selectivity(q)*fieldsizei/BWflash (5)
其中，selectivity(q)是查询的选择性并且fieldsizei是列ci的字段尺寸。这是投影算法的近似。
如果i驻留在盘上，则与利用现有技术算法的情况一样，它被整体读取。E[ci]＝sizei/BWhdd，其中sizei是文件中列的总尺寸。所得到的矩阵被优化，以产生列的有序集合，当该有序集合被放在闪存上时，为所有查询产生最大加速，同时最小化成本。然后，所得到的列集合被用来利用回归分析确定系数\alpha等的值。排名等式被用来确定出现在数据集中的每个新列的排名，以确定其在存储层次结构中的放置。列被排名并且列排名在确定列在闪存中的放置时使用；最高排名的列被放置在闪存中。在每一轮训练中，查询图利用窗口中的查询重新生成并且系数被重新确定，以确保预测模型的通用(currency)。
在数据库初始创建时，并且在缺少用于类似数据库的历史查询日志的情况下，自举放置算法基于观察到的列特性和试探法确定列的初始放置。在第一步中，被摄取的可配置数量的行被缓存在存储器中。从缓存的行学习特性(例如，基数、排序次序，等等)。
在一种或多种实施例中，自举算法还需要知道列作为选择或投影列的潜在用途。自举算法还尝试找出列的潜在流行性。潜在的流行性列可以以多种方式进行：1)由用户提供的提示，2)从数据集、字段类型、名称获取的见解，从应用获取的通告，等等。例如，在表中，主键和外键倾向于在大量查询中出现，并因此是固有地流行的选择列。在财务数据集中，具有货币属性的列(例如，税、折扣、价格、工资，等等)往往是用于聚集查询(aggregation query)的流行投影列。例如，在根据财务数据集建模的TPCH数据集中，在line item表中，l_discount和l_xtendedprice是最流行的投影列。
然后，试探法被用来基于先前确定的特性来确定列的放置。试探法由投影和选择算法通知。为了了解试探法背后的直觉知识，描述由选择算法通知的选择列的放置决定。算法中的第一部分涉及用于执行谓词匹配的独特值的顺序读取。由于第二部分涉及为匹配谓词的每个值读取行位置blob，因此其具有多得多的随机存取的可能。如果行位置blob尺寸小并且如果大量独特值匹配谓词，则算法的第二部分导致大量的随机存取。当列的基数高时，发生这种场景，并且在闪存中放置列数据块将产生选择算法的更高的每美元性能。另一方面，如果行位置blob尺寸非常大，则在谓词匹配后提取行位置blob导致少量的大顺序存取；这是在列具有低基数的情况下的典型的场景。将这种列数据块放在闪存中允许选择算法的较低的每美元性能。列的尺寸也在每美元性能产出中起到类似的作用。在列具有高基数的情况下放置试探法排名更高。
图9示出了根据实施例的将块910分割成子块920、922的例子。在一种实施例中，块910和关联的子块920和922利用文件lineitem601进行分割。然后，关联的子块920和922在SDD或闪存层930和HDD层940中在服务器12上协同定位。在一种实施例中，当行保持被摄取到数据库表401中时，FlashQueryFile 80的FlashQueryFile串行器构建文件系统块。FlashQueryFile串行器将每个文件系统块910分割成两个子块920和922：一个子块(子块920)包含闪存-最佳流行列的子集和可配置数量的行，并且另一个子块(子块922)包含数据库表401中剩余的列和与另一子块相同数量的行。
图10示出了根据一种实施例的将服务器(S1和S2)12上的来自图6被存储为lineitem文件601的表的子块放置到闪存75的SDD或闪存块和HDD 34的HDD块中。在一种实施例中，FlashQueryFile串行器使用块级处理410的由服务器/系统12的底层文件系统暴露的提供用于FlashQueryFile串行器的API(图4)来将两个子块(例如，子块920和922，图9)和它们的存储层通告传递到文件系统。此外，块级处理410的API向文件系统提供用于两个子块的协同定位通告-该协同定位通告建议文件系统将两个子块放在同一个服务器12上；但是，放在存储器块的不同层中(闪存层930/闪存块和HDD层940/HDD块)。
在一种实施例中，文件系统接收调用Write(子块1，层＝闪存，子块2，层＝HDD，协同定位＝真)。然后，文件系统定位在闪存层930/闪存块上具有用于子块1(例如，子块920)的足够空间并且在HDD层940/HDD块上具有用于子块2(例如，子块922)的足够空间的服务器12。一旦服务器12被定位，文件系统就将子块1放置在闪存层930/闪存块上并将子块2放在HDD层940/HDD块上。
基于上面定义的算法来确定OLAP数据库中的流行列(只读，并且数据只附加到表)。该算法在确定通过放置在SSD中而将优化性能的列(基于列是将被顺序还是更随机地存取)之前考虑几个因素，诸如尺寸、基数、数据分布，等等。根据实施例，除了对千兆兆字节数据的OLAP类型的用例(use case)，还有其它几种激励用例用于在GPFS和GPFS-FPO环境中都执行块级分层。块协同定位跨所有用例可能或可能不需要。下面的例子提供了其中块协同定位可能重要的用例：在Hadoop环境中，在诸如RCFile的常见DB文件格式中，表被表示为单个文件并且跨数据节点被分割。每个文件系统块包含固定数量的行。在一种或多种实施例中，块被分成将包含SSD友好的流行列的一块和将包含剩余列的另一块。在一种实施例中，同一数据节点上这两个分割块的协同定位由于许多原因而是重要的。如果查询涉及两种类型的列，则对HDD层上的列的存取不应当招致额外的网络等待时间(如果块被放在另一个节点上，这将会发生)。由于两个块共同驻留在该数据节点上，因此它们都可以由相同的映射任务处理。这对于性能将是重要的。如果其碎片目前被放在SSD上的行不再重要，则GPFS可能需要执行块的迁移。因为行可能再次流行并且可能需要执行向上分层返回到SSD层，因此维护块之间的协同定位信息将是重要的。在一种实施例中，协同定位信息有助于在同一数据节点上的正确层上放置数据块。在一种实施例中，在重新划分的情况下，分割的块需要被一起移动。
在hadoop环境中，OLAP表被以多个文件格式存储，例如，RCFile(混合行/列)、ORCFile(优化行/列)、CIF(列)，等等。文件被分成跨群集散布的块。每个块包含n个行组。查询引擎使用算法将RCFile块分成两块-一块具有流行的列元数据和数据并且另一块具有不流行的列元数据。在一种实施例中，查询引擎通过以下与底层文件系统接口，同时创建并加载RCFile：提供提示以将流行的列块放在SSD池上并且将不流行的列块放在HDD池上；以及指定用于行组的流行/不流行列块被放置在同一数据节点上的约束。在一种实施例中，因为来自不流行的列的数据可以从同一节点上的HDD提取而不招致网络成本，因此在同一节点上协同定位对性能是非常重要的。在一种或多种实施例中，FS需求包括：对文件跨存储池的块级分层的支持；对用于让应用对数据放置提供通告和约束的机制的支持；以及对在摄取、重新划分、迁移和向上分层期间维护流行和不流行块之间的关系并且共同放置它们的支持。
常规系统具有包括以下的存储级：非常少的语义信息；只有块的视图；粗粒度的决策；没有关于进入的数据在正确的层上的前期、最佳放置的摄取时间决定，因为它们本质上主要是反应式的；HSM：在文件系统的外部；依赖存根(stub)(例如，重新分析点，EA)来捕获到另一层的数据移动；单纯文件系统级分层：文件系统支持存储池(HDD，SSD，等等)并基于策略跨池移动文件；所有现有的文件系统(例如，GPFS、EMC的OneFS、StorNext，等等)在整个文件级执行文件系统分层，其中同一文件的不同块不能被放在不同的池上。大多数现有的方法(例如，Easy Tier)在摄取之后的时间被执行并且本质上是反应式的，由此，一旦系统认识到数据块中的一些被频繁存取，这些块就被移动到SSD层中。其结果是，常规系统不能提供前期性能保证。这些系统在系统堆栈中也低级得多并且没有可用于诸如文件系统的应用或更高层的语义知识。其它系统(例如，VerticaFlexStore)依靠用户对流行的列提供提示，并且将这种列放在SSD层上。这种系统有几个问题：1)用户可能甚至认识不到所有流行的列，并因此，这种提示是不全面的，2)如果流行性度量随时间改变，则这种静态方案不能捕获该变化，以及3)仅仅在SSD中单纯地放置所有的流行列可能甚至不可行，因为SSD的容量有限，并且因此，重要的是以选择或投影子句中列尺寸、预期选择性和列的存在性为准来优化流行列的放置。其它非分层解决方案依赖于近似查询处理来减少查询等待时间。在存储器中维护底层表的元组的高速缓存样本。
一种或多种实施例利用应用具有关于其数据的最多语义知识并且可以连同必要的查找信息一起分配和打包具有对SSD最适合的数据的数据块的事实。在一种实施例中，一种机制被用来向文件系统传递通告，以便将进入的文件块放置在特定的层/存储池上；对于数据块协同定位指定约束；索引节点结构被修改，以支持文件内分层；利用修改后的索引节点结构指定两个块之间的关系。
一种或多种实施例允许应用在文件摄取本身的时候对将数据块放置在期望层上进行控制，这提供了前期性能保证。一种或多种实施例允许文件系统：如果一些块呈现比其它块更高的热度，则向上分层这些块，并且，或者利用应用的通告或者响应于块热度变化而反应性地主动复制一些块。
在一种实施例中，应用为块分层提供通告和约束，并且文件系统选择对在它们各自的层上的块都具有空间的数据节点。文件系统为索引节点中的块创建条目并且表示索引节点中块之间的关系。在一种实施例中，有效的文件内分层不同于文件跨层的文件过渡迁移或失败的迁移。一种或多种实施例维护跨文件迁移、重新划分等的协同定位，以确保应用约束被兑现。
图11示出了根据实施例的文件内块分层和协同定位的例子1100。在一种实施例中，lineitem文件601(图6)的索引节点1110具有用于支持文件内级块分层和协同定位的子块关系的结构。在一种实施例中，通过在索引节点1110中添加块的SSD或闪存块列表1120中的子块920的信息或块的HDD块列表1130中的子块922的信息，更新lineitem文件601的索引节点1110。在一种实施例中，两个子块920和922之间的关系1140被记录，以说明两个子块920和922包含互补的信息。在一种实施例中，在随后的迁移、重新划分等期间使用这种关系。
一种或多种实施例利用用于HDD和SDD上两个子块的分层(即，文件内块分层)在索引节点1110上协同定位来自同一文件的文件块(即，文件内块协同定位)，以用于提供文件内块组织的存储放置。在一个例子中，来自文件的第一子块920作为HDD数据子块被分层并且来自该文件的第二子块922作为闪存或SDD数据子块被分层，从而用于文件内块分层。OLAP数据库中的流行列(只读，并且数据只附加到表)可以基于上述算法来确定，该算法在确定通过放在SSD或闪存分层中而将优化性能的列(基于列是将被顺序还是更随机地存取)之前考虑几个因素，诸如尺寸、基数、数据分布，等等。在一种实施例中，修改算法以确定列子块分层，并且来自同一文件的子块针对索引节点1110协同定位，以用于提供文件内块协同定位。
除了对千兆兆字节数据的OLAP类型的用例，还有用于在GPFS和GPFS-FPO环境二者中执行块级分层(文件内块分层)的几种其它激励用例。子块协同定位跨用例可能或可能不需要。下面的例子提供了其中文件内子块协同定位可能重要的用例。在Hadoop环境中，在诸如RCFile的常见DB文件格式中，表被表示为单个文件并且跨数据节点被分割。每个文件系统块包含固定数量的行。在一种实施例中，块被分割/划分成将包含闪存/SSD友好的流行列的一个子块和将包含剩余列的另一子块。在这种示例实施例中，由于以下的许多原因这两个分割的块在同一数据节点上的文件内块协同定位是重要的：1)如果查询涉及两种类型的列，则对HDD层上的列的存取不应当招致额外的网络等待时间(如果块被放在另一个节点上，这将会发生)。因为两个块它们共同驻留在该数据节点上，因此它们都可以由相同的映射任务处理，这对于性能是重要的；2)如果其碎片目前被放置在SSD上的行不再重要，则GPFS可能需要执行块的迁移。维护因为行可能再次流行并且可能需要执行向上分层返回到SSD层，因此维护块之间的协同定位信息将是重要的。协同定位信息有助于在同一数据节点上的正确层上放置块；3)在重新划分的情况下，分割的块需要被一起移动。
不是所有的块在文件中都一样并且一种或多种实施例将层(例如，SDD或闪存和HDD层)的性能与存储在文件块中的数据的重要性匹配。查询引擎具有关于表中各个列的相对重要性的多得多的语义信息并且可以以这样一种方式创建块：流行的被存取列信息/元组和索引被合并到文件块中。这种块将是针对闪存/SSD或类似这种更快的层的更大匹配。为了确保性能，在同一节点中协同分配具有用于匹配行组的剩余列的子块也是重要的。诸如Easy Tier的大多数分层解决方案在系统堆栈中低级得多并且没有可用于诸如文件系统的应用或更高层的语义知识。GPFS目前提供跨存储池的分层；但是，就像对于一种或多种实施例，分层仅仅是在文件级并且不在文件内块分层级。
图12是根据实施例的示出用于在文件系统中的文件内块组织存储放置的过程1200的框图。在一种实施例中，在方框1210中，在文件系统中获得文件。在一种实施例中，在方框1220中，文件被分成多个块(例如，2个或更多个)。在方框1230中，多个块中的每个块被分成至少两个相关的子块。在方框1240中，在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设备上的文件内块组织的存储放置。在一种实施例中，过程1200可以提供为至少两个相关的子块确定在不同存储器设备上的文件内块分层。在一种实施例中，过程1200可以包括为至少两个相关的子块确定在不同存储器设备上的文件内块协同定位。在另一实施例中，过程1200可以提供为至少两个相关的子块确定在不同存储器设备上的文件内块分层和协同定位。
在一种实施例中，为了为用于多个块中的每一个的至少两个相关的子块确定在不同存储器设备上的块存储放置，过程1200还可以确定文件系统中的应用通告。在一种实施例中，修改后的索引节点结构支持文件内块分层并且包括条目，该条目包括指示驻留在文件系统中同一数据节点服务器上的分层子块之间的协同定位关系的信息。在一种实施例中，过程1200可以在文件摄取时提供在期望层上的应用控制块放置，以用于提供前期性能保证。
在一种实施例中，过程1200还可以包括确定至少两个相关子块当中用于目标针对第一存储器层的文件的第一子块，确定至少两个相关子块当中用于目标针对第二存储器层的文件的第二子块，并且选择具有用于在第一存储器层上的第一子块的和在第二存储器层上的第二子块的空间的数据节点服务器。在一种实施例中，过程1200可以提供对有效的文件内块分层与跨层的文件过渡内迁移或失败迁移的区分。在一种实施例中，过程1200可以包括维护至少两个相关的子块之间的关系，其中一个子块包含流行列的子集且第二子块包含剩余的列，并且在文件摄取、存储器重新划分、文件迁移和文件块向上分层期间共同放置流行块和不流行块。
在一种实施例中，过程1200还可以包括由应用提供用于在SSD池上放置包含流行列的子集的子块且在HDD池上放置包含剩余列的子块的通告，并且对于指定数量的行指定包含流行列的子集的子块和包含剩余列的子集的子块放置在文件系统中同一数据节点服务器上不同存储池上的约束。
如本领域技术人员将认识到的，本发明的各方面可以体现为系统、方法或计算机程序产品。因此，本发明的各方面可以采取完全硬件实施例、完全软件实施例(包括固件、驻留软件，微代码，等等)，或者组合软件和硬件方面的实施例的形式，所有这些一般全都可以在本文中被称为“电路”、“模块”或“系统”。此外，本发明的各方面可以采取体现在一个或多个计算机可读介质中的计算机程序产品的形式，在该计算机可读介质上包含计算机可读程序代码。
可以使用一种或多种计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质可以是例如，但不限于，电、磁、光、电磁、红外线或者半导体系统、装置或设备或者以上所述的任意合适组合。计算机可读存储介质的更具体例子(非穷尽列表)将包括以下：具有一条或多条电线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦可编程只读存储器(EPROM或者闪存存储器)、光纤、便携式光盘只读存储器(CD-ROM)、光学存储设备、磁性存储设备或者以上所述的任意合适组合。在本文档的背景下，计算机可读存储介质可以是可以包含或者存储由指令执行系统、装置或设备使用或者与指令执行系统、装置或设备联合使用的程序的任何有形介质。
计算机可读信号介质可以包括在基带中或者作为载波的一部分的其中体现计算机可读程序代码的传播数据信号。这种传播信号可以采取多种形式中的任何一种，包括但不限于电磁、光或者其任意合适组合。计算机可读信号介质可以是非计算机可读存储介质而且可以传送、传播或者运输由指令执行系统、装置或设备使用或者与其联合使用的程序的任何计算机可读介质。
体现在计算机可读介质上的程序代码可以利用任何适当的介质发送，包括但不限于，无线电、有线线路、光纤电缆、RF等，或者其任意合适组合。
用于执行本发明各方面的操作的计算机程序代码可以用一种或多种编程语言的任意组合来写，编程语言包括面向对象的编程语言，例如Java、Smalltalk、C++等，及传统的过程编程语言，例如“C”编程语言或者类似的编程语言。程序代码可以完全在用户的计算机上、部分地在用户的计算机上、作为独立的软件包、部分在用户的计算机上而且部分在远端计算机上或者完全在远端计算机或服务器上执行。在后一种场景下，远端计算机可以通过任何类型的网络连接到用户的计算机，包括局域网(LAN)或广域网(WAN)，或者可以连接到外部的计算机(例如，通过利用互联网服务提供商的互联网)。
以下参考根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图说明和/或框图来描述本发明的各方面。将理解，所述流程图说明和/或框图的每个方框及所述流程图说明和/或框图中方框的组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或者其它可编程数据处理装置的处理器，来产生一种机器，使得当所述指令经计算机或者其它可编程数据处理装置的处理器执行时，产生用于实现在所述流程图和/或框图中的一个或多个方框中所指定的功能/动作的装置。
这些计算机程序指令还可以存储在可以指示计算机的计算机可读介质中、其它可编程数据处理装置或者以特定的方式起作用的其它设备中，使得存储在计算机可读介质中的指令产生一种制造物品，该物品包括实现在流程图和/或框图中的一个或多个方框中所指定的功能/动作的指令。
计算机程序指令还可以加载到计算机、其它可编程数据处理装置或者其它设备上，以产生要在计算机、其它可编程装置或者其它设备上执行的一系列操作步骤，从而产生计算机实现的过程，使得在所述计算机或者其它可编程装置上执行的指令提供用于实现流程图和/或框图中的一个或多个方框中所指定的功能/动作的过程。
附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表模块、程序段或者代码的一部分，所述模块、程序段或代码的一部分包含用于实现(一个或多个)规定的逻辑功能的一个或多个可执行指令。在一些替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，连续示出的两个方框实际上可以基本并行地执行，或者方框有时可以按相反的顺序执行，这依赖所涉及的功能而定。也要注意的是，框图和/或流程图说明中的每个方框以及框图和/或流程图说明中方框的组合可以用执行规定的功能或动作或者执行专用硬件与计算机指令的组合的专用的基于硬件的系统来实现。
除非明确地如此陈述，否则权利要求中对单数形式的元素的引用并非意在表示“一个且唯一”，而是指“一个或多个”。目前本领域普通技术人员已知或以后知道的与上述示例性实施例的元素等效的所有结构和功能要被本权利要求涵盖。本文没有权利要求元素要援引35U.S.C第112部分第6段来解释，除非该元素明确地利用短语“用于...的装置”或“用于...的步骤”来阐述。
本文所使用的术语仅仅是为了描述特定的实施例而不是要作为本发明的限制。如本文所使用的，除非上下文明确地另外指出，否则单数形式“一个”和“这个”是要也包括复数形式。还应当理解，当在本说明书使用时，术语“包括”规定所述特征、整数、步骤、操作、元素和/或部件的存在，但是并不排除一个或多个其它特征、整数、步骤、操作、元素、部件和/或其组的存在或添加。
以下权利要求中所有方式或步骤加功能元素的对应结构、材料、动作及等同物都是要包括用于结合具体所述的其它所述元素执行所述功能的任何结构、材料或动作。已经为了说明和描述目的给出了本发明的描述，但这不是详尽的或者要把本发明限定到所公开的形式。在不背离本发明范围与精神的情况下，许多修改和变化对本领域普通技术人员都将是清楚的。实施例的选择和描述是为了最好地解释本发明的原理和实践应用，并使本领域普通技术人员能够理解本发明具有适于预期特定使用的各种修改的各种实施例。

Claims (23)

1.一种用于文件内块存储器管理的方法，包括：
获得文件系统中的文件；
将文件分成多个块；
将所述多个块中的每个块分成至少两个相关的子块；以及
在文件系统元数据布局中为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块组织的存储放置，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块分层，其中，所述文件内块组织的存储放置是基于考虑列数据块的多个属性的预测列数据块放置模型的，所述列数据块的多个属性包括基数。
2.如权利要求1所述的方法，其中，
将文件分成多个块是基于将列水平划分成多个行组；
一个子块包含流行投影列的子集，另一个子块包含剩余列。
3.如权利要求2所述的方法，其中：
文件系统元数据包括块级元数据标头、行组级元数据标头和列级元数据标头；以及
所述列数据块的多个属性还包括排序顺序、稀疏性和尺寸。
4.如权利要求3所述的方法，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块协同定位；
所述块级元数据标头包含文件块中的行组的个数和版本号，所述版本号帮助维护跨文件块结构的多个版本的向后和向前的兼容性；
所述行组级元数据标头包含在行组中存在的行和列的数量；以及
所述列级元数据标头包含在文件块中的多个列布局的文件偏移指针。
5.如权利要求1所述的方法，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块分层和协同定位。
6.如权利要求1所述的方法，还包括为了为所述至少两个相关的子块确定在不同类型的存储器设备上的块存储放置而确定文件系统内的应用通告。
7.如权利要求3所述的方法，其中修改后的索引节点结构支持文件内块分层，并且包括条目，该条目包括指示驻留在文件系统中同一数据节点服务器上的分层的子块之间的协同定位关系的信息。
8.如权利要求6所述的方法，其中，在文件摄取时应用控制在期望层上对所述至少两个相关子块的子块放置，以用于提供前期性能保证。
9.如权利要求3所述的方法，还包括：
为目标针对第一存储器层的文件确定所述至少两个相关子块中的第一子块；
为目标针对第二存储器层的文件确定所述至少两个相关子块中的第二子块；以及
选择具有用于第一存储器层上的第一子块和第二存储器层上的第二子块二者的空间的数据节点服务器。
10.如权利要求3所述的方法，其中，有效的文件内块分层与跨层的文件过渡迁移或失败的迁移不同。
11.如权利要求4所述的方法，还包括：
维护所述至少两个相关子块之间的关系，其中一个子块包含流行列的子集并且第二个子块包含剩余列；以及
在文件摄取、存储器重新划分、文件迁移和文件块向上分层期间共同放置流行块和不流行块。
12.如权利要求11所述的方法，还包括：
由应用提供用于在固态驱动器池上放置包含流行列的子集的子块并且在硬盘驱动器池上放置包含剩余列的子块的通告；以及
对于指定数量的行指定包含流行列的子集的子块和包含剩余列的子块放置在文件系统中同一数据节点服务器上不同存储池上的约束。
13.一种用于文件内块存储器管理的计算机系统，包括：
处理器；
耦合到处理器的存储器；
存储在存储器中并由处理器执行的程序代码，以便：
由处理器获得文件系统中的文件；
由处理器将文件分成多个块；
由处理器将所述多个块中的每个块分成至少两个相关的子块；以及
由处理器在文件系统元数据布局中为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块组织的存储放置，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块分层，其中，所述文件内块组织的存储放置是基于考虑列数据块的多个属性的预测列数据块放置模型的，所述列数据块的多个属性包括基数。
14.如权利要求13所述的计算机系统，其中：
将文件分成多个块是基于将列水平划分成多个行组；
一个子块包含流行投影列的子集，另一个子块包含剩余列。
15.如权利要求14所述的计算机系统，其中：
文件系统元数据包括块级元数据标头、行组级元数据标头和列级元数据标头；以及
所述列数据块的多个属性还包括排序顺序、稀疏性和尺寸。
16.如权利要求15所述的计算机系统，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块协同定位；
所述块级元数据标头包含文件块中的行组的个数和版本号，所述版本号帮助维护跨文件块结构的多个版本的向后和向前的兼容性；
所述行组级元数据标头包含在行组中存在的行和列的数量；以及
所述列级元数据标头包含在文件块中的多个列布局的文件偏移指针。
17.如权利要求13所述的计算机系统，其中，确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同类型的存储器设备上的文件内块分层和协同定位。
18.如权利要求13所述的计算机系统，其中，可由处理器执行的程序代码还使得：由处理器为了为所述至少两个相关的子块确定在不同类型的存储器设备上的块存储放置而确定文件系统内的应用通告。
19.如权利要求15所述的计算机系统，其中，可由处理器执行的程序代码还使得：
由处理器为目标针对第一存储器层的文件确定所述至少两个相关子块中的第一子块；
由处理器为目标针对第二存储器层的文件确定所述至少两个相关子块中的第二子块；以及
由处理器选择所述文件系统中具有用于第一存储器层上的第一子块和第二存储器层上的第二子块二者的空间的数据节点服务器。
20.如权利要求16所述的计算机系统，其中，可由处理器执行的程序代码还使得：
维护所述至少两个相关子块中的包含流行列的子集的第一子块与所述至少两个相关子块中的包含剩余列的第二子块之间的关系；
由处理器在包括摄取、存储器重新划分、文件迁移和文件块向上分层中的一个或多个的文件系统操作期间共同放置并一起管理第一子块和第二子块；
由应用提供用于在固态驱动器池上放置文件的第一子块并且在硬盘驱动器池上放置文件的第二子块的通告；以及
指定第一子块和第二子块放置在文件系统中同一数据节点服务器上的约束。
21.一种用于文件内块存储器管理的方法，包括：
获得文件系统中的文件的块；
将块分成至少两个相关的子块；以及
在文件系统元数据布局中为所述至少两个相关子块确定在不同类型的存储器设备上的文件内块分层和协同定位，其中，所述文件内块分层和协同定位是基于考虑列数据块的多个属性的预测列数据块放置模型的，所述列数据块的多个属性包括基数。
22.如权利要求21所述的方法，其中，
所述块包括水平划分成多个行组的列的一部分；以及
对于所述至少两个相关的子块，一个子块包含流行投影列的子集，另一个子块包含剩余列。
23.如权利要求22所述的方法，还包括：
为了为所述至少两个相关的子块确定在不同类型的存储器设备上的子块存储放置而确定文件系统内的应用通告；
确定用于所述至少两个相关的子块中的第一子块的第一存储器层；
确定用于所述至少两个相关的子块中的第二子块的第二存储器层；以及
选择所述文件系统中具有用于第一存储器层上的第一子块和第二存储器层上的第二子块二者的空间的数据节点服务器。
CN201610177924.8A 2015-03-26 2016-03-25 文件系统块级分层与协同分配 Active CN106021268B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/669,565 2015-03-26
US14/669,565 US9952808B2 (en) 2015-03-26 2015-03-26 File system block-level tiering and co-allocation

Publications (2)

Publication Number Publication Date
CN106021268A CN106021268A (zh) 2016-10-12
CN106021268B true CN106021268B (zh) 2020-04-10

Family

ID=56889716

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610177924.8A Active CN106021268B (zh) 2015-03-26 2016-03-25 文件系统块级分层与协同分配

Country Status (3)

Country Link
US (3) US9952808B2 (zh)
CN (1) CN106021268B (zh)
DE (1) DE102016105472B4 (zh)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US10042914B2 (en) * 2015-06-10 2018-08-07 International Business Machines Corporation Database index for constructing large scale data level of details
US10649850B1 (en) 2015-06-29 2020-05-12 Amazon Technologies, Inc. Heterogenous media storage and organization in automated data storage systems
US9923966B1 (en) 2015-06-29 2018-03-20 Amazon Technologies, Inc. Flexible media storage and organization in automated data storage systems
US9961141B1 (en) * 2015-06-29 2018-05-01 Amazon Technologies, Inc. Techniques and systems for tray-based storage and organization in automated data storage systems
US10379959B1 (en) * 2015-06-29 2019-08-13 Amazon Technologies, Inc. Techniques and systems for physical manipulation of data storage devices
US10983957B2 (en) * 2015-07-27 2021-04-20 Sas Institute Inc. Distributed columnar data set storage
US10599352B2 (en) * 2015-08-14 2020-03-24 Samsung Electronics Co., Ltd. Online flash resource allocation manager based on a TCO model
US9886440B2 (en) * 2015-12-08 2018-02-06 International Business Machines Corporation Snapshot management using heatmaps in a large capacity disk environment
US10838911B1 (en) 2015-12-14 2020-11-17 Amazon Technologies, Inc. Optimization of data request processing for data storage systems
JP6165909B1 (ja) * 2016-03-16 2017-07-19 株式会社東芝 階層化ストレージシステム、ストレージコントローラ、及び階層化制御方法
US10320906B2 (en) * 2016-04-29 2019-06-11 Netapp, Inc. Self-organizing storage system for asynchronous storage service
US10891201B1 (en) * 2017-04-27 2021-01-12 EMC IP Holding Company LLC Dynamic rule based model for long term retention
US10838963B2 (en) * 2017-09-11 2020-11-17 International Business Machines Corporation Optimized access for hierarchical low cardinality value synopsis in analytical databases
CN109669623B (zh) * 2017-10-13 2021-09-03 杭州海康威视系统技术有限公司 一种文件管理方法、文件管理装置、电子设备及存储介质
US10360214B2 (en) * 2017-10-19 2019-07-23 Pure Storage, Inc. Ensuring reproducibility in an artificial intelligence infrastructure
CN111902804B (zh) 2018-06-25 2024-03-01 阿里巴巴集团控股有限公司 用于管理存储设备的资源并量化i/o请求成本的系统和方法
US11061735B2 (en) 2019-01-02 2021-07-13 Alibaba Group Holding Limited System and method for offloading computation to storage nodes in distributed system
US11106674B2 (en) 2019-03-31 2021-08-31 International Business Machines Corporation Extensible data skipping
SG11202002027TA (en) * 2019-09-12 2020-04-29 Alibaba Group Holding Ltd Log-structured storage systems
CN115398874A (zh) 2019-09-12 2022-11-25 创新先进技术有限公司 日志结构存储系统
SG11202002588RA (en) 2019-09-12 2020-04-29 Alibaba Group Holding Ltd Log-structured storage systems
US10942852B1 (en) 2019-09-12 2021-03-09 Advanced New Technologies Co., Ltd. Log-structured storage systems
SG11202002775RA (en) 2019-09-12 2020-04-29 Alibaba Group Holding Ltd Log-structured storage systems
CN111886591A (zh) 2019-09-12 2020-11-03 创新先进技术有限公司 日志结构存储系统
CN111837113A (zh) 2019-09-12 2020-10-27 创新先进技术有限公司 日志结构存储系统
SG11202002614XA (en) 2019-09-12 2020-04-29 Alibaba Group Holding Ltd Log-structured storage systems
EP3682344A4 (en) 2019-09-12 2020-12-02 Advanced New Technologies Co., Ltd. ENERGY STORAGE SYSTEMS
US11617282B2 (en) 2019-10-01 2023-03-28 Alibaba Group Holding Limited System and method for reshaping power budget of cabinet to facilitate improved deployment density of servers
US11983155B2 (en) * 2020-01-14 2024-05-14 International Business Machines Corporation Namespace range creation to distribute workload in a dispersed storage system
US11507499B2 (en) 2020-05-19 2022-11-22 Alibaba Group Holding Limited System and method for facilitating mitigation of read/write amplification in data compression
US11556277B2 (en) 2020-05-19 2023-01-17 Alibaba Group Holding Limited System and method for facilitating improved performance in ordering key-value storage with input/output stack simplification
US11422931B2 (en) * 2020-06-17 2022-08-23 Alibaba Group Holding Limited Method and system for facilitating a physically isolated storage unit for multi-tenancy virtualization
US11487465B2 (en) 2020-12-11 2022-11-01 Alibaba Group Holding Limited Method and system for a local storage engine collaborating with a solid state drive controller
US11734115B2 (en) 2020-12-28 2023-08-22 Alibaba Group Holding Limited Method and system for facilitating write latency reduction in a queue depth of one scenario
US11902597B2 (en) * 2021-02-09 2024-02-13 Netflix, Inc. Media aware content placement
US11550812B2 (en) 2021-02-22 2023-01-10 International Business Machines Corporation Processing a federated query via data serialization
US11726699B2 (en) 2021-03-30 2023-08-15 Alibaba Singapore Holding Private Limited Method and system for facilitating multi-stream sequential read performance improvement with reduced read amplification
US20230031304A1 (en) * 2021-07-22 2023-02-02 Vmware, Inc. Optimized memory tiering

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6425020B1 (en) * 1997-04-18 2002-07-23 Cirrus Logic, Inc. Systems and methods for passively transferring data across a selected single bus line independent of a control circuitry
US7024414B2 (en) * 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
CN103440244A (zh) * 2013-07-12 2013-12-11 广东电子工业研究院有限公司 一种大数据存储优化方法
US8868576B1 (en) * 2012-06-28 2014-10-21 Emc Corporation Storing files in a parallel computing system based on user-specified parser function

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5918225A (en) 1993-04-16 1999-06-29 Sybase, Inc. SQL-based database system with improved indexing methodology
US5848406A (en) 1996-09-03 1998-12-08 Matsushita Electric Industrial Co., Ltd. Method for presenting information on display devices of varying sizes
US6330555B1 (en) 1999-02-19 2001-12-11 Nortel Networks Limited Method and apparatus for enabling a view of data across a database
US6487641B1 (en) 1999-04-19 2002-11-26 Oracle Corporation Dynamic caches with miss tables
US7499907B2 (en) 2001-10-12 2009-03-03 Teradata Us, Inc. Index selection in a database system
US7117222B2 (en) 2003-03-13 2006-10-03 International Business Machines Corporation Pre-formatted column-level caching to improve client performance
CA2538568C (en) 2003-09-15 2009-05-19 Ab Initio Software Corporation Data profiling
KR100684942B1 (ko) 2005-02-07 2007-02-20 삼성전자주식회사 복수의 사상 기법들을 채용한 적응형 플래시 메모리 제어장치 및 그것을 포함한 플래시 메모리 시스템
US8538969B2 (en) 2005-06-03 2013-09-17 Adobe Systems Incorporated Data format for website traffic statistics
US7457910B2 (en) 2005-06-29 2008-11-25 Sandisk Corproation Method and system for managing partitions in a storage device
US7761444B2 (en) * 2006-10-05 2010-07-20 Hewlett-Packard Development Company, L.P. Identifying a sequence of blocks of data to retrieve based on a query
EP2097825B1 (en) 2006-12-26 2013-09-04 SanDisk Technologies Inc. Use of a direct data file system with a continuous logical address space interface
US8150850B2 (en) 2008-01-07 2012-04-03 Akiban Technologies, Inc. Multiple dimensioned database architecture
US9805077B2 (en) 2008-02-19 2017-10-31 International Business Machines Corporation Method and system for optimizing data access in a database using multi-class objects
US8121975B2 (en) 2008-02-20 2012-02-21 Panorama Software Inc. Creating pivot tables from tabular data
US8478775B2 (en) 2008-10-05 2013-07-02 Microsoft Corporation Efficient large-scale filtering and/or sorting for querying of column based data encoded structures
US8935223B2 (en) * 2009-04-30 2015-01-13 Oracle International Corporation Structure of hierarchical compressed data structure for tabular data
JP5858432B2 (ja) 2009-06-02 2016-02-10 サフロン・テクノロジー，インコーポレイテッド 分散連想メモリベースを提供する方法、システム、及びコンピュータプログラム製品
US20110029319A1 (en) 2009-07-29 2011-02-03 Google Inc. Impression forecasting and reservation analysis
WO2011142026A1 (ja) 2010-05-14 2011-11-17 株式会社日立製作所 時系列データ管理装置、システム、方法、およびプログラム
US9218408B2 (en) 2010-05-27 2015-12-22 Oracle International Corporation Method for automatically creating a data mart by aggregated data extracted from a business intelligence server
US8284627B2 (en) 2010-10-22 2012-10-09 International Business Machines Corporation Reducing energy consumption and optimizing workload and performance in multi-tier storage systems using extent-level dynamic tiering
JP5178813B2 (ja) 2010-12-16 2013-04-10 ヤフー株式会社 検索システム及び方法
US20120198152A1 (en) 2011-02-01 2012-08-02 Drobo, Inc. System, apparatus, and method supporting asymmetrical block-level redundant storage
US8756382B1 (en) * 2011-06-30 2014-06-17 Western Digital Technologies, Inc. Method for file based shingled data storage utilizing multiple media types
US10152482B2 (en) 2011-10-07 2018-12-11 Synopsys, Inc. Method of speeding up access to design databases having large numbers of design units
US8914353B2 (en) 2011-12-20 2014-12-16 Sap Se Many-core algorithms for in-memory column store databases
US11347443B2 (en) * 2012-04-13 2022-05-31 Veritas Technologies Llc Multi-tier storage using multiple file sets
US9658896B2 (en) 2012-05-16 2017-05-23 International Business Machines Corporation Apparatus and method to manage device performance in a storage system
US10909113B2 (en) 2013-07-31 2021-02-02 Sap Se Global dictionary for database management systems
US9292554B2 (en) 2013-08-20 2016-03-22 Pivotal Software, Inc. Thin database indexing
US9176801B2 (en) * 2013-09-06 2015-11-03 Sap Se Advanced data models containing declarative and programmatic constraints
CA2867589A1 (en) * 2013-10-15 2015-04-15 Coho Data Inc. Systems, methods and devices for implementing data management in a distributed data storage system
US9450602B2 (en) 2014-01-02 2016-09-20 Sap Se Efficiently query compressed time-series data in a database
US9846567B2 (en) 2014-06-16 2017-12-19 International Business Machines Corporation Flash optimized columnar data layout and data access algorithms for big data query engines
US10127275B2 (en) * 2014-07-11 2018-11-13 International Business Machines Corporation Mapping query operations in database systems to hardware based query accelerators
US11023486B2 (en) * 2018-11-13 2021-06-01 Thoughtspot, Inc. Low-latency predictive database analysis
US11062133B2 (en) * 2019-06-24 2021-07-13 International Business Machines Corporation Data structure generation for tabular information in scanned images

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6425020B1 (en) * 1997-04-18 2002-07-23 Cirrus Logic, Inc. Systems and methods for passively transferring data across a selected single bus line independent of a control circuitry
US7024414B2 (en) * 2001-08-06 2006-04-04 Sensage, Inc. Storage of row-column data
US8868576B1 (en) * 2012-06-28 2014-10-21 Emc Corporation Storing files in a parallel computing system based on user-specified parser function
CN103440244A (zh) * 2013-07-12 2013-12-11 广东电子工业研究院有限公司 一种大数据存储优化方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RCFile:A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse System;Yongqing he等;《IEEE2011》;20111231;第1202页第Ⅲ部分 *

Also Published As

Publication number Publication date
US11593037B2 (en) 2023-02-28
DE102016105472A1 (de) 2016-09-29
CN106021268A (zh) 2016-10-12
US9952808B2 (en) 2018-04-24
US20180189003A1 (en) 2018-07-05
US10558399B2 (en) 2020-02-11
DE102016105472B4 (de) 2024-05-02
US20200097218A1 (en) 2020-03-26
US20160283140A1 (en) 2016-09-29

Similar Documents

Publication Publication Date Title
CN106021268B (zh) 文件系统块级分层与协同分配
JP6542785B2 (ja) 第一クラスデータベース要素としての半構造データの実装
EP2901323B1 (en) Policy driven data placement and information lifecycle management
US10235376B2 (en) Merging metadata for database storage regions based on overlapping range values
US9990265B2 (en) Diagnosing causes of performance issues of virtual machines
Jindal et al. Trojan data layouts: right shoes for a running elephant
US20180011690A1 (en) Flash optimized columnar data layout and data access algorithms for big data query engines
US9223820B2 (en) Partitioning data for parallel processing
US10922316B2 (en) Using computing resources to perform database queries according to a dynamically determined query size
US20160283538A1 (en) Fast multi-tier indexing supporting dynamic update
US20200272636A1 (en) Tiered storage for data processing
US10387415B2 (en) Data arrangement management in a distributed data cluster environment of a shared pool of configurable computing resources
KR20130049111A (ko) 분산 처리를 이용한 포렌식 인덱스 방법 및 장치
Sinthong et al. Aframe: Extending dataframes for large-scale modern data analysis
US11455305B1 (en) Selecting alternate portions of a query plan for processing partial results generated separate from a query engine
Sinthong et al. AFrame: Extending DataFrames for large-scale modern data analysis (Extended Version)
Blamey et al. Adapting the secretary hiring problem for optimal hot-cold tier placement under top-K workloads
CN117321583A (zh) 用于混合数据处理的存储引擎
Ross et al. Storage systems and input/output: Organizing, storing, and accessing data for scientific discovery. report for the doe ascr workshop on storage systems and i/o.[full workshop report]
Wang et al. An Efficient Big Data Storage Service Architecture
Chandramouli et al. ICE: Managing cold state for big data applications
Paul An application-attuned framework for optimizing hpc storage systems
JP2022053542A (ja) コンピュータシステム、コンピュータプログラムおよびコンピュータ実装方法（ワークロード駆動によるデータベース再編成）
Martin Collocation of Data in a Multi-temperate Logical Data Warehouse
Park et al. KV-CSD: A Hardware-Accelerated Key-Value Store for Data-Intensive Applications

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant