見出し画像

インタビューの質問:デザインTwitter(エピソード5)

人気のある面接質問:プロセスとスレッドの違いは何ですか?

この質問を理解するために、まずプログラムとは何かを見てみましょう。プログラムは、一連の命令を含む実行可能ファイルであり、ディスク上にパッシブに保存されています。1つのプログラムには複数のプロセスが含まれることがあります。例えば、Chromeブラウザは各タブごとに異なるプロセスを作成します。

プロセスはプログラムが実行中であることを意味します。プログラムがメモリにロードされてアクティブになると、そのプログラムはプロセスになります。プロセスはレジスタ、プログラムカウンタ、スタックなどの必須リソースを必要とします。

スレッドはプロセス内での最小実行単位です。

以下のプロセスはプログラム、プロセス、スレッドの関係を説明します。

  1. プログラムは一連の命令を含んでいます。

  2. プログラムがメモリにロードされ、1つまたは複数の実行中のプロセスになります。

  3. プロセスが開始されると、メモリとリソースが割り当てられます。プロセスには1つまたは複数のスレッドが含まれます。例えば、Microsoft Wordアプリでは、1つのスレッドがスペルチェックを担当し、別のスレッドが文書へのテキスト挿入を担当します。

プロセスとスレッドの主な違い:

  • プロセスは通常独立していますが、スレッドはプロセスのサブセットとして存在します。

  • 各プロセスは独自のメモリ空間を持っています。同じプロセスに属するスレッドは同じメモリを共有します。

  • プロセスは重量級の操作です。作成と終了には時間がかかります。

  • プロセス間のコンテキストスイッチはより高価です。

  • スレッド間の通信はスレッドの方が速いです。

あなたへの質問:

  1. 一部のプログラミング言語はコルーチンをサポートしています。コルーチンとスレッドの違いは何ですか?

  2. Linuxで実行中のプロセスをリストする方法は?


面接質問:Twitterの設計

この投稿は、2013年に行われたTwitterのテックトークの要約です。見てみましょう。

ツイートの流れ

  1. ツイートはWrite APIを通じて送信されます。

  2. Write APIはリクエストをFanoutサービスにルーティングします。

  3. Fanoutサービスは多くの処理を行い、それらをRedisキャッシュに保存します。

  4. Timelineサービスがホームタイムラインが存在するRedisサーバーを見つけます。

  5. ユーザーはTimelineサービスを通じてホームタイムラインを取得します。

検索と発見

  • Ingester: ツイートを注釈付けし、トークン化してデータをインデックス化できるようにします。

  • Earlybird: 検索インデックスを保存します。

  • Blender: 検索と発見のタイムラインを作成します。

プッシュコンピュート

  • HTTPプッシュ

  • モバイルプッシュ

注意: この記事は2013年のTwitterのテックトークに基づいています(https://bit.ly/3vNfjRp)。数年が経過しても、依然として非常に関連性があります。元の図は読みづらいため、再描画しました。

あなたへの質問: Twitterを使用していますか?LinkedInとTwitterの主な違いは何ですか?それがシステムアーキテクチャにどのように影響するでしょうか?


正しいデータベースを選択するためのビジュアルガイド

データベースの選択は長期的なコミットメントですので、軽率に決定してはいけません。重要なのは、適切なジョブのために適切なデータベースを選ぶことです。

SQL vs NoSQL: チートシート(AWS、Azure、Google Cloud用)

データベースの種類と使用ケース

  1. 構造化データ

    • リレーショナル(ACIDトランザクション)

      • 使用ケース: トランザクション処理(OLTP)

      • AWS: RDS, Aurora

      • Azure: Azure SQL Database

      • Google Cloud: Cloud SQL, Cloud Spanner

      • クラウド非依存: SQL Server, Oracle, DB2, MySQL, PostgreSQL

    • カラム型(Analytics)

      • 使用ケース: データ解析(OLAP)

      • AWS: RedShift

      • Azure: Azure Synapse

      • Google Cloud: BigQuery

      • クラウド非依存: Snowflake, ClickHouse, Druid, Pinot, Databricks

  2. 辞書型データ

    • キーバリュー型(キャッシュ)

      • 使用ケース: キャッシュ

      • AWS: DynamoDB

      • Azure: Cosmos DB

      • Google Cloud: BigTable

      • クラウド非依存: Redis, ScyllaDB, Ignite

    • インメモリ

      • 使用ケース: 高速アクセスキャッシュ

      • AWS: ElastiCache

      • Azure: Azure Cache for Redis

      • Google Cloud: Memorystore

      • クラウド非依存: Redis, Memcached, Hazelcast, Ignite

    • 2次元キーバリュー

      • 使用ケース: タイムシリーズ、監査記録

      • AWS: Keyspaces, Timestream

      • Azure: Cosmos DB

      • Google Cloud: BigTable, BigQuery

      • クラウド非依存: HBase, Cassandra, ScyllaDB

  3. 半構造化データ

    • イミュータブルレジャー(不変の元帳)

      • 使用ケース: 監査記録、タイムシリーズ

      • AWS: Quantum Ledger Database (QLDB)

      • Azure: Azure SQL Database Ledger

      • Google Cloud: 対応なし

      • クラウド非依存: Hyperledger Fabric

    • 地理空間データ

      • 使用ケース: ロケーションベースサービス

      • AWS: Keyspaces

      • Azure: Cosmos DB

      • Google Cloud: BigTable, BigQuery

      • クラウド非依存: OpenTSDB, InfluxDB, ScyllaDB

    • グラフデータベース

      • 使用ケース: エンティティ間の関係性

      • AWS: Neptune

      • Azure: Cosmos DB

      • Google Cloud: JanusGraph + BigTable

      • クラウド非依存: OrientDB, Neo4j, Giraph

    • ドキュメントデータベース

      • 使用ケース: JSON、XMLデータ

      • AWS: Document DB

      • Azure: Cosmos DB

      • Google Cloud: Firestore

      • クラウド非依存: MongoDB, Couchbase, Solr

    • テキスト検索データベース

      • 使用ケース: テキスト検索

      • AWS: OpenSearch, CloudSearch

      • Azure: Cognitive Search

      • Google Cloud: Search APIs on Datastores

      • クラウド非依存: ElasticSearch, Solr, Cassandra

    • バイナリラージオブジェクト(BLOB)

      • 使用ケース: 画像、音声、動画データ

      • AWS: S3

      • Azure: Blob Storage

      • Google Cloud: Cloud Storage

      • クラウド非依存: HDFS, MinIO

SQL vs. NoSQL Database: When to Use, How to Choose

このチートシートを使って、異なるクラウドサービスプロバイダーが提供するSQLおよびNoSQLデータベースの違いとその使用ケースを簡単に比較できます。

一般的なデータベースカテゴリ:

  • リレーショナル

  • カラム型

  • キーバリュー型

  • インメモリ

  • ワイドカラム

  • タイムシリーズ

  • イミュータブルレジャー

  • 地理空間

  • グラフ

  • ドキュメント

  • テキスト検索

  • バイナリラージオブジェクト(BLOB)

あなたへの質問: どのデータベースをどのワークロードに使用しましたか?


ユニークIDジェネレーター

IDはバックエンドで非常に重要です。グローバルにユニークなIDを生成する方法を知っていますか?

この投稿では、Facebook、Twitter、LinkedInなどのソーシャルメディアで使用されるIDに関する一般的な要件を探ります。

要件:

  • グローバルにユニーク

  • 時間によって大まかにソートされる

  • 数値のみ

  • 64ビット

  • 高スケーラビリティ、低レイテンシ

以下は、ソーシャルメディアでよく使われるID生成アルゴリズムの要件と一般的な解決策です。

一般的な解決策

  • DB自動インクリメント: 簡単に設定できるが、単一サーバー設定でのみ動作。

  • UUID: グローバルにユニークだが、数値ではなく非常に長い。

  • DBチケットサーバー: 単一サーバー使用の場合、単一障害点(SPOF)が存在。

  • Redis: DBに依存しないが、Redisサーバーの追加や削除が複雑化する可能性。

  • Twitter Snowflake ID: 広く使われている業界標準。

上記の情報を基に、異なるクラウドサービスプロバイダーが提供するSQLおよびNoSQLデータベースの違いとその使用ケースを比較できます。

参照元


いいなと思ったら応援しよう!

川村康弘(Yasuhiro Kawamura、Ted)@クラウド屋
おもしろきこともなき世を面白く 議論メシ4期生http://gironmeshi.net/ メンタリストDaiGo弟子 強みほがらかさと発散思考 外資系企業でインフラエンジニア