問題タブ [system-design]

一部のデータを監視する SQL アラーム システムを実装しています。

このアラーム システムは基本的に、返された出力エラー コードに基づいてアラームをトリガーするストアド プロシージャを呼び出します。

例：

@ErrorCode = -100 ==>トリガー アラーム

@ErrorCode = 0 ==>何もしない

アラームがトリガーされると、データベースに移動し、ユーザーと、ユーザーに送信する必要があるメッセージを取得します。

送信されるメッセージには、そのアラームをトリガーしたストアド プロシージャに基づいてデータベースから取得する必要があるデータが含まれています。元：

*メッセージ1 :

ユーザーの皆様

%ServiceName%のコンテンツは%NbrOfDays%日 後に終了します。*

*メッセージ 2 :

ユーザーの皆様

今日の購読者数は%NbrOFSubscribers%*です

ご覧のとおり、必要なデータはメッセージごとに動的であり、アラームをトリガーするストアド プロシージャによって異なります。

ストアド プロシージャからデータを取得し、メッセージ内の動的な値に置き換えるために使用する必要があるもの ( %ServiceName%、%NbrOfDays%、%NbrOFSubscribers%)

私の考えの 1 つは、それらを XML 出力パラメーターとして返すことでした。以下のように置き換えます。

約 1000 台のマシンがセンサーからデータを生成し、それを中央システムに送信して SQL テーブルに格納する必要があるシステムがあるとします。

私の質問は、各システムをデータベースに直接接続してデータを挿入する (これが必要な唯一の操作です) か、または ie. HornetQ からのデータを消費し、データベース システムに書き込むソフトウェアの単一 (または少数) のインスタンスがありますか?

特にシステムのサーバー側 (つまり、多くのクライアントを処理するように設計されたデータベース システム) で、CPU/メモリのコストとスケーラビリティの点で 2 つのアプローチを比較する方法を知りたいです。

もともとは小さなプロジェクトで、わずか 150 個のアカウントに対して、Python で小さなタスクを実行するためのセレン プログラムを作成しました。1 台のコンピュータを使用し、約 5 時間かかりました。ただし、現在は 1000 アカウントまで拡大することを検討しています。明らかな理由から、1 台のコンピューターでこれを実行したくありません。このタスクは 1 日に 1 回実行する必要があり、1 台のコンピューターでこのタスクを完了するには、明らかに約 30 ～ 35 時間かかります。複数のマシンを使用したいのですが、3 つ、4 つ、またはそれ以上に簡単に拡張できるオプションも必要です。

すべてのアカウントのデータを amazon クラウド データベースに移動したので、python プログラムから簡単に接続できます。ただし、前述したように、このプロジェクトを簡単に拡張できるようにしたいと考えています。値をハードコーディングしたくありません。つまり、1 台のコンピューターでアカウント 1 ～ 500 を実行し、もう 1 台のコンピューターで 501 ～ 1000 を実行します (さらに 500 個のアカウントと 2 台のマシンを追加するとどうなるでしょうか? 各マシンに 1500/4 を実行させたいと思います)。マスタースレーブのアプローチを考えています。各マシンのどこに、いくつかのアカウントを配列として呼び出すことができるプログラムがあります。そして、私のマシンで実行されるマスター プログラムは、24 時間に 1 回、各マシンが使用するはずのアカウントを含むコマンドを送信できます。

次に、プログラムにデータを返してもらい、各スレーブが終了すると、マスタープログラムは各スレーブから返されたデータを結合し、それに応じてテーブルを更新します。または、各スレーブがテーブルを個別に更新しますが、テーブルロックが原因でこれが可能かどうかはわかりません (誰かがこれについてコメントできれば、それも役に立ちます)

読んでくれてありがとう！

編集：これが広すぎると思われる場合は、正確な答えを探しているわけではありません. 以前にこのようなことをした人を見つけようとしているだけです。私が研究できるテクノロジーやこれを行う方法をリストするだけで、大いに役立ちます

これは、Google のインタビューで尋ねられたシステム設計に関する質問です。インタビュアーは、Google ドキュメントをサポートするシステムを設計したいと考えています。複数の人が同時にドキュメントを編集し、ローカル マシンで編集する経験を積むことができます。

ファイルのブロックを生成する複数のスレッドがある場合、ブロックを書き出す最善の方法は何ですか?

例) 500 ブロックのファイルで作業する 5 つのスレッド。ブロック 0 は必ずしもブロック 1 の前に完了するとは限りませんが、ディスク上の出力ファイルは順序どおりである必要があります。(ブロック 0、ブロック 1、ブロック 2、.... ブロック 499)

プログラムは C++ で書かれていますが、fwrite() でファイルに「ランダム アクセス」することはできますか? ファイルはゼロから作成されます。つまり、ブロック 5 が完了しても、ブロック 1 ～ 4 がまだ完了していないため、ファイルのサイズはまだ 0 のままである可​​能性があります。ブロック 5 を直接書き出すことはできますか? （適切なfseekを使用）

このコードはパフォーマンスが重要なので、パフォーマンスを改善できるものには本当に興味があります。これは、複数のプロデューサー (ブロック ジェネレーター) と 1 つのコンシューマー (出力ライター) のシナリオのように見えます。理想的なケースは、スレッド A が前のブロックを完了したときに、次のブロックを生成し続けることができるということです。

fwrite を「ランダム」にできる場合、出力ライターは単純に出力を取得し、シークしてから書き込むことができます。ただし、この設計が大規模でうまく機能するかどうかはわかりません。

いくつかの制限

• 各ブロックは同じサイズで、メモリ内に生成されます
• ブロック サイズは事前にわかっていますが、ブロックの総数はわかっていません。
• 合計サイズは数 GB です。大きい。
• 1 つのサーバーで複数のジョブが実行されている可能性があります。各ジョブは上記で説明されています。それらには、独自の独立したジェネレーター/ライター、異なるプロセスがあります。
• サーバーは Linux/CentOS マシンです。

Web サイトの既存のコメント セクションに、Facebook に似た Like/Unlike システムを作成しようとしていますが、システムの設計に助けが必要です。

現在、ウェブサイトのすべての製品にはコメント セクションがあり、メンバーはコメントを投稿したり、気に入ったりすることができます。各メンバーが投稿したコメントの数と、各メンバーの各コメントがいいね! を獲得した数を知る必要があります。もちろん、分析目的で、誰がどのコメントを気に入ったかを知る必要があります (一部は、ユーザーが同じコメントを複数回気に入らないようにするためです)。

Like システムを現在のコメント モジュールに実装する単純な方法は、CommentID と UserID への外部キーを持つ新しいテーブルをデータベースに作成することです。次に、ユーザーがコメントに「いいね」を付けるたびに、ターゲット コメント ID とユーザー ID を含む行をこの新しいテーブルに挿入します。

これはうまくいくかもしれませんが、膨大な量のコメントとユーザーがこのテーブルを急速に拡大させ、この巨大なテーブルからレコードを取得したりカウントしたりするのは遅くなり、非効率的になります。いずれかの列にインデックスを付けることができますが、それがどれほど効果的かはわかりません。ウェブサイトには10​​0万件以上のコメントがあります。

PHPとMySQLを使用しています。巨大なデータベースを持つこのようなシステムの場合、Like システムをより最適化して安定させるには、どのように設計すればよいでしょうか?

これをここに投稿しても問題ないことを願っています。私は、システム設計とアーキテクチャのインタビューの質問/アイデアのサンプルを誰かが共有できるかどうか疑問に思っていました. (単純にハイスコアを保存し、現在の推測ワードを提供するサーバーを備えたハングマンのように) 面接が迫っていますが、フルスタックのソフトウェア エンジニア ロールなので、それぞれ 3 分 45 分のシステム設計とアーキテクチャの質問が求められます。重いクライアント コンポーネントを持つアプリを設計し、クライアント/サーバーの関係も確認します。

また、アプローチ方法やホワイト ボード上での表示方法について共有できる情報があれば、ぜひ参考にしてください。私はよりサーバー集約的な設計を描くことに満足していますが、クライアント側のアーキテクチャ/システムを描く方法について少し混乱しています。

ありがとう！