--- a/PG9_4Report.tex	Tue Sep 09 18:23:47 2014 +0900
+++ b/PG9_4Report.tex	Tue Sep 09 19:31:59 2014 +0900
@@ -30,30 +30,30 @@
 \maketitle
 
 \section{Postgres Unstructured 概要}
-Postgres Unstructured は EnterpriseDB 社による プレゼン\cite{PostgresUnstructured}タイトル内の言葉で、NoSQL に対応した PostgreSQL を指す。 Postgres 9.4 beta2 時点では HStore, json, jsonb という三つのデータ型が非構造なデータを扱うことを可能にしている。本報告書では Postgres 9.4 で新たに加わった jsonb 型、9.3 からの json 型について中心に述べる。
+Postgres Unstructured は EnterpriseDB 社による プレゼン\cite{PostgresUnstructured}タイトル内の言葉で, NoSQL に対応した PostgreSQL を指す.  Postgres 9.4 beta2 時点では HStore, json, jsonb という三つのデータ型が非構造なデータを扱うことを可能にしている. HStore は Postgres 8.2 から存在する Key-Value pair のデータ型であり, json 型, jsonb 型はそれぞれ 9.3, 9.4 で新たに加わった json を扱うデータ型である. 本報告書では jsonb 型 json 型について中心に述べる. 
 
 \section{Postgres 9.4 beta2 環境設定}
-EnterpriseDB 社のページにインストーラが用意されているのでそれを利用する\cite{Install}。Mac OS X, Windows, Linux 向けにそれぞれ app, exe, run ファイルが用意されており、実行するだけでインストールが完了する。インストーラにより、データベース用ディレクトリの作成、Postgresユーザの追加までサポートされる。ただしパスの通ってないディレクトリをインストール先に指定した場合はパスを通す必要がある。
+EnterpriseDB 社のページにインストーラが用意されているのでそれを利用する\cite{Install}. Mac OS X, Windows, Linux 向けにそれぞれ app, exe, run ファイルが用意されており, 実行するだけでインストールが完了する. インストーラにより, データベース用ディレクトリの作成, Postgresユーザの追加までサポートされる. ただしパスの通ってないディレクトリをインストール先に指定した場合はパスを通す必要がある. 
 
-インストール後, createdbコマンドでデータベースを作成、psql [db name]でデータベースを操作できる。デフォルトではデータベースのユーザーには postgres しか存在しないので、ユーザーが postgres 出ない場合は -U オプションで postgres ユーザーを指定する必要がある。
+インストール後, createdbコマンドでデータベースを作成, psql [db name]でデータベースを操作できる. デフォルトではデータベースのユーザーには postgres しか存在しないので, ユーザーが postgres 出ない場合は -U オプションで postgres ユーザーを指定する必要がある. 
 
-サーバプロセスの管理は pg\_ctl コマンドによって行う。こちらの操作も postgres ユーザーでしか行えない。以下のように使用する。
+サーバプロセスの管理は pg\_ctl コマンドによって行う. こちらの操作も postgres ユーザーでしか行えない. 以下のように使用する. 
 \begin{lstlisting}[frame=lrbt]
 % pg_ctl -D [database path] [start | stop | status | restart]
 \end{lstlisting}
-portやlisten address の設定はデータベースに指定したディレクトリ以下の data/postgresql.conf を編集することで行える。
-それぞれport=****,listen\_addresses=****を任意の値に変更する。
-この設定は再起動するまで反映されない。
+portやlisten address の設定はデータベースに指定したディレクトリ以下の data/postgresql.conf を編集することで行える. 
+それぞれport=****,listen\_addresses=****を任意の値に変更する. 
+この設定は再起動するまで反映されない. 
 
 \section{json, jsonb型}
-jsonb型は postgres の持つ json のバイナリ表現である。 mongoDB の BSON とは異なり, 64bit 以上の数値を正確に表現することが可能という利点を持つ. jsonb は json の内部表現というわけではなく, json型とjsonb型はそれぞれ独立して存在する. jsonb型を利用する際、入力として与える値は json であるので、型を指定する以外は特別 jsonb型であることを意識する必要はない。jsonb型を格納する際、与えられた json を jsonb へと変換する処理が入るので 値の格納に関しては json よりやや速度が劣る。しかし、jsonbのみが利用できる演算子の存在、値の処理はjsonbの方が速いという利点が存在する。
+jsonb型は postgres の持つ json のバイナリ表現である.  mongoDB の BSON とは異なり, 64bit 以上の数値を正確に表現することが可能という利点を持つ. jsonb は json の内部表現というわけではなく, json型とjsonb型はそれぞれ独立して存在する. jsonb型を利用する際, 入力として与える値は json であるので, 型を指定する以外は特別 jsonb型であることを意識する必要はない. jsonb型を格納する際, 与えられた json を jsonb へと変換する処理が入るので 値の格納に関しては json よりやや速度が劣る. しかし, jsonbのみが利用できる演算子の存在, 値の処理はjsonbの方が速いという利点が存在する. 
 
-その他の違いとして、json型は文字列をそのまま格納するのに対しjsonb型は一度変換を介すので, jsonb型は整形されるという点がある。そのため、1.230e-5 のように小数の表現に e を使ったものも 0.0000123 と直される。
+その他の違いとして, json型は文字列をそのまま格納するのに対しjsonb型は一度変換を介すので, jsonb型は整形されるという点がある. そのため, 1.230e-5 のように小数の表現に e を使ったものも 0.0000123 と直される. 
 
-また、json,jsonb型に共通して、数値に NaN, infinity を使用することができない。これらの値をもつ json は別の値に変換する必要がある。
+また, json,jsonb型に共通して, 数値に NaN, infinity を使用することができない. これらの値をもつ json は別の値に変換する必要がある. 
 
 \section{json, jsonbとデーブルデータ間の変換}
-テーブルデータをjsonに変換するのには to\_json関数を用いる。この関数はテーブルの項目, 値をそれぞれキー, 要素とするjsonに変換する関数ある。以下に使用例と実行結果を示す。
+テーブルデータをjsonに変換するのには to\_json関数を用いる. この関数はテーブルの項目, 値をそれぞれキー, 要素とするjsonに変換する関数ある. 以下に使用例と実行結果を示す. 
 \begin{lstlisting}[frame=lrbt]
 =# SELECT to_json(table_name.*) FROM table_name;
                                    to_json                                    
@@ -64,7 +64,7 @@
 
 \end{lstlisting}
 
-jsonをテーブルデータに変換するにはjson\_populate\_record関数,json\_populate\_recordset関数を用いる。この関数は引数としてベースとなるテーブルとjsonを求め, ベースとなるテーブルに与えられた json を対応させていく。このときベースに存在しない項目は無視され、jsonに存在しない項目にはnullが格納される。以下の使用例と実行結果を示す。
+jsonをテーブルデータに変換するにはjson\_populate\_record関数,json\_populate\_recordset関数を用いる. この関数は引数としてベースとなるテーブルとjsonを求め, ベースとなるテーブルに与えられた json を対応させていく. このときベースに存在しない項目は無視され, jsonに存在しない項目にはnullが格納される. 以下の使用例と実行結果を示す. 
 \begin{lstlisting}[frame=lrbt]
 =# SELECT * FROM json_populate_recordset(NULL::table_name, (SELECT array_to_json(array_agg(json.data)) FROM json_table_name));
   city   | temp_lo | temp_hi | prcp |    date    
@@ -75,7 +75,7 @@
 \end{lstlisting}
 
 \section{json, jsonb型のフィールドへのアクセス}
-json, jsonのフィールドへのアクセスには'\verb|->|','\verb|->>|'演算子を用いる。前者はフィールドを単に取得するもので、後者はテキストとして取得する。フィールドの値を SELECT に用いるのは容易で、以下のように使用する。
+json, jsonのフィールドへのアクセスには'\verb|->|','\verb|->>|'演算子を用いる. 前者はフィールドを単に取得するもので, 後者はテキストとして取得する. フィールドの値を SELECT に用いるのは容易で, 以下のように使用する. 
 \begin{lstlisting}[frame=lrbt]
 =# SELECT json_data FROM json_jsonb;
                                       json_data                                      
@@ -91,7 +91,7 @@
  ``aua''
 \end{lstlisting}
 
-WHEREの条件に利用する場合は型に気をつける必要があり, フィールドの型と比較先の値の型を揃える必要がある。例えばフィールド内の数値と 100 を比較したい場合、フィールドの値は'\verb|->>|'演算子を用いてテキストとして取得し、右辺の 100 はシングルクォートで囲い文字列扱いにする必要がある。'\verb|->|'演算子で取得した値は json 型になるので比較できない。
+WHEREの条件に利用する場合は型に気をつける必要があり, フィールドの型と比較先の値の型を揃える必要がある. 例えばフィールド内の数値と 100 を比較したい場合, フィールドの値は'\verb|->>|'演算子を用いてテキストとして取得し, 右辺の 100 はシングルクォートで囲い文字列扱いにする必要がある. '\verb|->|'演算子で取得した値は json 型になるので比較できない. 
 
 \begin{lstlisting}[frame=lrbt, caption={エラーが出る例}]
 =# SELECT json_data->'string' FROM json_jsonb WHERE jsonb_data->>'number' = 234500;;
@@ -107,13 +107,13 @@
 
 
 \section{json, jsonb型のデータの更新}
-json全体の UPDATE は通常の値を更新するのと同様に UPDATE を用いて行うことができる。しかし、以下のように'\verb|->|','\verb|->>|'演算子を利用してフィールドの値を直接更新することはできず、Postgres 公式ドキュメント\cite{PostgresDoc}にもその方法は記載されていない。
+json全体の UPDATE は通常の値を更新するのと同様に UPDATE を用いて行うことができる. しかし, 以下のように'\verb|->|','\verb|->>|'演算子を利用してフィールドの値を直接更新することはできず, Postgres 公式ドキュメント\cite{PostgresDoc}にもその方法は記載されていない. 
 \begin{lstlisting}[frame=lrbt, caption={エラーが出る例}]
 =# UPDATE table_name SET json->'a' = to_json(5) WHERE json->>'b' = '2';
 ERROR:  syntax error at or near ``->''
 \end{lstlisting}
 
-以下に示すリスト\ref{json_update}のような関数を利用することで更新は可能であるが、この場合、複数のjson内のフィールドの値を更新することはできない。(関数は stackoverflowより引用\cite{stackoverflow})。
+以下に示すリスト\ref{json_update}のような関数を利用することで更新は可能であるが, この場合, 複数のjson内のフィールドの値を更新することはできない. (関数は stackoverflowより引用\cite{stackoverflow}). 
 \begin{lstlisting}[frame=lrbt,caption={json\_object\_set\_key}, label=json_update]
 CREATE OR REPLACE FUNCTION ``json_object_set_key''(
   ``json''          json,
@@ -136,50 +136,50 @@
 )::json
 $function$;
 \end{lstlisting}
-この関数は次のように利用する。
+この関数は次のように利用する. 
 \begin{lstlisting}[frame=lrbt]
 UPDATE json_jsonb SET SELECT json_object_set_key((SELECT json_data FROM json_jsonb WHERE json_data->>'condition_key'='condition_value'),'key_name','new_value'::text)) WHERE json_data->>'condition_key'='condition_value';
 \end{lstlisting}
 
 
 \section{json,jsonb型でのINDEX}
-json, jsonb型どちらでもフィールドに対する index の作成が可能で、作成のためのCREATE INDEX 文は次の二通りの記述方法がある。
+json, jsonb型どちらでもフィールドに対する index の作成が可能で, 作成のためのCREATE INDEX 文は次の二通りの記述方法がある. 
 \begin{lstlisting}[frame=lrbt]
 CREATE INDEX index_name ON table_name ((json_column_name->>'key'));
 CREATE INDEX index_name ON table_name ((json_extract_path_text(json_column_name, 'key')));
 \end{lstlisting}
 
-json型の場合, jsonデータへのインデックスは作成できない。jsonb型へはインデックスの作成が可能で、\verb-@>, ?, ?&, ?|- の4つの演算子がサポートされる。
+json型の場合, jsonデータへのインデックスは作成できない. jsonb型へはインデックスの作成が可能で, \verb-@>, ?, ?&, ?|- の4つの演算子がサポートされる. 
 \begin{lstlisting}[frame=lrbt]
 CREATE INDEX index_name ON table_name USING GIN (jsonb_column_name);
 \end{lstlisting}
-また、以下のようにすると \verb|@>|のみをサポートする index を作ることができる。
+また, 以下のようにすると \verb|@>|のみをサポートする index を作ることができる. 
 \begin{lstlisting}[frame=lrbt]
 CREATE INDEX index_name ON table_name USING GIN (jsonb_column_name jsonb_path_ops);
 \end{lstlisting}
 
-尚、各演算子の意味は次のようになっている。
+尚, 各演算子の意味は次のようになっている. 
 \begin{table}[htb]
   \centering
   \begin{tabular}{|c|c|}\hline
     演算子 & 説明 \\ \hline\hline
-    \verb-@>- & 指定した json を含むかどうか。\\ \hline
-    \verb-?- & 指定したキーを持つかどうか。\\ \hline
-    \verb-?&- & 指定したキーをすべて持つかどうか。\\ \hline
-    \verb-?|- & 指定したキーのうちどれか一つでも持つか。\\ \hline
+    \verb-@>- & 指定した json を含むかどうか. \\ \hline
+    \verb-?- & 指定したキーを持つかどうか. \\ \hline
+    \verb-?&- & 指定したキーをすべて持つかどうか. \\ \hline
+    \verb-?|- & 指定したキーのうちどれか一つでも持つか. \\ \hline
   \end{tabular}
 \end{table}
 
 \section{まとめ}
-Postgres は 9.4 beta2 時点で HStore, json, jsonb の三種の方により Unstructuerd data に対応している。既存のテーブルデータと json, jsonb 間の変換が容易なので、jsonで受け取ったデータを RDB で管理するといった使い方もできる。
+Postgres は 9.4 beta2 時点で HStore, json, jsonb の三種の方により Unstructuerd data に対応している. 既存のテーブルデータと json, jsonb 間の変換が容易なので, jsonで受け取ったデータを RDB で管理するといった使い方もできる. 
 
-json, jsonb型を用いて NoSQLDB として使う場合はフィールドの値を簡単に更新できないことが課題になるだろう。先に作られた HStore 型の方はフィールドの値の更新に対応しているので、HStore 型で表現できるのならば HStore 型を用いるのが良い。
+json, jsonb型を用いて NoSQLDB として使う場合はフィールドの値を簡単に更新できないことが課題になるだろう. 先に作られた HStore 型の方はフィールドの値の更新に対応しているので, HStore 型で表現できるのならば HStore 型を用いるのが良い. 
 
-また、'\verb+?+','\verb+?|+','\verb+?&+'の三つの演算子はドキュメントでは要素の検索も可能となっているが実際にはキーの検索しかできず、ドキュメント側のミスなのか開発段階なのかの判断ができない。
+また, '\verb+?+','\verb+?|+','\verb+?&+'の三つの演算子はドキュメントでは要素の検索も可能となっているが実際にはキーの検索しかできず, ドキュメント側のミスなのか開発段階なのかの判断ができない. 
 
-同様に json を扱う mongoDB と比較した場合、 EnterpriseDB 社の発表\cite{PostgresUnstructured}によると処理速度、データベースサイズ等のパフォーマンス面では Postgres が勝るようだが、前述したjsonのフィールドの更新が未対応である点に使いづらさを感じた。
+同様に json を扱う mongoDB と比較した場合,  EnterpriseDB 社の発表\cite{PostgresUnstructured}によると処理速度, データベースサイズ等のパフォーマンス面では Postgres が勝るようだが, 前述したjsonのフィールドの更新が未対応である点に使いづらさを感じた. 
 
-この点を考えると、json を扱うためのデータベースとして利用するにはまだ早いと感じた。NoSQL と SQL の両方が利用できるという強みを活かせる使い方をするのがいいだろう。
+この点を考えると, json を扱うためのデータベースとして利用するにはまだ早いと感じた. NoSQL と SQL の両方が利用できるという強みを活かせる使い方をするのがいいだろう. 
 
 \begin{thebibliography}{9}
 \bibitem{PostgresUnstructured}NoSQL on ACID - Meet Unstructured Postgres. \\ ``http://www.slideshare.net/EnterpriseDB/no-37327319''