哪些数据库比较适合实现数据实时入库的需求?

眼中的沙
  • 64

需求大致上是这样的:数据接收端每5-10个毫秒会从分布式计算网络收到1-10M左右的数据,希望在不影响接收线程接收速度,不丢帧的前提下,把这些数据记录下来。这些数据是以任务名+时间戳+数据的形式发送过来的。希望能根据任务名实时保存到数据库中。 现在的问题是有哪些数据库比较适合干这件事。

数据库新手,曾经尝试过SQLserver2008,每来一条数据就调用API写入数据库,结果常常崩溃。后来先在内存中缓存一些再写入数据库,但是申请内存多了也容易导致程序崩溃。对sqlserver未做什么优化。

考虑NOSQL数据库是不是更适合干这种事情,例如mongoDB什么的。

我们现在的临时解决方案有两个,一个是先在内存中缓存,然后新开线程向数据库写入,但是在回放使用数据时非常麻烦,要对数据排序,合并等等。另一个是数据先直接写到硬盘的dat文件中,在接收结束后再慢慢写入数据库,写入后删除硬盘上的文件。问题是这些数据有保密性和访问权限的要求,如果在写入数据库过程中程序崩溃或者程序被强行中止,那么硬盘上的数据就暴露了。所以还是希望能实时入库。

回复
阅读 10.7k
11 个回答

如果按照每10ms接收10M数据的话,1秒钟就是1G数据,每小时的数据量高达3.6T,这个大的数据量个人觉得使用传统的关系型数据已经不合适了。

如果对查询的灵活性要求不高,建议直接放到日志文件存储。缓存的意义估计不大,一般配置的PC server,在这样的大数据量下内存是不够用的。

至于权限管理,应该和数据存放方式没有直接关系,毕竟不可能让用户直接查询数据库,权限处理在应用程序中处理就可以了。

队列+mongodb。

数据先入队列,然后开多线程入库。

----ps:

1秒1G数据,1分钟1x60=60G数据,1小时3.6T,一天86.4T数据,一个月就2.5PB。

您做的是什么东西= =

单纯的insert,其实考验的是io,建议可以这样,数据接收端将接收到的数据,经过最少的处理,然后放到缓存或者队列中,另外启动一个进程,从缓存或者队列中,读取并处理数据,再存储到数据库中。

通过分离操作,避免影响数据接收的效率,也提高了存入数据库的可靠性。

另外,如果你的数据,仅仅是简单的查询,不一定非得存储到数据库里,使用日志来存储也不是不可以,再整个全文检索,其实也挺不错的。

处理实时数据,最重要的是保证数据的有效性和不间断性,能够保证数据准确无误。有些情况会处理较高的并发性,有着大量的IO,要做到监控实时数据上处理上的压力,能够进行优化。
例如:对于电信行业,对数据处理和实时数据有着非常高的并发性,数据一定要做到准确无误,并且有着非常大量的数据高并发处理。
第一种方案:采用MongoDB数据库,MongoDB能够有效的缓解数据并发上所带来的压力,能够支持动态的扩容,有效的保证数据的不间断性,MongoDB有着监控机制,可以对数据上的利用率和性能效率上进行优化。如果考虑到数据处理量非常的大,IO操作会造出瓶颈,可以结合Redis内存数据库,可以有效缓解数据库上的压力。
第二种方案:便于数据分析和处理,可以考虑采用HDF5文件系统,HDF5支持并发IO操作,如果对数据频繁的上的读写操作,采用分布式系统能够有效缓解数据处理上的压力。传统的部分金融行业会采用HDF5分布式来处理大量的实时金融数据。
第三种方案:流式处理系统,需要进行大量的计算和规则运算分析,可以考虑采用Storm,这是一个复杂的实时数据处理方案。~~~Twitter开源。
第四种方案:数据一定不能有任何上的差错,不能出现任何出入。必须保证有效性和一致性。可以考虑采用KDB+,银行和金融数据上会采用KDB+,不过需要学习复杂的Q语言。
其他还有很多复杂的实时数据处理方案。不过要结合数据的规则和对于数据处理分析的方案来解决瓶颈。

5-10个毫秒一次写入=1秒 200次写入.mysql貌似可以胜任(可以能数据有点大).建议楼主试试mongodb.虽然是单线程写入.但是也应该可以满足需求

ChinaS
  • 1
新手上路,请多包涵

队列+mongodb MySql + 缓存技术 ,主流数据库都可以实现,但是需要增加一些额外的程序辅助。

Blue_may
  • 1
新手上路,请多包涵

se quo iadb

根据场景适合时序型数据存储(比如openTSDB)。不过单条记录比较大,可以考虑基于KV存储自己开发。
另外,I/O看起来非常高,一般主机系统里面能写到30-50MB/s已经很高了,1GB/s看起来必须考虑分布式存储。

你这个问题根本性能瓶颈在磁盘,你把磁盘换成SSD试试看!

你们采用的第一个临时方案就有点想队列的形式了,但是光有队列远远不够。 Mysql这样的关系型数据库多半是不行了。(彻底打消这个念头了)

数据库可以试试Redis类的NoSQL,因为它有一些数据整理功能(合并、排序什么的)。 还可以用C扩展一些功能或者修改一些源代码。(把Redis用好不容易啊) 还有一些levelDB啊性能高的NoSQL。

这样分离之后应该能好些啊。

考虑分布式数据库吧,单机肯定不行了,1秒1G的数据,啥硬盘都不好使

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
你知道吗?

宣传栏