Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
見やすいプレゼン資料の作り方 - リニューアル増量版
書籍化し、12万部突破しました。 【SlideShare広告回避用】 https://www.docswell.com/s/morishige/K3MXPZ-howtodesignslides ・PDFは無料でダウンロードできます ・自己学習や勉強会などの目的でしたらご自由にお使いいただけます ・授業・研修への利用はフォーム( https://forms.gle/WwgXTT974xFW78mFA )にご報告ください ・記事への参考資料にする際は適切な出典明記をお願いいたします 【使っているフォントについて】 M+フォント「MigMix1P」です。こちらもメイリオ同様おすすめです。 フリーで使えます。 【個人HP】 > https://mocks.jp > 仕事のご依頼はこちらから 【書籍情報】 デザイン入門：https://amzn.asia/d/4WDsTI6 デザイン図鑑：https
Gitで操作を取り消す方法色々 | Yakst
コミットなどのGitの色々な操作を取り消すための方法。その操作が必要になる場面と、方法、その仕組みと意味合いまで丁寧な説明。GitHub社のブログから。 あらゆるバージョン管理システムの最も便利な機能の1つに、間違いを「取り消す(undoする)」ことができるというのがあります。Gitにおいては、「取り消す」という言葉には少しずつ異なる様々な意味合いがあります。 新しいコミットをすると、ある時点におけるあなたのリポジトリのスナップショットをGitが保存します。それにより、後からあなたのプロジェクトを以前の状態に戻すのにGitを使うことができるわけです。 この記事では、あなたの変更を「取り消し」たくなるだろうよくあるシナリオを提示して、そのためにうまい具合にGitを使えるような方法を取り上げようと思います。 「パブリックな」変更を取り消す シナリオ : git pushを実行してGitHubに
MySQL 5.7で削除または廃止予定となる機能について (MySQL Server Blogより) | Yakst
免責事項 この記事はErlend Dahl氏によるMySQL Server Blogの投稿(2015/6/17)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 5.7の最初のリリース候補版(RC)のリリースから、次のサーバーのメジャーバージョンが急速に形になってきています。5.6がGAとなってからおよそ2年半にわたって、巨大な製品とコードベースを開発し維持する負担を軽減する為に、サーバーのコードの効率化に取組んできました。 この仕事の重要なところは、廃止予定(deprecation)と削除(removal)です。 機能を廃止予定とする(deprecating)ということは、我々が外部に「この機能は現在のところ利用可能である一方、将来のリリースで廃止されるため、利用の仕方にあわせて適応して欲しい」とお知らせしていることになります。機能を削除する(removi
今更ながら MySQL の HASH / KEY パーティショニングについて調べてみた。 - CARTA TECH BLOG
こんにちは、ECナビ事業本部の佐々木です。 今回は、MySQLのパーティション周りについて書きたいと思います。 ただ「いまさらパーティションの話？」と言われてしまうとそれまでなのですが、それぞれにタイプによりどう違うがあるのか曖昧な部分もあり、改めて調べてみようかと思った次第です。 では、調べていくに当たり、まずは MySQLのパーティショニングタイプについて、軽くふれておきます。 大まかな種類としては、以下。 HASH カラム値またはカラム値に対してユーザ定義式から整数結果を算出し、パーティションを選択する。 KEY 指定カラム/カラムセットに対してMySQLで提供される関数を使って整数結果を算出し、パーティションを選択する RANGE 範囲によってパーティションの選択をする。例えば、～2015年, ～2016年, ～2017年 ... といった年数で分ける場合など。 LIST 連続しな
大規模分散システムの現在 -- Twitter
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
app serverがリクエストの処理にかかった時間をログに記録する
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
エンジニアのための英語
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
nginx連載5回目: nginxの設定、その3 - locationディレクティブ
locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致（"=", "^~", プレフィックスなし）の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現（"~", "~*"）の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意
Shibuya.pm#17でnginxの話をしました - 考える人、コードを書く人
speakerdeck.com Shibuya Perl Mongersテクニカルトーク#17にお呼ばれしたのでnginxの話をしました。(なんとShibuya.pmは初参加です) 発表直後にちょっと私事でバタバタした関係であまり集中して他の方の発表を聞くことができなかったのが少し残念ですが、 あらためてh2oすごいなーって思った一日でした。 HTTP/2やSPDYのprioritizationについては僕は元々少々懐疑的で「これ、自分でチューニングしたくないなぁ」と思っていたのですが、なるほど、サーバ側で全部やってしまうのもアリかと思った次第です。 あと、発表の最後でも軽く触れましたがYAPC::Asia Tokyo 2015に実践nginxモジュール開発〜CとLua〜というトークで応募しています。採択されたらngx_small_lightやngx_dynamic_upstreamの開発
HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY
HTTP/2 (and H2O) improves user experience over HTTP/1.1 or SPDY HTTP/2 is expected to offer better user experience than HTTP/1.1, the unanswered question is how much the benefit is in practice. Tonight I have given a presentation regarding the issue, showing HTTP/2 performance of H2O HTTP server at shibuya.pm, a popular technology meetup at Tokyo. This blog post is a summary of the presentation at
RiotJs
Emergencies wait for no one, which is why bad credit is available 24 hours a day, 7 days a week. Instead of waiting for your bank or credit union to submit your loan application, the online loan networks listed below can process your application in minutes. If you are eligible, you can choose from several […]
GitBucket 3.3をリリースしました - たけぞう瀕死ブログ
Scalaで実装されたオープンソースのGitHubクローン、GitBucket 3.3をリリースしました。 https://github.com/takezoe/gitbucket/releases/tag/3.3 今回はリポジトリビューアに様々な新機能が追加されています。これらのほとんどは@nazokingさんにプルリクエストしていただいたものです。いつもありがとうございます。 画像の差分表示 画像ファルに対してリッチな差分表示を行えるようになりました。 ファイル検索 リポジトリビューアでファイルのインクリメンタル検索を行えるようになりました。GitHub同様、tでのキーボードショートカットも有効です。 Blameの表示 ソースビューアでBlameを表示できるようになりました。 この他にも、バグ修正に加え、以下のような改善を行っています。 ユーザの削除時にユーザのデータやリポジトリを削除
MySQLはドキュメントデータベースの夢を見るか - rkajiyama’s diary
MySQL 5.7.7 Release Candidateと同時にLabs(実験室)版としてMySQL JSONがリリースされました。MySQL JSONでは新しいデータ型としてJSON型をサポートしています。JSON型は格納されるデータ形式が正しいかを自動的にチェックするDocument Validationを持ち、またJSONドキュメントをバイナリ化して格納することで参照性能の向上を図っています。またMySQL 5.7.6で実装されたGenerated Column(生成列)を活用することで、functional indexes(関数インデックス)の形でインデックスを利用できます。 関連情報(MySQL Server Teamブログ)： 機能概要 JSON Labs Release: Native JSON Data Type and Binary Format | MySQL Ser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Life with IT
クックパッドはなぜ開発しやすいのか // Speaker Deck
MySQLのバックアップ運用について色々
https://takezoe.github.io/gitbuckethttps://takezoe.github.io/gitbucket/gitbucket/2015/05/31/gitbucket-3.3.html