今回は、「Amazon EC2」のインスタンスを停止してもデータが失われないストレージオプションである「Amazon Elastic Block Store（EBS）」の使い方や活用方法を紹介し、「Amazon EC2」を取り巻くデータバックアップ方法を紹介していきます。 はじめに 前回は、「Amazon EC2」をより実践的に扱うためのオプションや、GUIで簡単に操作できるツールの利用手順を紹介しました。 今回は、「Amazon EC2」のインスタンスを停止してもデータが失われないストレージオプションである「Amazon Elastic Block Store（EBS）」の使い方や活用方法を紹介し、「Amazon EC2」を取り巻くデータバックアップ方法を紹介していきます。 前提条件 今回も前回同様「Amazon EC2 Command-Line Tools」を利用した方法を紹介していき
Cloud Serversは、メモリ256MB/ディスク10GBのインスタンスから用意されていて、 このミニマムのインスタンスが$0.015/時間で借りることができます。1ヶ月利用で$10.8。 256MB以上のインスタンス、例えばメモリ1GB/ディスク40GBのインスタンスでも$0.06/時間。 ディスク容量がネックになる用途以外では魅力的なラインナップではないでしょうか。 特にテスト機や実験機として一時的に利用したいようなケースでは、ロースペック・ローコストはとても助かります。 自動バックアップサービスが無料 バックアップと言ってもデータ自体のバックアップではなく､LVMのスナップショットベースのバックアップになります。 ファイルを個別に取り出すことはできませんが、データを復元する上では全く問題ありません。 このスナップショットがインスタンスごとに3つまでストックできるようになっていて
計測元は、都内のBフレッツでISPはライブドアプロバイダ。 計測とグラフ描写のコードはここに: http://github.com/hirose31/monitor-latency グラフは、紺色の線がレイテンシの平均値で、水色の範囲は最小値と最大値。 ping RTT まず、ホットなシンガポールのEC2。このグラフだけ、表示期間が1日分。だいたい90msecぐらいですね。 続いてEC2のwestとeast。この2つだけ、計測期間がちょっと古くて2010/3/27のもの。 Amazon EC2 アメリカ西海岸 125msec Amazon EC2 アメリカ東海岸 200msec あとはいろいろ。 ニフティクラウド Google JPIX はてなブックマーク 都内某iDC httping データは httping -c 10 -i 0.7 -r -g TARGET_URLの結果の最小値、平均
仰々しいタイトルをつけてますが、 たいしたことは書いてません(´･ω･`) なぜKVSを試していたのか？ 今月に入り、KVS・・・というより、 NoSQL系の技術をいろいろ試してきたわけですが、 そもそも何を目的としているのか、というと・・・ ＜前提＞ 100万件以上あるDBテーブルが複数ある データとしては一つの集合だが、論理的にパーティショニングされている そこまで大きくはないが、他にも多くのテーブルがある これをある程度任意のクエリで検索させたい 既存システムは決まった検索から出力を行うため、それに特化した仕組みになっている 論理的なVIEWテーブルを作ったり ＜目論見＞ クエリをテーブル単位で分割し、クラスタサーバに割り振って検索を実行させる クエリをそのまま流せば確実にDBが耐えられない ある程度時間的余裕があるとはいえ、何十分もかけたくはない 一テーブルの処理に数分かかるとすれ
はじめに NoSQL（Not Only SQL）という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで、不得意なところにはRDBMSにこだわらず、用途に合ったデータストアを使いましょう』という考え方です。最近では、いわゆるNoSQLデータベース （key-valueストアや各種データベース） が次々と登場してきています。 そこで今回から数回に渡り、それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。 RDBMSの強みとは そもそも、MySQLやPostgreSQLなどのRDBMSの弱みを補うため、様々なNoSQLデータベースが登場してきたわけですが、RDBMSにはたくさんの強みがあることも忘れてはいけません。 RDBMSの強み データの一貫性 （トランザクション） 更新時のコストが少ない（JOINが前提でテーブルが正規化されている）
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF（単一故障点）を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach
Working with hugedomains.com was a quick and easy process. We got to speak to multiple real people located in Colorado without having to wait on hold! Our only complaint was we felt we had to overpay more than this particular domain was worth, and we weren't able to negotiate it down to a level that we felt was fair. However, payment and delivery were seamless, and within a few hours we had all of
昨年末から「NoSQL」という言葉をネット上で見かけるようになった。字面だけを見ると「もはやSQLは必要ない」（No SQL）という意味にも取れる。だが実際には、「SQLだけに限らない」（＝Not Only SQL）というのが正しいようだ。 NoSQLとは、SQL言語を利用しない非リレーショナルデータベース（RDB）を総称した表現である。代表的なものとして、数値や文字列といったデータ（value）を1個のキー（key）にひも付けて管理する「key-valueストア」がある。 key-valueストアで処理できるのは、keyで検索を実行してvalueの値を読み書きすることだけである。「販売単価が100円以上、1000円未満の製品情報だけを抽出」といった、SQLでは当たり前のように処理できる操作をNoSQLでは実行できない。RDBのようにデータの一貫性を厳密に保持しているわけでもない。 過去に
「今後12カ月以内にWebインフラを新しく立ち上げるプロジェクトの大多数は，プライマリ・データストアとしてRDB以外のデータベースを選ぶだろう」。オープンソースのデータベース開発プロジェクト「MongoDB」を支援する米10genのCEOであるDwight Merriman氏（写真1）は，「Web 2.0 Expo New York 2009」でこう予測した。 Merriman氏は，「表と表の関係でデータを処理するリレーショナル・データベース（RDB）は，現在のWebアプリケーションの実態にそぐわない。リレーショナル・モデルに向かないデータ処理や分析処理が急増しつつある」と指摘。Webでは，写真や動画といった巨大データを多数のユーザーがやり取りし，クレジットカード情報もあればTwitterのつぶやきまでと価値の異なるデータと混在している。このため最近Web技術者の間で「NoSQL」と呼ばれ
非リレーショナルモデルのデータベース全般を指す「NoSQL」という用語について議論が巻き起こっています。 グーグルのBigTableやアマゾンのSimpleDBなど、クラウドへの注目が高まると同時にキーバリュー型データストアにも関心が集まり、さらにHadoopなどの新しいソフトウェアも登場してきました。このPublickeyでも、一昨日、昨日と記事で紹介してきました。 データベースは目的別に使い分けるべし NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある こうした非リレーショナルなデータベースを指す一般的な名称が求められてきたときに登場したのが「NoSQL」という名前です。 なんとなく考案された「NoSQL」 「NoSQL」という用語を考案したとされるEric Evans氏は、この名称は特に何も考えずに適当に思いついた言葉だとブログに書いています。ブログ「E
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
どうもこんにちは!! Amazon EBSで Apache2とmysqlを動かしてみた 自称EC2マニアのWebデザイナーです。 ↑こちらが実際にAmazon EC2上で動いているサービスです。 無料ホームページ素材ダウンロード [ Web-Stylish!! ] / テストサイト いかがです？ お気づきになられましたか？ そうなんです…。お世辞にも速いとは言えませんよね…？ （これでもいちお「Gzip」というパフォーマンス処理をしてある） いくら高性能のサーバといえど、置かれているのは遙か海の彼方アメリカ。 物理的な距離の壁は越えられず、結局この程度の通信速度になってしまうんですね。 別にそこまで重くないからいいんぢゃない？ そう思えるならばここでゴールなのですが、 ビジネスの成功にとってWebサイトのパフォーマンスが非常に重要であることを 体験してきた私にとっては、イマイチ乗り気になれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
