ホーム » 2021 (ページ 4)

年別アーカイブ: 2021

2024年5月
 1234
567891011
12131415161718
19202122232425
262728293031  

検索・リンク

データベースガイダンス2021

インターネットの情報量

インターネット上の情報量の話として、2010年度に281EB(エクサバイト)=281✕1018B(参考:kMGTPEZY)で、2013年度で、1.2 ZB(ゼタバイト)=1.2✕1021B という情報があった。ムーアの法則の「2年で2倍」の概算にも、それなりに近い。 では、今年2021年であれば、どのくらいであろうか?

しかし、これらの情報を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つに分類する。

単価表
商品ID 商品名 単価
1010 りんご 125
1011 みかん 50
2101 アイスクリーム 125
販売表
商品ID 個数
1010 2
1011 6
2101 1
1011 3
必要に応じて、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万になるかもしれない。

さらに、コンピュータといってもハードディスクの故障などは発生する。 障害が発生してもデータの原子性永続性を保つためには、バックアップや 障害対応が重要となる

専攻科の履修登録の確認作業

特例認定の専攻科で、学位授与機構の学位授与してもらうために、専攻科2年の学生さんの履修計画書のアップロードの期間となっている。履修科目の間違い(履修時期)のチェックも必要だけど、大量の行のチェックは大変。

履修登録のWebシステムで、履修科目のファイルを CSV 出力させた「申請者科目データ.csv」を、他の学生と比較してみる。

$ nkf -Lu -w 申請者科目データ.csv
  | awk -F, '{print $4,$9,$16}' > aa.csv
     nkf -Lu (行末文字コードを¥n)
         -w (文字コードをUTF8に変更)
     awk -F, (コンマで区切る)
         '{print $4,$9,$16}' (科目名,履修時期,履修/未習得)だけ抽出

$ diff -u aa.csv bb.csv | grep -v '^ ' | grep -v "0"$
     diff -u        違いを出力
     grep -v '^ '   先頭が空白の行を削除(違いがなかった)
     grep -v '"0"$' 行末が"0"を行を削除(履修していない)

キャンパスツアー2021

今日は、福井高専のオープンキャンパスです。「キャンパスツアー」ということで、各学科の展示を次々と見学します。

電子情報工学科では、各卒研室の中からいくつかのテーマにて発表してもらいます。

以前であれば、中学生と保護者の方が一緒に見学してもらっていましたが、コロナ対策ということで保護者の方には、Teamsのリモート会議の機能を使って別室にて各学科の発表会場の内容を見学してもらっています。

{CAPTION}

{CAPTION}

データと誤差(クラフテックラボ)

電子情報工学科のジュニアドクター養成講座・クラフテックラボでは、9/12(日)に、データと誤差の講座を行いました。
ストップウォッチでの時間の測定の実験を通して、誤差のズレやばらつきについて考えてもらう内容でした。
{CAPTION}

{CAPTION}

緊急連絡システムにSendGridを使ったら

丹南地区の緊急連絡システムを動かしているけど、最近はメールが届かないといった連絡を受けることも多い。

2021/09/10 については、docomo.ne.jp 宛のメールの配送でトラブルが発生し、設定を見直すことで無事に配送ができるように復旧することができました。

基本的に無料で提供しているサービスだけれど、Azure のサーバから送信すると、迷惑メールの送信者と誤認される可能性が高く、最近のキャリアではメールが届かないなどの問題が起こりやすい。

正しく配信されるようにするために、サーバを信用してもらえるような構成にすることも考えられるが、設定のメンテナンスの負担も懸念される。そこで、Azure サーバでメールを配信するための、有料サービス SendGrid を使うことを検討してみた。

最初に、有料システムを利用することになるので、どの課金体系を利用するのかを判断するために、現在の緊急連絡システムの月別のメール流量を集計してみた。この結果、最近ではコロナによる連絡も多いのか平均4万通/月のメールが流れている。多い時には、10万通を超える場合もある。(下図参照)

これを、元にSendGrid を使った場合の費用を算出してみる。一番安い料金 “Essencial 4k” では、1900円/月 (4万通/月,これ以上は、0.125円/通)、”Essencial 10k” では、3800円/月(10万通/月, これ以上は0.094円/通)となる。これを見ると、現状の平均 4万通 からしても Essencial 4k を採用すれば、約 年額 45,000 円 以下に収まると思われる。(下図参照)

 

教員室にhomebridge導入

自宅では、iPhoneとの連動で、Raspberry-Pi にhomebridgeを入れて、家電制御で便利に使っているけど、教員室の Linux サーバにも導入してみた。

自分のスマホに ping で所在確認するプラグインと、自室の在室や予定を表示している掲示板システムを操作するプラグインを入れてみた。

在室状態に応じて掲示板にメッセージを表示していたけど、更新間隔が1時間おきとかなので、「不在表示なのに居るじゃん…」とか学生からのチェックが入るので、ドアや充電器の所に置いてあるNFCをタッチすると、掲示板の在室/不在表示+予定表示するようにしてみた。

# 以前から同様なことはしていたけど、手抜き Web API 経由だったのを、ホームアクセサリとして動かしてみた。

変態コード

Twitterで以下のようなコードが紹介されていた。
ポイントは、a[i] と書くべき所が、*(a + i) と等価であり、*(i + a) = i[a] と書かれている点。

{CAPTION}

でも、昔どこかで見たという点では、以下のコードの方がさらに変態っぽいでしょ。

{CAPTION}

8/14(土)学校周辺のハザードマップ

福井県は、大きく心配するほどじゃないけど、危険性の確認。吉野瀬川の方が先に危なくなるらしい。
{CAPTION}

ゼロトラスト研究会

EVER/IPのコネクトフリーさんが、鯖江市・越前市・福井県・地元企業と協力して、EVER/IPの活用を見いだすためのゼロトラスト研究会が行われました。

{CAPTION}

ゼロトラストとは

  • LANなどの小さなネットワーク内を安全とする境界型セキュリティから脱却し、世界中のコンピュータを結ぶ。
  • 境界型セキュリティの限界。LANの中でも信用しないという考え方

IPv6

  • IPアドレスの詐称の可能性がある

EVER/IP

  • Advanced Security
  • Autonomous Networking
  • Authenticated Connectivity
  • 公開鍵暗号。公開鍵のハッシュがIPアドレス
  • ゼロタッチプロビジョニング

自治体ネットワーク、三層分離の見直し

  • 自治体の3層構造
    • 個人番号利用事業系
    • LGWAN接続系
    • インターネット接続系
  • LGWAN系、インターネット接続系に、リモートワークシステムが接続するには。

さくらクラウドの実験サーバのアップグレード

学生実験で、Webプログラムのセキュリティ問題の対応をテーマに実験しているけど、Ubuntu 18系を20系にアップグレードを行った。基本的な実験だけなので、Apache+PHP程度なので、移行も手間取らないだろうと踏んでいたけど、sulinux でちょっと手間取った。

# systemctl enable apache2
# aptitude install update-manager
# aptitude update
# aptitude dist-upgrade
# do-release-upgrade -d

無事に、更新が終わって再起動をかけたら、ブートに失敗。ssh などが繋がらなくなる。

どうしようもなくなったので、さくらのクラウドのコンソールをみると、sssd 関連でエラーが出てブート途中で止まっている。
冷や汗をかきながら、Ubuntu ブート時のリカバリーモードの起動を試みて、ようやく成功。

起動時にESCを押すと、ブートメニューが表示される。インストール済みの kernel とそのリカバリーモードの一覧がでるので、リカバリーモードでログイン。”aptitude remove sssd-common” により一旦、sssd を削除(sulinux関連)すると、無事に起動したので、基本機能の確認をして、再び”aptitude install sssd-common”。

アップグレード作業中に、apache2 が disable されていたり、php の関連パッケージが入っていなかったので、インストール。

# systemctl enable apache2
# systemctl start apache2
# aptitude install php-mbstring php-sqlite3
# a2enmod php7.4

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー