|
锁定老帖子 主题：为什么用RoR?为什么不用RoR?
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-06-28
论坛，海量用户，积分很敏感，大量文件上传，前台是PHP，公司成立才两年
前两条象天涯，后面又不象了。。。到底是哪呢 |
| 返回顶楼 | |
|
发表时间：2007-06-28
难道是 cyworld ?
如果是的话，qiezi 帮帮弄点积分阿... |
| 返回顶楼 | |
|
发表时间：2007-06-28
鄙视楼上的几个八卦男，哈哈.
|
| 返回顶楼 | |
|
发表时间：2007-06-28
qiezi 写道 补一点：
前几天听了个课程，讲的是公司经营发展的，一般公司前2年是快速成长期，技术通常还不上档次，也比较散。之后5年是规范期，大概到这个5年的末期各个产品才会规范成熟。目前我们刚刚过完前2年，技术上才刚刚从db/php的2层架构往db/midware/php的3层上转型。国外公司也许技术上比较好一些，经过2年就有拿得出手的产品(比如rails)去开源，国内恐怕还差得很远。 很有感触，特别是分库这里。如果网站真的达到这么大的规模，也只能这么做了。除非你狂上机器。 |
| 返回顶楼 | |
|
发表时间：2007-06-28
俺目前不用ror的主要理由是ror的周边库还太少， 在java里面分词搜索、导出为word,excel,pdf以及生成个统计图都非常方便，但ror里面这些都还很难。
|
| 返回顶楼 | |
|
发表时间：2007-06-28
qiezi 写道： firebody 写道： 我并没有参与过大型高并发高负载网站的建设，不过对楼主的一些观点存在疑问，请教一下： 各种数据每秒访问量都上万，所以不是任何数据库能负载的，即使是把数据库分库分表(这种情况下用RoR的ActiveRecord也不方便)。目前是按业 务划分把各种业务逻辑和cache用C++写中间件，前台PHP用socket来调用(WebService?太慢)，我所知道的一些国内同等访问量的网 站也都是使用类似的方式。 疑问： 因为数据库压力采用分库分表的话，我理解中的Hibernate/JPA应该可以应付这样的场景，保持多个sessionFactory，根据合适的策略选择相应 的sessionFactory 。虽然我没使用过rails,但是 ActiveRecord同时连接多个数据库应该是一个很合理的需求。 如果 rails应用到几个大型高并发高负载项目里面，会碰到具体的应对高并发高负载而设计的系统架构所带来的问题，伴随这些具体问题的解决，rails似乎也不能成为架构高性能网站的阻碍哦。比如楼主提到的分库分表，多级目录的问题。 以前用hibernate主要是做一些表的映射、关联，更深层的应用就没有了，所以也没什么经验，拿个具体的情况来分析一下吧。 目前主要数据库是mysql，由于数据库存储限制： 1、通常会把用户名和密码放一个库(负载相对较少，但也要依赖cache)。 2、用户基本资料拆开多台DB按用户名或ID hash，用户扩展信息也拆开多台。 3、用户积分因为太敏感，甚至使用了oracle来保证效率和稳定性(事实证明它比mysql慢。。它的C++绑定也更不稳定)。 4、用户发帖是保存在文件的，数据库只保存文件链接发帖人等简单信息。 5、用户之间的消息是放数据库的，当然也是按用户名hash到多台，这时候要查询我给别人的消息和别人给我的消息，就得从2个表里面查，因为你给别人的消息是按别人的用户名hash到某一台上，别人给你的是按你的用户名hash的，所以增加一条消息就得往2个库各写一条。 以上列举了一部分应用，当然由于库拆得比较散，基本上每个库都会有冗余字段。 上面这种情况下，能不能分析一下hibernate和ActiveRecord用得比较舒服的部分？ 我在用rails的时候，ActiveRecord对于多数据库支持并不好，即使是有这样的方案也是非方的技巧。分表情况下表之间的关联基本上没法做，如果没有关联，ActiveRecord的意义只是帮我们生成SQL？ 多级目录不是最大的问题，也不是阻碍性能的问题，俺只想找个最后的理由把RoR不适用这个项目说得更充分些。。。
ebay也是拆库拆表的方式，在应用级处理之间的关联关系，我想越是大型的系统，在应用级处理的方式越原始，不能用框架，或是需要自己写框架处理。 还有一点，我认为整体网站应该拆分为非常细小的应用，一个应用只处理一样事情，应用之间的调用可以用HTTP、Socket，不建议Webservice，效率较低。 |
| 返回顶楼 | |
|
发表时间：2007-06-28
说到底，开发大型网站和中小型网站的方法可能大不一样，这就带来一个问题，有比较丰富的中小型网站经验的架构师不一定能胜任大型网站，反过来应该也成立，把大型网站的方法弄到中小网站上，会不会造成开发周期长？中间是不是有个鸿沟？
|
| 返回顶楼 | |
|
发表时间：2007-06-28
qiezi 写道 说到底，开发大型网站和中小型网站的方法可能大不一样，这就带来一个问题，有比较丰富的中小型网站经验的架构师不一定能胜任大型网站，反过来应该也成立，把大型网站的方法弄到中小网站上，会不会造成开发周期长？中间是不是有个鸿沟？
还是我一开始说的，99.99%的中小网站永远不会变成大型网站。所以“如何开发中小网站”的知识不能应用于大型网站，并不是一个严重的问题。 另一方面，大型网站会遇到一些特殊的问题。这些问题也许别人也会遇到，但只有他们有足够的钱来解决。出于社会责任感，他们应该把这些解决方案贡献给开源社区。 具体到这个案例，就是楼主应该说“我告诉你们如何用Ruby（甚至Rails）处理复杂的数据库”，而不是问“Ruby on Rails应该如何处理这些复杂的数据库”。这才是一个大型网站，一个受到最多用户关注的组织，一个拥有最强技术力量和最多资金的组织应该有的态度。 |
| 返回顶楼 | |
|
发表时间：2007-06-28
qiezi 写道 说到底，开发大型网站和中小型网站的方法可能大不一样，这就带来一个问题，有比较丰富的中小型网站经验的架构师不一定能胜任大型网站，反过来应该也成立，把大型网站的方法弄到中小网站上，会不会造成开发周期长？中间是不是有个鸿沟？
赞同，从小型网站，到企业应用，到高并发高负载大型网站， 根据应用负载的性能要求，数据量多少这些需求，所涉及的系统架构大不一样， 不过，相对来说，中小型网站和企业应用的占有市场的比率要大一些。 目标定位于大型网站，但是当前还是中小型网站的系统架构设计还是应该遵循逐步渐进的方式，先定位于单服务器架构，这样的架构可以在在将来适当增加LVS,squid,数据库集群，应对增加的需求应该还是绰绰有余。 同样，对于gigix的观点，我也赞同，至少很多开发团队都渴望存在一个效率高的开发框架，能够应对性能需求带来的复杂问题，比如你提到的分库分表的问题。 这个问题如果rails或者jpa能够得到解决，那么对于我们开发人员来说，还是一个很好的福音的，要促成这个福音，还需要很多人作出自己的贡献，特别是那些具备高并发高负载框架设计开发经验的人。 他们可以提出自己实际的问题和建议，甚至可以参与贡献，那对所有开发人员来说，都是一个很好的帮助。 在这样的情况下，高效率成熟的框架会大大消除从中小型网站 到 大型高并发高负载网站 开发所存在的系统架构的差异问题，大大减少开发成本和维护成本。 |
| 返回顶楼 | |
|
发表时间：2007-06-28
qiezi 写道 说到底，开发大型网站和中小型网站的方法可能大不一样，这就带来一个问题，有比较丰富的中小型网站经验的架构师不一定能胜任大型网站，反过来应该也成立，把大型网站的方法弄到中小网站上，会不会造成开发周期长？中间是不是有个鸿沟？
有一定道理，不过我到设想将大型网站拆分为多个中小网站来做，当然前提是网站基础一定要稳固，可扩展性要好。 |
| 返回顶楼 | |
