【図解】初心者が知っておきたいサーバ周りの仕組みの話 - Qiita
※2021年 3月28日 更新※ たくさんの方にご一読いただき、ありがとうございます。お読みいただいた方からご指摘を賜った点をもとに記事を修正いたしました。修正・追記箇所は末尾をご確認ください。 サーバ周りの仕組みについて、初心者でも最低限知っておくべきだと感じた内容を整理しています。 ここでいう「最低限」とは、プログラミング言語を勉強し、何かしらアプリケーションを作成して、ユーザが利用可能な状態にし（デプロイ）、公開するうえで必要になる知識のことです。 「サーバ」とは何か ユーザの要求（リクエスト）に応じて、サービスを提供（レスポンス）するコンピュータやプログラムのことを「サーバ」と言います。 例えば、ユーザが「このWebページを閲覧したい」とリクエストしたら、サーバはそのWebページの表示に必要な処理を実行し、ユーザに返します。これによってユーザが使用しているブラウザに、Webページが
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
本当にあったやらかしDB設計シリーズ一覧 - Qiita
本当にあったやらかしDB設計シリーズをまとめてみました SQLアンチパターンで書かれているほど高尚な問題ではなく、もっと初歩的な、でもありがちな問題を取り上げています 初心者を脱出したと思っている人に是非読んでもらい、正しく設計してもらうことを目的としています もしここに載っていないパターンを経験したことのある方がいたら是非教えてください 本当にあったやらかしDB設計①【R無しRDB】 本当にあったやらかしDB設計②【囚人番号テーブル】 本当にあったやらかしDB設計③【ロジカルクエリー】 本当にあったやらかしDB設計④【テストチューニング】 本当にあったやらかしDB設計⑤【第三正規化病】 本当にあったやらかしDB設計⑥【見えない削除フラグ】 本当にあったやらかしDB設計⑦【ステートフルDB】 本当にあったやらかしDB設計⑧【ファンクションDB】 本当にあったやらかしDB設計⑨【文字列日付】
ポケモンを題材に「SQLアンチパターン」を実践してみる - kanayamaのブログ
@tkanayama_です。「SQLアンチパターン *1」 という本を読みました。「ポケモンを題材に因果推論を実践してみる」のように、仮想的なストーリ上で実際に使ってみた感を出すことにより、自分の記憶に定着させることを狙います。 前提として、何をアンチパターンとするかは状況（ベンダーフリーである必要があるかどうか、どの程度の頻度で更新されるか・・・など）によって大きく異なるので、下記で紹介するアンチパターンは実は状況によっては問題にならないケースもあるかと思います。この投稿はあくまで「SQLアンチパターン」に忠実に従うことが目的です。 www.oreilly.co.jp 追記 登場人物 ストーリー フシギダネへの対応 ヤミカラスへの対応 ディグダへの対応 誤登録でポケモントレーナーになってしまったユーザーの削除 最後に 謝辞 追記 このブログを公開後、「外部キー制約はレコードロック周りのト
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
Sequel Proを超えるGUIツールが出てきたぞ
悲報 2019年6月26日現在、TeamSQLのサポートがなくなってしまったようでダウンロードできなくなくなりました。。 TeamSQL has retired and is not available for download anymore. 今までSequel Proを重宝してきましたが、それを超えるGUIツールが出てきました。 その名も、TeamSQL 現状サポートしているものだけでもかなり豊富 今後、elasticやmongoDBにも対応されるようです。 機能 クエリ保存 履歴保持 ファイル出力 抽出した結果をボタン１つでcsvやjson形式に保存可能。 共有 データをエクスポートしなくても共有が可能。 グループの作成が可能なため、特定のユーザー同士で簡単に共有ができるとこがメリット。 可視化 様々なチャートでクエリの可視化が可能。 そのままイメージとして保存も可能。 テーマ選択
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
非エンジニアが最速でSQLをマスターする方法 - Gunosy Tech Blog
こんにちは、データ分析部の石塚です。 Gunosyではエンジニア以外の職種でもSQLを叩いて自らデータを集計・分析するという習慣と全社員が各サービスのログ*1に触ることができる環境があります。 例えば、ユーザー獲得を担っているプロモーションチームはエンジニアが0名のチームなのですが、実際にSQLを叩いています。 それによって、自分たちの獲得したユーザーはどのような行動をしているのかを確認したり、分析することができています。 これはGunosyのみの事例ではなく、AWSのRedshiftやAthena、GCPのBigQueryが台頭してきたおかげで、どの会社も低コストにログをSQLで集計・分析できる基盤が整ってきています。 個人的にはアプリやウェブの業界で働くマーケターにはSQLは必須の知識と言える時代になってきたと感じています。 そこで今回は特別プログラミングなどの経験が無い人でも、SQL
本当は恐ろしい分散システムの話
2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープラ
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
秒間100万クエリを受け付ける大規模ソーシャルゲームのバックエンドDBシステムの設計・運用ノウハウ
2016/08/26 CEDEC 2016
若手プログラマー必読！５分で理解できるER図の書き方５ステップ
データベース設計の基本中の基本であるER図。ER図を書きたいけど、「記法が分からない」「どういうステップで書けば良いか分からない」という若手エンジニアも多いのではないでしょうか。 ER図は１０種類近くあり、種類によって記法が異なります。このことが難しいイメージを与えていますが、実はそれほど難しいものではありません。覚えれば良いER図は２種類だけです。 しかも、この記事で解説している基礎知識を押えれば、たった５つのステップで作成することができます。 この記事では、ER図の基礎知識からER図の書き方まで、エンジニアが抑えておくべきER図の全知識をどこよりも分かりやすく解説します。 この記事を読み終えたとき、若手エンジニアもER図を書けるようになっているでしょう。 この記事を参考に最適なデータベース設計を進めて下さい。 １．ER図とは ER図とは、「データベース設計（データモデリング）で使う設計
今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた | PLAID engineer blog
今回は、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。
個人のスマホアプリ開発者がParseを使うべき15の理由 - Qiita
注意(2016/01/29追記) Parseサービスの終了が発表されました。 利用できるのは2017/01/28までだということです。 Facebook Shutters Its Parse Developer Platform | TechCrunch http://techcrunch.com/2016/01/28/facebook-shutters-its-parse-developer-platform/ Moving On http://blog.parse.com/announcements/moving-on/ こんなに便利なサービスが終了してしまうのは残念でなりません。。 (一応ParseサーバーとMongoDBのマイグレーションツールが公開されるということなので 自前サーバーで管理すればParseと同じようなものを動作させることは可能かもしれません。) 背景 最近個人で掲
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴を持つデータの設計
ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城
ついに解禁！Amazon Aurora徹底検証！
