1000万ユーザに耐えるサーバを作ってみた
概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
CyberZ が Amazon DynamoDB を使用してフォロータイムラインの表示に必要な Read-Light 方式を実現した方法 | Amazon Web Services
Amazon Web Services ブログ CyberZ が Amazon DynamoDB を使用してフォロータイムラインの表示に必要な Read-Light 方式を実現した方法 CyberZ について CyberZ はスマートフォンに特化した広告マーケティング会社として 2009 年に設立しました。スマートフォン広告における運用・効果検証、交通広告やウェブ CM の制作など、幅広いマーケティング事業を展開しています。日本に加えて、サンフランシスコ、韓国、台湾にも支社を構え、国内広告主の海外進出および海外広告主の日本展開支援も行っています。また、メディア事業として動画配信プラットフォーム「 OPENREC.tv 」、 e スポーツ事業として、国内最大級のeスポーツイベント「 RAGE 」を運営しています。 CyberZ 100 % 子会社としては、オンラインエンタテインメント事業、プ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
【DOAコラム】-更新と履歴
ビジネスシステムのデータファイルやデータベースのテーブルに、「～履歴」と言う名前が付いている事があります。 同様に、データモデルにも、「～履歴」と名前が付いた、ビジネス要素が表現されていることがあります。 履歴と言うからには、当初登録された情報に、何がしかの変更があったので、その変更前の情報を維持することを目的として、わざわざ該当のデータを移し替えるために、別のファイルやテーブルを作ります。 売上履歴マスター・受注履歴ファイル・契約変更履歴テーブルなどが、それにあたり、それぞれ、売上・受注・契約の内容が変更されたり、キャンセルされた場合に、元の売上・受注・契約の情報を保持します。 ところが、これが、キャンセル履歴ファイル、とか、督促履歴テーブルなど、本来、常識的にはあまり件数が発生しないはずのビジネスイベント（ここで言う「キャンセル」・「督促」がそれです）を名称に含んでいる場合には、なぜか
履歴を持ったテーブルの設計 - Qiita
概要 データベースの設計や不具合の調査をしていて、ふと思ったことは無いでしょうか？ ログやバックアップに頼らずに、データベースに全ての変更履歴が残るようにできないだろうか、と。 試しに、設計してみるとFOREIGN KEY制約を保ちながら履歴を持ったテーブルを設計するというのは、なかなか厄介なことに気づきます。 しかし、突飛なアイディアという訳ではなく、ネット検索してみると結構ヒットします。 変更履歴を持つテーブルの設計 履歴テーブルからデータを取得するSQL リレーショナルデータベースでは履歴の管理をすべきでない？ データベース設計 ～ マスタデータを含めて、全ての履歴を残したいという要望 先人の試行錯誤を自分なりに咀嚼して、設計してみた方法を文章として残して置こうかと思います。（※実際のプロジェクトに適用してみた気付きを加筆しました） 設計方針 履歴を持つことに意味のあるテーブルのみを
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴を持つデータの設計