問題タブ [architecture]

私は、電子メール サービスとソーシャル ネットワークの間のどこかにある Web アプリに取り組んでいます。今後かなり大きくなる可能性を感じているので、スケーラビリティが気になります。

集中化された 1 つの MySQL/InnoDB データベースを使用し、その時が来たらそれを分割する代わりに、アクティブなユーザーごとに個別の SQLite データベースを作成することにしました。つまり、「シャード」ごとに 1 つのアクティブなユーザーです。

そうすれば、データベースのバックアップは、各ユーザーの小さなデータベース ファイルをリモートの場所に 1 日に 1 回コピーするのと同じくらい簡単になります。

スケールアップは、新しいファイルを保存するためにハードディスクを追加するのと同じくらい簡単です。

アプリが単一のサーバーを超えて成長した場合、GlusterFS を使用してファイルシステム レベルでサーバーをリンクし、アプリを変更せずに実行するか、各サーバーが隣接するサーバーの sqlite ファイルを操作できるようにする単純な SQLite プロキシ システムを装備できます。

各 HTTP リクエストは一度に 1 つまたは 2 つのデータベース ファイルにしかアクセスせず、SQLite は読み取り時にのみブロックするため、同時実行の問題は最小限に抑えられます。

このアプローチにより、アプリを適切にスケーリングし、多くのクールでユニークな機能をサポートできると確信しています。私は間違った賭けですか？何か不足していますか？

更新これまでのところ問題なく機能している、それほど極端ではないソリューションを使用することにしました。私は一定数のシャードを使用しています - 正確には256個のsqliteデータベースです。各ユーザーは、単純なハッシュ関数によってランダムなシャードに割り当てられ、バインドされます。

私のアプリのほとんどの機能では、1 回のリクエストで 1 つまたは 2 つのシャードにアクセスする必要がありますが、ユーザーによっては、256 個の異なるシャードのうち 10 ～ 100 個の異なるシャードに対して単純なクエリを実行する必要があるものがあります。テストでは、すべてのデータが RAM にキャッシュされている場合、約 0.02 秒以下かかることが示されています。私はそれで生きていけると思います！

UPDATE 2.0アプリを MySQL/InnoDB に移植し、通常のリクエストではほぼ同じパフォーマンスを得ることができましたが、シャード ウォーキングを必要とするその 1 つのリクエストでは、innodb が 4 ～ 5 倍高速です。この理由とその他の理由で、私はこのアーキテクチャを削除しますが、どこかで誰かがその用途を見つけてくれることを願っています...ありがとう。

私は本当に若いソフトウェア エンジニア/QA チーム リーダーです。私は約 2 年間ソフトウェアを開発しており、そのうちの 1 年間はソフトウェア開発会社の QA チームの責任者でもありました。現在、私は QA ツールの QA チーム リーダー/ソフトウェア エンジニアとして働いています。最近、ソフトウェア会社を立ち上げたい友人や仲間のグループに招待されました。彼らは私がソフトウェアのアーキテクト/技術リーダーになることを望んでいます (私が言えることは、Java で書かれた特別なチャット クライアントだけです)。私は火の下で学ぶのがとても得意で、実践することで多くのことを学びます。しかし、私の経験不足が原因でプロジェクトが失敗する (または少なくとも不十分に開発される) のではないかと心配しています。ですから、私がこのポジションに就き、最善を尽くし、学びながら学ぶことを提案していただけないでしょうか? それとも、私が拒否することをお勧めしますか?

もし私がその立場を取ることをお勧めするなら、初心者の Java アーキテクトに適したリソースを提供していただけますか?

SQL Server、PostgreSQL、MySQL をサポートする手頃な価格の SQL モデリング ツールをお勧めしてもらえますか? ライセンス範囲ごとに最大 300 ドルを検討しています。回答ごとに 1 つのツールでお願いします。

ありがとう！

私がほぼ完成した最近のプロジェクトでは、Web/サービス層からの相互作用の最上位層として XXXManager クラスを使用するアーキテクチャを使用しました。

たとえば、いくつかの多様なデータ ソースからシステムにデータをインポートする、スケジュールに基づいて実行される Windows サービスがあります。このサービス内では、CPImportScheduleManager、CPImportProcessManager など、いくつかの「マネージャー」クラスが呼び出されます。

現在、これらの Manager クラスは、Web/サービス レイヤーで使用するためにメソッドをチェーンに渡すだけではありません。たとえば、私の UserManager.Register() メソッドは、下位レベルのアセンブリを介してユーザーを永続化するだけでなく、WAP プッシュをユーザーに送信し、使用される携帯電話などを決定します。

このタイプのアーキテクチャーは、OOP を手続き型モデルに適合させようとする一般的な手段であることが示唆されています。私は彼らの要点をここで見ることができますが、私が不思議に思っているのは、このトップ レベルのクラス セットを使用すると、コードを書き直す必要なく、Web/サービス レイヤーが同じ共通メソッドを簡単に呼び出すことができるということです。したがって、ある時点でユーザーを登録する Web サービスを作成したい場合は、すべてのロジックを再度書き直さなくても、 UserManager.Register() メソッドを再度呼び出すことができます。

私は自分自身を説明するのに最適な人物ではない.

乾杯、クリス。

私は Reporting Services と Sharepoint を使用しています。レポート サービスを利用するアプリケーションを持っていますが、クライアントは私たちのアプリケーションを SharePoint に統合したいと考えています。現在、操作を実行するためのさまざまなメソッドを公開する ReportService.asmx Web サービスに密接に結合されています。Reporting Services には「Sharepoint 統合モード」と呼ばれるものがあり、有効にすると、レポート サーバーの動作が異なり、Sharepoint を使用してレポートを管理します。Sharepoint は、ほぼ同じ ReportService2006.asm という新しい Web サービスを追加します。

ここで、アプリケーションは ReportService への Web 参照を使用し、サービスによって公開されるさまざまなオブジェクトを使用します。ReportService2006 にはまったく同じオブジェクトがありますが、それらは明らかに異なる名前空間にあります。たとえば、2 つの Web 参照があります。各サービスに 1 つずつあり、オブジェクト MyApplication.ReportService.CatalogItem と別の MyApplication.ReportService2006.CatalogItem があります。

依存性注入を使用して、サービスをアプリケーションから抽象化し、ファクトリ パターンと組み合わせて、インターフェイスのどの実装をインスタンス化するかを決定しようとしました。これが私のインターフェースです。このアプリケーションに必要な呼び出しのみを含めるように簡略化しました。

したがって、それぞれが異なる Web サービスをインスタンス化する 2 つの実装があります。

と

したがって、これらを実行時に ServiceWrapper に挿入できるようにする計画です。ただし、インターフェイスが ReportService に関連付けられており、一部のメソッドが Web 参照 (CatalogItem など) からのオブジェクトを返すことに気付いた場合。したがって、ReportService2006 の実装が別の名前空間から CatalogItem を参照しているため、私のプロジェクトはビルドされません。

何か案は？私はこれで完全に間違った方向に進んでいますか？

動的言語（PythonまたはRuby）とコンパイル型言語を組み合わせたアプリケーションを構築することを検討しており、これが良いアイデアであると自分自身に納得させるための支援が必要です。

私の考えでは、動的言語を使用して大量のコードをすばやく記述し、c /c++などのコンパイル言語にドロップダウンしてパフォーマンスが重要なコードを実装できます。

このアプローチには多くの利点があります。

1. 主に動的言語でコーディングすることによる生産性の向上
2. 両方の言語からのライブラリの可用性

しかし、いくつかの欠点もあります。

1. 2つの言語間の架け橋を維持する
2. 1つではなく2つの言語と言語/ライブラリのバグへの依存

このアプローチの他の長所/短所は何ですか？誰かがこれに関するリソースやベストプラクティスについて知っていますか？

bigtabe/simpledb データベースとリレーショナル データベースはいつ使用しますか?

私は当初、このコード プロジェクトの記事で概説されている s# アーキテクチャの例に従ってシステムを設計しました(残念ながら、私は NHibernate を使用していません)。基本的な考え方は、永続化レイヤーと通信する必要があるドメイン オブジェクトごとに、対応するデータ アクセス オブジェクトを別のライブラリに持つというものです。各データ アクセス オブジェクトはインターフェイスを実装し、ドメイン オブジェクトがデータ アクセス メソッドにアクセスする必要がある場合、常にインターフェイスに対してコーディングし、DAO 自体に対してコーディングすることはありません。

当時も今も、このデザインは非常に柔軟だと思いました。しかし、ドメイン モデル内のオブジェクトの量が増えるにつれて、ここに組織上の問題がないか疑問に思うようになりました。たとえば、ドメイン内のほぼすべてのオブジェクトは、最終的に対応するデータ アクセス オブジェクトとデータ アクセス オブジェクト インターフェイスになります。それだけでなく、これらはそれぞれ別の場所にあるため、いくつかの名前空間をシフトするような単純なことをしたい場合、維持するのがより困難になります。

興味深いことに、これらの DAO (および対応するインターフェイス) の多くは非常に単純な生き物です。最も一般的なものには、GetById() メソッドが 1 つしかありません。私は次のようなたくさんのオブジェクトになってしまいます

それらの実装者も通常非常に些細なことです。これは、単純なデータ アクセス タスク用に 1 つのオブジェクトを用意し、もう少し何かを必要とするタスクのために専用のデータ アクセス オブジェクトの作成を予約することで戦略を切り替えることで、別の方向に進む方が簡単ではないかどうか疑問に思っています。複雑。

このようなアーキテクチャの経験がある人はいますか? 全体的に、これらすべての小さなファイルを管理することだけが私の関心事であるため、セットアップに非常に満足しています. しかし、データアクセスレイヤーを構築するための他のアプローチが存在するかどうかはまだ疑問に思っています。

たとえば Java や C# で、デスクトップ アプリケーションまたはスタンドアロン アプリケーションを作成するためのアーキテクチャ フレームワークがあるかどうか疑問に思っています。Web アプリケーションで利用できるリソースはたくさんあるようですが、デスクトップ開発のフレームワークやアーキテクチャのベスト プラクティスに関する優れたリソースはあまり見つかりません。

理想的には、優れたアーキテクチャを持っている、または特定のフレームワークで構築されていると見なされるデスクトップ アプリケーションのソース コードが利用できるかどうかを知りたいです。

更新:
これは私の最も多く寄せられる質問の 1 つですが、それでも自分のプロジェクトにとって満足のいく解決策はまだ見つかっていません。別の質問への回答で読んだ 1 つのアイデアは、リストから選択したプロジェクトのソリューションを「その場で」構築できるツールを作成することです。私はまだそれを試していません。

非常に大規模なアプリケーションをどのように構築しますか?

• 複数の小さなプロジェクト/アセンブリを 1 つの大きなソリューションにまとめていますか?
• いくつかの大きなプロジェクト？
• プロジェクトごとに 1 つのソリューションですか?

また、ソリューションが 1 つもない場合、依存関係をどのように管理しますか。注: Google で見つけた回答ではなく、経験に基づいたアドバイスを求めています (自分でできることです)。

私は現在、80 以上の dll を持つアプリケーションに取り組んでおり、それぞれが独自のソリューションになっています。依存関係の管理はほぼフルタイムの仕事です。依存関係の dll をあちこちにコピーするための機能が追加されたカスタムの社内 'ソース管理' があります。私には次善の解決策のように思えますが、より良い方法はありますか? 80 のプロジェクトでソリューションに取り組むことは、実際にはかなり大雑把になると思います。

(コンテキスト: Web ではなく、winforms)

編集：（これが別の質問だと思う場合は、コメントを残してください）

以下の間に相互依存関係があるように私には思えます。

• アプリケーションのプロジェクト/ソリューション構造
• フォルダ/ファイル構造
• ソース管理の分岐構造 (分岐を使用する場合)

しかし、これらを分離して個別に検討することは非常に困難です。

ここで別の関連する質問をしました。