数据存储_存储器数据 - CSDN
  • Android之数据存储

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

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

    (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 使用场景

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

    2013-04-17 10:39:11
    大数据的存储和管理 任何机器都会有物理上的限制:内存容量、硬盘容量、处理器速度等等,我们需要在这些硬件的限制和性能之间做出取舍,比如内存的读取速度比硬盘快得多,因此内存数据库比硬盘数据库性能好,但是...

    大数据的存储和管理

    任何机器都会有物理上的限制:内存容量、硬盘容量、处理器速度等等,我们需要在这些硬件的限制和性能之间做出取舍,比如内存的读取速度比硬盘快得多,因此内存数据库比硬盘数据库性能好,但是内存为2GB的机器不可能将大小为100GB的数据全部放入内存中,也许内存大小为128GB的机器能够做到,但是数据增加到200GB时就无能为力了。

    数据不断增长造成单机系统性能不断下降,即使不断提升硬件配置也难以跟上数据的增长速度。然而,当今主流的计算机硬件比较便宜而且可以扩展,现在购置八台8内核、128GB内存的机器比购置一台64内核、TB级别内存的服务器划算得多,而且还可以增加或减少机器来应对将来的变化。这种分布式架构策略对于海量数据来说是比较适合的,因此,许多海量数据系统选择将数据放在多个机器中,但也带来了许多单机系统不曾有的问题。

    下面我们介绍大数据存储和管理发展过程中出现的四类大数据存储和管理数据库系统。

    并行数据库

    并行数据库[1]是指那些在无共享的体系结构中进行数据操作的数据库系统。这些系统大部分采用了关系数据模型并且支持SQL语句查询,但为了能够并行执行SQL的查询操作,系统中采用了两个关键技术:关系表的水平划分和SQL查询的分区执行。

    水平划分的主要思想就是根据某种策略将关系表中的元组分布到集群中的不同节点上,这些节点上的表结构是一样的,这样就可以对元组并行处理。现有的分区策略有哈希分区、范围分区、循环分区等。例如,哈希分区策略是将表T中的元组分布到n个节点上,可以使用统一的哈希算法对元组中的某个或某几个属性进行哈希,如hash(T.attribute1) mod n,然后根据哈希值将元组放置到不同的节点上。

    在分区存储的表中处理SQL查询需要使用基于分区的执行策略,如获取表T中某一数值范围内的元组,系统首先为整个表T生成总的执行计划P,然后将P拆分成n个子计划{P1,,Pn},子计划Pi在节点ni上独立执行,最后每个节点将生成的中间结果发送到某一选定的节点上,该节点对中间结果进行聚集产生最终的结果。

    并行数据库系统的目标是高性能和高可用性,通过多个节点并行执行数据库任务,提高整个数据库系统的性能和可用性。最近一些年不断涌现一些提高系统性能的新技术,如索引、压缩、实体化视图、结果缓存、I/O共享等,这些技术都比较成熟且经得起时间的考验。与一些早期的系统如Teradata必须部署在专有硬件上不同,最近开发的系统如AsterVertica等可以部署在普通的商业机器上,这些数据库系统可以称得上准云系统。

    并行数据库系统的主要缺点就是没有较好的弹性,而这种特性对中小型企业和初创企业是有利的。人们在对并行数据库进行设计和优化的时候认为集群中节点的数量是固定的,若需要对集群进行扩展和收缩,则必须为数据转移过程制订周全的计划。这种数据转移的代价是昂贵的,并且会导致系统在某段时间内不可访问,而这种较差的灵活性直接影响到并行数据库的弹性以及现用现付商业模式的实用性。

    并行数据库的另一个问题就是系统的容错性较差,过去人们认为节点故障是个特例,并不经常出现,因此系统只提供事务级别的容错功能,如果在查询过程中节点发生故障,那么整个查询都要从头开始重新执行。这种重启任务的策略使得并行数据库难以在拥有数以千个节点的集群上处理较长的查询,因为在这类集群中节点的故障经常发生。基于这种分析,并行数据库只适合于资源需求相对固定的应用程序。不管怎样,并行数据库的许多设计原则为其他海量数据系统的设计和优化提供了比较好的借鉴。

    NoSQL数据管理系统

    NoSQL[5]一词最早出现于1998年,它是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系型数据库(他认为,由于NoSQL悖离传统关系数据库模型,因此,它应该有一个全新的名字,比如“NoREL”或与之类似的名字[6])。

    2009年,Last.fmJohan Oskarsson发起了一次关于分布式开源数据库的讨论[7],来自RackspaceEric Evans再次提出了NoSQL的概念,这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。

    2009年在亚特兰大举行的“no:sql(east)”讨论会是一个里程碑,其口号是"select fun, profit from real_world whererelational=false;"。因此,对NoSQL最普遍的解释是“非关系型的”,强调键值存储和文档数据库的优点,而不是单纯地反对关系型数据库。

    传统关系型数据库在处理数据密集型应用方面显得力不从心,主要表现在灵活性差、扩展性差、性能差等方面。最近出现的一些存储系统摒弃了传统关系型数据库管理系统的设计思想,转而采用不同的解决方案来满足扩展性方面的需求。这些没有固定数据模式并且可以水平扩展的系统现在统称为NoSQL(有些人认为称为NoREL更为合理),这里的NoSQL指的是“Not Only SQL”,即对关系型SQL数据系统的补充。NoSQL系统普遍采用的一些技术有:

         简单数据模型。不同于分布式数据库,大多数NoSQL系统采用更加简单的数据模型,这种数据模型中,每个记录拥有唯一的键,而且系统只需支持单记录级别的原子性,不支持外键和跨记录的关系。这种一次操作获取单个记录的约束极大地增强了系统的可扩展性,而且数据操作就可以在单台机器中执行,没有分布式事务的开销。

         元数据和应用数据的分离。NoSQL数据管理系统需要维护两种数据:元数据和应用数据。元数据是用于系统管理的,如数据分区到集群中节点和副本的映射数据。应用数据就是用户存储在系统中的商业数据。系统之所以将这两类数据分开是因为它们有着不同的一致性要求。若要系统正常运转,元数据必须是一致且实时的,而应用数据的一致性需求则因应用场合而异。因此,为了达到可扩展性,NoSQL系统在管理两类数据上采用不同的策略。还有一些NoSQL系统没有元数据,它们通过其他方式解决数据和节点的映射问题。

         弱一致性。NoSQL系统通过复制应用数据来达到一致性。这种设计使得更新数据时副本同步的开销很大,为了减少这种同步开销,弱一致性模型如最终一致性和时间轴一致性得到广泛应用。

    通过这些技术,NoSQL能够很好地应对海量数据的挑战。相对于关系型数据库,NoSQL数据存储管理系统的主要优势有:

         避免不必要的复杂性。关系型数据库提供各种各样的特性和强一致性,但是许多特性只能在某些特定的应用中使用,大部分功能很少被使用。NoSQL系统则提供较少的功能来提高性能。

         高吞吐量。一些NoSQL数据系统的吞吐量比传统关系数据管理系统要高很多,如Google使用MapReduce每天可处理20PB存储在Bigtable中的数据。

         高水平扩展能力和低端硬件集群。NoSQL数据系统能够很好地进行水平扩展,与关系型数据库集群方法不同,这种扩展不需要很大的代价。而基于低端硬件的设计理念为采用NoSQL数据系统的用户节省了很多硬件上的开销。

         避免了昂贵的对象-关系映射。许多NoSQL系统能够存储数据对象,这就避免了数据库中关系模型和程序中对象模型相互转化的代价。

    NoSQL向人们提供了高效便宜的数据管理方案,许多公司不再使用Oracle甚至MySQL,他们借鉴AmzonDynamoGoogleBigtable的主要思想建立自己的海量数据存储管理系统,一些系统也开始开源,如Facebook将其开发的Cassandra捐给了Apache软件基金会。

    虽然NoSQL数据库提供了高扩展性和灵活性,但是它也有自己的缺点,主要有:

         数据模型和查询语言没有经过数学验证。SQL这种基于关系代数和关系演算的查询结构有着坚实的数学保证,即使一个结构化的查询本身很复杂,但是它能够获取满足条件的所有数据。由于NoSQL系统都没有使用SQL,而使用的一些模型还未有完善的数学基础。这也是NoSQL系统较为混乱的主要原因之一。

         不支持ACID特性。这为NoSQL带来优势的同时也是其缺点,毕竟事务在很多场合下还是需要的,ACID特性使系统在中断的情况下也能够保证在线事务能够准确执行。

         功能简单。大多数NoSQL系统提供的功能都比较简单,这就增加了应用层的负担。例如如果在应用层实现ACID特性,那么编写代码的程序员一定极其痛苦。

         没有统一的查询模型。NoSQL系统一般提供不同查询模型,这一定程度上增加了开发者的负担。

    NewSQL数据管理系统

    人们曾普遍认为传统数据库支持ACIDSQL等特性限制了数据库的扩展和处理海量数据的性能,因此尝试通过牺牲这些特性来提升对海量数据的存储管理能力,但是现在一些人则持有不同的观念,他们认为并不是ACID和支持SQL的特性,而是其他的一些机制如锁机制、日志机制、缓冲区管理等制约了系统的性能,只要优化这些技术,关系型数据库系统在处理海量数据时仍能获得很好的性能。

     

    关系型数据库处理事务时对性能影响较大、需要优化的因素有:

         通信。应用程序通过ODBCJDBCDBMS进行通信是OLTP事务中的主要开销。

         日志。关系型数据库事务中对数据的修改需要记录到日志中,而日志则需要不断写到硬盘上来保证持久性,这种代价是昂贵的,而且降低了事务的性能。

         锁。事务中修改操作需要对数据进行加锁,这就需要在锁表中进行写操作,造成了一定的开销。

         闩。关系型数据库中一些数据结构,如B树、锁表、资源表等的共享影响了事务的性能。这些数据结构常常被多线程读取,所以需要短期锁即闩。

         缓冲区管理。关系型数据将数据组织成固定大小的页,内存中磁盘页的缓冲管理会造成一定的开销。

    为了解决上面的问题,一些新的数据库采用部分不同的设计,它取消了耗费资源的缓冲池,在内存中运行整个数据库。它还摈弃了单线程服务的锁机制,也通过使用冗余机器来实现复制和故障恢复,取代原有的昂贵的恢复操作。这种可扩展、高性能的SQL数据库被称为NewSQL,其中“New”用来表明与传统关系型数据库系统的区别,但是NewSQL也是很宽泛的概念。它首先由451集团在一份报告中提出,其主要包括两类系统:拥有关系型数据库产品和服务,并将关系模型的好处带到分布式架构上;或者提高关系数据库的性能,使之达到不用考虑水平扩展问题的程度。前一类NewSQL包括ClustrixGenieDBScalArcScaleBaseNimbusDB,也包括带有NDBMySQL集群、Drizzle等。后一类NewSQL包括TokutekJustOne DB。还有一些“NewSQL即服务”,包括Amazon的关系数据库服务、MicrosoftSQL AzureFathomDB等。

    当然,NewSQLNoSQL也有交叉的地方,例如,RethinkDB可以看作NoSQL数据库中键/值存储的高速缓存系统,也可以当作NewSQL数据库中MySQL的存储引擎。现在许多NewSQL提供商使用自己的数据库为没有固定模式的数据提供存储服务,同时一些NoSQL数据库开始支持SQL查询和ACID事务特性。

    NewSQL能够提供SQL数据库的质量保证,也能提供NoSQL数据库的可扩展性。VoltDBNewSQL的实现之一,其开发公司的CTO宣称,它们的系统使用NewSQL的方法处理事务的速度比传统数据库系统快45倍。VoltDB可以扩展到39个机器上,在300CPU内核中每分钟处理1600万事务,其所需的机器数比Hadoop集群要少很多。

    随着NoSQLNewSQL数据库阵营的迅速崛起,当今数据库系统“百花齐放”,现有系统达数百种之多,图1-1将广义的数据库系统进行了分类。

     

    1-1  数据库系统的分类

    1-1中将数据库分为关系型数据库、非关系型数据库以及数据库缓存系统。其中,非关系型数据库主要指的是NoSQL数据库,分为:键值数据库、列存数据库、图存数据库以及文档数据库四大类。关系型数据库包含了传统关系数据库系统以及NewSQL数据库。

    高容量、高分布式、高复杂性应用程序的需求迫使传统数据库不断扩展自己的容量极限,这些驱动传统关系型数据库采用不同的数据管理技术的6个关键因素可以概括为“SPRAIN”,即:

         可扩展性(Scalability)——硬件价格

         高性能(Performance)——MySQL的性能瓶颈

         弱一致性(Relaxedconsistency)——CAP理论

         敏捷性(Agility)——持久多样性

         复杂性(Intricacy)——海量数据

         必然性(Necessity)——开源

     

     

    作者简介

    陆嘉恒,中国人民大学教授,博士生导师。2006年毕业于新加坡国立大学计算机科学系,获博士学位;2006-2008年在美国加利福尼亚大学尔湾分校(University of California, Irvine)进行博士后研究;2008年加入中国人民大学,2012年破格晋升为教授。主要研究领域包括数据库技术和云计算技术。先后在SIGMODVLDBICDEWWW等国际重要会议和期刊上发表数据库方向的论文40多篇,主编多本云计算和大数据的教材和著作。

    本文节选自《大数据挑战与NoSQL数据库技术》一书。陆嘉恒编著,由电子工业出版社出版。

     

     

    展开全文
  • “大数据”现在可谓越来越火了,不管是什么行业,也不敢是不是搞计算机的,都...多大的数据算“大数据”哪?麦肯锡研究中心给出的定义是“超过一般计算机处理能力”的数据。好吧,这个概念真是投机取巧,让人难以攻...

    “大数据”现在可谓越来越火了,不管是什么行业,也不敢是不是搞计算机的,都要赶个集,借着这股热潮,亦或炒作,亦或大干一番。尤其是从事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也可以,但入门学习成本可能稍微有一些高。

    下一篇文章,咱们来聊聊大数据的分析过程和方法。
    展开全文
  • Android数据存储五种方式总结
  • Android五大数据存储

    2019-04-09 11:06:12
    数据存储可谓是Android中灰常灰常重要的一部分了。任何一个应用离不开数据的存储,有时需内存存储,有时需本地存储,还有时需要两个进程间传输数据,等等。那接下来介绍的五大存储中将包括了所有的应用中可能遇到的...
  • 结构化数据存储 随着互联网应用的广泛普及,海量数据存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的...
  • 数据存储方式 1 使用SharedPreferences存储数据; 是Android提供的用来存储一些简单配置信息的一种机制,例如:登录用户的用户名与密码。其采用了Map数据结构来存储数据,以键值的方式存储,可以简单的读取与写入。...
  • 随着互联网应用的广泛普及,海量数据存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来...
  • Unity(游戏)中五种数据存储的方法 一、PlayerPrefs unity3d提供了一个用于本地持久化保存与读取的类-------PlayerPrefs.工作原理很简单,以键值对的形式将数据保存在文件中,然后程序可以根据这个名称取出上次保存...
  • 今天和大家聊聊Android数据存储的那些事,顺便对这一块知识做一个总结归纳。学习Android开发,知识很多很杂,对于一个刚学习的人来说,学的即使再多但在实际的开发中却也不懂得怎么去用,碰到问题了也不知道选择哪种...
  • 现状:隔一段时间去数据中心获取一次数据,每次获取数据时只有极少部分数据会发生变更,但是系统需要溯源数据变更的情况。方案: 现状表+历史表结合的方式: ... 将全量数据存储在Hbase中,现状数
  • HIVE-元数据存储

    2019-02-26 14:53:26
    HIVE-元数据存储 元数据(Meta Date),主要记录数据仓库中模型的定义、各层级间的映射关 系、监控数据仓库的数据状态及 ETL 的任务运行状态。一般会通过元数据资料库 (Metadata Repository)来统一地存储和...
  • 按照存储模型来说分为以下4类。 键值存储 列式存储 文档存储 图形存储 ...键值数据模型的主要思想来自于哈希表:在...但是若对整个海量数据存储系统需要更侧重于批量数据的查询,更新操作,键值数据模型则在效...
  • 单片机测试系统的数据存储和管理 时间:2007-12-10 09:48:00 来源:单片机及嵌入式系统应用 作者:北京航空航天大学 赵成 袁海文 摘要 介绍一种应用于单片机洲试系统的链式存储结构,其特点在于采用数据...
  • HTML5数据存储

    2018-07-22 09:32:26
    HTML5中增加了两种全新的数据存储方式:WebStorage和WebSQLDatabase。 WebStorage可用于临时或永久保存客户端的少量数据,WebSQLDatabase是客户端本地化的一套数据库系统,可以将大量的数据保存在客户端,无须与...
  • Redis 数据存储位置 导出数据 qq1413139134 2015-12-23 15:25:00 浏览7302 评论0 云数据库Redis版 摘要: Redis是一款支持多种数据类型的Key-Value数据库。这里介绍下如何从Redis中导出数据。 数据是...
  • Hive的数据存储

    2017-08-26 15:01:01
    Hive的数据分为表数据和元数据,表数据是Hive中表格...在让你真正明白什么是hive 博文中我们提到Hive是基于Hadoop分布式文件系统的,它的数据存储在Hadoop分布式文件系统中。Hive本身是没有专门的数据存储格式,也没
  • jQuery允许把jQuery对象当作一个临时的“数据存储中心“,开发者能以key-value对的形式将数据存储到jQuery对象里,并林jQuery对象里取出之前存储的数据,也可以删除之前存储的数据。存入jQuery对象里的数据既可以是...
1 2 3 4 5 ... 20
收藏数 4,829,432
精华内容 1,931,772
关键字:

数据存储