ビッグデータの取り出し

ビッグデータをいかに分解し、いかに関連性のあるデータに加工するかは至難の技術。
Hadoopを利用するにしても費用面では不明・・・
また、開発コストがかかります。

そこで費用対効果にはAWSのEMRを利用することをお勧めする。
これによって、ビッグデータを取り出すことが可能となります。

ビッグデータの可視化

ビッグデータについてAWSを利用して可視化が可能です。
今後大きく成長する分野です。
当社ではAWSを利用してビッグデータの解析を行います。

AWSはよい

AWSは使いやすい。他のクラウド環境に比較すれば価格面はよい。
ただ、いろいろな機能があるので使いこなすまでは時間がかかる。
これをクリアすれば、アプリケーションの作成および、運用面では大幅なコストダウンが可能。

活用は英文が多いので苦手な人や会社が多いが、うまく使いこなしましょう。

プログラム的には、PHP、JAVAが主であると思いますが、Rubyやpythonを利用すると、大幅なコスト削減が可能です。

初歩的にはEBTを利用してサーバ構築が可能で、あとはアプリケーションの配置。
簡単なアプリケーションでサーバおよび、運用面は他のクラウドに比較してやすい。

ただEC-CUBEや単なるホームページに関しては、他のクラウドのほうがよい。
プログラムを利用する場合には便利。

AWSについては後日説明します。

Oracle物理設計3

◆サーバプロセス設計
アプリケーションからSQLを受け取ると、データの取得やバックグラウンドプロセスと連携して処理を行い、アプリケーションに結果を返す。
・サーバプロセスはPGAというメモリーを使用
・PGA_AGGREGATE_TARGET：全サーバプロセスで領域を共有し、必要に応じて割り当てを行う
・メモリが安価⇒専用サーバ接続が増える

◆インスタンス設計
SGAとバックグラウンドプロセスとで構成される
・SGA設計
システム規模や処理の特性、使用するOracleデータベースの機能など⇒SGAサイズが変わる
各コンポーネントに割り当てるメモリサイズを検討
　⇒自動化しても予期しないメモリ変動には対応はできない。

・バックグラウンドプロセス設計
各プロセスの機能を理解するだけで設計には影響が少ない

◆データベース設計
・制御ファイルの多重化の検討
・REDOログファイルのメンバ数とグループ数の検討
⇒ストレージの容量とも検討課題
・初期化パラメータファイルをpfile、spfileにするかの検討
・パスワード認証を許可するかどうかの検討

◆DBパラメータ設計
・データベース名、ドメイン名の検討
・ブロックサイズの検討
・キャラクタセット、ナショナルキャラクタセットの検討
⇒~記号の関係でJA16SJISTILDE
⇒ ナショナルキャラクタセットの利用は少ないが、デフォルトのAL16UTF16のほうがUTF8で利用するバイト数が減る
・アーカイブログモードにするかの検討

ネットワーク4

◆L2スイッチ
メモリ上のMACアドレステーブルを基にフレームをスイッチング
・受け取ったフレームのポートと送信元MACアドレスの登録
・知らないMACアドレスをフラッディング
・使用しない時は削除

◆VLANの利用
・VLANでブロードキャストを分ける
　⇒VLANはブロードキャストを分割して、トラフィックの効率化をする
・ポートVLANで1ポートにつき1VLAN
・タグVLANでケーブルを1本化
　⇒仮想化環境でも使用できる
　⇒ネイティブVLAN
　　　接続機器間(L2スイッチ同士)のVLANIDとネイティブVLANも合わせる

◆ARPで論理と物理をつなぐ
ARPはIPアドレスからMACアドレスを求める
・ブロードキャストでIPアドレスをしる