i*t
2 楼
请问怎么辞职啊？
需要写辞职信吗？ 一般都怎么写呢？
和公司上级表面关系还不错，想双方都舒服些
多谢指点
需要写辞职信吗？ 一般都怎么写呢？
和公司上级表面关系还不错，想双方都舒服些
多谢指点
L*n
3 楼
亲爱的瓶子们，你们有需要资金才能实现的计划吗？9月初，募集资金方面你们有着多
么美好的前景。你可以开始自己的business,或是去读研究生，或是买房子。银行、奖
学金，风投等等类型的资金都将乐于祝你一臂之力。你会惊喜的发现他们都愿意铺好红
地毯等着为你资助。这是个非比寻常的消息，特别是考虑到你前几年所经历的挫折和资
金上困窘。宇宙的运行在于修正前面的错误，你正是受益者。
上月28日出现的新月，运行于你的第八宫——掌管着与其他人有关的钱财问题，将会是
2011年所有新月中最对你有帮助的最幸运的一个。它直到9月11日都将会占有重要地位
，所以如果你需要钱，确保你在本月初期的这些正确的日子里去递交申请吧。在新月发
生后的几天是最有帮助的，在随后的几天中，它会逐渐失去其效力。如你所见，尽快处
理这些事情，将会有非同寻常的收获。你或许可以用这几天来处理你的税务问题，或是
与你的保险公司协商一些问题。
这个新月的特别之处在于它将受到来自木星和谐的震动的影响，木星现在在你的不动产
/家庭/房子方面；以及受到冥王星——位于你的幕后的、隐秘的区域。你可能会获得你
父母的借贷甚至是完全的赠与，不过条件是不能告诉你的兄弟姐妹。或者是某个长久没
有联系的姨姨突然把你放入她的遗嘱。你可能突然把放在市场上几个月的房子一下子就
卖掉了,并且卖出了个好价钱。（http://www.meiguoshenpo.com/）
虽然你的绝好的金钱运看起来来自于家庭和不动产，然而你有可能会发现还有其他途径
让梦想成为现实。甚至可能会赢一小笔钱，虽然有些困难。如果它发生了，那很不错，
但是我觉得你的星运更多的应该用于去申请或者协商那些需要技能的资助，而不是去凭
运气赢它。
在八月的运程中，我提到了28日的那个特别的新月，你也可以再去看看我的前一个月的
预告，你现在正在做吗？你可以发现与前一个预言的联系。你也会在下面的总结和那些
特别日期中发现这些联系。我们最近把这些联系描述得更加醒目，然你们更容易找到他
妈。
两个绝好的金钱幸运日是9月1，2号，当木星向太阳投射其耀眼的光束的时候。你会想
和那些掌管金钱的人会面，同样的，如果你做销售，你会遇到值得庆祝的新客户。
到9月12日在双鱼座19度的新月时，你应该做完所有关于资金的讨论并作出决定。这个
新月同样会点亮你的金钱运但是并非与是与其他人的有关的金钱（本月出的金钱运与此
有关），这个新月会点亮你的第二宫，与个人的资源（personal resources）有关的区
域。这时你或许会接受新工作为你，或者你会接受一个新的项目或者任务。你可能有钱
进账，也可能需要花费一些钱，比如付一大笔账单。总之，这个新月是讨人喜欢的，因
为火星将会对你非常友好，它掌管着你的房屋的合同或协议，因此合同方面你会很容易
得获得一致的。
9月14日是另一个拥有绝好的金钱运的日子，水星和木星为你而相遇。这一天，你要在
金钱方面做出决定。在这一天签订合同，因为水星掌管着合同，而木星的加入则意味着
慷慨的资助或者利润。你的钱财上的幸运会发生在9月初，而不是后半月。这个月是个
黑白分明的月份，你有可能在第一个星期在银行贷款、申请奖学金等等那些方面拥有好
运，而随后则完全相反。9月最后一个星期，水星会在冥王星的围困之中，届时，你会
开始注意到风向发生了变化。最好不要申请任何资助，乖乖呆着最好（sit tight）.这
就是我为什么觉得你应该在9月上旬迅速行动。
如果你处于失业状态或者正在计划跳槽，我有好消息给你：掌管你的名誉和荣耀之第十
宫的冥王星，将在9月16日结束逆行。冥王星自4月早期开始逆行。你会发现这个改变为
你带来颇受欢迎的宽慰。当任何一个大行星结束逆行时，在转折点的前后几日总会为未
来的发展留下一些重要线索。你要留心抓住那些面包屑。注意9月16日以及前后各两天
，当那些线索最终成为你的职业，事情必将变得越来越好。
至于健康问题，第八宫正在为你点亮，你会获得关于某个健康问题的不同诊断或手术或
是安排好治疗的时间。在本月早期完成这些将会对你有极大的帮助，不行吗？那就等到
十月底的最后一周吧。
本月前半月，火星在你的第六宫，直到18号，实际上是直到你决定提升你的健康的那一
天。你应该足够明智关注于经济问题，在此前后各四天（直译，有点看不懂）。至此你
会了结一些麻烦，比如买一些大件，或者寄出一张所欠的大额支票。你也能也会听到一
些关于钱的好消息，特别是如果你有伴侣的话。
在9月25-29日，旅行将会混乱不堪，最好推迟任何你计划中的出行。此间开始任何法律
诉讼或者在法庭上作证，都是不明智的。
关于远方的亲戚的信息，比如那些in-law之类的亲戚（不是血缘关系的亲戚），可能在
最后一个星期有麻烦。
从9月18日至11月11日，狮子座的火星会带来对伴侣问题的关注，并且需要合作。对对
方指手画脚看来行不通了，你的另一半看来掌握了话语权并且很爱发号施令。
待续
么美好的前景。你可以开始自己的business,或是去读研究生，或是买房子。银行、奖
学金，风投等等类型的资金都将乐于祝你一臂之力。你会惊喜的发现他们都愿意铺好红
地毯等着为你资助。这是个非比寻常的消息，特别是考虑到你前几年所经历的挫折和资
金上困窘。宇宙的运行在于修正前面的错误，你正是受益者。
上月28日出现的新月，运行于你的第八宫——掌管着与其他人有关的钱财问题，将会是
2011年所有新月中最对你有帮助的最幸运的一个。它直到9月11日都将会占有重要地位
，所以如果你需要钱，确保你在本月初期的这些正确的日子里去递交申请吧。在新月发
生后的几天是最有帮助的，在随后的几天中，它会逐渐失去其效力。如你所见，尽快处
理这些事情，将会有非同寻常的收获。你或许可以用这几天来处理你的税务问题，或是
与你的保险公司协商一些问题。
这个新月的特别之处在于它将受到来自木星和谐的震动的影响，木星现在在你的不动产
/家庭/房子方面；以及受到冥王星——位于你的幕后的、隐秘的区域。你可能会获得你
父母的借贷甚至是完全的赠与，不过条件是不能告诉你的兄弟姐妹。或者是某个长久没
有联系的姨姨突然把你放入她的遗嘱。你可能突然把放在市场上几个月的房子一下子就
卖掉了,并且卖出了个好价钱。（http://www.meiguoshenpo.com/）
虽然你的绝好的金钱运看起来来自于家庭和不动产，然而你有可能会发现还有其他途径
让梦想成为现实。甚至可能会赢一小笔钱，虽然有些困难。如果它发生了，那很不错，
但是我觉得你的星运更多的应该用于去申请或者协商那些需要技能的资助，而不是去凭
运气赢它。
在八月的运程中，我提到了28日的那个特别的新月，你也可以再去看看我的前一个月的
预告，你现在正在做吗？你可以发现与前一个预言的联系。你也会在下面的总结和那些
特别日期中发现这些联系。我们最近把这些联系描述得更加醒目，然你们更容易找到他
妈。
两个绝好的金钱幸运日是9月1，2号，当木星向太阳投射其耀眼的光束的时候。你会想
和那些掌管金钱的人会面，同样的，如果你做销售，你会遇到值得庆祝的新客户。
到9月12日在双鱼座19度的新月时，你应该做完所有关于资金的讨论并作出决定。这个
新月同样会点亮你的金钱运但是并非与是与其他人的有关的金钱（本月出的金钱运与此
有关），这个新月会点亮你的第二宫，与个人的资源（personal resources）有关的区
域。这时你或许会接受新工作为你，或者你会接受一个新的项目或者任务。你可能有钱
进账，也可能需要花费一些钱，比如付一大笔账单。总之，这个新月是讨人喜欢的，因
为火星将会对你非常友好，它掌管着你的房屋的合同或协议，因此合同方面你会很容易
得获得一致的。
9月14日是另一个拥有绝好的金钱运的日子，水星和木星为你而相遇。这一天，你要在
金钱方面做出决定。在这一天签订合同，因为水星掌管着合同，而木星的加入则意味着
慷慨的资助或者利润。你的钱财上的幸运会发生在9月初，而不是后半月。这个月是个
黑白分明的月份，你有可能在第一个星期在银行贷款、申请奖学金等等那些方面拥有好
运，而随后则完全相反。9月最后一个星期，水星会在冥王星的围困之中，届时，你会
开始注意到风向发生了变化。最好不要申请任何资助，乖乖呆着最好（sit tight）.这
就是我为什么觉得你应该在9月上旬迅速行动。
如果你处于失业状态或者正在计划跳槽，我有好消息给你：掌管你的名誉和荣耀之第十
宫的冥王星，将在9月16日结束逆行。冥王星自4月早期开始逆行。你会发现这个改变为
你带来颇受欢迎的宽慰。当任何一个大行星结束逆行时，在转折点的前后几日总会为未
来的发展留下一些重要线索。你要留心抓住那些面包屑。注意9月16日以及前后各两天
，当那些线索最终成为你的职业，事情必将变得越来越好。
至于健康问题，第八宫正在为你点亮，你会获得关于某个健康问题的不同诊断或手术或
是安排好治疗的时间。在本月早期完成这些将会对你有极大的帮助，不行吗？那就等到
十月底的最后一周吧。
本月前半月，火星在你的第六宫，直到18号，实际上是直到你决定提升你的健康的那一
天。你应该足够明智关注于经济问题，在此前后各四天（直译，有点看不懂）。至此你
会了结一些麻烦，比如买一些大件，或者寄出一张所欠的大额支票。你也能也会听到一
些关于钱的好消息，特别是如果你有伴侣的话。
在9月25-29日，旅行将会混乱不堪，最好推迟任何你计划中的出行。此间开始任何法律
诉讼或者在法庭上作证，都是不明智的。
关于远方的亲戚的信息，比如那些in-law之类的亲戚（不是血缘关系的亲戚），可能在
最后一个星期有麻烦。
从9月18日至11月11日，狮子座的火星会带来对伴侣问题的关注，并且需要合作。对对
方指手画脚看来行不通了，你的另一半看来掌握了话语权并且很爱发号施令。
待续
S*s
4 楼
任务本身很简单，大概有几万个记录，对每个记录都要应用一大堆假设参数产生几百个
数，再对产生的几十个M的数根据各种组合进行汇总统计。
最开始用excel+vba实现很简单，运算都在内存中，那几百万个数在生成的时候就同时
汇总，算完了就扔所以内存也够用，算一次也就是100多秒。
后来放到云上用node.js+mysql就遇到问题了。开始的想法是把记录、参数放在数据库
里，算的时候前面js遍历每一条记录，把中间结果写回数据库里，再用sql group by汇
总。这样运算了一次以后结果已经cache在数据库里再次运算就不用像excel一样重算，
只要算那些以前没算过的了。但是实际运行以后发现写回数据库非常慢，改用load
data local infile之后的速度仍然无法接受，load个几百兆的文件也要几十分钟。
显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。
数，再对产生的几十个M的数根据各种组合进行汇总统计。
最开始用excel+vba实现很简单，运算都在内存中，那几百万个数在生成的时候就同时
汇总，算完了就扔所以内存也够用，算一次也就是100多秒。
后来放到云上用node.js+mysql就遇到问题了。开始的想法是把记录、参数放在数据库
里，算的时候前面js遍历每一条记录，把中间结果写回数据库里，再用sql group by汇
总。这样运算了一次以后结果已经cache在数据库里再次运算就不用像excel一样重算，
只要算那些以前没算过的了。但是实际运行以后发现写回数据库非常慢，改用load
data local infile之后的速度仍然无法接受，load个几百兆的文件也要几十分钟。
显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。
d*e
5 楼
###此帖已应当事人要求删除###
【在 J********a 的大作中提到】
: 那个该死的有毛的皮，很难搞哇！
【在 J********a 的大作中提到】
: 那个该死的有毛的皮，很难搞哇！
w*n
6 楼
网上找个模板，写好辞职信，跟老板约好时间，不用提前说为什么，到时候当面辞职，
信交上去就好了，口头的是不算的。
好和好散，山不转水转，就这么一个圈子，将来还说不定用得着的。
信交上去就好了，口头的是不算的。
好和好散，山不转水转，就这么一个圈子，将来还说不定用得着的。
P*I
7 楼
9月16号对我的工作确实是个大日子。
W*o
8 楼
不明白为啥需要把中间结果保存到数据库里，是因为这些中间结果数量巨大导致内存装
不下吗？如果是这样，是不是可以多弄几台机器share memory？
不下吗？如果是这样，是不是可以多弄几台机器share memory？
l*3
9 楼
啊。。。怎么我能买到的都没有毛呢。。。
i*i
10 楼
咱们组很好。
我这有点小问题，你第一个知道，先考虑考虑。
我们组会蒸蒸日上。
我这有点小问题，你第一个知道，先考虑考虑。
我们组会蒸蒸日上。
O*e
11 楼
俺有个房子挂牌一个多月了，都没人问，nnd。中介说我挂了天价。。。。
上个月提到的好日子没一个准的，且看这个月的重点日子有没有傻兔子撞树！！！
上个月提到的好日子没一个准的，且看这个月的重点日子有没有傻兔子撞树！！！
S*s
12 楼
for cache, also aggregation although not a must.
how to "多弄几台机器share memory"
【在 W***o 的大作中提到】
: 不明白为啥需要把中间结果保存到数据库里，是因为这些中间结果数量巨大导致内存装
: 不下吗？如果是这样，是不是可以多弄几台机器share memory？
how to "多弄几台机器share memory"
【在 W***o 的大作中提到】
: 不明白为啥需要把中间结果保存到数据库里，是因为这些中间结果数量巨大导致内存装
: 不下吗？如果是这样，是不是可以多弄几台机器share memory？
d*e
13 楼
###此帖已应当事人要求删除###
【在 l********3 的大作中提到】
: 啊。。。怎么我能买到的都没有毛呢。。。
【在 l********3 的大作中提到】
: 啊。。。怎么我能买到的都没有毛呢。。。
s*1
14 楼
如果跟老板关系好，那么亲口告知他/她，强调personal reason,不是这里不好，而是
由客观原因，自己的一些考虑，让老板觉得你在这里还是很开心的。如果关系不好，就
一份辞职电邮就好了。网上太多模板了。
由客观原因，自己的一些考虑，让老板觉得你在这里还是很开心的。如果关系不好，就
一份辞职电邮就好了。网上太多模板了。
a*y
15 楼
me too
around that date
【在 P**I 的大作中提到】
: 9月16号对我的工作确实是个大日子。
around that date
【在 P**I 的大作中提到】
: 9月16号对我的工作确实是个大日子。
c*n
16 楼
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机制大家有什么好建议吗？把所
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机制大家有什么好建议吗？把所
F*t
17 楼
天天你买到的都是些响应号召裸奔滴
【在 l********3 的大作中提到】
: 啊。。。怎么我能买到的都没有毛呢。。。
【在 l********3 的大作中提到】
: 啊。。。怎么我能买到的都没有毛呢。。。
J*G
18 楼
这两年好背啊，正期盼赶紧转运呢。。。
d*a
19 楼
"显然瓶颈是和数据库的io操作。如果仍然想保留cache机制大家有什么好建议吗？把所
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。"
可以把中间生成的数据表放在内存里，MySQL应该有这个选项。放在HDD上确实是太慢了
，SSD也比内存慢很多。几百万个数，有几GB的内存足够了，真不够就把内存加大，几
十GB也不贵。
有的逻辑都用存储过程在数据库端实现吗？存储过程做那些事很笨拙，直觉不像是个好
主意。"
可以把中间生成的数据表放在内存里，MySQL应该有这个选项。放在HDD上确实是太慢了
，SSD也比内存慢很多。几百万个数，有几GB的内存足够了，真不够就把内存加大，几
十GB也不贵。
l*3
20 楼
？？？这咋又跟纯洁挂上边儿了。。。想不出来哇。。。今天那个贴之后脑袋有点短路
。。
【在 d**e 的大作中提到】
: ###此帖已应当事人要求删除###
。。
【在 d**e 的大作中提到】
: ###此帖已应当事人要求删除###
H*y
21 楼
我的9月运势简直恐怖，susan miller 很少give such strong words,她一般都比较温
和，我看了想说要自杀，最好趁早。
【在 J*G 的大作中提到】
: 这两年好背啊，正期盼赶紧转运呢。。。
和，我看了想说要自杀，最好趁早。
【在 J*G 的大作中提到】
: 这两年好背啊，正期盼赶紧转运呢。。。
w*m
22 楼
用node不对吧。你这个要用hash map。
l*3
23 楼
哈哈哈。。。。没错。。。不过没有披个纱布。。
【在 F*******t 的大作中提到】
: 天天你买到的都是些响应号召裸奔滴
【在 F*******t 的大作中提到】
: 天天你买到的都是些响应号召裸奔滴
J*G
24 楼
你嘛座的？
【在 H***y 的大作中提到】
: 我的9月运势简直恐怖，susan miller 很少give such strong words,她一般都比较温
: 和，我看了想说要自杀，最好趁早。
【在 H***y 的大作中提到】
: 我的9月运势简直恐怖，susan miller 很少give such strong words,她一般都比较温
: 和，我看了想说要自杀，最好趁早。
S*s
25 楼
对，我依赖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的那部分
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的那部分
o*1
26 楼
认栽吧。曾经煮开又泡几个小时，最后还是用小刀刮掉一层栗子肉才吃到嘴。我琢磨可
能需要特别的工具，类似玉米脱粒机原理的。
【在 J********a 的大作中提到】
: 那个该死的有毛的皮，很难搞哇！
能需要特别的工具，类似玉米脱粒机原理的。
【在 J********a 的大作中提到】
: 那个该死的有毛的皮，很难搞哇！
a*y
27 楼
我真的是要打算9月16号决定职业方向………………………………
【在 L*********n 的大作中提到】
: 亲爱的瓶子们，你们有需要资金才能实现的计划吗？9月初，募集资金方面你们有着多
: 么美好的前景。你可以开始自己的business,或是去读研究生，或是买房子。银行、奖
: 学金，风投等等类型的资金都将乐于祝你一臂之力。你会惊喜的发现他们都愿意铺好红
: 地毯等着为你资助。这是个非比寻常的消息，特别是考虑到你前几年所经历的挫折和资
: 金上困窘。宇宙的运行在于修正前面的错误，你正是受益者。
: 上月28日出现的新月，运行于你的第八宫——掌管着与其他人有关的钱财问题，将会是
: 2011年所有新月中最对你有帮助的最幸运的一个。它直到9月11日都将会占有重要地位
: ，所以如果你需要钱，确保你在本月初期的这些正确的日子里去递交申请吧。在新月发
: 生后的几天是最有帮助的，在随后的几天中，它会逐渐失去其效力。如你所见，尽快处
: 理这些事情，将会有非同寻常的收获。你或许可以用这几天来处理你的税务问题，或是
【在 L*********n 的大作中提到】
: 亲爱的瓶子们，你们有需要资金才能实现的计划吗？9月初，募集资金方面你们有着多
: 么美好的前景。你可以开始自己的business,或是去读研究生，或是买房子。银行、奖
: 学金，风投等等类型的资金都将乐于祝你一臂之力。你会惊喜的发现他们都愿意铺好红
: 地毯等着为你资助。这是个非比寻常的消息，特别是考虑到你前几年所经历的挫折和资
: 金上困窘。宇宙的运行在于修正前面的错误，你正是受益者。
: 上月28日出现的新月，运行于你的第八宫——掌管着与其他人有关的钱财问题，将会是
: 2011年所有新月中最对你有帮助的最幸运的一个。它直到9月11日都将会占有重要地位
: ，所以如果你需要钱，确保你在本月初期的这些正确的日子里去递交申请吧。在新月发
: 生后的几天是最有帮助的，在随后的几天中，它会逐渐失去其效力。如你所见，尽快处
: 理这些事情，将会有非同寻常的收获。你或许可以用这几天来处理你的税务问题，或是
N*r
28 楼
第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
上大内存全部load到内存操作
第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
sort, 这是通用做法
综上所述，你根本的错误就在于不应该在这里用数据库
关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
上大内存全部load到内存操作
第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
sort, 这是通用做法
综上所述，你根本的错误就在于不应该在这里用数据库
Y*e
29 楼
用小铁勺子刮来吃.
【在 o*******1 的大作中提到】
: 认栽吧。曾经煮开又泡几个小时，最后还是用小刀刮掉一层栗子肉才吃到嘴。我琢磨可
: 能需要特别的工具，类似玉米脱粒机原理的。
【在 o*******1 的大作中提到】
: 认栽吧。曾经煮开又泡几个小时，最后还是用小刀刮掉一层栗子肉才吃到嘴。我琢磨可
: 能需要特别的工具，类似玉米脱粒机原理的。
S*s
30 楼
very make sense.
how do they implement the big data?
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
how do they implement the big data?
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
J*a
31 楼
：（
【在 o*******1 的大作中提到】
: 认栽吧。曾经煮开又泡几个小时，最后还是用小刀刮掉一层栗子肉才吃到嘴。我琢磨可
: 能需要特别的工具，类似玉米脱粒机原理的。
【在 o*******1 的大作中提到】
: 认栽吧。曾经煮开又泡几个小时，最后还是用小刀刮掉一层栗子肉才吃到嘴。我琢磨可
: 能需要特别的工具，类似玉米脱粒机原理的。
N*r
32 楼
不同的大数据有不同的处理办法
要看数据特征， 需要排序的和不需要的不一样， 要维护相对关系的和不需要维护相对
关系的不一样
【在 S*******s 的大作中提到】
: very make sense.
: how do they implement the big data?
l*g
33 楼
哪里有卖栗子的？？馋
S*s
34 楼
guess none is using RDBMS?
can you elaborate further, what technology is used for each case?
【在 N*****r 的大作中提到】
:
: 不同的大数据有不同的处理办法
: 要看数据特征， 需要排序的和不需要的不一样， 要维护相对关系的和不需要维护相对
: 关系的不一样
can you elaborate further, what technology is used for each case?
【在 N*****r 的大作中提到】
:
: 不同的大数据有不同的处理办法
: 要看数据特征， 需要排序的和不需要的不一样， 要维护相对关系的和不需要维护相对
: 关系的不一样
k*u
35 楼
赞
缓冲区一般怎么搞最好？
是不是data -> redis -> mysql 这样？
我曾经做过实时download twitter data，然后直接到db，基本每天都会挂掉
后来改成每天的data直接保存为jsonfile或者sqllite，放在硬盘上，一天一个file，
把日期加在文件名上
能不能帮忙解惑，实际生产环境是怎么个缓冲法？
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
缓冲区一般怎么搞最好？
是不是data -> redis -> mysql 这样？
我曾经做过实时download twitter data，然后直接到db，基本每天都会挂掉
后来改成每天的data直接保存为jsonfile或者sqllite，放在硬盘上，一天一个file，
把日期加在文件名上
能不能帮忙解惑，实际生产环境是怎么个缓冲法？
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
N*r
36 楼
看需要什么的环境吧
如果是要上关系数据库，只考虑读的速度memcached 和上面提到的 redis 都可以
关系数据库要读写都快，那就是redis
如果数据关联性不强， 那就用 nosql。或者土方法直接 hashtable + 大文件块
真要搞海量文件系统 google那篇 bigtable 要好好读
另外现在好像有新的海量关系数据库，没仔细看
【在 k*****u 的大作中提到】
: 赞
: 缓冲区一般怎么搞最好？
: 是不是data -> redis -> mysql 这样？
: 我曾经做过实时download twitter data，然后直接到db，基本每天都会挂掉
: 后来改成每天的data直接保存为jsonfile或者sqllite，放在硬盘上，一天一个file，
: 把日期加在文件名上
: 能不能帮忙解惑，实际生产环境是怎么个缓冲法？
d*c
37 楼
关系数据库建在那几条原则之上。你用不上的话就不需要用数据库。
仅仅是duplicate，那就是hash table足够。找个快的二进制格式存文件，尽量用内存。
【在 S*******s 的大作中提到】
: 对，我依赖index on duplicate replace.
: redis是啥，我搜搜看，谢谢
: 按理说我这个需求应该是很普遍很典型的吧，先从数据库里拿点数当输入，折腾出更多
: 的数出来存进数据库，再对这些新产生的数进行分析。我这才不到几百兆的数据，人家
: 大数据动辄几十T,也没听说这么慢吧？
仅仅是duplicate，那就是hash table足够。找个快的二进制格式存文件，尽量用内存。
【在 S*******s 的大作中提到】
: 对，我依赖index on duplicate replace.
: redis是啥，我搜搜看，谢谢
: 按理说我这个需求应该是很普遍很典型的吧，先从数据库里拿点数当输入，折腾出更多
: 的数出来存进数据库，再对这些新产生的数进行分析。我这才不到几百兆的数据，人家
: 大数据动辄几十T,也没听说这么慢吧？
d*n
38 楼
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
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
39 楼
赞总结. 这些数量级最好能背下来.
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
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
40 楼
收藏了
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
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
41 楼
你用过很多存储过程吗？直觉从哪里来的？
你这个问题，我觉得最方便快捷的办法可能还就是存储过程。
你在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机制大家有什么好建议吗？把所
你这个问题，我觉得最方便快捷的办法可能还就是存储过程。
你在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
42 楼
他这个问题存储过程有不好的地方吗?
vba都可以搞定的
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
vba都可以搞定的
【在 N*****r 的大作中提到】
: 第一数据不要直接写到数据库， 放在缓冲区攒齐了一起写
: 关系数据库的IO性能本来就奇差无比，你这完全是没实战经验
: 第二其实最好不要用数据库存储， 直接写在磁盘上, 后期计算几百万量级的数据直接
: 上大内存全部load到内存操作
: 第三, 大规模的数据排序更不要用关系数据库，直接写在磁盘上用external merge
: sort, 这是通用做法
: 综上所述，你根本的错误就在于不应该在这里用数据库
N*r
43 楼
他一开始本机excel + vba 是没啥问题啊
问题在于他后来在上mysql
mysql 没有优化的话，同时写150个记录就可能出问题
关系数据库同时写从来都是大问题，因为有lock
【在 g****t 的大作中提到】
: 你用过很多存储过程吗？直觉从哪里来的？
: 你这个问题，我觉得最方便快捷的办法可能还就是存储过程。
: 你在excel+VBA没问题。
: 只要数据和处理都在一头，不要来回读写，应该就没问题。
: oracle，DB2 + 存储过程不可能比excel+VBA慢啊
g*t
44 楼
Excel同时写照样也有锁
我觉得问题就在于他不用自带的存储过程
用别的踩了坑
我猜
所有逻辑数据库端存储过程实现
Vs excel vba
前者不应该差很多
: 他一开始本机excel vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
【在 N*****r 的大作中提到】
:
: 他一开始本机excel + vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
我觉得问题就在于他不用自带的存储过程
用别的踩了坑
我猜
所有逻辑数据库端存储过程实现
Vs excel vba
前者不应该差很多
: 他一开始本机excel vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
【在 N*****r 的大作中提到】
:
: 他一开始本机excel + vba 是没啥问题啊
: 问题在于他后来在上mysql
: mysql 没有优化的话，同时写150个记录就可能出问题
: 关系数据库同时写从来都是大问题，因为有lock
S*s
45 楼
现在先用现场算+redis缓存对付了。redis真神奇啊，有缓存的秒现，没在缓存的即使
现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
多谢诸位支招。
这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？
现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
多谢诸位支招。
这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？
c*n
46 楼
你没试一下另一个直接跑的方法？ 很好奇v8 在超大内存下会不会有奇怪的问题
我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
改代码最有用。。。
【在 S*******s 的大作中提到】
: 现在先用现场算+redis缓存对付了。redis真神奇啊，有缓存的秒现，没在缓存的即使
: 现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
: 多谢诸位支招。
: 这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？
我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
改代码最有用。。。
【在 S*******s 的大作中提到】
: 现在先用现场算+redis缓存对付了。redis真神奇啊，有缓存的秒现，没在缓存的即使
: 现算也不算慢。以后有空再琢磨怎么弄个更漂亮的。
: 多谢诸位支招。
: 这个express-redis-cache的内存策略是什么样的？不会不重启就不停地占内存吧？
S*s
47 楼
现在就是在缓冲没有命中的时候直接跑，你问的是这个吗？
缓冲只记录最后汇总的结果，所以对内存压力不大。
【在 c******n 的大作中提到】
: 你没试一下另一个直接跑的方法？ 很好奇v8 在超大内存下会不会有奇怪的问题
: 我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
: 改代码最有用。。。
缓冲只记录最后汇总的结果，所以对内存压力不大。
【在 c******n 的大作中提到】
: 你没试一下另一个直接跑的方法？ 很好奇v8 在超大内存下会不会有奇怪的问题
: 我最近改了个代码 内存占用少了700M，处理时间缩短了10多秒 看来一般而言果然还是
: 改代码最有用。。。
相关阅读
请教C++ 背景的怎么往互联网转呢？atom很好用Spa这东西不适合所有场景吧？有没有谁做 text mining 的？古德霸别骂架了 给新人指点指点学啥技术吧Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East RegionAWS早上有挂了scala基本是死了。clojure还有戏么socket.io doesn't work with IEHibernate值得深入学习吗?[python] raise another exception in exception constructgo很牛啊。这个10ms 非常快了。sql未必会被历史淘汰掉，但是sp一定是过时的东西有每天上班写py的么 会不会疯掉？vertica如何，跟impala, hbase,比有什么异同？现在怎么越来越多的公司用cookie了？这不是过时的技術吗？请教哪家公司工作时间比较灵活pay 得又多问个弱智问题，有网站用nosql做primary db么？设计系统关键在于taste一个烂设计的实例SmartThings