数据存储_数据存储技术 - CSDN
精华内容
参与话题
  • 数据的四种基本存储方法

    万次阅读 2017-12-09 12:11:10
    数据的四种基本存储方法

    数据的存储结构可用以下四种基本存储方法得到:

    (1)顺序存储方法

    该方法把逻辑上相邻的结点存储在物理位置上相邻的存储单元里,结点间的逻辑关系由存储单元的邻接关系来体现。

    由此得到的存储表示称为顺序存储结构 (Sequential Storage Structure ),通常借助程序语言的数组描述。

    该方法主要应用于线性的数据结构。非线性的数据结构也可通过某种线性化的方法实现顺序存储。

    (2)链接存储方法

    该方法不要求逻辑上相邻的结点在物理位置上亦相邻,结点间的逻辑关系由附加的指针字段表示。由此得到的存储表示称为链式存储结构(Linked Storage Structure), 通常借助于程序语言的指针类型描述。

    (3)索引存储方法

    该方法通常在储存结点信息的同时,还建立附加的索引表。 索引表由若干索引项组成。若每个结点在索引表中都有一个索引项,则该索引表称之为稠密索引(Dense Index )。若一组结点在索引表中只对应一个索引项,则该索引表称为稀疏索引(Spare Index)。索引项的一般形式是:

    (关键字、地址)

    关键字是能唯一标识一个结点的那些数据项。稠密索引中索引项的地址指示结点所在的存储位置;稀疏索引中索引项的地址指示一组结点的起始存储位置。

    (4)散列存储方法

    该方法的基本思想是:根据结点的关键字直接计算出该结点的存储地址。

    四种基本存储方法,既可单独使用,也可组合起来对数据结构进行存储映像。

    同一逻辑结构采用不同的存储方法,可以得到不同的存储结构。选择何种存储结构来表示相应的逻辑结构,视具体要求而定,主要考虑运算方便及算法的时空要求。

    数据结构三方面的关系

    数据的逻辑结构、数据的存储结构及数据的运算这三方面是一个整体。孤立地去理解一个方面,而不注意它们之间的联系是不可取的。 存储结构是数据结构不可缺少的一个方面:同一逻辑结构的不同存储结构可冠以不同的数据结构名称来标识。

    【例】线性表是一种逻辑结构,若采用顺序方法的存储表示,可称其为顺序表;若采用链式存储方法,则可称其为链表;若采用散列存储方法,则可称为散列表。

    数据的运算也是数据结构不可分割的一个方面。在给定了数据的逻辑结构和存储结构之后,按定义的运算集合及其运算的性质不同,也可能导致完全不同的数据结构。

    【例】若对线性表上的插入、删除运算限制在表的一端进行,则该线性表称之为栈;若对插入限制在表的一端进行,而删除限制在表的另一端进行,则该线性表称之为队列。更进一步,若线性表采用顺序表或链表作为存储结构,则对插入和删除运算做了上述限制之后,可分别得到顺序栈或链栈,顺序队列或链队列。


    转载至:http://www.chinadmd.com/theme/6IL8J5o595758154A75b7HJ3SY153F696JoE6/

    展开全文
  • 数据存储

    2020-03-24 11:22:57
    ①MySQL 索引使用的注意事项 ②说说分库与分表设计 ③分库与分表带来的分布式困境与应对之策 ④说说 SQL 优化之道 ⑤MySQL 遇到的死锁...⑥存储引擎的 InnoDB 与 MyISAM ⑦数据库索引的原理 ⑧为什么要用 B-Tree ...

    MySQL 索引使用的注意事项

    • 更新频繁的列不应设置索引
    • 数据量小的表不要使用索引
    • 重复数据多的字段不应设为索引(比如性别,只有男和女,一般来说:重复的数据超过百分之15就不该建索引)
    • 首先应该考虑对where 和 order by 涉及的列上建立索引

    说说分库与分表设计

    • 垂直分表:垂直分表在日常开发和设计中比较常见,通俗的说法叫做“大表拆小表”,拆分是基于关系型数据库中的“列”(字段)进行的。通常情况,某个表中的字段比较多,可以新建立一张“扩展表”,将不经常使用或者长度较大的字段拆分出去放到“扩展表”中。在字段很多的情况下,拆分开确实更便于开发和维护(笔者曾见过某个遗留系统中,一个大表中包含100多列的)。某种意义上也能避免“跨页”的问题(MySQL底层都是通过“数据页”来存储的,“跨页”问题可能会造成额外的性能开销),拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分,则需要改写以前的查询语句,会额外带来一定的成本和风险,建议谨慎。
    • 垂直分库:垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库,而不是像早期一样将所有的数据表都放到同一个数据库中。系统层面的“服务化”拆分操作,能够解决业务系统层面的耦合和性能瓶颈,有利于系统的扩展维护。而数据库层面的拆分,道理也是相通的。与服务的“治理”和“降级”机制类似,我们也能对不同业务类型的数据进行“分级”管理、维护、监控、扩展等。
    • 水平分表:水平分表也称为横向分表,比较容易理解,就是将表中不同的数据行按照一定规律分布到不同的数据库表中,这些表保存在同一个数据库中,这样来降低单表数据量,优化查询性能。最常见的方式就是通过主键或者时间等字段进行Hash和取模后拆分。水平分表,能够降低单表的数据量,一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中,所以库级别还是会有IO瓶颈。所以,一般不建议采用这种做法。
    • 水平分库:水平分库分表与上面讲到的水平分表的思想相同,唯一不同的就是将这些拆分出来的表保存在不同的数据库中。这也是很多大型互联网公司所选择的做法。某种意义上来讲,有些系统中使用的“冷热数据分离”(将一些使用较少的历史数据迁移到其他的数据库中。而在业务功能上,通常默认只提供热点数据的查询),也是类似的实践。在高并发和海量数据的场景下,分库分表能够有效缓解单机和单库的性能瓶颈和压力,突破IO、连接数、硬件资源的瓶颈。当然,投入的硬件成本也会更高。同时,这也会带来一些复杂的技术问题和挑战(例如:跨分片的复杂查询,跨分片事务等)。

    分库与分表带来的分布式困境与应对之策

    • 事务问题:使用分布式事务。
    • 查询问题:使用汇总表。
    • ID唯一性
      • 使用全局唯一 ID:GUID。
      • 为每个分片指定一个 ID 范围。
      • 分布式 ID 生成器。

    说说 SQL 优化之道

    • 负向条件查询不能使用索引,像“!=”、“not in”、“not exists”都不是好习惯,可以用 “in” 查询代替
    • 前导模糊查询“like '%xxx'” 不能使用索引,后导模糊查询可以使用前缀索引。
    • 数据区分度不大的字段不宜使用索引,比如性别。
    • 调用函数之后的字段不能使用索引,例如 select from order where YEAR(date) < = '2020'
    • 如果业务大部分是单条查询,使用Hash索引性能更好。因为 B-Tree 索引的时间复杂度是 O(log(n)),Hash 索引的时间复杂度是 O(1)。
    • 如果明确知道只有一条结果返回,limit 1 能够提高效率
    • 把计算放到业务层而不是数据库层,节省数据库的CPU。
    • 如果只返回部分需要的列,不要使用 “select *”,能够大大的节省数据传输量,与数据库的内存使用量。

    MySQL 遇到的死锁问题

    • 死锁场景描述:用户A访问表T1(锁住了表T1),然后又试图访问表T2;用户B访问表T2(锁住了表T2),然后试图访问表T1;这时用户A由于用户B已经锁住了表T2,必须等待用户B释放T2的锁才能进行下一步,而用户B也需要等待用户A释放T1的锁才能进行下一步,于是产生了死锁。
    • 这种死锁比较常见,是由于程序的BUG产生的。仔细分析程序的逻辑,对于数据库的多表操作时,尽量按照相同的顺序进行处理,尽量避免同时锁定两个资源,如操作A和B两张表时,总是按先A后B的顺序处理,必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源。

    存储引擎的 InnoDB 与 MyISAM

    对比项 MyISAM InnoDB
    主外键 不支持 支持
    事务 不支持 支持
    表级锁和行级锁 表锁,即使操作一条记录也会锁住整个表,不适合高并发操作 行锁,操作时只锁住某一行,不对其他行有影响,适合高并发操作
    缓存 只缓存索引,不缓存真实数据 都缓存,对内存要求较高,而且内存大小对性能有决定性的影响
    表空间
    关注点 性能 事务

    数据库索引的原理

    • 索引的目的:加快查询速度。
    • 索引的数据结构:哈希、有序数组、B-Tree

    为什么要用 B-Tree

    • 对比 二叉树 索引,树高不高,所以减少了IO磁盘的读取,从而提高了性能。
    • 对比 Hash 索引,Hash索引不支持范围查询、排序查询。而且如果相同Hash索引值相同的数据太多的话,性能并不一定会比B-Tree高。
    • 对比 有序数组 索引,

    聚集索引与非聚集索引的区别

    • 聚集索引即聚簇索引,叶子结点存的直接就是数据,InnoDB的主键索引就是聚簇索引。
    • 非聚簇索引,叶子结点存的是主键的值,非聚簇索引查询所有数据需要先查询主键的值,再回表查询回到主键索引查询所有数据

    limit 20000 加载很慢怎么解决

    • limit 20000 一次从磁盘加载到内存的数据页太多,会造成查询很慢的情况。
    • 可以按照主键排序,一次查询1000条,像这样:select * from T order by id where id > {id} limit 1000
    • 其中 id 一开始取值 0,后面都取前一次查询 id 的最大值,连续查询20次,就可以查询前20000行数据了。

    选择合适的分布式主键方案

    • 可以使用分布式 Redis 生成主键 ID,Redis 是单线程的可以保证生成唯一 ID,可以利用 Redis 原子操作 INCR 和 INCRBY 来实现。

    选择合适的数据存储方案

    • 关系型数据库 MySQL
    • 内存键值型数据库 Redis
    • 文档数据库 MongoDB

    ObjectId 规则

    • ObjectId 使用12字节的存储空间,是一个由24个16进制数字组成的字符串。示例:d98f7w6gryth4r68yr65tey4
    • 前四位是时间戳,可以提供秒级别的唯一性。
    • 接下来三位是所在主机的唯一标识符,通常是机器主机名的散列值。
    • 接下来两位是产生 ObjectId 的 PID,确保同一台机器上并发产生的 ObjectId 是唯一的。
    • 前九位保证了同一秒钟不同机器的不同进程产生的 ObjectId 是唯一的。
    • 最后三位是自增计数器,确保相同进程同一秒钟产生的 ObjectId 是唯一的。

    聊聊 MongoDB 使用场景

    1. 网站实时数据:mongoDB非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
    2. 数据缓存:由于性能很高,MongoDB 也适合作为信息基础设施的缓存层。在系统重启之后,由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。
    3. 大尺寸、低价值数据存储:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
    4. 高伸缩性场景:MongoDB 非常适合由数十或数百台服务器组成的数据库。MongoDB 的路线图中已经包含对 MapReduce 引擎的内置支持。
    5. 对象或 JSON 数据存储:MongoDB 的 BSON 数据格式非常适合文档化格式的存储及查询。

    倒排索引

    • 传统关键词查询流程是,遍历所有记录查询出含有关键词的所有匹配记录再进行一个排序,返回结果。
    • 但是在网页上查询时,互联网上收录在搜索引擎中的数据记录是个天文数字,每个遍历显然是不现实的。
    • 于是采用倒排排序的方式,即关键词到记录ID的映射,每个关键词都对应了一系列的文件记录ID,这些文件记录都出现了该词。

    聊聊 ElasticSearch 使用场景

    • 全文搜索,加上分词插件、拼音插件什么的可以做成强大的搜索引擎。
    • 在线统计分析引擎,日志系统,可以实时动态分析数据。
    展开全文
  • 大数据技术之数据存储

    千次阅读 2018-04-05 10:13:40
    目前市场上有两种类型的大数据分析方式--同步的和异步的,两种都有各自在存储容量和特性上的要求。 近来大数据分析这个词正逐渐成为IT界流行的一个术语,以代指有关大数据本身的猜想,通俗说来即成堆数据背后问题的...

    目前市场上有两种类型的大数据分析方式--同步的和异步的,两种都有各自在存储容量和特性上的要求。

      近来大数据分析这个词正逐渐成为IT界流行的一个术语,以代指有关大数据本身的猜想,通俗说来即成堆数据背后问题的答案。然而,如果我们能够从足够的数据点入手比对及交叉分析,或许能帮助我们找到一些有用的数据,甚至可能帮助避免灾难。

      问题是显而易见的,所有的分析都需要大量甚至海量的数据,这便给当今的IT管理人员带来了更新的挑战,即如何捕获、存取、以及分析这些数据并将从中得到的分析用于后续任务的执行?

      大数据分析应用通常会使用例如网络流量、金融交易记录以及敏感数据来替代传统形式的内容。数据本身的价值在于数据间的比对、关联或者引用。对大数据的分析通常会意味着与大量的小数据对象打交道,而这些小数据对象往往对响应延时要求非常之高。

      当前业界主要有两种大数据分析场景,而它们通常是根据数据处理的形式而区分:

      在实时使用场景下,响应效率是最为关键的 ,因此大数据存储架构本身的设计需要满足最小延时的功能。

      同步,即实时的或者近乎于实时的;另外一种就是异步的方式,这种方式下,数据首先会被获取,记录下来然后再用批处理进程进行分析。

      同步分析

      可以想到的近乎于实时的大数据分析的最早的例子就是超级市场里的工作人员是如何统计消费者行为习惯以便于提供相应的优惠促销券的。事实上是,消费者购买行为计算很可能在用户收银前就已经完成,但是概念本身是非常类似的。另外一个相关的例子是在线社交网站可以通过访问用户的行为建立属于他们的行为数据库,这样就可以根据各自不同的消费习惯提供不同的点对点广告植入。

      在零售行业,一些大型商铺正开始在停车场对前来购物的消费者使用面部识别技术,这样一旦他们路过或者经过对应的商铺与之相应的促销信息便随之而来。因此,在这样一类的实时大数据分析场景中,速度是第一要素,故而大数据存储架构需要建设成为低延时的场景。

      针对同步大数据分析的存储

      实时分析应用通常会运行在例如NoSQL之类的数据库上,通常都能支持海量可扩展的商用硬件上。Hadoop,从另一角度考虑,非常适合批量的数据处理,这种技术非常合适于异步大数据分析。由于在很多场合下,存储本身会成为延时问题的瓶颈,那么固态存储设备对于实时数据分析是很有帮助的。闪存存储可以以多种形式进行部署:作为传统存储磁盘阵列的一层,以NAS系统的方式,再或者以应用服务器本身的方式都可以实现。

      这种服务器端的闪存实施方式广受用户欢迎,之所以这样是由于它能够实现最低程度的延时(因该方式下的存储最为接近CPU),并且提供了很灵活的容量选择,几百GB容量就可以实现。SAS/SATA接口的固态硬盘本身就是个选择,但是近来我们看到PCIe板卡为接口的固态设备逐渐成了性能应用(比如实时分析)的标准,因为相对于前者,其延时更低。

      如今,业界有许多提供PCIe闪存存储的公司,包括Fusion-io、LSI、Micron Technology、SanDisk、sTec(现在是HGST的一部分,作为Western Digital的一个部门)、Violin Memory以及Virident (也被Western Digital收购)。其它所有主流服务器及存储厂商们也都提供PCIe解决方案,大多数是与这些公司通过了OEM协议。

      尽管PCIe卡最大容量已经近乎于10 TB,但仍无法满足用户的需求,因此一个共享的存储资源池也是需要考虑的。一个解决方案是使用Virident的FlashMAX Connect software,这种软件可以实现将PCIe卡的资源通过服务器上的InfiniBand,进行资源池化。

      这对扩展闪存容量会非常有帮助,尤其是对于那些PCIe插槽不足的服务器或者需要使用VMware vSphere的Storage vMotion功能的时候。通过在不同服务器之间实现闪存的池化,这些解决方案可以提供冗余以及高可用性方面的支持。

      另外一个选择是通过InfiniBand、光纤通道或者甚至PCIe的连接方式使用全闪存阵列。全闪存阵列的容量从10 TB到100 TB之间,可以以模块的方式进行扩容。以全闪存阵列这类的高端解决方案可以提供至少100万IOPS,相对应到百万微秒级别。大多数主流的存储厂商都有相应的全闪存阵列类别,除了IBM对Texas Memory的收购,小厂商都有类似的产品并提供了更多的选择,他们中有Kaminario、Nimbus Data Systems、Pure Storage、Tegile、即将被思科收购的Whiptail以及Violin Memory.

      异步大数据分析

      异步处理的大数据分析中遵守了捕获、存储加分析的流程,过程中数据由传感器、网页服务器、销售终端、移动设备等获取,之后再存储到相应设备上,之后再进行分析。由于这些类型的分析都是通过传统的关系型数据库管理系统(RDBMS)进行的,数据形式都需要转换或者转型成为RDBMS能够使用的结构类型,例如行或者列的形式,并且需要和其它的数据相连续。

      处理的过程被称之为提取、变形、加载或者称为ETL.首先将数据从源系统中提取处理,再将数据标准化处理且将数据发往相应的数据仓储等待进一步分析。在传统数据库环境中,这种ETL步骤相对直接,因为分析的对象往往是为人们熟知的金融报告、销售或者市场报表、企业资源规划等等。然而在大数据环境下,ETL可能会变得相对复杂,因此转型过程对于不同类型的数据源之间处理方式是不同的。

      当分析开始的时候,数据首先从数据仓储中会被抽出来,被放进RDBMS里以产生需要的报告或者支撑相应的商业智能应用。在大数据分析的环节中,裸数据以及经转换了的数据大都会被保存下来,因为可能在后面还需要再次转换。

      适用于异步大数据分析的存储设备

      在异步大数据场景下对于存储的调整主要来自于容量、可扩展性、可预见性,尤其是提供这些功能的成本。当数据仓库产生大量数据集的时候,磁带存储的延时会显得非常大以至于无法满足业务需求。换而言之,传统的向上扩展的磁盘存储架构在相同容量标准下,往往并不能做到节约成本。

      横向扩展存储。横向扩展存储是使用模块或者节点以群集的方式将资源池化,以文件系统的形式作为接口为大数据分析服务。例如有Dell EqualLogic、EMC Isilon、Exablox (also object-based)、Gridstore、HP StoreAll (之前叫Ibrix)以及IBM横向扩展NAS (SONAS)。这些解决方案里,每个节点都包含有处理能力及磁盘容量,它们能实现容量与性能的并行扩展。

      Hadoop技术也被应用于存储架构的方式,使得企业能够以较低的硬件成本与较高的灵活性,搭建属于它们自己的高可扩展性存储系统。Hadoop运行在集群的不同节点上,每个节点都有自己的存储及计算资源,尤其是在面对数据处理需求的时候。其它节点会协调这些处理任务并以分布式资源池的方式进行处理,通常是以Hadoop分布式文件系统HDFS的形式存在。

      为什么Hadoop对大数据意义重大

      Hadoop得以在大数据应用中广泛应用得益于其自身在数据提取、变形和加载(ETL)方面上的天然优势。Hadoop的分布式架构,将处理引擎尽可能的靠近存储,对例如像ETL这样的批处理操作相对合适,因为类似这样操作的批处理结果可以直接走向存储。Hadoop的MapReduce功能实现了将单个任务打碎,并将碎片任务发送(Map)到多个节点上,之后再以单个数据集的形式加载(Reduce)到数据仓库里。

      但是对于Hadoop,特别是Hadoop分布式文件系统(HDFS)来说,数据至少需要三份以支持数据的高可用性。对于TB级别的数据来说,HDFS看起来还是可行的,但当达到PB级别海量数据的时候,其带来的存储成本压力不可小觑。即便是可横向扩展存储亦不能避免压力本身,一些厂商选择了使用RAID技术实现卷级别的保护,而在系统级别则使用了复制的方式。对象存储技术可以提供面对大型环境的数据冗余问题的解决方案。

      对象存储。基于对象的存储架构可以通过替代分层存储架构的方式,极大程度上提升可横向扩展存储的优势,它使用的方式则是以单一索引来关联灵活的数据对象。这将解决无限制扩展问题,从而提升了性能本身。对象存储系统包含了无需RAID或者复制作为数据保护的纠删码,极大程度上提升了存储的使用效率。

      不像HDFS方式下需要两份或者三份多余数据拷贝以及额外的RAID机制,对象存储系统的纠删码可仅以50%-60%的额外容量就能达到更高的数据保护级别。在大数据存储级别,对于存储本身的节省将是非常重大的。许多对象存储系统亦可选择,包括Caringo、DataDirect Networks Web Object Scaler、NetApp StorageGRID、Quantum Lattus以及开源的 OpenStack Swift和 Ceph.

      一些对象存储系统,比如Cleversafe的,甚至可以做到与Hadoop兼容。在这些项目的实施中,Hadoop软件组件可以运行在这些对象存储节点的CPU上,对象存储系统将替换存储节点的Hadoop分布式文件系统。

      大数据存储的底线

      大数据分析逐渐在IT行业成为了一个热门的话题,越来越多的企业相信它将引领企业走向成功。然而任何事情都有两个方面。这件事情上来看,就是现有存储技术本身。传统存储系统不管是在需要极低延时响应、实时大数据应用或者还是面对海量数据仓储的数据挖掘应用的时候都会遇到瓶颈。为了保证大数据分析业务能正常运行,相应的存储系统需要足够快,可扩展并且性价比有优势。

      对于闪存解决方案来说,不管是以服务器端flash卡的形式还是以全闪存阵列的形式,都提供了一些对于高性能、低延时、大容量存储的替代解决方案。基于对象的带有擦写功能编程的可横向扩展架构为使用传统RAID以及复制方式的存储结构提供了一种能具备更高效率和更低价格的选择。

    展开全文
  • 聊聊大数据(一)——大数据的存储

    万次阅读 多人点赞 2018-05-04 19:25:44
    “大数据”现在可谓越来越火了,不管是什么行业,也不敢是不是搞计算机的,都...多大的数据算“大数据”哪?麦肯锡研究中心给出的定义是“超过一般计算机处理能力”的数据。好吧,这个概念真是投机取巧,让人难以攻...

    “大数据”现在可谓越来越火了,不管是什么行业,也不敢是不是搞计算机的,都要赶个集,借着这股热潮,亦或炒作,亦或大干一番。尤其是从事IT行业的,不跟“大数据”沾点边,都不好意思出去说自己是干IT的。

    “大数据”一词,已无从考证具体是什么时候兴起的,只是隐约记得大概火了三四年了吧。多大的数据算“大数据”哪?麦肯锡研究中心给出的定义是“超过一般计算机处理能力”的数据。好吧,这个概念真是投机取巧,让人难以攻击。因为大数据的界限真的难以定义。只能说我们平时自己保存和处理的数据都不是大数据。有些人以为自己电脑里有个特别大的Excel文件就是大数据;还有些人觉得有个数据库装了些数据就是大数据;有些闷骚男们说了:我专门买了个盘存了好几T的片片那,看我有这么大的数据……这些都不是大数据。

    按照麦肯锡的定义,既然大数据是一般的计算机都处理不了的数据,那么肯定不是几个尺寸大点儿的文件就可以被称之为大数据。笔者斗胆总结一下大数据的几个特性:

    首先,大数据肯定是存储量很大的数据。

    这是前提条件。业界没有给出明确的数量定义,但肯定不能低于TB级。否则一般的个人电脑就可以轻松处理,就没有多大的研究价值了。

    其次,大数据一定是没有明确组织规律的。

    虽然局部可能有些规律可循,但总体上一定是没有统一的规律了。否则也没有多大的研究价值。可能兼顾了表格、图片、日志等多种类型的数据,甚至可能会有各种格式的视频和音频流。

    第三,大数据一定是不容易分析的。

    接着第二点来说,大数据肯定不会是单纯的存储和组织方式,不会像我们平时自己造的表格那样简单明了。而且,我们无法从中分析出一个简单统一的公式,使得所有数据都可以满足这个公式。即便是可以分析出某些公式来,也会形成成百上千个公式。所以,大数据的分析一定不是一蹴而就的,而是分布开展的。可能先会得到一些最原始的规律,再从这些原始规律中去分析出更高级的规律……不知会经过多少步才会得到最终有些价值的信息。

    第四、大数据一般是动态的。

    大数据一般不会是死或一成不变的数据,而是会不断追加新的数据,从而其尺寸不断变大。比如常见的就是操作日志、监测数据……等等。常见的大数据包括大型机场的订票或飞行数据、大型超市的用户购物记录、证券公司股民的股票交易记录、化工厂的设备运行监测数据、城市出租车起止位置数据、煤矿等作业区域的人员定位数据……等等。这些数据除了数据量很大外,还会实时产生海量的新数据。所以进行大数据分析时要充分考虑到数据的变化因素。

    第五、大数据一般是用于预测的。

    正如上段内容中介绍的,大数据环境一定是海量的数据环境,并且增量都有可能是海量的。大数据分析的价值就是从已有的数据中分析出固有的一些规律,从而能够与未来新产生的数据相吻合,从而可以提前预测未来会发生的一些事件,或提供一些有价值的信息,提前进行决策和处置。

    忽然想起了多年前大学期间学过一门课程,叫《数据挖掘》,里面提到了数据挖掘针对的对象是“数据仓库”,指的就是数据量很大的数据。为此还提出了钻取、抽析等多种分析方法和理论。现在看来个人感觉大数据应该就是从数据挖掘的基础上发展起来的,只不过大数据面对的数据量比数据挖掘理论盛行时还要大很多个数量级吧。

    正因为大数据的特殊性,所以已经不能用通常的理论和方法来处理了。

    首先是大数据的存储。前面说了,大数据面对的数据量异常大,不是几块几个TB的硬盘就可以随随便便容纳得了的。而且个人电脑上的存储设备一般也无法容纳如此大量的数据。为了能够提供快速、稳定地存取这些数据,至少得依赖于磁盘阵列。同时还得通过分布式存储的方式将不同区域、类别、级别的数据存放于不同的磁盘阵列中。

    以往的关系型数据库受限于设计模式的限制,一般只考虑到了单机的数据存储方式,即不管数据量大与小,一定会让一台机器存储和管理所有数据(即便是做集群,集群中的每个节点实际上也是要把所有的数据再存储一遍)。而每台机器上可以承载的存储设备是有限的,一般也不会超过几个TB。而且一旦某个数据库的数据量和文件的尺寸暴增到一定程度后,数据的检索速度就会急剧下降。

    为了应对这个问题,很多主流的数据库纷纷提出了一些解决方案。如MySQL提供了MySQL proxy组件,实现了对请求的拦截,结合分布式存储技术,从而可以将一张很大的表中的记录拆分到不同的节点上去进行查询。对于每个节点来说,数据量不会很大,从而提升了查询效率。


    而Oracle针对大数据公开可查询的资料是“大数据机X3-2+Hadoop+NoSQL”的解决方案。在这套方案中,Oracle提供了拥有288个CPU、1152G内存、648T硬盘的无比豪华的服务器配置,同时结合Hadoop和NoSQL等技术对其中存储的大数据进行分析:


    怎么说那,个人感觉Oracle完全是土豪策略:有钱你才能玩大数据,而有了钱你就买个特别牛×的机器,这样你就不怕数据大了。实际上Oracle并没有从根儿上专门为大数据而动过手术。

    而对于像MongoDB、HBase等非关系型数据库,由于摆脱了表的存储模式,再加上起步较晚,所以对大数据的响应要比关系型数据库快的多。

    MongoDB和HBase天生都支持分布式存储,即将一份大的数据分散到不同的机器上进行存储,从而降低了单个节点的存取压力。


    所以在实际应用中,如果是针对老的系统尤其是老的数据库进行大数据存储及分析,那么只能考虑横向拆分关系型数据库中的数据了;如果是准备建设新的系统,那么最好采用MongoDB,并使用分片集特性来存储大数据。HBase也可以,但入门学习成本可能稍微有一些高。

    下一篇文章,咱们来聊聊大数据的分析过程和方法。
    展开全文
  • 结构化数据存储 随着互联网应用的广泛普及,海量数据存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的...
  • java中数据的5种存储位置

    千次阅读 多人点赞 2018-05-09 07:25:39
    这是最快的保存区域,因为它位于和其他所有保存方式不同的地方:处理器内部。然而,寄存器的数量十分有限,所以寄存器是根据需要由编译器分配。我们对此没有直接的控制权,也不可能在自己的程序里找到寄存器存在的...
  • 大数据的存储和管理

    千次阅读 2018-11-03 18:27:40
    分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow也欢迎大家转载本...分享知识,造福人民,实现我们中华民族伟大复兴!&nbsp;&nbsp;&nbsp;... 大数据的存储和管理任何
  • 数据存储---五种存储方式简介

    万次阅读 2017-05-01 11:09:19
    数据存储方式 1 使用SharedPreferences存储数据; 是Android提供的用来存储一些简单配置信息的一种机制,例如:登录用户的用户名与密码。其采用了Map数据结构来存储数据,以键值的方式存储,可以简单的读取与写入。...
  • Android数据存储总结 之一

    万次阅读 2016-11-28 18:43:25
    今天和大家聊聊Android数据存储的那些事,顺便对这一块知识做一个总结归纳。学习Android开发,知识很多很杂,对于一个刚学习的人来说,学的即使再多但在实际的开发中却也不懂得怎么去用,碰到问题了也不知道选择哪种...
  • HTML5数据存储

    2018-07-22 09:32:26
    HTML5中增加了两种全新的数据存储方式:WebStorage和WebSQLDatabase。 WebStorage可用于临时或永久保存客户端的少量数据,WebSQLDatabase是客户端本地化的一套数据库系统,可以将大量的数据保存在客户端,无须与...
  • Hive的数据存储

    千次阅读 2017-08-26 15:01:01
    Hive的数据分为表数据和元数据,表数据是Hive中表格...在让你真正明白什么是hive 博文中我们提到Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中。Hive本身是没有专门的数据存储格式,也没
  • 1)、内嵌模式:将元数据保存在本地内嵌的derby数据库中,内嵌的derby数据库每次只能访问一个数据文件,也就意味着它不支持多会话连接。 2). 本地模式:将元数据保存在本地独立的数据库中(一般是mysql),这...
  • 数据存储 使用场景 许多时候我们需要将用户的数据保存到本地,以便以后的调用。比如说openid,如果每次打开小程序都需要发送code到后台解析成出openid,对资源消耗还是比较大的。这个时候数据缓存就派上了用场。 ...
  • Redis 数据存储位置 导出数据

    千次阅读 2017-11-28 12:44:28
    Redis 数据存储位置 导出数据 qq1413139134 2015-12-23 15:25:00 浏览7302 评论0 云数据库Redis版 摘要: Redis是一款支持多种数据类型的Key-Value数据库。这里介绍下如何从Redis中导出数据。 数据是...
  • Hive数据的数据存储

    千次阅读 2018-03-07 10:19:23
    Hive建表后,表的元数据存储在关系型数据库中(如:mysql),表的数据(内容)存储在hdfs中,这些数据是以文本的形式存储在hdfs中(关系型数据库是以二进制形式存储的),既然是存储在hdfs上,那么这些数据本身也是...
  • 微信小程序---数据存储与取值

    千次阅读 2018-10-08 10:16:52
    在小程序开发的过程,经常要需要这个页面输入的数据,在下一个页面中进行取值赋值。...微信小程序提供了数据存储的API,wx.setStorage(OBJECT) 可以将数据存储在本地缓存中指定的 key 中,如果重复会覆盖掉...
  • 单片机测试系统的数据存储和管理

    千次阅读 2012-11-05 10:42:57
    单片机测试系统的数据存储和管理 时间:2007-12-10 09:48:00 来源:单片机及嵌入式系统应用 作者:北京航空航天大学 赵成 袁海文 摘要 介绍一种应用于单片机洲试系统的链式存储结构,其特点在于采用数据...
  • 结合个人参与的游戏项目开发,谈一下游戏开发玩家数据保存的处理 玩家的数据基本上分为两份,一份是玩家下线或者永久保存数据,通常保存至数据库(mysql或者mongodb)中,一份是保存在内存中。 一般玩家数据的...
  • Android之数据存储

    万人学习 2018-11-29 17:01:28
    Android数据存储视频教程,该课程介绍了Android中几种数据存储方式,让大家对Android中的数据存储一个系统的认识,比如文件存储、复制SD卡、SharedPreference引导页、数据源等。
  • 海量文本数据保存到数据库思路

    千次阅读 2016-03-21 15:21:11
    后台处理网页上传的文本文件,将相应的数据存储到数据库中;后台数据全部处理完成后,将整个后台处理花费的时间传给前端,并显示。 在开发中,使用的技术以及一些问题。 使用SpringMVC做项目的整体架构;后台...
1 2 3 4 5 ... 20
收藏数 4,806,566
精华内容 1,922,626
关键字:

数据存储