【PHP】指定時間前や指定時間後の日時を求めるの「注意」にあるように、日時によっては正確な月を取得できない場合があります。
※指定日時は「2014-03-31」
$startDate = date("Y-m-01", strtotime("-1 month"));
→2014-03-01
$endDate = date("Y-m-t", strtotime("-1 month"));
→2014-03-31
「2014-03-31」の1ヶ月前は「2014-02-31」
そんなもんねーよ、ってことで「2014-03-01」として扱われる
月末ではなく初日を基準にして計算すること
$targetDay = date("Y-m-01", time());
$startDate = date("Y-m-01", strtotime($targetDay . "-1 month"));
$endDate = date("Y-m-t", strtotime($targetDay . "-1 month"));
参考
http://ysklog.net/php/2095.html
2015年3月31日火曜日
2015年3月16日月曜日
DBまとめ2:ACID特性
トランザクションは，次の4つの特性をすべて保証しなければなりません。
原子性(Atomicity)
トランザクションは，すべてが完全に実行されるか，全く実行されないかどちらかです。つまり，トランザクションを構成する「一連の処理」は，これ以上分割できない最小単位です。
一貫性(Consistency)
トランザクションの開始時と終了時で，データが整合性を保っていなければなりません。データは以前の「有効な状態」から新しい「有効な状態」に変化します。
隔離性(Isolation)
複数のトランザクションを同時に並行して実行しても，終了するまでトランザクション同士はお互いに干渉しません（あるトランザクションからほかのトランザクションは見えません。あるいは，ほかのトランザクションの影響を受けません）。
持続性(Durability)
トランザクションが正常に終了した結果は必ず「永続化」され，障害によって失われることはありません。
これらの「トランザクション特性」のことを，頭文字を取って「ACID」（アシッド）と呼び，ACIDを満たすトランザクションを「ACIDトラ ンザクション」と言います。逆に言うと，この特性に当てはまる業務処理をシステムで実装する場合に，トランザクションの機能を利用するメリットを享受でき るのです。この4つをすべてクリアした場合，「トランザクション特性」を満たすと言います。
http://itpro.nikkeibp.co.jp/article/lecture/20070528/272630/
原子性(Atomicity)
トランザクションは，すべてが完全に実行されるか，全く実行されないかどちらかです。つまり，トランザクションを構成する「一連の処理」は，これ以上分割できない最小単位です。
一貫性(Consistency)
トランザクションの開始時と終了時で，データが整合性を保っていなければなりません。データは以前の「有効な状態」から新しい「有効な状態」に変化します。
隔離性(Isolation)
複数のトランザクションを同時に並行して実行しても，終了するまでトランザクション同士はお互いに干渉しません（あるトランザクションからほかのトランザクションは見えません。あるいは，ほかのトランザクションの影響を受けません）。
持続性(Durability)
トランザクションが正常に終了した結果は必ず「永続化」され，障害によって失われることはありません。
これらの「トランザクション特性」のことを，頭文字を取って「ACID」（アシッド）と呼び，ACIDを満たすトランザクションを「ACIDトラ ンザクション」と言います。逆に言うと，この特性に当てはまる業務処理をシステムで実装する場合に，トランザクションの機能を利用するメリットを享受でき るのです。この4つをすべてクリアした場合，「トランザクション特性」を満たすと言います。
http://itpro.nikkeibp.co.jp/article/lecture/20070528/272630/
DBまとめ1:分散Key-Valueストア
クラウド時代のデータベース「分散Key-Valueストア」
グーグルがインターネットの世界をここまで席けんできた最大の理由検索技術ではなく、同社が生み出した巨大な分散データストア、「Bigtable」にあります。
Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Google App Engineなど、グーグルの70以上のプロジェクトの基盤として利用されています。合計で数PB（ペタバイト）に達する天文学的規模のデータを、全世界 36カ所以上のデータセンターに配置された数万〜数十万台のサーバに分散して格納し、これらグーグルの各種サービスの圧倒的なスケーラビリティと高可用性 を低コストで実現しています。
Bigtableは、リレーショナルデータベース（以下、RDB）ではなく、いわゆる「分散Key-Value Store（以下、KVS）」の1つです。KVSは、プログラミング言語の連想配列やMapと同様に「Key（キー）」と「Value（値）」のペアからなる、ごくシンプルなデータモデルに基づくデータストアです。KVSは「キー・バリュー型データストア」「Key/Valueストア」などと呼ばれることもあります。
分散KVSが苦手なトランザクションの「ACID特性」
RDBのように、テーブルとテーブルを結合（SQLでいうJOIN文）して複雑な条件検索や集計処理を一発でこなすような芸当はできません。また、トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。RDBが不得意な分散／拡張
そのため、これらの不足をアプリケーション側で補うためのさまざまな工夫やフォローが必要となります。その一方で、分散KVSはデータストア全体をいくらでも多くのサーバに分散（スケールアウト）できるのが最大の特徴です。一方でこれは、RDBが最も不得意とするところです。RDBでは、その長所であるテーブル結合やACIDの確保がボトルネックとなり、複数のサー バにスケールアウトさせることが「原理的」に容易ではありません。そのため、負荷分散や高可用性を低コストで実現することが困難です。
RDBで負荷分散させようとすると……
例えばMySQLを使う場合、1テーブルのレコード件数が数百万〜数千万件を超えるような規模になると、1台のDBサーバだけでは実用的なパ フォーマンスが達成しにくくなります。そこで一般には、以下のような対策によってRDBのスケーラビリティを引き上げる努力が必要となります。- RDBサーバのスケールアップ（大型サーバへの載せ替え）
- DBのレプリケーションやシャード（パーティション）分割によるクラスタ構築
- 分散キャッシュ（Oracle RACやmemcachedなど）によるクラスタ構築
■利点その【1】負荷分散や可用性に悩まないでいい！負荷分散や可用性に悩まないでいい！
まず、実用上は制限のないスケーラビリティのおかげで、「負荷分散や可用性のことで悩んだりコストを掛けたりする必要があまりなくなる」ということです。
■利点その【2】データを効率よく集約できる！データを効率よく集約できる！
そしてもう1つの、かつ最も重要な利点は、「アプリケーションの分散化対応によって、クラウドによる全体最適のメリットを享受できる」ことです。
例えるなら、「一戸建て」と「タコ部屋」である
これは例えるなら、独立した仮想マシンやOS、DBインスタンスを占有していた「一戸建て」の環境を捨て、100人くらいで1つの部屋を共有する「タコ部屋」に入居するようなものです。このタコ部屋では、分散KVSという使いにくい収納しかありません。http://www.atmarkit.co.jp/ait/articles/0907/02/news101.html
2015年2月21日土曜日
良くある備忘録1:リダイレクト・フォワード
○基本
【モジュール名】/【コントローラ名】/【アクション名】.phtml
別のアクションのテンプレートを読み込む
【モジュール名】/【コントローラ名】/【別アクション名】.phtml
$this->render('【別アクション名】');
○リダイレクト
/hoge/foo にリダイレクトする。
$this->_redirect('/hoge/foo');
http://www.example.com/hoge/foo/bar にリダイレクトする。
$this->_redirect('http://www.example.com/hoge/foo/bar');
http://www.example.com/hoge/foo/bar?a=1&b=2 にリダイレクトする。
$this->_redirect('http://www.example.com/hoge/foo/bar?a=1&b=2');
/【コントローラ名】/【アクション名】 にリダイレクトする。
$this->_helper->redirector('【アクション名】', '【コントローラ名】');
○フォワード
別のアクションにフォワードする
$this->_forward('【別アクション名】');
【モジュール名】/【コントローラ名】/【別アクション名】
別のコントローラにフォワードする
$this->_forward('【別アクション名】', '【別コントローラ名】');
【モジュール名】/【別コントローラ名】/【別アクション名】
別のモジュールにフォワードする
$this->_forward('【別アクション名】', '【別コントローラ名】', '【別モジュール名');
【別モジュール名】/【別コントローラ名】/【別アクション名】
パラメータを指定してフォワードする
$params = array(
'a' = '1',
'b' = '2'
);
$this->_forward('【別アクション名】', '【別コントローラ名】', '【別モジュール名】', $params);
【別モジュール名】/【別コントローラ名】/【別アクション名】/a/1/b/2
参考：http://pentan.info/php/zend_fw/redirector.html
○リダイレクトとフォワードの違い
リダイレクトの場合、クラアイアントがページXを要求すると、サーバがページYを要求する指示をクライアントに戻します。これによって“クライアントは自動的に”ページYを要求し、結果としてページYがクライアントに戻されます（ページXとページYは、必ずしも同一サーバからのレスポンスではない）。これに対しフォワードは、クライアントがページXを要求すると、“サーバ内で”ページXからYへ処理が移送され、ページYが応答として戻されます（ページXとページYは、必ず同一サーバからのレスポンス）。
以上の説明を図示すると以下のようになります。
リダイレクトは、サーバからクライアントに異なるページYにアクセスする要求を返すことでページYへの遷移を実現する。これに対し、フォワードはサーバ内でページYに処理を転送し、ページYを結果としてクライアントへ返すことでページ遷移を実現する
この結果、「リダイレクト」と「フォワード」には、以下のような違いが発生します。
リダイレクトよりもフォワードの方がパフォーマンスが良い
リダイレクトがクライアントとサーバ間を2往復（ラウンドトリップ）する非効率な処理であるのに対して、フォワードは通常のリクエスト同様に1回のリクエスト／レスポンスで処理が完結します。これは、単純に2倍のトラフィックが発生するというだけのことではありません。リダイレクトによって発生した2回目のリクエストは、待ち行列の末尾に配置されるため、特にトラフィックの多いサーバにおいては、要求待ちによる遅延が発生する可能性があります。一方、フォワードは、1つのリクエスト処理内の連続したロジックとして処理されるため、こうした遅延の心配はありません。
フォワードはサーバ内部の転送にのみ使用できる
遅延が起こらないからといって、ページの自動的な転移を常にフォワードで行えば良いというわけではありません。フォワードは、「サーバ内」で処理を転送するというその性質上、同一サーバ内ページ（クラス）間でしか利用することができません。外部のサーバ上のページに対して移動したいという場合には、リダイレクトを使用する必要があります。
リクエスト情報を引き継げるのはフォワードのみ
リダイレクトでは、ページA、Bへの要求はまったく独立した「2つの」リクエストとして扱われるため、リクエストパラメータやリクエスト属性などの情報を両者で共有することはできません。しかし、フォワードでは、ページA、Bの処理は「1つの」リクエスト処理として扱われるため、リクエストパラメータやリクエスト属性はすべて引き継がれます。
参考：http://www.atmarkit.co.jp/fjava/javatips/062jspservlet029.html
【モジュール名】/【コントローラ名】/【アクション名】.phtml
別のアクションのテンプレートを読み込む
【モジュール名】/【コントローラ名】/【別アクション名】.phtml
$this->render('【別アクション名】');
○リダイレクト
/hoge/foo にリダイレクトする。
$this->_redirect('/hoge/foo');
http://www.example.com/hoge/foo/bar にリダイレクトする。
$this->_redirect('http://www.example.com/hoge/foo/bar');
http://www.example.com/hoge/foo/bar?a=1&b=2 にリダイレクトする。
$this->_redirect('http://www.example.com/hoge/foo/bar?a=1&b=2');
/【コントローラ名】/【アクション名】 にリダイレクトする。
$this->_helper->redirector('【アクション名】', '【コントローラ名】');
○フォワード
別のアクションにフォワードする
$this->_forward('【別アクション名】');
【モジュール名】/【コントローラ名】/【別アクション名】
別のコントローラにフォワードする
$this->_forward('【別アクション名】', '【別コントローラ名】');
【モジュール名】/【別コントローラ名】/【別アクション名】
別のモジュールにフォワードする
$this->_forward('【別アクション名】', '【別コントローラ名】', '【別モジュール名');
【別モジュール名】/【別コントローラ名】/【別アクション名】
パラメータを指定してフォワードする
$params = array(
'a' = '1',
'b' = '2'
);
$this->_forward('【別アクション名】', '【別コントローラ名】', '【別モジュール名】', $params);
【別モジュール名】/【別コントローラ名】/【別アクション名】/a/1/b/2
参考：http://pentan.info/php/zend_fw/redirector.html
○リダイレクトとフォワードの違い
リダイレクトの場合、クラアイアントがページXを要求すると、サーバがページYを要求する指示をクライアントに戻します。これによって“クライアントは自動的に”ページYを要求し、結果としてページYがクライアントに戻されます（ページXとページYは、必ずしも同一サーバからのレスポンスではない）。これに対しフォワードは、クライアントがページXを要求すると、“サーバ内で”ページXからYへ処理が移送され、ページYが応答として戻されます（ページXとページYは、必ず同一サーバからのレスポンス）。
以上の説明を図示すると以下のようになります。
リダイレクトは、サーバからクライアントに異なるページYにアクセスする要求を返すことでページYへの遷移を実現する。これに対し、フォワードはサーバ内でページYに処理を転送し、ページYを結果としてクライアントへ返すことでページ遷移を実現する
この結果、「リダイレクト」と「フォワード」には、以下のような違いが発生します。
リダイレクトよりもフォワードの方がパフォーマンスが良い
リダイレクトがクライアントとサーバ間を2往復（ラウンドトリップ）する非効率な処理であるのに対して、フォワードは通常のリクエスト同様に1回のリクエスト／レスポンスで処理が完結します。これは、単純に2倍のトラフィックが発生するというだけのことではありません。リダイレクトによって発生した2回目のリクエストは、待ち行列の末尾に配置されるため、特にトラフィックの多いサーバにおいては、要求待ちによる遅延が発生する可能性があります。一方、フォワードは、1つのリクエスト処理内の連続したロジックとして処理されるため、こうした遅延の心配はありません。
フォワードはサーバ内部の転送にのみ使用できる
遅延が起こらないからといって、ページの自動的な転移を常にフォワードで行えば良いというわけではありません。フォワードは、「サーバ内」で処理を転送するというその性質上、同一サーバ内ページ（クラス）間でしか利用することができません。外部のサーバ上のページに対して移動したいという場合には、リダイレクトを使用する必要があります。
リクエスト情報を引き継げるのはフォワードのみ
リダイレクトでは、ページA、Bへの要求はまったく独立した「2つの」リクエストとして扱われるため、リクエストパラメータやリクエスト属性などの情報を両者で共有することはできません。しかし、フォワードでは、ページA、Bの処理は「1つの」リクエスト処理として扱われるため、リクエストパラメータやリクエスト属性はすべて引き継がれます。
参考：http://www.atmarkit.co.jp/fjava/javatips/062jspservlet029.html
2015年1月14日水曜日
サーバーまとめ1:リバースプロキシ(reverse proxy)
リバースプロキシ(reverse proxy)とは
恥ずかしがり屋なWebサーバさん用代理交渉人のこと。
○ホームページが表示されるまでの流れ
１．Webブラウザ→「このページおくれ」→Webサーバ
２．Webブラウザ←「ほれ、そのページだよ」←Webサーバ
Webサーバさんの身代わりになってホームページを返してくれるサーバさんのこと。
○プロキシサーバが入ったホームページ表示までの流れ
１．Webブラウザ→「俺の代わりにこのページ貰ってきておくれ」→プロキシサーバ
２．プロキシサーバ→「このページおくれ」→Webサーバ
３．プロキシサーバ←「ほれ、そのページだよ」←Webサーバ
４．Webブラウザ←「ほれ、貰ってきたページだよ」←プロキシサーバ
○リバースプロキシサーバが入ったホームページ表示までの流れ
１．Webブラウザ→「このページおくれ」→リバースプロキシサーバ
２．リバースプロキシサーバ→「このページくれってきたよ」→Webサーバ
３．リバースプロキシサーバ←「じゃあこのページ返してあげて」←Webサーバ
４．Webブラウザ←「ほれ、そのページだよ」←リバースプロキシサーバ
普通のプロキシさんの場合は「Webブラウザ＋プロキシサーバ」で一つのクライアント
リバースプロキシさんの場合は「リバースプロキシサーバ＋Webサーバ」で一つのサーバになるイメージです。
○メリット
(1)．身元を隠せる
(2)．負荷分散ができる
(1)のメリットは普通のプロキシと同じです。
矢面に立つのはリバースプロキシサーバなのでWebサーバの正体はバレません。
(2)はちょっとややこしいのですが、1つのリバースプロキシに複数のWebサーバを割り当てることができる
参考：http://wa3.i-3-i.info/word1755.html
http://itdoc.hitachi.co.jp/manuals/3020/30203M0461/EM040070.HTM
http://www.atmarkit.co.jp/ait/articles/1406/17/news013.html
○関連項目
nginx
1日に数億リクエストを処理するような大規模サイトを中心に、近年急速にシェアを拡大しているWebサーバーが「Nginx（エンジンエックス）」です。
HTMLドキュメントや画像ファイルといった静的コンテンツを高速で配信し、消費メモリが少なく、リバースProxyやロードバランサーといった機能も有した注目の軽量Webサーバーです。ネットクラフト社の調査によると、2014年6月時点でApache HTTP、Microsoft IISに次ぐ第3位のシェアを獲得しています。
恥ずかしがり屋なWebサーバさん用代理交渉人のこと。
○ホームページが表示されるまでの流れ
１．Webブラウザ→「このページおくれ」→Webサーバ
２．Webブラウザ←「ほれ、そのページだよ」←Webサーバ
Webサーバさんの身代わりになってホームページを返してくれるサーバさんのこと。
○プロキシサーバが入ったホームページ表示までの流れ
１．Webブラウザ→「俺の代わりにこのページ貰ってきておくれ」→プロキシサーバ
２．プロキシサーバ→「このページおくれ」→Webサーバ
３．プロキシサーバ←「ほれ、そのページだよ」←Webサーバ
４．Webブラウザ←「ほれ、貰ってきたページだよ」←プロキシサーバ
○リバースプロキシサーバが入ったホームページ表示までの流れ
１．Webブラウザ→「このページおくれ」→リバースプロキシサーバ
２．リバースプロキシサーバ→「このページくれってきたよ」→Webサーバ
３．リバースプロキシサーバ←「じゃあこのページ返してあげて」←Webサーバ
４．Webブラウザ←「ほれ、そのページだよ」←リバースプロキシサーバ
普通のプロキシさんの場合は「Webブラウザ＋プロキシサーバ」で一つのクライアント
リバースプロキシさんの場合は「リバースプロキシサーバ＋Webサーバ」で一つのサーバになるイメージです。
○メリット
(1)．身元を隠せる
(2)．負荷分散ができる
(1)のメリットは普通のプロキシと同じです。
矢面に立つのはリバースプロキシサーバなのでWebサーバの正体はバレません。
(2)はちょっとややこしいのですが、1つのリバースプロキシに複数のWebサーバを割り当てることができる
参考：http://wa3.i-3-i.info/word1755.html
http://itdoc.hitachi.co.jp/manuals/3020/30203M0461/EM040070.HTM
http://www.atmarkit.co.jp/ait/articles/1406/17/news013.html
○関連項目
nginx
1日に数億リクエストを処理するような大規模サイトを中心に、近年急速にシェアを拡大しているWebサーバーが「Nginx（エンジンエックス）」です。
HTMLドキュメントや画像ファイルといった静的コンテンツを高速で配信し、消費メモリが少なく、リバースProxyやロードバランサーといった機能も有した注目の軽量Webサーバーです。ネットクラフト社の調査によると、2014年6月時点でApache HTTP、Microsoft IISに次ぐ第3位のシェアを獲得しています。
2014年12月18日木曜日
Linuxまとめ1：kondemandというプロセスを見たら、CPU設定確認
Linuxでtopコマンドを打ってロードアベレージを確認したとき、
プロセスに「kondemand」というプロセスが以上に多いことに気付いた。
2372 root 20 0 0 0 0 S 0.3 0.0 478:36.64 kondemand/0
2376 root 20 0 0 0 0 S 0.3 0.0 58:19.28 kondemand/4
2378 root 20 0 0 0 0 S 0.3 0.0 119:19.47 kondemand/6
2379 root 20 0 0 0 0 S 0.3 0.0 93:23.73 kondemand/7
2384 root 20 0 0 0 0 S 0.3 0.0 188:04.64 kondemand/12
2393 root 20 0 0 0 0 S 0.3 0.0 16:41.26 kondemand/21
下記のHPを参考に確認
○省電力モードが無効になっているのを確認する方法
・/sys/devices/system/cpu/cpu0/cpufreq/scaling_governorを確認する。この値はオンデマンドで変更はできない。
・/proc/cpuinfoを確認し、"model name"の下に表示されているCPUの周波数を比較する。
・"ondemand"が実行されていたら無効にする。
○"ondemand"が起動している確認する方法
$ ps ax| grep kondemand|wc -l
65
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
上のように起動している状態だと、下記のように設定されているはず
/proc/cpuinfo:
model name : Intel(R) Xeon(R) CPU E5-4640 0 @ 2.40GHz
..
cpu MHz : 1200.000
この場合、"ondemand"を無効にする必要がある。
おそらく、下記サイトが参考になるはず
http://yakst.com/ja/posts/109
これらのシンプルなチューニングのヒントは、MySQLのパフォーマンスを上げ、より安定性を高くする(スワップもしなくなる)。
○参考
MySQLのためのLinuxチューニングヒント
http://yakst.com/ja/posts/109
プロセスに「kondemand」というプロセスが以上に多いことに気付いた。
2372 root 20 0 0 0 0 S 0.3 0.0 478:36.64 kondemand/0
2376 root 20 0 0 0 0 S 0.3 0.0 58:19.28 kondemand/4
2378 root 20 0 0 0 0 S 0.3 0.0 119:19.47 kondemand/6
2379 root 20 0 0 0 0 S 0.3 0.0 93:23.73 kondemand/7
2384 root 20 0 0 0 0 S 0.3 0.0 188:04.64 kondemand/12
2393 root 20 0 0 0 0 S 0.3 0.0 16:41.26 kondemand/21
下記のHPを参考に確認
○省電力モードが無効になっているのを確認する方法
・/sys/devices/system/cpu/cpu0/cpufreq/scaling_governorを確認する。この値はオンデマンドで変更はできない。
・/proc/cpuinfoを確認し、"model name"の下に表示されているCPUの周波数を比較する。
・"ondemand"が実行されていたら無効にする。
○"ondemand"が起動している確認する方法
$ ps ax| grep kondemand|wc -l
65
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
上のように起動している状態だと、下記のように設定されているはず
/proc/cpuinfo:
model name : Intel(R) Xeon(R) CPU E5-4640 0 @ 2.40GHz
..
cpu MHz : 1200.000
この場合、"ondemand"を無効にする必要がある。
おそらく、下記サイトが参考になるはず
http://yakst.com/ja/posts/109
これらのシンプルなチューニングのヒントは、MySQLのパフォーマンスを上げ、より安定性を高くする(スワップもしなくなる)。
○参考
MySQLのためのLinuxチューニングヒント
http://yakst.com/ja/posts/109
登録:
投稿 (Atom)