gpu 数据库_GPU驱动的数据库可以为您做什么

gpu 数据库

SQL数据库的历史可以追溯到1970年代,并且自1980年代起就是ANSI标准,但这并不意味着该技术可以保持不变。 它仍在变化,并且是GPU加速数据库的其中一种方式。

关系数据库的规模已经扩大到可以测量PB级甚至更高的数据集。 即使出现了64位计算和数TB的内存来提高处理能力,也仍然需要大量数据处理-CPU只能管理这么多数据。 那就是GPU出现的地方。

[了解更多: GPU计算是释放所有数据奥秘的关键 •有关机器学习中GPU革命的全部内容。 构建自己的GPU服务器以进行深度学习 | 通过InfoWorld大数据和分析报告时事通讯深入了解分析和大数据。 ]

GPU已从加速游戏的最初使命转变为加速几乎所有内容。 英伟达已经精打细算地成为人工智能的代名词,这个过程需要并行处理大量数据以及可以很好并行化的其他任务。 AMD正开始追赶,但Nvidia遥遥领先。

说到核心,还差得远。 Xeon CPU最多具有22个内核。 AMD Epyc具有32个内核。 Nvidia Volta架构具有5,120个内核。 现在想象一下,有5,000个以上的内核在数据上并行运行,这很清楚为什么GPU在大型计算项目中如此流行。

因此,出现了一种全新的数据库,从头开始编写,以支持和拥抱GPU及其强大的并行处理功能。 这些数据库可以处理常规CPU驱动的数据库根本无法处理的数据集,从而使数据处理,分析和实时大数据达到新的水平。

GPU数据库已定义

GPU数据库的概念非常简单:它使用GPU的并行性来执行大量的数据处理加速。 GPU非常适合加速SQL查询的处理,因为SQL对集合中的每一行执行相同的操作(通常是搜索)。

但是,您不只是将一堆Nvidia Tesla卡放在托管Oracle数据库的服务器中。 从SQL JOIN操作开始,已经完全设计和编写了GPU数据库以执行并行处理。

JOIN建立数据库中多个表的列之间的关系,对于执行有意义的分析至关重要。 多年前,在传统RDBMS系统上针对JOIN的传统设计方法是为单核CPU设计的,即使对于CPU(尤其是GPU),它们也无法很好地发挥作用。

除了JOIN之外,GPU数据库还具有相当大的支持水平,包括:

  • 与流行的开源框架(如Hadoop,Kafka,HBase,Spark和Storm)的连接器。
  • ODBC和JDBC驱动程序,用于与现有的可视化和BI工具(如Tableau,Power BI和Spotfire)集成
  • 与流行的编程语言(例如C ++,SQL,Java,Node.js和Python)绑定的API。

在哪里使用GPU数据库

在这方面,GPU数据库实际上无法与Oracle,SQL Server或DB2竞争。 GPU数据库面向的是做出数据分析决策,公司试图从大量数据中实时做出决策,但由于数据过多或视觉分析工具太慢而无法进行决策。

GPU数据库供应商并不认为自己可以替代Oracle或Teradata之类的OLTP数据库。 GPU数据库不是针对传统的RDBMS工作负载,而是针对OLAP / OLTP世界和大数据 ,这些数据集非常庞大且需要实时。 GPU数据库不是在数小时或一夜之间运行的批处理过程,而是可以实时或每小时显示数据的地方。

GPU数据库应该可以解决NoSQL试图解决的许多问题,但是可以让您使用现有的结构化查询工具。 使用NoSQL意味着重写所有SQL工具,但是GPU数据库使用现有SQL工具。

“我们意识到人们已经意识到他们可以构建多维系统,并可以从多个场景中获取数据并进行组合,”使用GPU数据库SQream的IT咨询公司Datatrend Technologies的新兴技术解决方案架构师Steve Worthington说。 “医疗公司希望从多个系统中获取[数据]并跨数据库进行分析,因为以前,他们无法进行交叉引用,也无法加入数据库。”

他还列举了金融机构进行欺诈和风险分析的过程,这些机构现在可能只做信用卡检查,但想对多个帐户进行检查。 借助GPU的强大功能,他们可以立即交叉引用所有这些信息源。

对于位置服务提供商Skyhook的地理空间数据副总裁Rich Sutton而言,使用OmniSci GPU数据库给他的地理数据集可视化效果比基于CPU的数据库要大得多。 他说:“我可以将10亿行加载到OmniSci中,而几乎没有延迟,而不必查看传统CPU空间中的10,000行数据集。” “它有多个数量级,这对我来说有利于减少数据消耗,并大大减少了延迟。”

OmniSci的首席执行官Todd Mostak说,一位客户告诉他OmniSci的速度“降低了好奇心。 他们问一些以前会坚持的问题。” 一位金融服务客户告诉他,在传统数据库上进行18小时的处理查询的时间降低到了亚秒级,而一家电信公司告诉他,耗时数小时的查询现在可以在不到一秒的时间内响应。

GPU数据库的另一个地方是实时大数据,而Hadoop则不足。 GPU数据库提供商SQream的首席执行官Ami Gal说,大数据的许多希望(发现驻留在数十PB的行数据中的所有机会)在Hadoop上没有实现,因为它太慢了。

Spark非常适合数据移动和转换,但是一旦您需要处理大量数据并移动它们,您就开始处理成千上万的[计算]节点,这对于处理大型数据集来说实在太繁琐了。 但是,如果您可以使用10或15个节点来执行此操作,那将效率更高。”他说。

沃辛顿说,基于GPU的服务器可以在一个机柜中运行,而这需要许多机柜的CPU驱动的多并行处理(MPP)节点。 “我们可以用六个节点替换每个MPP节点机架,每个节点中有2至4个GPU。 这样一来,我们可以用不到一百万美元的投资来代替一千万美元的投资。”他说。

GPU对Skyhook也很重要,后者可以对大型地理数据集进行可视化。 “如果您在一分钟内有数百万次在现场和ping位置,那么您每天要谈论20亿条数据。 这在传统数据库中是不可能的。 只是不可能。 因此,[a] GPU [数据库]使您可以使用这些数据。” Sutton说。

在采用OmniSci之前,Skyhook将不得不“金字塔化”数据,仅将其中的一部分用于可视化。 萨顿说,现在,它可以查看整个数据图。 “我从未见过其他可行的方法来使数据成型以适应我的使用方式。”

GPU数据库:可用功能

GPU数据库完全是一种新兴现象,诸如BrytlytSQream TechnologiesOmniSciKineticaPG-StromBlazegraph之类的公司都是如此

它们的工作方式略有不同。 例如,OmniSci进行数据可视化,而SQream使用连接器连接到Tableau等可视化工具,因此需要分别评估每个工具,以确定最适合您的需求。

除了IBM之外,RDBMS中的知名人士尚未加入,IBM确实支持DB2 Blu(用于分析工作负载的DB2的特殊版本)中的某些GPU处理。 Oracle和TeraData都表示他们正在与Nvidia合作,但目前还没有。 Microsoft在SQL Server上不支持GPU加速。 SQream的Gal表示,他听说所有RDBMS供应商都在努力为其产品添加某种GPU支持,但没有进一步的信息。

翻译自: https://www.infoworld.com/article/3327561/what-a-gpu-powered-database-can-do-for-you.html

gpu 数据库

由于内存数据库具有比基于磁盘的数据库更高的查询响应速度和并发度,其被广泛应用于银行、证券交易所和在线购物等数据量庞大并且实时性要求高的商业领域。索引能够有效降低数据的搜索空间、提高内存数据库的查询效率,然而当前它却受到性能和效率的挑战。 基于图形处理器的通用计算(GPGPU)在多个领域具有重要的研究价值和应用前景,也是当前研究的热点。目前图形处理器(GPU)上索引技术的研究已有一定的相关成果,然而这些研究成果存在着诸如:并行算法未充分利用硬件的资源、并行度不高,算法缺乏可扩展性且不能解决索引数据的更新等问题。因此,本文以如何充分利用 GPU 的硬件资源、最大限度地提高内存数据库索引的操作性能为主要研究内容,在相关研究的基础上,本文主要了以下工作: 1. 对目前内存数据库索引技术的研究成果进行总结归纳,并且对 GPU 的硬件特点和编程技术了相关综述。 2. 提出一种基于 GPU T-树索引的并行计算方案,该方案通过分析 T-树的节点间的父子关系,在 GPU 上实现对 T-树的最大并行度构建。设计在 GPU 上 T-树索引数据可任意伸缩的动态数组,解决 GPU 上尚无动态分配显存空间的问题;通过对各种构建 T-树方案的理论和实验分析,提出的并行建树方案较传统的建树方案,在操作效率和空间利用率上均有明显的性能优势。为解决 CUDA 程序数据传输的瓶颈问题,通过页锁定内存的方式提高 CPU 和 GPU 间的数据传输速率;为适应未来硬件发展的需求,对算法的可扩展性进行相关研究;为验证方案的正确性,提出基于 GPU T-树的遍历算法; 为验证提出的并行方案的有效性,进行相关的实验论证。 3. 为加速多维数据的操作性能,提出一种基于 GPU 多维线性哈希索引的并行处理方案。该方案通过对传统哈希索引数据结构的扩展,利用 2 层的数据结构可实现哈希表在 GPU 上的任意收缩,从而解决多维数据在 GPU 上无法有效更新的问题。在哈希表的记录并行批量插入算法中,采用并行分裂哈希桶的方式可加速哈希表分裂的处理 速度,从而提高了插入的效率;设计一个灵活的溢出桶管理机制,可提高多维哈希索引在 GPU 上的存储空间利用率;对提出的记录并行批量插入方案进行算法时间和空间复杂度的分析,并与传统的 CPU 算法进行相关对比;在各种硬件平台上对多维线性哈希索引记录的并行批量插入、批量删除和查询的操作性能进行相关的实验论证。 4. 提出一种基于 GPU 缓存敏感 CSB+-树索引的无锁并行处理方案,该方案通过对传统的 CSB+-树的结构改进,可实现 CSB+-树的索引数据在 GPU 上动态更新。在 GPU上提出基于树层和基于节点索引键 CSB+-树两种并行构建算法,其中后者可实现对CSB+-树的最大并行度构建;通过在 CSB+-树的内部节点添加填充位的方式,可减少GPU 线程块里的线程分支数,从而提高 CSB+-树的查询性能;通过对 CSB+-树的查询算法使用共享存储器的可行性分析,指出传统的缓存敏感技术的思想在复杂的 GPU 内存框架中并不适合使用。为验证提出的并行方案的有效性,在多个硬件平台上进行相关的实验论证。 5.在 GPU 平台上提出一种 BD-树索引的并行计算方案,该方案通过修改传统 BD-树的哈希函数,可实现对 BD-树索引的并行处理。通过对传统 BD-树的数据结构改进,可实现 BD-树索引数据在 GPU 上的更新操作;通过分析 BD-树的树形结构,可实现基于内部节点键的并行度方式构建 BD-树;通过增加额外的空间开销,减少 GPU 原子函数的调用次数,可显著提高 BD-树哈希表的数据插入效率;对 BD-树并行构建算法进行空间复杂度的分析,与传统的构建算法相比,提出算法的空间利用率明显得到提高。同样,为验证提出方案的有效性,进行相关的实验论证。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值