这是一个创建于 3804 天前的主题，其中的信息可能已经有所发展或是发生改变。
现行需求分析
- 每隔十秒产生1万条数据，每一条数据约260字节。
- 数据产生时间9:30－11:30；13:00 －15:00。在这个时间段内一天数据量约为：$1万*6*60*4 = 1440万条，约3.5GB数据$。长期预估1-3年内产生：3.7TB数据。
- 已产生数据非常小量更新操作，可以任务数据库无更新操作（如update ，delete），只有插入、查询操作（insert 、select）
- 无复杂查询。如：group by ，join
- 查询操作并发度不高，但查询效率严格控制在十毫秒到几百毫秒内。
- 对写数据库操作要求高，达到10秒内完成插入1万条数据
- 每条数据字段都是数字或段文字，没有复杂字段。
- 选择什么样物理服务器＋数据库＋数据架构？如dell r730+mysql＋分库分表？
 | 2 lhy360121 2015-07-09 14:30:18 +08:00 mysql按日期分表比较好，建好索引，查询还是很快的。插入没测过。 |
 | 3 realpg PRO 撸主是自己计算XX指数么 还是数据分析的高频交易 |
 | 4 dododada 2015-07-09 14:31:51 +08:00 读写分离，分库分表，上搜索引擎. elasticsearch号称支持pb级的搜索。 |
 | 5 Tink PRO 数据产生时间9:30－11:30；13:00 －15:00 周六周日不产生? |
 | 6 em70 2015-07-09 14:33:36 +08:00 via Android 每个写入时间段，创建一个新表来接受输入，尽量少的索引，来保证插入效率。如果觉得效率还不够，就每一天的每一个小时都创建一个表接受插入。 每天15点开始执行数据汇总操作，将当天的每个表数据汇入总表，加尽量多且必要的索引。 如果存在大量重复记录，可以去重，然后建立一个计数器表，统计每一种记录的次数即可 数据库不建议自己服务器搭建，用阿里云RDS，性能超强 |
 | 7 zhanglp888 2015-07-09 14:45:21 +08:00 我的做法时，根据时间创建新表，我当时是一天一个表，加必要的索引 搜索时，如果搜索某一天的话，就搜索那天的表， 如果搜索两天以上，就根据时间范围，把那几天的表的组合起来建立临时表，再去搜索 没有你的数据这么多，所以没法给你具体的结果 |
8 scys 2015-07-09 14:47:05 +08:00 考虑自己有多大的带宽，如果1000MB/s的带宽，可以直接考虑同步到服务器上，然后让云去烦恼。 如果是自有服务器，考虑服务器群来处理，其实就是分表。 |
 | 10 hbq OP @em70 你就是每天产生的数据，最终都会汇总到一个大表中，这样日积月累这个表会很大很大，我想这个总表是不是在逻辑看作一个表，在实际物理存储的时候是分成小表存储，其实就是一个分表操作。但是做成一个总表，在以后查询效率控制在百毫秒内，我觉效率会不好。但是每天建一个表，就是每天产生的表数据量为1440万，以后查询时候，按照时间查询，找到对应的表，再到对应的字段，这样效率应该可以控制在百毫秒内。在全局上看，我还不太清楚这两种方案好与坏 |
| 12 hbq OP @zhanglp888 你的做法，和我一开始是一样的。你的单表数据量是多少，查询效率如何，参考下。谢谢哦 |
 | 13 fredcc 2015-07-09 15:16:27 +08:00 无复杂查询尽量别用RDMS |
 | 14 scys 2015-07-09 15:21:11 +08:00 |
 | 15 mingyuan2011 2015-07-09 15:21:32 +08:00 卤煮要自己存L1还是L2的行情数据啊？ |
 | 16 vmskipper 2015-07-09 15:26:53 +08:00 @zhanglp888 装脸了 还是本家 |
 | 17 webflier 2015-07-09 15:29:09 +08:00 如果你存的是时间序列之类，直接append文件，每条记录固定长度，查询的时候自己去算offset，然后读出来。 |
| 18 em70 2015-07-09 15:30:41 +08:00 @hbq 计算机永远是时间换空间,空间换时间的游戏,要想查找快,就需要占更大的空间,最有效的加快查找办法是做反向索引,google上千亿页面怎么做的几十毫秒查询的呢,他是先把所有可能的关键词都做了预先的计算,把关键词对应的搜索结果已经缓存下来了,查找的时候就直接调用结果,不需要再去遍历总表了. 你是否可以提前预判到可能被查询的关键词,利用15点到第二天9点这段时间全部穷举,缓存下来.写到一个表里. |
| 19 webflier 2015-07-09 15:32:04 +08:00 @mingyuan2011 我估计楼主应该是要存股市之类的tick data |
 | 20 akira 2015-07-09 15:47:31 +08:00 稍微计算了一下，每秒大约是250kb的数据写入，这个对大部分提供数据库云服务商来说，都不是什么难度。 除非你自己能handle，不然不是很建议自建数据库。 查询的效率 依赖你的sql语句以及索引，这个只能具体分析了。例如如果你写个select * from table;想100ms以内返回当日的所有数据，神仙都帮你不了。 |
 | 21 gamecreating 2015-07-09 15:52:10 +08:00 股市???? |
 | 24 dingyaguang117 2015-07-09 16:26:24 +08:00 via iPhone mongodb无压力 |
 | 25 billwang 2015-07-09 17:16:30 +08:00 我们这边一天产生4g的数据量，按日分表建立索引。数据进入时采用缓存，每隔15秒插入一次。 |
 | 26 ksupertu 2015-07-09 18:40:22 +08:00 后端elasticsearch存储，调优后单台2W/S写入速度，可水平扩展集群系统，前面可以在加个mogodb之类的数据库来持久化一下，elasticsearch丢起数据来集群恢复起来很慢 |
 | 27 taowen 2015-07-09 18:47:17 +08:00 via Android taowen.gitbooks.io 用elasticsearch设计好mapping |
 | 28 xujif 2015-07-09 19:33:54 +08:00 一看就知道是l2数据，别问我为什么知道 |
 | 30 simonlei 2015-07-09 22:51:43 +08:00 |
 | 31 xlvecle 2015-07-09 23:23:38 +08:00 elasticsearch，solr，sphinx |
 | 32 hwind 2015-07-10 00:18:53 +08:00 NoSQL的解决方案就可以满足你的需求，比如HBase |
 | 33 kurosagi 2015-07-10 06:57:51 +08:00 1,可以不更新，就插入和查询 2,无复杂查询 3 写数据库操作要求高 4 没有复杂字段 我知道可能不行，以前也就实习的时候用过，但是dynamoDB和cassandra怎么样？ 理论上，可能，好像，没问题，但是似乎有人告诫我NoSQL是坑不要入。 |
 | 34 caomaocao 2015-07-10 09:29:37 +08:00 放mongo? |
| 37 zhanglp888 2015-07-10 11:26:24 +08:00 |
 | 38 ybh37 2015-07-10 12:00:26 +08:00 Redis？ |
 | 40 liuweisj 2015-07-10 17:34:39 +08:00 数据库的话试试Hbase吧,性能的话可以根据需求来部署HDFS集群 |
Select Language