良くある備忘録2:日付計算

【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

DBまとめ2:ACID特性

トランザクションは，次の4つの特性をすべて保証しなければなりません。

原子性(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