ISO/IEC/IEEE 42010 Homepage
Welcome to the ISO/IEC/IEEE 42010 Website This is the website for ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description, the latest edition of the original IEEE Std 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems. If you are a first time visitor, you may want to start with the Frequently Asked Questions (FAQ) or Getting Sta
GlusterFS技術情報 - アーキテクチャ(1)
複数のストレージノードのローカルファイルシステムを論理的に統合した「ボリューム」を作成して、クライアントからマウント可能にします。GlusterFSのクライアントパッケージを導入した「Nativeクライアント」では、マウントしたボリュームは、通常のファイルシステムとしてアクセス可能になります。 Nativeクライアントは、ファイル名のハッシュ計算に基づいて、実際にファイルを保存する決定して、該当のストレージノードにアクセスを行います。 ボリュームを定義する際は、各ノードのディレクトリを「ブリック」として指定します。1つのボリュームはこれらのブリックの集合として作られます。１つのノードが複数のブリックを提供することも可能です。また、ノードごとに提供するブリック数、ディレクトリ名などを揃える必要はありません。 ボリュームサイズを拡大／縮小する際は、ボリュームに対するブリックの追加／削除を行いま
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
コンピュータアーキテクチャの話 Hisa Ando | コラム | エンタープライズ | マイコミジャーナル
新着記事一覧 【連載】乗って! 撮って! 食べて! 江ノ電で旅気分 第2回 観音様や大仏を上手に撮影しよう--長谷・極楽寺編 [10:39 9/30] ミリタリーアクションドラマ第3シーズンが放送! - 『ザ・ユニット3〜』 [10:00 9/30] 【特集】『クリミナル・マインド』 研究部 [10:00 9/30] 【レポート】ネットで申し込める"お気軽"自動車ローンに注目--三井住友銀行&みずほ銀行 [10:00 9/30] 【連載】山田塾長の結婚必勝方程式 第2回 エリート難民にパラサイト親子…あなたは「結婚できない男」ではないですか? [10:00 9/30] 1タブ1プロセスを実現したMac用ブラウザ「Stainless」登場 [09:41 9/30] 安藤建築の原点「住吉の長屋」を原寸大で再現 - 安藤忠雄建築展 [09:37 9/30] 【AIRコレ】オフライン
アーキテクチャドキュメントに必要なこと [arch]
最近本腰を入れて大掛かりなアーキテクチャ設計をしようとしているが，ドキュメントを書く際にいつも帰ってくるのがこのエントリー． Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal: What should be in an Architecture Document? とても素晴らしい内容なので，以下に意訳しておきます．ぜひ原文も合わせて読んでみて下さい． - ドメインモデル (もしあれば)，使用されているパターン，ガイドラインなどに特化したドキュメントを合わせて紹介すること．アーキテクチャドキュメントは，それらのガイドラインと整合性を保つこと． - 1つのドキュメントは50ページを超えないこと．肥大化したドキュメントは誰にも読まれない (少なくともその全ての内容は)． - 当たり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
