MySQL JOIN Types Poster - Steve Stedman
So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S
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設計⑨【文字列日付】
イミュータブルデータモデル(入門編)
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
GitHub - amacneil/dbmate: :rocket: A lightweight, framework-agnostic database migration tool.
Dbmate is a database migration tool that will keep your database schema in sync across multiple developers and your production servers. It is a standalone command line tool that can be used with Go, Node.js, Python, Ruby, PHP, or any other language or framework you are using to write database-backed applications. This is especially helpful if you are writing multiple services in different language
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
【DOAコラム】-更新と履歴
ビジネスシステムのデータファイルやデータベースのテーブルに、「～履歴」と言う名前が付いている事があります。 同様に、データモデルにも、「～履歴」と名前が付いた、ビジネス要素が表現されていることがあります。 履歴と言うからには、当初登録された情報に、何がしかの変更があったので、その変更前の情報を維持することを目的として、わざわざ該当のデータを移し替えるために、別のファイルやテーブルを作ります。 売上履歴マスター・受注履歴ファイル・契約変更履歴テーブルなどが、それにあたり、それぞれ、売上・受注・契約の内容が変更されたり、キャンセルされた場合に、元の売上・受注・契約の情報を保持します。 ところが、これが、キャンセル履歴ファイル、とか、督促履歴テーブルなど、本来、常識的にはあまり件数が発生しないはずのビジネスイベント（ここで言う「キャンセル」・「督促」がそれです）を名称に含んでいる場合には、なぜか
履歴を持ったテーブルの設計 - Qiita
概要 データベースの設計や不具合の調査をしていて、ふと思ったことは無いでしょうか？ ログやバックアップに頼らずに、データベースに全ての変更履歴が残るようにできないだろうか、と。 試しに、設計してみるとFOREIGN KEY制約を保ちながら履歴を持ったテーブルを設計するというのは、なかなか厄介なことに気づきます。 しかし、突飛なアイディアという訳ではなく、ネット検索してみると結構ヒットします。 変更履歴を持つテーブルの設計 履歴テーブルからデータを取得するSQL リレーショナルデータベースでは履歴の管理をすべきでない？ データベース設計 ～ マスタデータを含めて、全ての履歴を残したいという要望 先人の試行錯誤を自分なりに咀嚼して、設計してみた方法を文章として残して置こうかと思います。（※実際のプロジェクトに適用してみた気付きを加筆しました） 設計方針 履歴を持つことに意味のあるテーブルのみを
Goで作ったWEBアプリケーションの環境ごとの接続設定とテストをする - Qiita
driver: mysql development: user: root password: "" db: gorm production: user: hoge password: fuga db: gorm test: user: root password: "" db: gorm_test go-yamlのサンプルには予め型が決まったyamlの読み込みの方法が記述されていますが、map[interface{}]interface{}を使うと型を決めずに読み込めるようです。 詳しいやり方は下記にまとまっていますので、このまま使わせていただきます。 http://qiita.com/yamasaki-masahide/items/d6e406c4c11d5870a1c6 前回のmain.goを、go-yamlを使って任意の接続先を選択できるように書き換えます。 package mai
LevelDB入門 (基本編) - from scratch
さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持
iOS/Androidに対応したモバイルデータベース「Couchbase Mobile」正式版登場。無料のコミュニティ版も
iOS/Androidに対応したモバイルデータベース「Couchbase Mobile」正式版登場。無料のコミュニティ版も Couchbaseは、NoSQLデータベースの一種であるドキュメント指向のデータベースをサーバ向けに開発、展開していました。今回リリースされたCouchbase Mobileは、そのNoSQLデータベースのモバイル版である「Couchbase Lite」と、サーバ上で稼働しモバイルとサーバのデータベース同期を行う「Couchbase Sync Gateway」の2つから構成されています。 Couchbase Mobileは、昨年ベータ版として登場したときには「JSON Anywhere」という名称でしたが、正式版では「Couchbase Mobile」という名称になったようです。 オフラインでもデータベース利用が可能に Couchbase Liteはモバイル用のJSO
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴を持つデータの設計