ブログ

３．量子コンピューター・シミュレーター
　なんだか、たくさんの本を読んだみたいなタイトルだが、実は、読了したと言えるのは、

　　　「先読み！IT×ビジネス講座 量子コンピューター(湊雄一郎、酒井麻里子、ISBN978-4-295-01737-0)」

一冊だけである。他には、読みかけの本が何冊かあるが、それ等については、またの機会に。

　この本には、量子コンピューター・シミュレーターが紹介されている。
　そのURLは、

http://qplat-education.devel-q.com/

である。このリンクを開くと、下図のような量子コンピューター・シミュレーター画面が表示される。この画面の表示は、ブラウザ等によって微妙に異なるが、内容としては同じである。

画面は、３つの領域に分かれている。 　

• 左は、「ゲート」の一覧である。
• 中央は、「キュービット」に「ゲート」を配置した図である。
• 右は、「計算」結果などを表示する。

　「キュービット」（「量子ビット」とも呼ばれる）は、左端に各キュービットの初期値である|0〉を持つ水平の線で表示される。
　キュービット上では、時間は左から右へ進む。
　量子コンピュータでも、繰り返し処理は可能であるが、これはシミュレータなので、時間は一方にしか進まない。
　値|0〉は、古典コンピュータにおける0（false、yes/noのno、偽）に当たる。
　1（true、yes/noのyes、真）に当たるのは、|1〉である。
　単に0、1と書かないのは、これらが「ベクトル量」とでも言うべきものだからである。

　「ゲート」を、ドラッグ&ドロップにより中央部に配置し、中央部右上の「EXECUTION」をクリックすると、「計算」が行われ、その結果が右部に表示される。
　だだし、ゲート種別名に「two」あるいは「three」と付いているものは、複数の「キュービット」にまたがって配置しなければいけないので、後述する調整操作が必要になることがある。
　「ゲート」は、古典コンピュータにおける「ゲート」との機能的な類似性からそう呼ばれる。
　しかし、古典コンピュータとは違って、「ゲート」は、いわば「『量子』の照射のしかた」である。
　「量子」を照射することによって、そろばん珠を指で弾いたのと同様に、キュービットが「値」を変える。

　「ゲート」一覧の一番下にある、measurement「M」ゲートは重要である。これは、「計算」をするゲートではなく、計算結果を「観測」する。だから、各「キュービット」の一番右に、一つずつ置かれることになる。

　この本に説明のある、他のゲートについて説明しておく。
　　　pauli gate「X」。これは、キュービットの値を反転させる（コインをひっくり返す）。
　　　one qubit gate「H」。「コインを回す」と表現されている。
　　　　　　表が出るか裏が出るか、「観測」されるまで分からないということ。
　　　two qubit gate「CX」。２つのキュービットの値により、計算結果が決まる。
　　　　　　配置すると、黒丸と四角に「X」が縦線で結んだ表示となる。
　　　　　　１つ目のキュービット(control bit)の値は不変。
　　　　　　２つ目(target bit)は１つ目が偽のときはそのまま、１つ目が真のときは反転。
　　　　　　つまり、２つ目は両者の排他的論理和となる。
　　　tree qubit gate「CCX」。３つのキュービットの値により、計算結果が決まる。
　　　　　　配置すると、黒丸２つと四角に「X」が縦線で結んだ表示となる。
　　　　　　１つ目、２つ目のキュービット(control bit)の値は不変。
　　　　　　３つ目(target bit)は、１つ目、２つ目がともに真のときにのみ反転する。

　ここで、「CX」や「CCX」のような、複数のキュービットにまたがるゲートのキュービットの指定方法について述べておく。
　「画面右の[Result]を[Detail]に切り替えたうえでブロックをダブルクリックすると云々」とある。
　例えば「CX」と「CCX」をドラッグ&ドロップにより配置し、[Detail]をクリック。下図のようになる。

　「CCX」をダブルクリックすると、下図のようになる。
　このとき表示される数値は、黒丸２つと四角に「X」の位置であるが、先頭のキュービットの番号は0、つまり「ゼロオリジン」となっている。

　[Detail]に表示された、[control bit1]、[control bit2]、[target bit]の数値を書き換える。
　すると、対応する黒丸２つと四角に「X」が、指定されたキュービット上に移動する。
　これで、当該の「CCX」は、配置したいところに配置された。

　中央部左上の「Qubits:5」とあるのは、使用する「キュービット」の個数。この数値を変更すると、表示される「キュービット」の個数が変わる。
　その隣の「Shots:1000」は、計算回数。古典計算機上では、同じ計算を多数回行うことで、確率が求められるので。

　中央部右にあるポリバケツは、配置されているゲートをすべて捨てる。「ご破算で願いましては」ということ。

　ポリバケツの下に並んでいるのは、中央部の表示倍率の調整用。

　シミュレータの操作法が分かった（と思えた）ので、やってみる。
　上２ビットの足し算で、３ビット目が10の位、４ビット目が1の位。下図が、その結果。

　最下行に、[ [ “0101”, 264 ], [ “1001”, 254 ], [ “1110”, 248 ], [ “0000”, 234 ] ]とあるが、
これは、
　　計算結果＝"0101"となったのが、264件
　　計算結果＝"1001"となったのが、254件
　　計算結果＝"1110"となったのが、248件
　　計算結果＝"0000"となったのが、234件
という意味である。計算結果は「観測」されたものなので、ベクトル量ではなく、スカラー量である。
　ちゃんと計算できているもののみであることが確認できる。

４．量子コンピューターはピアノ？
　筆者は、以前、「量子コンピュータはそろばん」と書いた（量子コンピュータ関連書籍を読んで（その１、その２））。
　しかし、この本には、「ピアノの鍵盤のようなものが並んでいて、それを演奏するようなイメージ」とある。

　ピアノとそろばんとでは、かなり違う。
　どちらが正しいのか、あるいはどちらも正しいのか。

　そろばんは、指で弾はじくことによって、珠たまを動かして計算する。
　ピアノは、指で弾ひくことによって音を出し、人間の魂たまに働きかける。
　やはり、ピアノとそろばんとでは、一見、違うように見えて、よく似ている。
　だから、きっと、どちらも正しい。

ＩＴ資産にかけるコストを少なくするようになってきている為でしょうか。
OracleからオープンソースのPostgreSQLに変えたいというニーズは昔からあるものの、最近は以前に比べ急増してきているように感じます。
Oracleのソフトウェア費用が高いことに加え、仮想化環境におけるライセンスの考え方により、必要以上に費用が掛かってしまうことが理由とされています。
ところがPostgreSQLに変えたくとも、変えられない場合が多く見受けられます。
PostgreSQLへの移行に関する問題点をいくつか列挙しますので、PostgreSQLへの移行を検討する際の一助となればと思います。

(1) SQL
アプリケーションにて自前のSQL文を使用している場合、Oracle固有のSQL文があった場合、SQL文の修正または新規のSQL文の作成が必要になります。
SQL文の修正または新規のSQL文の作成が多いほど、PostgreSQLへの移行は困難になります。
アプリケーションにおけるすべてのSQL文が対象となるため、対象の把握が困難な場合があります。プログラムで動的にSQLを生成している場合は特に注意が必要です。

(2) ストアドプロシージャ
OracleとPostgreSQLでは、構文、エラーハンドリング、トランザクションの管理などが大きく違うため、大規模な修正や新規ストアドプロシージャの作成が必要になることが度々発生します。
アプリケーションがストアドプロシージャに多く依存している場合は、PostgreSQLへの移行へのハードルが極めて高くなります。
なお、ストアドプロシージャの修正の難易度や修正に要する工数は、ora2pgというプログラムにてある程度は確認できます。

(3) データベース構成
大規模データベースでは、性能や耐障害性を考慮して、Oracle RAC構成を採用しているケースが多いかと思います。
PostgreSQLに移行する場合、どんなクラスタ構成を採用しても、更新処理ができるノードが１つしか存在しない点に留意するがあります。（Oracle RACではどのノードでも更新処理が可能）
また、更新結果が更新ログの転送により他のノードに伝播されるため、タイムラグが発生することにより、別のトランザクションで更新結果が反映されていないデータを読み取ってしまうリスクもあります。
更新処理が多い場合はネックとなるかもしれません。

(4) データベース運用
データベース監視や運用については、Oracleの考え方がほぼ援用できませんし、データディクショナリも全く違うので、運用設計からやり直しとなります。
自前のスクリプトで情報採取を行い監視していた場合ですと、すべて新規作成となります。

(5) コスト
今後のOracleソフトウェア費用よりも、PostgreSQLのソフトウェア費用にPostgreSQLへの移行費用を加えた金額が小さくなることを見込んで、PostgreSQLへの移行を検討するものと思います。
(PostgreSQLへの移行費用は、コンサルティング費用、データ移行とアプリケーションの改修の合計とします)
多くの場合、アプリケーションの改修費用がかさみ、PostgreSQLへの移行費用が大きくなりがちです。
ソフトウェア費用を節約するため、サポート契約なしで素のPostgreSQLを利用することを考えるかもしれませんが、バグデータベースへのアクセスやPostgreSQLのノウハウの提供がサポート契約により得られることを考えると、ある程度の規模以上の企業ではサポート契約なしにPostgreSQLを使用することは必須ではないでしょうか。
そのため、ソフトウェアの利用期間などを考慮すると、Oracleのままでも問題ない、多額のコストをかけてPostgreSQLに移行する利点はないと判断するケースもあります。

以上

　　　　　　table 全件update       -> tableのselect権限は不要
　　　　　　table 条件付きupdate -> tableのselect権限が必要
　　　　
　updateやdeleteの対象となる特定の行や列を指定するには、そのテーブルのselect権限が必要になります。select権限がないユーザが、table条件付きupdateを行うと、例えば“権限不足でエラー”になります。
　　
　個人的な思い込みで、レコードのupdateができるのであれば、当然select権限が付与されているだろう、update権限を付与すると自動的にselect権限の付与が補完されるだろうぐらいの認識がありました。
　　
[以下が注意したい例]
　　
① oracleの"SQL92_SECURITY"パラメータをfalse　ー＞　True　に変更した時。 select権限を付与していないテーブルのupdateがエラーになる。
　　
② プログラムで動的にＳＱＬ文を作成している時、where句がある場合はselect権限が必要になる事に注意。select権限のないテーブルのupdateは、where句が無いときは成功しますが、where句がある時に失敗します。
 

 以上