セールスフォースのアーキテクチャはPaaSに向いていないと、Ruby on RailsクラウドのEngine Yardがブログで指摘
セールスフォースのアーキテクチャはPaaSに向いていないと、Ruby on RailsクラウドのEngine Yardがブログで指摘 セールスフォース・ドットコムは昨年12月、Ruby on RailsのPaaSを提供している「Heroku」の買収を発表しました。これにより、同じくRuby on RailsのPaaSを提供しHerokuのライバルであるEngine Yardの共同設立者兼CTOのTom Mornini氏が、「セールスフォース・ドットコムが隣人というよりも競合になった」と、同社のブログに「Cloud 2?」というエントリをポストしています。 そしてMornini氏は、「Ruby on Railsに未来がある、という点はセールスフォース・ドットコムに合意する」が、それ以外に合意できない点が2つあると書いています。 彼が同意できないと書いたのは、セールスフォースのアーキテクチャに
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。 では、個別に入力項目を増やすようなスキーマの変更を伴うアプリケーションのカスタマイズや、新たなテーブルを作成してそこに独自データを保存するようなアプリケーションの新規作成はできないのか？ といえば、そんなことはなく、セールスフォースが提供するプラットフォームの上で、自由に項目の追加や新しいテーブルの作成が可能です。 全ユーザーでスキーマを共有しながら、しかし個別のカスタマイズを許容する。この一見矛盾する要件を、セールスフォースはどのように実現しているのでしょうか？ （本エントリは「知られざる『マルチテナントアーキテクチャ』（2）～スケーラビリティのカギは組織ID」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル
知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID
セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。これによってインフラの共有が容易になり、非常に効率的な運用と低コストを実現しています。 （本エントリは「知られざる『マルチテナントアーキテクチャ』（1）～SaaSはみんな同じではない？」からの続きです。） しかし、それだけではスケーラビリティやアベイラビリティを実現することはできません。それらの実現には別の技術が併用されています。それはOracleのパーティショニング機能とパラレル機能による分散処理です。 パーティショニング機能の話をする前に、セールスフォースが採用しているデータベースの特徴を見てみましょう。 すべてのデータに振られる組織ID セールスフォースはすべてのユーザーが1つのデータベースを共有するマルチテナントアーキテクチャを採用しています。ということ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
