|
锁定老帖子 主题：为什么用RoR?为什么不用RoR?
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-06-29
pufan 写道 单机最大负荷也要考虑，这牵扯到server的数量（硬件、部署、维护都是钱啊）。
貌似ruby性能不是很好：无法使用多cpu，NIO机制不知道有没有，这必然导致单机负荷巨降，做中间件估计不合适。 多CPU是可以用到的，它用多进程嘛。做中间件应该是够用的，前台机器可以不断增加，维护成本也比较低，后台机器增加维护是稍麻烦些。 |
| 返回顶楼 | |
|
发表时间：2007-06-29
pufan 写道 貌似ruby性能不是很好：无法使用多cpu，NIO机制不知道有没有，这必然导致单机负荷巨降，做中间件估计不合适。
就扯淡吧啊。 Agile Web Development With Rails第二版，部署那一章，看完再说话不迟。 |
| 返回顶楼 | |
|
发表时间：2007-06-30
都讨论中间件啦?那就用tuxedo嘛，某大网站中间层都是tuxedo的服务调用。我们用在交易系统上。速度飞快.
|
| 返回顶楼 | |
|
发表时间：2007-06-30
qiezi 写道 第二个方法，我前面简单描述过，通常不能把一个用户所有信息放在一起，因为有时候某些表负载会比较高，不希望一些不重要的系统影响到登录、积分这些严重影响用户体验的。全部放在一起，可能就会分出更多的相同结构的数据库服务器，维护也是比较麻烦的。另外有些相互关联的比如某用户的好友，某用户是谁的好友这2个反向关系，其它一些我发出的邮件和我收到的邮件，每添加一条记录都是要写2个不同表的。
我对于你给出的理由有些疑问。 把一个用户所有信息放在一起，怎么就会影响到登录、积分这些严重影响用户体验？ 一种极端的情况，20亿用户，登录信息放到一个库中，或者放到10000个库中，每个20万用户。 哪个登录会更快呢？ 对于多写入一条冗余的历史信息，来提高查询效率，也是一种优化方法，两次查询消耗的资源绝对大大高于写入操作，另外，正因为所有的数据库有相同的结构，维护才简单勒。 |
| 返回顶楼 | |
|
发表时间：2007-07-01
qiezi 写道 说到解决方案，实际上已经说得比较清楚了，就是分库分表加上中间层，前台只写简单的页面逻辑，业务架构由中间层处理，目前国内排前20的网站大概都是这种模式，再细还能说什么？
可以看看 chinaren 同学录的解决方案 这几年做的一些门户级别的程序系统(C/C++开发) 引用 bserv:
用于高负载，高读写速度的单点和集合数据。 内核为BerkeleyDB，外壳为UDP线程池。 接口为读写单点数据或者集合数据。单点数据就是Key->Value数据。 集合数据就是有索引的数据，List->Keys->Values。 比如一个班级所有成员，一个主贴所有回帖等等。 DBDS性能很高，每秒读取>800个每秒，写>300个每秒（志强xeon:2G*2，72Gscsi，Ram:2G） 配合java接口，目前应用在ChinaRen所有项目中（ChinaRen校内，校友录，社区等等）。是整个ChinaRen的核心数据服务，大概配备了50台服务器。 特点：高速，高请求量。用于各种数据的低成本存储，解决数据库无法实现超高速读写的问题。门户级别的高速数据服务。 |
| 返回顶楼 | |
|
发表时间：2007-07-01
partech 写道 qiezi 写道 第二个方法，我前面简单描述过，通常不能把一个用户所有信息放在一起，因为有时候某些表负载会比较高，不希望一些不重要的系统影响到登录、积分这些严重影响用户体验的。全部放在一起，可能就会分出更多的相同结构的数据库服务器，维护也是比较麻烦的。另外有些相互关联的比如某用户的好友，某用户是谁的好友这2个反向关系，其它一些我发出的邮件和我收到的邮件，每添加一条记录都是要写2个不同表的。
我对于你给出的理由有些疑问。 把一个用户所有信息放在一起，怎么就会影响到登录、积分这些严重影响用户体验？ 一种极端的情况，20亿用户，登录信息放到一个库中，或者放到10000个库中，每个20万用户。 哪个登录会更快呢？ 对于多写入一条冗余的历史信息，来提高查询效率，也是一种优化方法，两次查询消耗的资源绝对大大高于写入操作，另外，正因为所有的数据库有相同的结构，维护才简单勒。 读取用户其它信息的请求数一般会比登录要大很多，这些系统在某些时候可能处于极高负载之下，如果放在一块怎么会不影响登录？把用户名和密码放在单独的物理服务器上，这些服务器压力是很小的。特别是积分，我前面已经描述过了，它是用异步写的，在高峰期它的写入会有堆积，在低峰时这些堆积被消化掉，所以这些部分基本上是满负荷运行，如果在同一个物理服务器上，对于登录的影响是很大的。 |
| 返回顶楼 | |
|
发表时间：2007-07-01
iunknown 写道 qiezi 写道 说到解决方案，实际上已经说得比较清楚了，就是分库分表加上中间层，前台只写简单的页面逻辑，业务架构由中间层处理，目前国内排前20的网站大概都是这种模式，再细还能说什么？
可以看看 chinaren 同学录的解决方案 这几年做的一些门户级别的程序系统(C/C++开发) 引用 bserv:
用于高负载，高读写速度的单点和集合数据。 内核为BerkeleyDB，外壳为UDP线程池。 接口为读写单点数据或者集合数据。单点数据就是Key->Value数据。 集合数据就是有索引的数据，List->Keys->Values。 比如一个班级所有成员，一个主贴所有回帖等等。 DBDS性能很高，每秒读取>800个每秒，写>300个每秒（志强xeon:2G*2，72Gscsi，Ram:2G） 配合java接口，目前应用在ChinaRen所有项目中（ChinaRen校内，校友录，社区等等）。是整个ChinaRen的核心数据服务，大概配备了50台服务器。 特点：高速，高请求量。用于各种数据的低成本存储，解决数据库无法实现超高速读写的问题。门户级别的高速数据服务。 其实大家的方案都差不多，我们这边也许多是从这些公司过来的，大家交流的时候发现能想到的方案都差不多，有时候细节上稍有差别。 
|
| 返回顶楼 | |
|
发表时间：2007-07-01
partech 写道 qiezi 写道 第二个方法，我前面简单描述过，通常不能把一个用户所有信息放在一起，因为有时候某些表负载会比较高，不希望一些不重要的系统影响到登录、积分这些严重影响用户体验的。全部放在一起，可能就会分出更多的相同结构的数据库服务器，维护也是比较麻烦的。另外有些相互关联的比如某用户的好友，某用户是谁的好友这2个反向关系，其它一些我发出的邮件和我收到的邮件，每添加一条记录都是要写2个不同表的。
我对于你给出的理由有些疑问。 把一个用户所有信息放在一起，怎么就会影响到登录、积分这些严重影响用户体验？ 一种极端的情况，20亿用户，登录信息放到一个库中，或者放到10000个库中，每个20万用户。 哪个登录会更快呢？ 对于多写入一条冗余的历史信息，来提高查询效率，也是一种优化方法，两次查询消耗的资源绝对大大高于写入操作，另外，正因为所有的数据库有相同的结构，维护才简单勒。 你说的是横向划分，我理解原文的意思是纵向划分，把不同的字段放在不同的表里。 |
| 返回顶楼 | |
|
发表时间：2007-07-01
lordhong 写道 RoR如果没有统一的编程规范, 维护和更新基本上是很难.
RUBY的多样性写法导致代码的多样性, 维护有你受的. 有点跑题了, 但对于大型项目来说, 可维护性很重要. 开发速度和效率倒是其次的. 我觉得这是最大的问题。 |
| 返回顶楼 | |
|
发表时间：2007-07-01
qiezi 写道 读取用户其它信息的请求数一般会比登录要大很多，这些系统在某些时候可能处于极高负载之下，如果放在一块怎么会不影响登录？把用户名和密码放在单独的物理服务器上，这些服务器压力是很小的。特别是积分，我前面已经描述过了，它是用异步写的，在高峰期它的写入会有堆积，在低峰时这些堆积被消化掉，所以这些部分基本上是满负荷运行，如果在同一个物理服务器上，对于登录的影响是很大的。
如果不采用你们目前的做法，而是把用户分在不同的库中，“这些系统在某些时候可能处于极高负载之下”还会发生吗？异步操作还有必要吗？ 不同的用户只会对不同的服务器产生压力，根本不会出现处理不过来的高峰，10台不行，就20台，100台,10000台...，因为水平扩展总是可能，而且近乎于无限制。 但如果是按照分用户属性的方法，毕竟属性是有限的，不可能无限分解的，所以，会存在一个上限。 另外，从程序改动来说，分用户的方法，会使得过渡相当平滑，对于业务层来说，编程模式同一个数据库没有任何区别，除了在从一台服务器升级到两台，需要改变一段代码外，后续增加的服务器可以通过配置来完成，完全不需要改变任何代码。 但如果是分属性的方法，业务层是否还能做到透明呢？ |
| 返回顶楼 | |
