NewSQL为何使传统关系数据库黯然失色(试述newsql数据库与传统的关系数据库的区别)
传统关系数据库可能永远不会消失——至少不会很快，但其辉煌的日子已经远去 许多新兴的NoSQL数据库的普及，例如MongnDB和Cassandra 这很好的弥补了传统数据库系统的局限性 相对于NoSQL蓬勃发展的情况基于SQL的关系数据库系统确实显得有些死气沉沉 但这是数据库厂商的错，而不是SQL的错 关系数据库长期以来一直作为企业部署的关键组成部分，但现在出现了更好的选择，以适应新的数据结构和现代化硬件系统 如IBM、微软和甲骨文等厂商都将继续使用关系数据库主导其金融交易的核心功能 但是NoSQL数据库似乎更适应当今的海量数据时代 如ApacheHadoop和MapRece技术 Bloor集团的首席分析师RobinBloor表示传统的关系数据库已经过时了，其架构需要更新 Bloor的理由是随着多CPU计算机和固态硬盘技术的不断成熟，访问磁盘的数据已经不再重要 固态硬盘的速度更快，所以在磁盘和内存之间读取速率将会加强 明尼苏达州明尼阿波利斯的一位元数据策略顾问DanMcCreary指出SQL数据库的也有自己的问题，例如其不具备很好的伸缩性 当数据增长超过一台服务器所能承受的极限时，就必须分享或分割数据到多台服务器上，跨越多台服务器是一个复杂的过程 此外如外部链接带来的问题 例如多个表中数据的融合，跨越服务器执行一些操作可能会产生一些问题 NoSQL的崛起和“NewSQL”的出现NoSQL将改变数据的定义范围 它不再是原始的数据类型，如整数、浮点 数据可能是整个文件 NoSQL可能会吓到DBA，因为他们担心失去他们自己的领域 NoSQL数据库是非关系的、水平可扩展、分布式并且是开源的 MongoDB的创始人DwightMerriman表示NoSQL可作为一个Web应用服务器、内容管理器、结构化的事件日志、移动应用程序的服务器端和文件存储的后背存储 分布式数据库公司VoltDB的首席技术官MichaelStonebraker表示NoSQL数据库可提供良好的扩展性和灵活性，但他们也有自己的不足 由于不使用SQL，NoSQL数据库系统不具备高度结构化查询等特性 NoSQL其他的问题还包括不能提供ACID（原子性、一致性、隔离性和耐久性）的操作 另外不同的NoSQL数据库都有自己的查询语言，这使得很难规范应用程序接口 Stonebraker表示数据库系统的滞后通常可归结于多项因素 诸如以恢复日志为目的的数据库系统维持的缓冲区池，以及管理锁定和锁定的数据字段 在VoltDB的测试中发现以上这些行为消耗系统96%的资源 RDBMSes处理的数据大约只有16%“虽然关系数据库感觉到了新技术到来的压力，但RDBMS仍然在企业计算中占有一些之地 目前RDBMS的市场约350亿美元 其中包括账户的软件许可、服务、技术支持以及维护”，Forrester的分析师NoelYuhanna说道 Forrester预计，在企业中的业务数据将有25%是结构化数据，其中至少有65%在使用RDBMS或其他传统关系数据库，而RDBMS在交易数据中，RDBMSes至少有16%的份额 企业将有75%的业务数据与半结构化文件（如XML、电子邮件和EDI）和非结构化数据（如文档、图片、音频和视频）相结合 Yuhanna表示，大约有5%的数据驻留在关系数据库之中，其他的都分布在非关系数据库和文件格式之中 此外，列式数据恐怕将成为数据库领域发生变化的过度候选产品，他们或将使关系数据库产品更简单 传统的关系型数据厂商比如IBM、微软和Oracle在其RDBMS领域肯定是有新的计划的，他们也不会选择公开自己的计划 Bloor表示，没有人会注意到RDBMS可能会死去
如何使用HBase构建NewSQL
目前主流的数据库或者NoSQL要么在CAP里面选择AP，比较典型的例子是Cassandra，要么选择CP比如HBase，这两个是目前用得非 常多的NoSQL的实现。我们的价值观一定认为未来是分布式的，一定是尽量倾向于全部都拥有，大部分情况下取舍都是HA，主流的比较顶级的数据库都会选择 C，分布式系统一定逃不过P，所以A就只能选择HA。现在主要领域是数据库的开发，完全分布式，主要方向和谷歌的F1方向非常类似。 目前看NewSQL代表未来(Google Spanner、F1、)，HBase在国内有六个Committer，在目 前主流的开源数据库里面几乎是最强的阵容。大家选型的时候会有一个犹豫，到底应该选择HBase还是选Cassandra。根据应用场景，如果需要一致 性，HBase一定是你最好的选择，我推荐HBase。它始终保持强一致，我们非常喜欢一致性，丧失一致性的时候有些错误会特别诡异，很难查。对于 Push-down特性的设计其实比较好，全局上是一个巨大的分布式数据库，但是逻辑上是分成了一个个Region，Region在哪台机器上是明确的。 比如要统计记录的条数，假设数据分布在整个系统里面，对数十亿记录做一个求和操作，就是说不同的机器上都要做一个sum，把条件告诉他要完成哪些任务，他给你任务你再汇总，这是典型的分布式的 MPP，做加速的时候是非常有效的。 2015年HBaseConf 上面有一句总结: “Nothing is hotter than SQL-on- Hadoop, and now SQL- on- HBase is fast approaching equal hotness status”， 实际上SQL-on-HBase 也是非 常火。因为 Schema Less 没有约束其实是很吓人的一件事情，当然没有约束也比较爽，就是后期维护十分痛苦，规模进一步扩大了之后又需要迁移 到 SQL。 现在无论从品质还是速度上要求已经越来越高，拥有SQL的同时还希望有ACID的东西(OLAP一般不追求一致性)。所以TiDB在设计时就强调这 样的特点：始终保持分布式事务的支持，兼容MySQL协议。无数公司在SQL遇到Scale问题的时候很痛苦地做出了选择，比如迁移到 HBase，Cassandra MongoDB已经看过太多的公司做这种无比痛苦的事情，现在不用痛苦了，直接迁过来，直接把数据导进来就OK了。TiDB最重要的是关注OLTP，对于 互联网业务来说通常是在毫秒级内就需要返回一个结果。 我们到目前为止开发了六个月，开源了两个月。昨天晚上TiDB达到了第一个Alpha的阶段，现在可以拥有一个强大的数据库：支持分布式事务，始终 保持同步的复制，强大的按需Scale能力，无阻塞的Schema变更。发布第一个Alpha版本的时候以前的质疑都会淡定下来，因为你可以阅读每一行代 码，体验每个功能。选择这个领域也是非常艰难的决定，实在太Hardcore了，当初Google Spanner也做了5年。不过我们是真爱，我们就是 技术狂，就是要解决问题，就是要挑大家最头痛的问题去解决。好在目前阿里的OceanBase给我们服了颗定心丸，大家也不会质疑分布式关系型数据库是否 可行。
什么是大数据存储管理
1.分布式存储 传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点，同时采用了HDFS文件系统的大规模横向扩展功能。 虽然，通常解决Hadoop管理自身数据低效性的方案是将Hadoop 数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在，如果你把所有的数据都通过集中式SAN处理器进行处理，与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN，要么将所有的数据节点都集中到一个SAN。 但Hadoop是一个分布式应用，就应该运行在分布式存储上，这样存储就保留了与Hadoop本身同样的灵活性，不过它也要求拥抱一个软件定义存储方案，并在商用服务器上运行，这相比瓶颈化的Hadoop自然更为高效。 2.超融合VS分布式 注意，不要混淆超融合与分布式。某些超融合方案是分布式存储，但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题，但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层，分布式存储运行在专有存储层这样会更好。之后，利用缓存和分层来解决数据本地化并补偿网络性能损失。 3.避免控制器瓶颈(Controller Choke Point) 实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之，要确保存储平台并行化，性能可以得到显著提升。 此外，这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。 4.删重和压缩 掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计，能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩，大大降低了存储数据所需能力。 5.合并Hadoop发行版 很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时，多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一，可删重和压缩的数据湖获取数据效率 6.虚拟化Hadoop 虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。 7.创建弹性数据湖 创建数据湖并不容易，但大数据存储可能会有需求。我们有很多种方法来做这件事，但哪一种是正确的?这个正确的架构应该是一个动态，弹性的数据湖，可以以多种格式(架构化，非结构化，半结构化)存储所有资源的数据。更重要的是，它必须支持应用不在远程资源上而是在本地数据资源上执行。 不幸的是，传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大，将应用迁移到数据不可避免，而因为延迟太长也无法倒置。 理想的数据湖基础架构会实现数据单一副本的存储，而且有应用在单一数据资源上执行，无需迁移数据或制作副本 8.整合分析 分析并不是一个新功能，它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现，以及数据库表单和社交媒体，非结构化数据资源(比如，维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力，有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。 9. 大数据遇见大视频 大数据存储问题已经让人有些焦头烂额了，现在还出现了大视频现象。比如，企业为了安全以及操作和工业效率逐渐趋于使用视频监控，简化流量管理，支持法规遵从性和几个其它的使用案例。很短时间内这些资源将产生大量的内容，大量必须要处理的内容。如果没有专业的存储解决方案很可能会导致视频丢失和质量降低的问题。 10.没有绝对的赢家 Hadoop的确取得了一些进展。那么随着大数据存储遍地开花，它是否会成为赢家，力压其它方案，其实不然。 比如，基于SAN的传统架构在短期内不可取代，因为它们拥有OLTP，100%可用性需求的内在优势。所以最理想的办法是将超融合平台与分布式文件系统和分析软件整合在一起。而成功的最主要因素则是存储的可扩展性因素。
大数据时代,数据的存储与管理有哪些要求?
数据时代的到来，数据的存储有以下主要要求：
首先，海量数据被及时有效地存储。根据现行技术和预防性法规和标准，系统采集的信息的保存时间不少于30天。数据量随时间的增加而线性增加。
其次，数据存储系统需要具有可扩展性，不仅要满足海量数据的不断增长，还要满足获取更高分辨率或更多采集点的数据需求。
第三，存储系统的性能要求很高。在多通道并发存储的情况下，它对带宽，数据容量，高速缓存等有很高的要求，并且需要针对视频性能进行优化。
第四，大数据应用需要对数据存储进行集中管理分析。