memchachedなどについて今日調べたこと

memchachedとはキャッシュサーバである。本来は複数台のマシンに分散してデータを持つことで効果が発揮されるものであるが、一台のマシンで動かして、気軽に効果を感じることはできないものか。

Webアプリケーションサーバを複数台用意することで、同時に処理できるリクエストの数を増やす。WebアプリケーションサーバからDBへのアクセスがネックとなるので、WebアプリケーションサーバとDBとの間にキャッシュサーバを置き、処理を高速化される。キャッシュサーバを複数台用意することで、さらに処理を高速化させるが、そのとき、どのキャッシュをどのサーバに置くかのアルゴリズム（Consistent Hashingなど）を統一することで、Webアプリケーションサーバ上のキャッシュクライアントが、必要とされるデータを持つキャッシュサーバに正しくアクセスできるようにする。（参考：http://gihyo.jp/dev/feature/01/memcached_advanced/0004）

どのページでも利用するような共通データは、すべてのキャッシュサーバに置き、クライアントからは均等に（ランダムに）アクセスされるようにする工夫が必要となる。（参考：http://gihyo.jp/dev/feature/01/memcached_advanced/0004）

稼働監視の方法には、「サーバからのping応答を確認する」「サーパプロセスが待機しているポートに接続できることを確認する」「CPU使用率を確認する」「Disk使用率を確認する」「サーバプロセスに簡単なコマンドを送って応答を確認する」「サーバプロセスの接続数を確認する」などがある。監視用のツールとして、NagiosやCloudForecastがある。（参考：http://gihyo.jp/dev/feature/01/memcached_advanced/0003）

memchachedにインターネット上からアクセス可能にしていると、memchached上のデータがすべて漏えいしてしまう。グローバルIP側のポートをリッスンしないようにするあるいは、可能であればSASLを使用する必要がある。また不要なデータをキャッシュしないようにすることが重要である。アスキープロトコルではコマンドインジェクションの問題が生じやすい。（参考：http://gihyo.jp/dev/feature/01/memcached_advanced/0002）

Kaiはmemcachedプロトコルのサーバをクラスタ構成し、memcachedクライアントからのリクエストを処理する。memcachedクライアントではなく、Kai側でデータの取得、格納ノードを判定する（参考：http://gihyo.jp/dev/feature/01/kai/0003）

memcachedはスラブ単位でキャッシュを格納する。（参考：http://gihyo.jp/dev/feature/01/memcached/0002?page=3）

memcachedの特徴は、データの揮発性である。（参考：http://gihyo.jp/dev/serial/01/various-nosql/0002）
TokyoTyrantはmemcachedに永続性機能を追加した代替実装である。expiresを指定できない以外は、memcachedと同じように使用できる（参考：http://gihyo.jp/dev/serial/01/various-nosql/0003）

HBaseとCassandraは、列指向型データベースとして、大規模なデータを扱うのに適している。（参考：http://gihyo.jp/dev/serial/01/various-nosql/0005）

MongoDBは、スキーマレスなDBである。（参考：http://gihyo.jp/dev/serial/01/various-nosql/0004）

JOINを行うselect文が遅くなる原因の一つが、データがメモリー内に収まらないこと。Sort MergeとHashアルゴリズムでは、メモリ上に一時的な作業領域が必要となる。Nested Loopでは、そのようなことは起きにくい。（参考：http://gihyo.jp/dev/serial/01/db-academy/000403?page=2）

システムのパフォーマンスにおけるボトルネックの原因は、「リソース消費」（CPU・メモリ・ディスク・ネットワークの消費）と「流量制限」（コネクションなどが空くのを待っている）以外にはない。（参考：http://gihyo.jp/dev/serial/01/db-academy/000502）

システムのパフォーマンスチューニングでは、最初に滞留時間を計測し、ボトルネックを探す。クライアント側やネットワークが問題となっていることもある。（参考：http://gihyo.jp/dev/serial/01/db-academy/000501?page=2）

統計情報が間違っているために、オプティマイザが最適な実行計画を選択できないという問題が起きる。（参考：http://gihyo.jp/dev/serial/01/db-academy/000401?page=2）

Serializableだと、Dirty Read（他トランザクションの未コミットのデータが読みだされる）、Unrepeatable Read（トランザクションの途中で、他のトランザクションによるコミットが行われたので、最初に読み込んだレコードの値と、次に読み込んだレコードの値が異なる）、Phantom（トランザクションの途中で、他のトランザクションによるコミットが行われたので、最初の検索結果と次の検索結果が異なる）のどれも発生しない。Repeatable ReadだとPhantomは防げない。Read CommittedだとPhantomとUnrepeatable Readは防げない。Read Uncommittedだと、どれも防げない。パフォーマンスと厳密性のトレードオフの結果、ほとんどのRDBMSでRead Committedがデフォルト。（参考：http://gihyo.jp/dev/serial/01/db-academy/000203?page=2）

トランザクションがコミットされると、WALでひとまずログファイルに書き込んで、データ反映処理はあとでゆっくりとやる（チェックポイント）。障害発生時にログファイルからデータファイルに変更を反映させることをロールフォワードという。（参考：http://gihyo.jp/dev/serial/01/db-academy/000202）

OLAP関数のサポートはPostgres8.4から。OLAP関数を使うと、ランク付けや移動平均の計算などができる（参考：http://gihyo.jp/dev/serial/01/sql_academy2/001101）