Rails云々の前にMVCフレームワークを適用するのが妥当かどうかがあります。MVCフレームワークの枠組みに当てはまらないようなシステムにRalisを使うことは無意味ですし、Rails以外のMVCフレームワークでも無意味です。そして、他のMVCフレームワークにできてRalisだとできないことはたぶん無いです(ただ、全く逆も言えます)。Railsだと実装が難しいと思うなら、それはMVCフレームワークを使おうとする時点で間違っています。
あと、Railsはレールの上は走りやすいだけで、レールから外れた処理ができないわけではありません。手動でいくらでもカスタマイズはできます(内容によってはRails本体のハックも必要かも知れませんが)。また、複数テーブルの結合も、テーブル同士の1対1や1対N、N対Nを結べるので結合された状態を簡単に取得できます。コントローラは別途作れるので、一括処理とかも何でもできます。ただ、これは他のMVCフレームワークにも言えることなので、Rails特有のことではありません。
次に、Ralisでは駄目だからRubyは駄目というわけではありません。Ralisでは難しい物でも、同じくRubyで書かれている優れたWebフレームワークであるSinatraでは簡単に作れる場合もあります。Ralisが駄目だから、他の言語がいいという結論を出すことはおかしいです。
最後に、Ruby自体をどうしてもやめたいようですので、Rubyの弱点とそれを補う言語は無いかと言うことについて述べます。Rubyは
- 遅いです。
- メモリが大好きです。
- マルチスレッドできるといいながら、一部の例外を除き、常にコア一つしか使いません。
- 動的型付けなので、一定規模以上になるとちょっと大変です。
- 間違っていても実行するまでエラーになりませんので、自動テスト必須です。
多くのアクセスがあり、処理速度が求められ、応答時間がシビアな基幹系では厳しいです。逆に、特に時間的制約があまり求められない管理者のタスク処理には向いています。chefやvagrantはRubyでできていますし、DSLとしてRubyを採用している例も見られます。また、(実行速度は遅いけど)開発速度が速いため、スタートアップのプロトタイプ作成にも向いています。初期のTwitterがRuby on Ralisでできていたのは有名な話です。処理の規模が小さく、シビアな速度が求められなければ、基幹・業務システムに使うことは十分できます。
さて、データ規模が大きくなり、世界中から多くのアクセスがあり、それでも応答速度を落とさないようにしなくてはならなくなったとき、現在のRubyでは残念ながら限界があります。そんな時に採用すべきだと私が注目している言語は二つです。
Goは並列処理が書きやすいと言われています。Rubyではいくらコアを増やしてもコア1個しか使ってくれませんが、Goであればマルチコアでもその実力を遺憾なくこなせるでしょう。並列処理がうまくこなせるようになれば、それだけ多数のアクセスをさばける・・・はずです。
次のScalaはスケールアウトを意識している・・・らしいです。遅かったら、サーバを単純に増やせばいいのです。また、基幹・業務システムで実績が高く、安定性があるJavaVM上で動くというのも重要です。実行速度もJavaと同じぐらいで、大規模でも十分耐えられると思っていただければと思います。(ただ、コンパイルはめちゃくちゃ遅いです)
以上になりますが、Rubyは何でもこなせるすごい奴では決してないです。でも、すぐにできなくなるような駄目な奴でもないです。大規模だから駄目というわけではなく、そこそこの規模でも十分こなせます。GitHubのシステムは未だにRubyを使っているそうです(今もそうかは資料がみつからなかったけど)。でも、Twitter並にユーザー数が増えると無理という感じでしょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。