データベースガイダンス2020
インターネットの情報量
インターネット上の情報量の話として、2010年度に281EB(エクサバイト)=281✕1018B(参考:kMGTPEZY)で、2013年度で、1.2 ZB(ゼタバイト)=1.2✕1021B という情報があった。ムーアの法則の「2年で2倍」の概算にも、それなりに近い。 では、今年2020年であれば、どのくらいであろうか?
- ムーアの法則でいけば、281EB(2010年)×32=9ZB(2020年)だけど
- 大塚商会の2016年度における2020年度の予測では…
- アメリカのIDCの2020/5月の発表では、59ゼタバイト!?
しかし、これらの情報をGoogleなどで探す場合、すぐにそれなりに情報を みつけてくれる。これらは、どの様に実装されているのか?
Webシステムとデータベース
まず、指定したキーワードの情報を見つけてくれるものとして、 検索システムがあるが、このデータベースはどのようにできているのか?
Web創成期の頃であれば、Yahooがディレクトリ型の検索システムを構築 してくれている。(ページ作者がキーワードとURLを登録する方式) しかし、ディレクトリ型では、自分が考えたキーワードではページが 見つからないことが多い。
そこで、GoogleはWebロボット(クローラー)による検索システムを構築した。 Webロボットは、定期的に登録されているURLをアクセスし、 そのページ内の単語を分割しURLと共にデータベースに追加する。 さらに、ページ内にURLが含まれていると、そのURLの先で、 同様の処理を再帰的に繰り返す。
これにより、巨大なデータベースが構築されているが、これを普通のコンピュータで実現すると、処理速度が足りず、3秒ルール/5秒ルール (Web利用者は次のページ表示が3秒を越えると、次に閲覧してくれない)で能力不足になってしまう。だからこそ、これらを処理するには負荷分散が重要となる。
Webシステムの負荷分散
一般的に、Webシステムを構築する場合には、 1段:Webサーバ、2段:動的ページ言語、3段:データベースとなる場合も 多い。この場合、OS=Linux,Web=Apache,DB=MySQL,動的ページ生成言語=PHPの組合せで、 LAMP構成とする場合も多い。
一方で、大量のデータを処理するDBでは、フロントエンド,セカンダリDB(スレーブDB),プライマリDB(マスタDB)のWebシステムの3段スキーマ構成となることも多い。
フロントエンドは、大量のWebユーザからの問合せを受ける部分であり、必要に応じてセカンダリDBに問合せを行う。
大量のユーザからの問合せを1台のデータベースシステムで捌くには処理の負荷が高い場合、複数のデータベースで負荷分散を行う。プライマリDBは、複数のデータベースシステムの原本となるべきデータを保存される。負荷分散の為に分散されたセカンダリDBは、プライマリDBと内容の同期をとりながらフロントエンドからの問合せに応答する。
データベースシステム
データベースには、ファイル内のデータを扱うためのライブラリの BerkleyDB といった場合もあるが、複雑なデータの問い合わせを実現する 場合には、リレーショナル・データベース(RDB)を用いる。 RDBでは、データをすべて表形式であらわし、SQLというデータベース 問い合わせ言語でデータを扱う。 また、問い合わせは、ネットワーク越しに実現可能であり、こういった RDBで有名なものとして、Oracle , MySQL , PostgreSQL などがある。 単一コンピュータ内でのデータベースには、SQLite などがある。
リレーショナルデータベースの串刺し
商品名 | 単価 | 個数 | 価格 |
りんご | 200 | 2 | 400 |
みかん | 50 | 6 | 300 |
アイスクリーム | 125 | 1 | 125 |
みかん | 50 | 3 | 150 |
このような表データでは、たとえば「みかん」の単価が変更になると、2行目,4行目を変更しなければいけなくなる。巨大な表の場合、これらの変更は大変。
そこで、この表を2つに分類する。
|
|
||||||||||||||||||||||||||||
必要に応じて、2つの表から、以下のような SQL の命令で、データを抽出する。
select 単価表.商品名, 単価表.単価, 販売表.個数, 単価表.単価*販売表.個数 from 単価表, 販売表 ; |
データベースに求められるのACID特性
データベースシステムと呼ばれるには、ACID特性が重要となる。(次に述べるデータベースが無かったら…を参照)
- A: 原子性 (Atomicity) – 処理はすべて実行するか / しない のどちらか。
- C: 一貫性 (Consistency) – 整合性とも呼ばれ、与えられたデータのルールを常に満たすこと。
- I: 独立性 (Isolation) – 処理順序が違っても結果が変わらない。それぞれの処理が独立している。
- D: 永続性 (Durability) – データが失われることがない(故障でデータが無くならないとか)
しかし、RDBでは複雑なデータの問い合わせはできるが、 大量のデータ処理のシステムでは、フロントエンド,スレーブDB,マスタDB の同期が問題となる。この複雑さへの対応として、最近は NoSQL(RDB以外のDB) が 注目されている。(例: Google の BigTable)
データベースが無かったら
これらのデータベースが無かったら、どのようなプログラムを作る 必要があるのか?
情報構造論ではC言語でデータベースっぽいことをしていたが、 大量のデータを永続的に扱うのであれば、ファイルへのデータの読み書き 修正ができるプログラムが必要となる。
こういったデータをファイルで扱う場合には、1件のデータ長が途中で 変化すると、N番目のデータは何処?といった現象が発生する。 このため、簡単なデータベースを自力で書くには、1件あたりのデータ量を 固定し、lseek() , fwrite() , fread() などの 関数でランダムアクセスのプログラムを書く必要がある。
また、データの読み書きが複数同時発生する場合には、排他処理(独立性)も 重要となる。例えば、銀行での預け金10万の時、3万入金と、2万引落としが 同時に発生したらどうなるか? 最悪なケースでは、 (1)入金処理で、残金10万を読み出し、 (2)引落し処理で、残金10万を読み出し、 (3)入金処理で10万に+3万で、13万円を書き込み、 (4)引落し処理で、残金10万-2万で、8万円を書き込み。 で、本来なら11万になるべき結果が、8万になるかもしれない。
さらに、コンピュータといってもハードディスクの故障などは発生する。 障害が発生してもデータの永続性を保つためには、バックアップや 障害対応が重要となる
高専プロコン2020-2日目
リモート開催の高専プロコン2020の2日目、福井高専の3チームは発表・質疑応答が全チーム2日目。
最終結果
課題部門 Labocket
–XRによる理科学習サポートアプリケーション–敢闘賞 オーラルボイス
–機械学習による英語発音支援アプリケーション–敢闘賞
NICT賞(起業家甲子園挑戦権)🎉自由部門 House Pointer
–写真×AIで木造建築を守れ!–敢闘賞
発表風景
色々と経験です
オブジェクト指向のUML図
専攻科2年のオブジェクト指向プログラミングでは、レポート課題の最終テーマがUMLで自分の特別研究のテーマを表現する内容。
今年のレポートでは、なかなかいいUML図を書いてくる人が多かったので、メモ。
参照渡しを積極的に使う
オブジェクト指向のレポート課題を採点していると、若干きになることがあったので、補足説明。
複素数クラスのレポート課題で、add() などのメソッドが、私がサンプルコードで示したのがそうなっていたのが原因だと思うけど、以下のようなコードとなっている。
class Complex { // 略 public: void add( Complex z ) { re += z.re ; im += z.im ; } // ~~~~~~~~~ 値渡し } ;
処理速度の効率を考える場合は、以下のような参照型(参照渡し)を使うのが一般的。上記のような値渡しだと、機械語を生成する際には、実引数の複素数のコピーが行われるので、無駄な処理が発生しがち。参照型を使えば実引数をコピーする手間が不要なので、処理の無駄が省ける。(Complexのような簡単なクラスなら無駄というほどのものじゃないけど)
class Complex { public: void add( const Complex &z ) { re += z.re ; im += z.im ; } // 定数型 ~~~~~~~~~~参照渡し } ;
ただ、上記の参照型を使うと、addメソッドで、zの内部を書き換えるような間違った処理を記述してしまうと、add()の処理で実引数に副作用が発生する。このため、こういった書き間違いによる影響がないことを明示するために、上記のように、z に const 指定子を記載しておくのが一般的。const がついていれば、addメソッド内部で間違って、zを書き換えるような処理を記載しても、コンパイラが間違いを指摘してくれる。
PHPとセキュリティのレポート講評
5年生の前期実験で「PHPとセキュリティ」のテーマについて、レポートの採点を行った。
以下に、レポート記載での注意点や減点評価を行なったポイントをあげる。
レポートの記載書式について
- 電子レポート提出でも所属や報告者の記載をつけること。
今回は、遠隔実験でPDFファイルのアップロード提出であったため、表紙のつけ忘れなどが見られた。印刷媒体で残す可能性を考慮し、文章内に所属・出席番号・氏名なりの記入は必須。 - 図番号・表番号を必ず引用すること。
実験結果に図番号や表番号をつける習慣はみなさんついているが、本文中で必ず図番号や表番号を引用すること。前表によれば…はNG。「図1をみると…」「(表1参照)」などをつけること。図表は配置の都合で本文とは別のページに記載することもあるので、異なるページに配置されても、わかるように記載する必要がある。 - 章・節のインデントはしない。
今回は減点対象としていないが、卒業論文や卒研中間報告では、節や小節でインデントをしないこと。
特に、2段組みをする文書の場合、インデントが入るとただでさえ狭い1行が、スカスカになる。1. 論文書式ではダメな書き方 □この実験は... □のようなインデントは不要!! □...であった。 □1.1 背景 □□この問題の背景として... □□1.1.1 なんとかかんとか □□□なんとかかんとか
レポートの考察内容について
- PHPのプログラムの改良で、<input … maxlength=”xx”>とか、<input type=…> とか、<input … pattern=”xxx”>をとるといった考察があったが、これは不十分。例えば、Webページの HTML を、自分のサイトにコピーして、maxlenthやpatternを削除したページを作ってそこからPHPにデータを送ることで、相変わらずセキュリティの問題を引き起こすことが可能。HTMLのページを偽装しなくても、プログラムからphpに対して直接データを渡すこともできる。
このため、送られてくる入力値のチェック(一般的にはサニタイジングと呼ばれる)は、php側でも十分に行う必要がある。 - password の管理については、/etc/shadow ファイルの話までしか調べていない考察があった。
passwdコマンドは、SUID の説明と、その機能「一時的にpasswdコマンドの所有者rootの権限を借りる」の説明がないと減点とした。
考察のヒントに記載した、自分のパスワードが変更できるのなら/etc/passwdへの書き込み権限があるはず…と同じで、自分のパスワードを変更可能なら/etc/shadowに書き込み権限がある…という話になってしまうから。
(追記)
レポートの採点結果つけたよ…とTeamsで伝えたら、ゾロゾロと自分の点数を聞きにくる人多数。いつも、レポート返却しても教室に放置されてるし、他の先生の評価で平均されるから、あまり気にしないと思ってた。