Visual Studio 2015 Professional VB.NET 単体テストの作成
Visual Studio 2015 Professional VB.NET(以下、VB)にて、MSTestを利用した単体テストの自動化を試しています。ユニットテスト・フレームワークはたくさんありますが、VisualStudio標準の「MSTest」から使ってみようというところです。
手順を確認した際に、VBにおいてコードエディタ上のコンテキストメニューから「単体テストの作成」が行えない現象が発生する場合がありました(※VBの単体テストプロジェクトを手動で作成する方法や、C# の場合には問題なく行えました)。 現時点で、他の端末での動作等は未確認のため、端末依存の問題であるかどうか不明で、また、設定が不足している、VisualStudioの不具合とも断定できない状況ではあります。
ただ、VBにおいても、コードエディタ上で右クリックから単体テストの作成を行えた方が便利と思い、コンテキストメニューから「単体テストの作成」が行えない現象を回避する方法を見つけましたので、記載しておきます。
■前提
前提としては、コードエディタ上のコンテキストメニューに「単体テストの作成」を表示する設定が行われていることです。まずは、「単体テストの作成」をコンテキストメニューに表示する設定を行う必要があります。
以下のサイトはVisualStudio2012の手順にはなりますが、参考になりました。
VisualStudio2015でも同様の手順で設定が行えます。
すがろぐ – visualization
■手順(例)
VBでコードエディタ上のコンテキストメニューから「単体テストの作成」を行うための操作
(1) メニュー[ファイル]から[新規作成]で[プロジェクト]を選択します。
(2) VBのクラスライブラリを選択します。OKボタンを押下します。
(4) ソリューションエクスプローラーで、ソリューションを右クリック→[追加]→[新しいプロジェクト]を選択します。
(5) C#のクラスライブラリを選択します。OKボタンを押下します。
(8) (C#)以下のエラー画面が表示されます。[OK]ボタンを押下します。
(12)(VB)単体テストのプロジェクト、テストコード(テンプレート)が自動生成されます。
その後、C#のプロジェクトを削除しても、
問題なくVBのコードエディタ上からの右クリックで「単体テストの作成」は行える状況でした。
■バージョン情報
「RDBMS」と「NoSQL」の比較
【１】「RDBMS」- ACID特性
RDBMS(リレーショナルデータベース管理システム)は、ACID特性という概念に基づいて設計されている。
ACID特性とは、トランザクション処理において必要とされる4つの要素、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）を頭字語で表したもの。
■ACID特性
| 要素 | 説明 |
|---|---|
| A:原子性 (Atomicity) |
トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質。 |
| C:一貫性 (Consistency) |
トランザクション開始と終了時に予め与えられた整合性を満たすことを保証する性質 。 Consistencyは日本語では「一貫性」あるいは「整合性」とも呼ばれる。 |
| I:独立性 (Isolation) |
トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指し、日本語では分離性、独立性または隔離性ともいう。より形式的には、独立性とはトランザクション履歴が直列化されていることと言える。この性質と性能はトレードオフの関係にあるため、一般的にはこの性質の一部を緩和して実装される場合が多い。 |
| D:永続性 (Durability) |
トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを指す。 |
【２】「NoSQL」 - BASE特性とCAP定理
NoSQLはBASE特性という概念に基づいて設計されている。
クラウド、ビッグデータ処理において、中心的な概念となるのが「BASE特性」と「CAP定理」。
BASE特性とは、「基本的には常に利用可能で、常に整合性を保っている必要はなく、一時的に一貫性のない状態を許容して、結果的には整合性が取れている状態に至る」という特性。
インクトミの創業者、カリフォルニア大学バークレー校の計算機科学の教授エリック・ブリュワー氏が、
「ACID」とは対照的に、可用性や性能を重視した特性を持つ分散システムの特性を「BASE」という文字で表した。
CAP定理はブリュワーの定理とも呼ばれる。分散コンピュータシステムのマシン間の情報複製に関する定理。
ウェブサービスを想定して作られた定理。
2000年にエリック・ブリュワー氏によって提案され、その後、2002年にマサチューセッツ工科大学のセス・ギルバート氏、ナンシー・リンチ氏によって証明されており、定理として確立されている。(CAP定理 - Wikipedia)
■NoSQLのデータモデル
| ①Key-Valueストア | ②Key-Valueストア | ③ドキュメントDB | |
|---|---|---|---|
| データ モデル |
Key-Value | カラム指向(ワイドカラム) | ドキュメント指向(JSON) |
| 特徴 | ・データアクセスが高速 ・小さい多数のデータの 蓄積が得意 |
・一部のものは スキーマ定義が必要 ・カラム指定での範囲検索、 集計処理が得意 |
・ドキュメント毎に 異なるデータ構造を持てる ・属性に対する検索・集計が可能 |
| 活用例 | ・キャッシュサーバ ・ログ蓄積 |
・大規模データ処理 ・ログ蓄積 ・ログ分析 |
・ログ分析 ・Webシステム ・オンラインゲーム |
| OSS例 | ・memcached ・Redis |
・Cassandra ・HBase |
・MongoDB |
■BASE特性
| 要素 | 説明 |
|---|---|
| (BA) Basically Available |
基本的にいつでも利用できる。 |
| (S) Soft-State |
常に整合性を保っている必要はない。 |
| (E) Eventual Consistency |
結果的には整合性が保証される。 |
NoSQLの特徴を表している概念として覚えておきたいところ。上記３つの工夫をして、性能をスケールさせていることにより、ビッグデータを扱えるようになっている。
■CAP定理
定義：ノード間のデータ複製において、同時に次の3つの保証を提供することはできない。
| 保証 | 説明 |
|---|---|
| C:一貫性 (Consistency) |
全てのノードで同時に同じデータが見える。 |
| A:可用性 (Availability) |
単一障害など一部のノードで障害が起きても処理の継続性が失われない。 |
| P:分断耐性 (Partition-tolerance) |
任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。 |
CAP定理によると、
分散システムは「C」「A」「P」の3つの保証のうち、同時に2つの保証を満たすことはできるが、
同時に3つの保証すべてを満たすことはできないとされている。
CAP定理により、
データベース管理システムは「CA型」「CP型」「AP型」のいずれかのタイプに分類できる。
RDBMSは「CA型」、NoSQLは主に「CP型」または「AP型」となる。
■CAP定理によってデータベース管理システムのタイプを分類
| タイプ | 説明 |
|---|---|
| CA型 (C:一貫性とA:可用性を重視) |
データはいつでも利用可能で一貫している。 →単一データベースサーバ |
| CP型 (C:一貫性とP:分断耐性を重視) |
データを分散しつつも整合性を保持する。 →整合性保持のため、複製中は全てのノードでデータ更新されるまで ロックをかけて不整合を阻止する。 →ロックがかかっている最中はAvailableではない。 |
| AP型 (A:可用性とP:分断耐性を重視) |
データは分散され、いつでもデータにアクセスできる →データ複製中は不整合な状態になり得る。 →Cはある程度妥協する。（Eventual consistency） |
■各タイプ別にデータベース管理システムを分類
| タイプ | データベース管理システム |
|---|---|
| CA型 (C:一貫性とA:可用性を重視) |
リレーショナル型：Oracle、MySQL、PostgreSQL、SQLServer カラム指向：Vertica |
| CP型 (C:一貫性とP:分断耐性を重視) |
Key-Value：Redis、memcached、Scalaris カラム指向：BigTable、HBase ドキュメント指向：MongoDB |
| AP型 (A:可用性とP:分断耐性を重視) |
Key-Value：TokyoTyrant/Cabinet、Dynamo、Voldemort カラム指向：Cassandra ドキュメント指向：SimpleDB、CouchDB、Riak |
(参考文献)
『RDB技術者のためのNoSQLガイド』秀和システム
(参考URL)
RDBMSとNoSQLの周辺技術や考え方の整理
http://tanakakns.hatenablog.com/entry/20140502/1399019336
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
http://shunichi-arai.blogspot.jp/2012/09/nosqlcapbaseeventual-consistency.html
IoTに適したNoSQL・分散Key-Valueストア
https://thinkit.co.jp/story/2014/09/25/5280?page=0%2C1
Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
CAP定理-wikipedia
https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
NoSQL登場の背景、CAP定理、データモデルの分類
http://www.publickey1.jp/blog/10/nosqlcap.html
12年後のCAP定理: "法則"はどのように変わったか
https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed
CAP定理
http://namihira.hatenablog.com/entry/2013/12/19/233853
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理
http://jyukutyo.hatenablog.com/entry/20090430/1241174854
データベースを分類する２つの軸、４つのエリア
【１】重視する性能による分類軸
①ターンアラウンドタイム重視
→クエリの応答速度を重視
②スループット重視
→単位時間あたりのデータ処理量を重視
【２】性能拡張モデルによる分類軸
①「スケールアウト」によって性能拡張できるもの（「スケールアップ」でも性能拡張できる）
②「スケールアウト」によって性能拡張できないもの（「スケールアップ」でのみ性能拡張できる）
※「スケールアウト（水平スケール）」とは
サーバーの数を増やすことで、サーバー群全体のパフォーマンスを向上させること。
※「スケールアップ（垂直スケール）」とは
性能の高いマシンへと入れ替えたり、メモリやハードディスクを増設したり、
CPUをより上位スペックに交換（スペックアップ）したりして、
サーバーそのもののパフォーマンスを向上させること。
（参考文献）
①『RDB技術者のためのNoSQLガイド』秀和システム
www.shuwasystem.co.jp
「分散KVS（Key-Value Store）」と「可視化」 その２
で、今のところの情報を整理してみる。
KVSとはKeyとValueの組み合わせでデータを管理する仕組み。
RDBのデータ構造と比較して、「単純なデータ構造」であるために高速化を実現する。
KVSは、大きく分けて①「揮発性KVS」と②「永続性KVS」がある。
①「揮発性KVS」
オンメモリでデータを扱うデータベース。分散キャッシュサーバ等に使用される。
高速ではあるが、データが一定量を超えた場合や、データベースやOSの再起動などでデータが消去されるものもある。
②「永続性KVS」
オンディスクストレージでデータを扱うデータベース。
揮発性KVSと比較して速度は落ちる。データの記憶容量と永続性の高さが特徴的。
①と②はもちろん用途によって選ぶ。
KVSはRDBよりも安価に大量のデータを保管できるため、データ同士に関連性がないため、分散化のコストが安い。サーバー複数台に分散して保存できるためスケールアウトしやすい。
「スケールアウト」とは、サーバーやネットワークといったインフラの性能を上げる方法の１つ、
「サーバの数を増やすことで、サーバ群全体のパフォーマンスを向上させること」。
・大量のサーバーにKVSを分散させて
「単純なデータ構造」、「オンメモリ」または「データの記憶容量と永続性」の威力を発揮させる。
・サーバーの数を増やせば増やすほど、①「揮発性KVS」を使いこなせば使いこなすほど
「単純なデータ構造」と「オンメモリ」の威力を発揮する。
・サーバーの数を増やせば増やすほど、②「永続性KVS」を使用すればするほど
「単純なデータ構造」と「データの記憶容量と永続性」の威力を発揮する。
・サーバーの数を増やせば増やすほど、「負荷分散」になる。
・サーバーの数を増やせば増やすほど、大量のデータであっても爆速データ処理を実現できる。
上記のようにKVSを分散させた仕組みを「分散KVS」と呼ぶ。ということだろう。たぶん。
今日は可視化の話は無し。
「分散KVS（Key-Value Store）」と「可視化」
データベースにも得意・不得意がある。
KVS(Key-Valueストア)は、RDB（リレーショナルデータベース）と比較して分散化のコストが安く、負荷分散に強く、可用性が高いそうだ。RDBが得意なものはRDBを使う、KVSが得意なものはKVSを使う。そうして、RDBとKVSの両方を使い、そして２つを適材適所で使い分けることにより、補完しあうことで、高速レスポンスを実現できるということになるらしい。
KVSにも弱点はあるが、高速である主なポイントとしてはインメモリ(オンメモリ)であることが挙げられる。
メモリのアクセス速度はHDDの10万~100万倍。そのためRDBの値をKVSに保持して使う。保持する方法は「RDBのレコードをそのままセット」「RDBのレコードを結合または加工してセット」等がある。要するに、データをメモリ内に読み込み、それを使いまわすことで、高速なデータアクセスを実現することが可能らしい。
他にも特徴はあるが今日はここまで調べたという事で。いったんKVSの特徴についての調査は終わりにする。
以下はKVSの活用事例まとめ。
Googleはどのようにして巨大なデータからの検索結果を返しているのか？
分散Key-Valueストアの本命「Bigtable」。
分散Key-Valueストアの本命「Bigtable」 - ＠IT
株式会社ミクシィでは、
RDBMSはMySQL、自社開発のKVS「Tokyo Tyrant」を使用している。
自社開発のKVS「Tokyo Tyrant」は高負荷なログイン処理の実装に使用しているそうだ。
分散Key-Valueストアの本命「Bigtable」（1）：もう1つの、DBのかたち、分散Key-Valueストアとは (1/3) - ＠IT
株式会社フリークアウトでは、
RDBMSはMySQL、KVSはHadoop hBase、Tokyo/Kyoto Product(Tokyo Cabinet、Kyoto Cabinet)、memcached などを使用している。しかも、クラウド全盛の中「自作サーバー」でRTBのシステムを構築・運用しているようだ（ただし海外事業ではAWS（アマゾン ウェブ サービス）も利用している様子）。
「20ms台への挑戦、Webエンジニアがアドテクノロジに惹かれた理由とは」フリークアウト 大窪 聡 氏 | ギークアカデミー ｜IT・Web業界の転職ならDODAエンジニア IT
(以下は引用)
本質的な仕組みは、人間を対象にしたWebサービスのシステムと同じです。ただ、RTBのシステムは非常に時間にシビアな点が違います。Webサービスでシステムが人間を相手にレスポンスを返す場合、1.5～2秒の猶予はあります。ところがRTBでは必ず100ms以内に収めないといけません。私たちのシステムでは平均して20ms程度のレスポンスを実現しています。これだけ短いとMySQLのようなDBMS（データベース管理システム）に接続する時間も取れませんから、KVSの使いこなしが重要になってきます。
www.slideshare.net
ログの可視化関連は多くの企業が
Fluentd、Norikra、Elasticserch、Kibanaを使ってると見受けられた。
以下①~④は概要説明。
①ログ収集「Fluentd」：
ログの収集、中継ツール、ElasticsearchやNorikraへデータを転送する。
②ログ解析「Norikra」：
SQLストリーミングを解析する。
③ログ検索「Elasticsearch」：
大人気の全文検索エンジン。
④ログ可視化「Kibana」：
Elasticsearchへ格納されたデータを可視化する。
