实时大数据存储及查询分析解决方案

问题描述

实时大数据存储及查询分析解决方案

上千辆设备每隔10秒上传一次数据,我要把数据存储起来,然后在基于这些数据进行查询分析,
担心传统的做法后期会有很大的性能问题,请教有做过这方面的经验的高手共享一下思路。

解决方案

你这种情况就非常适合使用基于Hadoop的HBase来存储数据,HBase不仅仅适合于做大数据的存储和处理,它的一个突出的性能优势就是写数据,
你的系统每隔10s就要写一次数据,Hbase就比较适合,最好不要使用传统的关系型数据库(例如MySql),这会让你的系统在后期出现许多性能瓶颈,
另外,HBase在数据查询上面也有提供了一些快速的优化方法,使用Hbase对数据进行读写,使用map/reduce对数据进行处理,你可以查阅相关资料看看。

解决方案二:

这里不适合什么Hadoop,工业采集数据要求的是可靠、简单、直接,应该用工业实时数据库存储数据,再导入关系数据库分析。
http://blog.csdn.net/liqfyiyi/article/details/6862886

解决方案三:

如果 一次的数据量不是很大,就将数据分析写入数据库吧,这样以后查询才能方便一些。
服务器端,最后能分成通讯服务器,数据存贮服务器等等。这个做后台的人都知道,偶是做终端的,只了解到这些。

解决方案四:

写入数据库,然后查询。现在数据库处理能力还是可以应付你那点数量的

时间: 2024-10-26 14:30:02

实时大数据存储及查询分析解决方案的相关文章

实时大数据存储-实时大数据写入数据库

问题描述 实时大数据写入数据库 项目:IOCP的多线程(工作线程)解析大量客户端发送过来的数据:这个数据量是非常大的,上千个客户端,每50MS发送一个数据包过来,要把他们写入数据库.以下是我做的两种设计,均不能成功. 1.简单地通过程序一条一条地执行SQL语句写入数据库,失败,效率极低,淘汰. 2.我目前的处理是把这个SQL语句做一个拼接(...+SQL语句+;+SQL 语句+:+...),然后一并执行,写入数据库,但是这么设计的话,内存会一直涨,因为写入数据库的速率小于IOCP解析出来的数据所

SAS嗅大数据商机 推出可视化分析解决方案

[赛迪网讯]日前,SAS推出可视化分析解决方案(SAS Visual http://www.aliyun.com/zixun/aggregation/16353.html">Analytics)新版本6.1,该软件从2010年开始研发,2012年8月曾推出5.8版本.可以满足规模从大到小的各类型企业对于数据分析的需求. SAS可视化分析(VA)具有强大的数据探索和显示能力,它不是一个简单的商业智能产品,而是一个将商业智能和分析能力充分结合,并且快速.易用的产品. SAS大中华区总裁吴辅世先

基于HBase的大数据存储的应用场景分析

引言 HBase是一个高可靠性.高性能.面向列.可伸缩的分布式存储系统,适用于结构化的存储,底层依赖于Hadoop的HDFS,利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群.因此HBase被广泛使用在大数据存储的解决方案中. 为何使用HBase HBase的优点: 列可以动态增加,并且列为空就不存储数据,节省存储空间. Hbase自动切分数据,使得数据存储自动具有水平scalability. Hbase可以提供高并发读写操作的支持. HBase的缺点: 不能支持条件查询,

公有云存储大数据的典型案例分析

云服务正在大数据应用中发挥重要作用,尤其是对于那些短期任务,或是已将大量数据存储在云上的应用而言. 云服务对于每个人都具有吸引力.当有人对你说,他们的大数据策略是"把所有的数据都存储在云端" 时,你根本无法判断这些人是有远见的人,还是在简单地重复着专家在行业会议上对他们的建议. 毫无疑问,目前大数据和云范例之间存在着巨大的重合之处.这些交集是如此的广泛,以致于你能够名正言顺地宣称自己正在利用现有的本地Hadoop.NoSQL或企业数据仓库环境,处理基于云的大数据.请记住,云服务被普遍解

华为与英特尔构建全融合大数据存储解决方案

IDC预测,全球数据总量将在2020年达到40ZB.40ZB的数据量是什么概念呢? IDC给出了一个比喻:如果把一粒沙子当做一个字的话,40ZB的数据量相当于地球上所有海滩上沙子数量的57倍;40ZB的数据量相当于667千亿部高清影片,一个人每天24小时连续不断地看,看完这些电影需要5万6千亿年;目前我们对地球年龄的估值是45.5亿年,意味着,如果这个人从地球诞生的时候就开始看电影,现在他只看完了这些电影总数的万分之八(0.0008).而这些数据,每两年还将翻一番,呈指数级增长态势.大数据将以一

基于云上分布式NoSQL的海量气象数据存储和查询方案

前言 气象数据是一类典型的大数据,具有数据量大.时效性高.数据种类丰富等特点.气象数据中大量的数据是时空数据,记录了时间和空间范围内各个点的各个物理量的观测量或者模拟量,每天产生的数据量常在几十TB到上百TB的规模,且在爆发性增长.如何存储和高效的查询这些气象数据越来越成为一个难题. 传统的方案常常采用关系型数据库加文件系统的方式实现这类气象数据的存储和实时查询,这种方案在可扩展性.可维护性和性能上都有一些缺陷,随着数据规模的增大缺点越来越明显.最近几年,学界和业界开始不约而同的转向利用分布式N

《大数据管理概论》一第3章‖大数据存储3.1 引言

本节书摘来自华章出版社<大数据管理概论>一书中的第3章,第3.1节,作者 孟小峰,更多章节内容可以访问"华章计算机"公众号查看 第3章| 大数据存储 3.1 引言 大数据存储与管理研究首先面临的是存储技术上的挑战.虽然目前有许多存储技术有望用于大数据存储,但它们都存在局限性[36].例如:目前以NoSQL数据库为代表的大规模分布式数据库系统设计了基于磁盘存储的读写方式.索引结构.查询执行.查询优化和恢复策略,但是磁盘固有的读写性能差等弊端限制了大数据存取尤其是大数据分析性能

《大数据存储:MongoDB实战指南》一1.6 MongoDB特点

1.6 MongoDB特点 大数据存储:MongoDB实战指南 它的存储模型与关系数据库的比较如表1-1所示. 关系数据库中最基本的单元是行,而MongoDB中最基本存储单元是document,典型结构如下所示. { "_id" : ObjectId("51e0c391820fdb628ad4635a"), "author" : { "name" : "Jordan","email" :

大数据时代的互联网分析引擎

随着互联网尤其是移动互联网的高速发展,互联网文档的数量.内容的丰富度和复杂度都大大增加,互联网正朝大数据时代迈进,而用户的信息需求也趋于复杂化.除了基本的信息检索需求外,对大量相关文档的深入理解与聚合分析的需求也越来越强烈,而传统的互联网搜索引擎已经无法满足人们对该类信息的需求.针对这一问题,提出"互联网分析引擎"的构想,阐述了其与搜索引擎和OLAP分析系统的区别,介绍了一种互联网分析引擎的架构,并详细讨论了实现该引擎的核心问题. 1 引言 随着移动互联网.智能手机.社交媒体.自媒体技