Microsoft Azure - クラウドにおけるフォールト トレランスの問題点と解決策
レプリカ セットでの実行が必要なデータベース ノード数が同数の場合 (たとえば、1 つのレプリカ セットに対して 2 つのデータベース ノード)、MongoDB では決定者の考え方が採用されます。決定者はマスター選出時に投票サーバーとしての役割を果たします。ただし、(コストとリソースを節約するために) データベース スタック全体を実行することはありません。そこで、MongoDB レプリカ セットのデータベース ノードは 2 つで十分という形に落ち着いた場合、第 3 のノード、つまり決定者が必要になります。この決定者は、障害が発生した際に過半数ベースのマスター選出で票数を増やすためだけに配置されます。 SQL Server AlwaysOn 可用性グループでも同様の状況が発生します。この場合、新しいプライマリ ノードを選出するために過半数のノードが必要になります。投票しか実行しないメンバーの
Azure MLでガジェクラかどうか判定してみよう #azurejp #jazug - かずきのBlog@hatena
たなかさんからこんな問い合わせがありました。 かずきせんせー、Azure MLで異常値検出をしたいです— たなか@ (@tanaka_733) 2015, 10月 8 @okazuki みんなの端末所持数一覧から異常な人をあぶりだすのはどうでしょう？— たなか@ (@tanaka_733) 2015, 10月 8 なので手動でインタビューをしてサンプリングしたのと一般人を大量投入したデータを作ってみました。 おでさん（予測値）が際立ちますね。 クラスタリング さて、教師なし学習の代表例？であるクラスタリング（要は分類）してみたいと思います。データをつっこむと勝手にデータをグルーピングしてくれるというやつですね。便利便利。 データのアップロード 先ほど作成したデータをML StudioのDATASETにアップします。 EXPERIMENTSの作成 ガジェクラ判定機という名前でEXPERIME
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
