S*******s
发帖数: 13043 | 1 任务本身很简单，大概有几万个记录，对每个记录都要应用一大堆假设参数产生几百个
数，再对产生的几十个M的数根据各种组合进行汇总统计。
最开始用excel+vba实现很简单，运算都在内存中，那几百万个数在生成的时候就同时
汇总，算完了就扔所以内存也够用，算一次也就是100多秒。
后来放到云上用node.js+mysql就遇到问题了。开始的想法是把记录、参数放在数据库
里，算的时候前面js遍历每一条记录，把中间结果写回数据库里，再用sql group by汇
总。这样运算了一次以后结果已经cache在数据库里再次运算就不用像excel一样重算，
只要算那些以前没算过的了。但是实际运行以后发现写回数据库非常慢，改用load
data local infile之后的速度仍然无法接受，load个几百兆的文件也要几十分钟。
显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。 |
W***o
发帖数: 6519 | 2 不明白为啥需要把中间结果保存到数据库里，是因为这些中间结果数量巨大导致内存装
不下吗？如果是这样，是不是可以多弄几台机器share memory？ |
S*******s
发帖数: 13043 | 3 for cache, also aggregation although not a must.
how to "多弄几台机器share memory"
【在 W***o 的大作中提到】
: 不明白为啥需要把中间结果保存到数据库里，是因为这些中间结果数量巨大导致内存装
: 不下吗？如果是这样，是不是可以多弄几台机器share memory？
|
c******n
发帖数: 16666 | 4 1. 去aws或者linode搞个大内存的vps
2. node --max_old_space_size=204800 yourApp.js
3. profit
linode200G内存的机器 也就一块钱1小时 不知道能不能撑到200g
但是上次我临时要算个东西 又不想开java 又不想改算法 搞了个24g的机器
划了16g跑nodejs 没啥问题
另就算你要拿数据库当临时存储的话 也要试试Redis
你用sql，估计I/O瓶颈里面还有mysql算indexing的那部分
【在 S*******s 的大作中提到】
: 任务本身很简单，大概有几万个记录，对每个记录都要应用一大堆假设参数产生几百个
: 数，再对产生的几十个M的数根据各种组合进行汇总统计。
: 最开始用excel+vba实现很简单，运算都在内存中，那几百万个数在生成的时候就同时
: 汇总，算完了就扔所以内存也够用，算一次也就是100多秒。
: 后来放到云上用node.js+mysql就遇到问题了。开始的想法是把记录、参数放在数据库
: 里，算的时候前面js遍历每一条记录，把中间结果写回数据库里，再用sql group by汇
: 总。这样运算了一次以后结果已经cache在数据库里再次运算就不用像excel一样重算，
: 只要算那些以前没算过的了。但是实际运行以后发现写回数据库非常慢，改用load
: data local infile之后的速度仍然无法接受，load个几百兆的文件也要几十分钟。
: 显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
|
d***a
发帖数: 13752 | 5 "显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。"
可以把中间生成的数据表放在内存里，MySQL应该有这个选项。放在HDD上确实是太慢了
，SSD也比内存慢很多。几百万个数，有几GB的内存足够了，真不够就把内存加大，几
十GB也不贵。 |
w********m
发帖数: 1137 | |
S*******s
发帖数: 13043 | 7 对，我依赖index on duplicate replace.
redis是啥，我搜搜看，谢谢
按理说我这个需求应该是很普遍很典型的吧，先从数据库里拿点数当输入，折腾出更多
的数出来存进数据库，再对这些新产生的数进行分析。我这才不到几百兆的数据，人家
大数据动辄几十T,也没听说这么慢吧？
【在 c******n 的大作中提到】
: 1. 去aws或者linode搞个大内存的vps
: 2. node --max_old_space_size=204800 yourApp.js
: 3. profit
: linode200G内存的机器 也就一块钱1小时 不知道能不能撑到200g
: 但是上次我临时要算个东西 又不想开java 又不想改算法 搞了个24g的机器
: 划了16g跑nodejs 没啥问题
: 另就算你要拿数据库当临时存储的话 也要试试Redis
: 你用sql，估计I/O瓶颈里面还有mysql算indexing的那部分
|
N*****r
发帖数: 94 | 8 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
上大内存全部load到内存操作
第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
sort, 这是通用做法
综上所述，你根本的错误就在于不应该在这里用数据库 |
S*******s
发帖数: 13043 | 9 very make sense.
how do they implement the big data?
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
|
N*****r
发帖数: 94 | 10
不同的大数据有不同的处理办法
要看数据特征， 需要排序的和不需要的不一样， 要维护相对关系的和不需要维护相对
关系的不一样
【在 S*******s 的大作中提到】
: very make sense.
: how do they implement the big data?
|
|
|
S*******s
发帖数: 13043 | 11 guess none is using RDBMS?
can you elaborate further, what technology is used for each case?
【在 N*****r 的大作中提到】
:
: 不同的大数据有不同的处理办法
: 要看数据特征， 需要排序的和不需要的不一样， 要维护相对关系的和不需要维护相对
: 关系的不一样
|
k*****u
发帖数: 1688 | 12 赞
缓冲区一般怎么搞最好？
是不是data -> redis -> mysql 这样？
我曾经做过实时download twitter data，然后直接到db，基本每天都会挂掉
后来改成每天的data直接保存为jsonfile或者sqllite，放在硬盘上，一天一个file，
把日期加在文件名上
能不能帮忙解惑，实际生产环境是怎么个缓冲法？
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
|
N*****r
发帖数: 94 | 13
看需要什么的环境吧
如果是要上关系数据库，只考虑读的速度memcached 和上面提到的 redis 都可以
关系数据库要读写都快，那就是redis
如果数据关联性不强， 那就用 nosql。或者土方法直接 hashtable + 大文件块
真要搞海量文件系统 google那篇 bigtable 要好好读
另外现在好像有新的海量关系数据库，没仔细看
【在 k*****u 的大作中提到】
: 赞
: 缓冲区一般怎么搞最好？
: 是不是data -> redis -> mysql 这样？
: 我曾经做过实时download twitter data，然后直接到db，基本每天都会挂掉
: 后来改成每天的data直接保存为jsonfile或者sqllite，放在硬盘上，一天一个file，
: 把日期加在文件名上
: 能不能帮忙解惑，实际生产环境是怎么个缓冲法？
|
d******c
发帖数: 2407 | 14 关系数据库建在那几条原则之上。你用不上的话就不需要用数据库。
仅仅是duplicate，那就是hash table足够。找个快的二进制格式存文件，尽量用内存。
【在 S*******s 的大作中提到】
: 对，我依赖index on duplicate replace.
: redis是啥，我搜搜看，谢谢
: 按理说我这个需求应该是很普遍很典型的吧，先从数据库里拿点数当输入，折腾出更多
: 的数出来存进数据库，再对这些新产生的数进行分析。我这才不到几百兆的数据，人家
: 大数据动辄几十T,也没听说这么慢吧？
|
d****n
发帖数: 1637 | 15 latency numbers every programmer should know.
FYI:
你那个数据库io最好的情况是disk io 再加上300ms delay.
几百个数据比较不出来啥，一百万个就会很大不同了。
Latency Comparison Numbers
--------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x
L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x
L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns 3 us
Send 1K bytes over 1 Gbps network 10,000 ns 10 us
Read 4K randomly from SSD* 150,000 ns 150 us ~
1GB/sec SSD
Read 1 MB sequentially from memory 250,000 ns 250 us
Round trip within same datacenter 500,000 ns 500 us
Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~
1GB/sec SSD, 4X memory
Disk seek 10,000,000 ns 10,000 us 10 ms 20x
datacenter roundtrip
Read 1 MB sequentially from disk 20,000,000 ns 20,000 us 20 ms 80x
memory, 20X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms
https://gist.github.com/jboner/2841832 |
w***g
发帖数: 5958 | 16 赞总结. 这些数量级最好能背下来.
14x
【在 d****n 的大作中提到】
: latency numbers every programmer should know.
: FYI:
: 你那个数据库io最好的情况是disk io 再加上300ms delay.
: 几百个数据比较不出来啥，一百万个就会很大不同了。
: Latency Comparison Numbers
: --------------------------
: L1 cache reference 0.5 ns
: Branch mispredict 5 ns
: L2 cache reference 7 ns 14x
: L1 cache
|
c******n
发帖数: 16666 | 17 收藏了
14x
【在 d****n 的大作中提到】
: latency numbers every programmer should know.
: FYI:
: 你那个数据库io最好的情况是disk io 再加上300ms delay.
: 几百个数据比较不出来啥，一百万个就会很大不同了。
: Latency Comparison Numbers
: --------------------------
: L1 cache reference 0.5 ns
: Branch mispredict 5 ns
: L2 cache reference 7 ns 14x
: L1 cache
|
g****t
发帖数: 31659 | 18 你用过很多存储过程吗？直觉从哪里来的？
你这个问题，我觉得最方便快捷的办法可能还就是存储过程。
你在excel+VBA没问题。
只要数据和处理都在一头，不要来回读写，应该就没问题。
oracle，DB2 + 存储过程不可能比excel+VBA慢啊
【在 S*******s 的大作中提到】
: 任务本身很简单，大概有几万个记录，对每个记录都要应用一大堆假设参数产生几百个
: 数，再对产生的几十个M的数根据各种组合进行汇总统计。
: 最开始用excel+vba实现很简单，运算都在内存中，那几百万个数在生成的时候就同时
: 汇总，算完了就扔所以内存也够用，算一次也就是100多秒。
: 后来放到云上用node.js+mysql就遇到问题了。开始的想法是把记录、参数放在数据库
: 里，算的时候前面js遍历每一条记录，把中间结果写回数据库里，再用sql group by汇
: 总。这样运算了一次以后结果已经cache在数据库里再次运算就不用像excel一样重算，
: 只要算那些以前没算过的了。但是实际运行以后发现写回数据库非常慢，改用load
: data local infile之后的速度仍然无法接受，load个几百兆的文件也要几十分钟。
: 显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
|
g****t
发帖数: 31659 | 19 他这个问题存储过程有不好的地方吗?
vba都可以搞定的
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
|
N*****r
发帖数: 94 | 20
他一开始本机excel + vba 是没啥问题啊
问题在于他后来在上mysql
mysql 没有优化的话，同时写150个记录就可能出问题
关系数据库同时写从来都是大问题，因为有lock
【在 g****t 的大作中提到】
: 你用过很多存储过程吗？直觉从哪里来的？
: 你这个问题，我觉得最方便快捷的办法可能还就是存储过程。
: 你在excel+VBA没问题。
: 只要数据和处理都在一头，不要来回读写，应该就没问题。
: oracle，DB2 + 存储过程不可能比excel+VBA慢啊
|
|
|
g****t
发帖数: 31659 | 21 Excel同时写照样也有锁
我觉得问题就在于他不用自带的存储过程
用别的踩了坑
我猜
所有逻辑数据库端存储过程实现
Vs excel vba
前者不应该差很多
: 他一开始本机excel vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
【在 N*****r 的大作中提到】
:
: 他一开始本机excel + vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
|
S*******s
发帖数: 13043 | 22 现在先用现场算+redis缓存对付了。redis真神奇啊，有缓存的秒现，没在缓存的即使
现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
多谢诸位支招。
这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？ |
c******n
发帖数: 16666 | 23 你没试一下另一个直接跑的方法？ 很好奇v8 在超大内存下会不会有奇怪的问题
我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
改代码最有用。。。
【在 S*******s 的大作中提到】
: 现在先用现场算+redis缓存对付了。redis真神奇啊，有缓存的秒现，没在缓存的即使
: 现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
: 多谢诸位支招。
: 这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？
|
S*******s
发帖数: 13043 | 24 现在就是在缓冲没有命中的时候直接跑，你问的是这个吗？
缓冲只记录最后汇总的结果，所以对内存压力不大。
【在 c******n 的大作中提到】
: 你没试一下另一个直接跑的方法？ 很好奇v8 在超大内存下会不会有奇怪的问题
: 我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
: 改代码最有用。。。
|
