|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-01-29
freespace 写道
view = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if ( view == MAP_FAILED ) {
out() << " mmap() failed for " << filename << " len:" << length << " errno:" << errno << endl;
if ( errno == ENOMEM ){
out() << " mmap failed with out of memory, if you're using 32-bits, then you probably need to upgrade to 64" << endl;
}
return 0;
}
return view;
在64位linux下也会报“mmap failed with out of memory”错误？ 没错，64bit也报错，但我的内存不大，只有4G |
| 返回顶楼 | |
|
发表时间：2010-02-05
庄表伟 写道 非常棒的帖子！
个人的看法，应该不是NoSQL，而是NoRelation。 最大的区别在于，传统的关系型数据库，追求的目标是： 1、数据唯一：一个数据，只会在一个地方找到。 2、实体关联：从系统分析设计的角度，自然会在数据库中建立各个Table、Column之间的关联关系。 3、永远一致：无论是数据一致性，还是事务一致性，都是RDBMS要追求的，而且还是追求每时每刻都是一致的。 现在的各种新的数据存储方案，说到底是通过牺牲三个方面的要求来达到高性能和高扩展性的： 一个是数据冗余； 一个是数据关联性； 一个是一致性； 而在一个真实的系统中，这些问题，又不能完全不考虑，因此，仅仅基于key-value，还不能搭建实际可用的系统，还得考虑非常多的问题。 回头空下来了，写写这方面的心得。 非常认同不是NoSQL的观点，NoRelation更恰当。在实际的工作中，我发现如果不提供SQL编程接口，那系统的使用难度和开发效率会严重的降低。对海量数据处理，例如数据仓库，要的不是ACID，而是CAP即可，最大的追求线性扩展和容灾能力。说到这一点，目前来看只有一条路可走，只有shared-nothing架构才能满足这样的需求，而要在这样的架构下，做到ACID目前的技术是不可能的。 一致性通常是最先被牺牲的；shared-nothing数据的容灾和安全都是通过多个备份来做的；关联性这一点还是需要，海量的数据计算会有大量的关联计算需求，这一点实际上是shared-nothing架构最大的诟病，天生的缺陷，通常是采用高速的网络带宽来弥补，但是成本就上来了，而且还会受限于磁盘的IO，所以有些做法会在每个节点新加一块SSD。 也正是由于有大量的关联计算，所以SQL的意义显得特别重要，Hadoop的Hive就是如此一种工具，而Hadoop Pig则是同类工具。 |
| 返回顶楼 | |
|
发表时间：2010-02-24
Voldemort 其实后端存储用的是第三方的如：mysql,dbd,mongodb等，那这样子的话这网络传输要多做一个操作，从client->voldemort->mongodb(mysql)等，但是Cassandra是类似于HBase一样自己实现了数据存储层，这样的话不用在中转，直接就client->Cassandra就可以，那么这样的话Cassandra是不是比voldmeort性能上要好很多啊？
|
| 返回顶楼 | |
|
发表时间：2010-02-25
是否使用强一致性
是否不使用关系 如何存储数据 这都是和使用场景紧密相关的 没有万能解决方案的。 |
| 返回顶楼 | |
|
发表时间：2010-03-02
比如一个SNS系统，有1亿注册用户，我们可以按用户ID平均分成100组DB。
客户端通过用户ID和一个映射规则去获取它所属的DB组，然后再使用。 因为每组DB只有100w，所以能满足高性能并发读写的需求，慢的话再细分； 对于写缓存，读缓存等是应用的事，可以写应用来实现缓存。 同理，对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到； 每组DB都做热备以达到高可用性； 当用户又增长了100万时，增加一组DB，修改下映射规则就可以满足扩展性。 什么时候该用 nosql db呀 |
| 返回顶楼 | |
|
发表时间：2010-03-02
onlytiancai 写道 比如一个SNS系统，有1亿注册用户，我们可以按用户ID平均分成100组DB。 客户端通过用户ID和一个映射规则去获取它所属的DB组，然后再使用。 因为每组DB只有100w，所以能满足高性能并发读写的需求，慢的话再细分； 对于写缓存，读缓存等是应用的事，可以写应用来实现缓存。 同理，对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到； 每组DB都做热备以达到高可用性； 当用户又增长了100万时，增加一组DB，修改下映射规则就可以满足扩展性。 什么时候该用 nosql db呀 |
| 返回顶楼 | |
|
发表时间：2010-03-02
onlytiancai 写道 比如一个SNS系统，有1亿注册用户，我们可以按用户ID平均分成100组DB。 客户端通过用户ID和一个映射规则去获取它所属的DB组，然后再使用。 因为每组DB只有100w，所以能满足高性能并发读写的需求，慢的话再细分； 对于写缓存，读缓存等是应用的事，可以写应用来实现缓存。 同理，对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到； 每组DB都做热备以达到高可用性； 当用户又增长了100万时，增加一组DB，修改下映射规则就可以满足扩展性。 什么时候该用 nosql db呀 100组DB，极端情况下就是100*2台服务器，有钱淫 |
| 返回顶楼 | |
|
发表时间：2010-03-03
pandonix 写道 100组DB，极端情况下就是100*2台服务器，有钱淫 都一亿用户了，多弄几台机器没问题吧，再说100w一组DB好像太少了，我只是举例而已，一般的系统活跃用户数很低的，1000w注册用户一组DB也没问题。 我还是觉得大多数情况mysql+memocached足够了，灵活应用就行了。 |
| 返回顶楼 | |
|
发表时间：2010-03-04
最近在看cloud computing的东西，robbin这篇文章不错
|
| 返回顶楼 | |
|
发表时间：2010-03-05
很有先见之明，打算统统换卡珊德拉了
|
| 返回顶楼 | |
