I saw a recent posting about Twitter moving some of their code from Rails to Java and it seemed to be germane to this conversation. It is a perfect example of the kinds of things you have to do for the tiny, tiny number of sites in the world that *really* need to scale: http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html
I think what they did makes good sense for their vanishingly unique use case, and I think anyone building a new site from scratch would be nuts to try to build an architecture like that to knock out a site and see whether anyone was going to use it. Rails is a great framework for building *almost* every web app :) Rails is dead, long live Rails. Best Wishes, Peter On Apr 6, 2011, at 10:32 AM, Peter Bell wrote: > > On Apr 6, 2011, at 10:17 AM, mengu wrote: > >> rails has become a lot better in the years thanks to the core devs, >> contributors and the community for pushing it that way. it definitely >> depends on how you build your application. >> there are couple of things i can recommend and i am following them in >> practice. > > I think all of those are really good points, but they relate to incremental > scaling up, not scaling out. They will allow you to get more performance from > a single server. For substantial scale, it's more a case of architecting so > that you can throw multiple servers at the problem. > > I've never tried to build out a Rails app with ten front end servers speaking > to a cluster of back end (SQL) db servers, but I'm guessing there would be > problems with database contention and you'd start to have to take a lot more > interest in failed saves - especially if you need to scale a write heavy > application. That's where a fundamentally different architectural approaches > based on designing from the get go for eventual consistency and asynchronous > messaging are really important (assuming you don't need immediate consistency > for most of your app). > > Personally I quite like the event sourcing model > (http://martinfowler.com/eaaDev/EventSourcing.html) as it effectively gets > rid of mutable state and makes any database values for entities a cache > rather than an authoritative source. It's a different way of writing things, > but it makes scaling out trivially simple. If I get some time I may have a > play to see the best way of providing an easy implementation of this in the > Ruby world. I see something here > (https://github.com/cavalle/banksimplistic#readme) but haven't had a chance > to play with it. > > That said, I just got brought in to do some architecture on a JRuby app that > is going to genuinely need substantial write scaling from day one, so I may > just get a chance to play with some of this if it makes sense to keep this in > Rails vs. just using Rails as a thin layer and handling all the contention > logic using a message bus or an eventually consistent, write scalable NoSQL > data store like Cassandra with callbacks for contention handling. > > Best Wishes, > Peter > >> >> - optimize your queries like hell. >> >> - design your database well and so you can avoid joins as much as >> possible. for example, you can have posts and comments. in order to >> display comment count of blog post in your blog home page, instead of >> doing the following query "select count(*) as count from comments >> where post_id = x" you can add a column in posts table called as >> "comment_count" and show them there. >> >> - use faster solutions wherever you can. >> >> - use solr or sphinx for full text searching. >> >> - make sure your views are perfectly fine and does not contain ruby >> code more than enough. remember, the rendering takes time, as well. >> >> - cache whatever you can. >> >> good luck. >> >> On Apr 6, 4:26 pm, Peter Bell <pe...@pbell.com> wrote: >>> On Apr 6, 2011, at 4:06 AM, Alexey Muranov wrote: >>> >>>> I think i understand David's point: "scalable" is true or false. >>> >>> I'm not sure that is Davids point at all. It sounds like he has experience >>> with building scalable applications and notices that some best practices >>> for scalability like UUID primary keys are not the default way in Rails. It >>> seems to me that he is more than sophisticated enough to realize that >>> scalability isn't a binary choice. >>> >>>> Could be nice if scalability was planned for from the beginning. >>> >>> I think there are some architectural defaults that could be changed which >>> would help, but scalability is so large, complex and specific to a given >>> use case I don't think there's any way to "just build scalability in". >>> >>>> I do not know anything about it, but i hope that the issue discussed >>>> here is only about Rails, i hope that Ruby can be used for scalable >>>> applications. >>> >>> Rails has some conventions which are not optimal for scaling certain types >>> of applications. All languages can be used for scalable applications - >>> although you need to look at the performance characteristics at runtime for >>> a given application. The main issue for scaling with Ruby is that it's an >>> OO rather than functional language which raises fundamental issues in >>> managing mutable state. You can work around that by writing Ruby in a more >>> functional style and using architectural patterns that don't depend on such >>> shared state. >>> >>> I think a way more interesting question is whether Rails is productive than >>> whether it is scalable. I would much rather build something quickly in a >>> productive framework and then revisit parts of the app if scale became a >>> concern than spend way more to build a scalable app that nobody ends up >>> using. I use Rails for it's productivity and am enjoying it more with each >>> project I deliver. >>> >>> Best Wishes, >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> Alexey. >>> >>>> -- >>>> Posted viahttp://www.ruby-forum.com/. >>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Ruby on Rails: Talk" group. >>>> To post to this group, send email to rubyonrails-talk@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rubyonrails-talk+unsubscr...@googlegroups.com. >>>> For more options, visit this group >>>> athttp://groups.google.com/group/rubyonrails-talk?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Talk" group. >> To post to this group, send email to rubyonrails-talk@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-talk+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-talk?hl=en. >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
