哪些数据库比较适合实现数据实时入库的需求？
需求大致上是这样的：数据接收端每5-10个毫秒会从分布式计算网络收到1-10M左右的数据，希望在不影响接收线程接收速度，不丢帧的前提下，把这些数据记录下来。这些数据是以任务名+时间戳+数据的形式发送过来的。希望能根据任务名实时保存到数据库中。 现在的问题是有哪些数据库比较适合干这件事。
数据库新手，曾经尝试过SQLserver2008，每来一条数据就调用API写入数据库，结果常常崩溃。后来先在内存中缓存一些再写入数据库，但是申请内存多了也容易导致程序崩溃。对sqlserver未做什么优化。
考虑NOSQL数据库是不是更适合干这种事情，例如mongoDB什么的。
我们现在的临时解决方案有两个，一个是先在内存中缓存，然后新开线程向数据库写入，但是在回放使用数据时非常麻烦，要对数据排序，合并等等。另一个是数据先直接写到硬盘的dat文件中，在接收结束后再慢慢写入数据库，写入后删除硬盘上的文件。问题是这些数据有保密性和访问权限的要求，如果在写入数据库过程中程序崩溃或者程序被强行中止，那么硬盘上的数据就暴露了。所以还是希望能实时入库。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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.虽然是单线程写入.但是也应该可以满足需求
队列+mongodb MySql + 缓存技术 ，主流数据库都可以实现，但是需要增加一些额外的程序辅助。
se quo iadb
根据场景适合时序型数据存储(比如openTSDB)。不过单条记录比较大，可以考虑基于KV存储自己开发。
另外，I/O看起来非常高，一般主机系统里面能写到30-50MB/s已经很高了，1GB/s看起来必须考虑分布式存储。
你这个问题根本性能瓶颈在磁盘，你把磁盘换成SSD试试看！
你们采用的第一个临时方案就有点想队列的形式了，但是光有队列远远不够。
Mysql这样的关系型数据库多半是不行了。(彻底打消这个念头了)
数据库可以试试Redis类的NoSQL，因为它有一些数据整理功能(合并、排序什么的)。
还可以用C扩展一些功能或者修改一些源代码。(把Redis用好不容易啊)
还有一些levelDB啊性能高的NoSQL。
这样分离之后应该能好些啊。
考虑分布式数据库吧，单机肯定不行了，1秒1G的数据，啥硬盘都不好使