GoogleのBigTableを参考にオープンソースで開発されたHBaseは、HadoopのファイルシステムであるHDFS上に構築されたキーバリューストア型のデータベース。高いスケーラビリティや柔軟なテーブル構造、自動シャーディングやフェイルオーバー機能などを特長とします。 そのHBaseがバージョン1.0に到達したことが、The Apache Software Foundation Blogにポストされた記事「The Apache Software Foundation Announces Apache™ HBase™ v1.0」で発表されました。 The Apache Software Foundation Announces Apache™ HBase™ v1.0 : The Apache Software Foundation Blog 1.0で行われた改善点や新機能として以下が上
どんなところに使える？ HBaseやCassandraはどちらもRDBMSで扱いきれないような大規模なデータの扱いに力を発揮します。強力なスケーラビリティも備えているため、データが増えても処理速度はそれほど低下しません。また、列指向データベースの強みを活かして、大量のデータを更新するようなバッチ処理のストレージとして利用しても有用でしょう。 具体的な利用シーン 大規模なデータをスケーラブルに処理する必要がある場合 大量データをバッチ処理する際のストレージとしての利用 HBaseのインストール 本稿では、実際にHBaseを使ってみましょう[1]。 まずは1台のサーバ上で環境を整えます。わかりにくかもしれないので、以下の手順を参考にしてください。JDK6およびHadoopのインストールが必要です。 プロンプト1 HBaseのインストール＆起動の手順 # http://java.sun.com
今やビッグデータのランダムアクセス系処理に欠かせない技術となったHBase。導入する企業や組織が続々と増える中、現場では運用や設定を行う上でのまとまった知識が求められています。 オライリー・ジャパンでは今年7月、日本語のものとしては初のHBase総合解説書となる『HBase』(Lars George 著、Sky株式会社 玉川 竜司 訳 全584ページ)を刊行いたしました。同書では、クライアントAPI（高度な機能・管理機能）、Hadoopとの結合、アーキテクチャといった開発に関わる事項や、クラスタのモニタリング、パフォーマンスチューニング、管理といった運用の方法を、豊富なサンプルとともに解説。この日本語版ではさらに、AWS Elastic MapReduceについての付録を独自に追加するなど、より実践的な内容となっており、読者から高い評価を得ています。 著者のLars George 氏は、2
ビッグデータのランダムアクセス系処理に欠かせないHBaseについて、基礎から応用までを詳細に解説。クライアントAPI（高度な機能・管理機能）、Hadoopとの結合、アーキテクチャといった開発に関わる事項や、クラスタのモニタリング、パフォーマンスチューニング、管理といった運用の方法を、豊富なサンプルとともに解説します。日本語版ではAWS Elastic MapReduceについての付録を追加。ビッグデータに関心あるすべてのエンジニアに必携の一冊です。 序文 訳者まえがき はじめに 1章 HBaseの紹介 1.1 ビッグデータの夜明け 1.2 リレーショナルデータベースシステムの問題 1.3 非リレーショナルデータベースシステム、Not-Only SQLあるいはNoSQL？ 1.3.1 観点 1.3.2 スケーラビリティ 1.3.3 データベースの（非）正規化 1.4 構成要素 1.4.1 背
ハンガリーの企業でCTOを務めるKristof Kovacs氏による記事です。各主要NoSQLプロダクトについて機能比較や利用ケースなどをまとめています。この記事ではCassandraやRedisなど6つのプロダクトを挙げています（表1）。 CouchDBは使い勝手に優れており、双方向レプリケーションやリアルタイム更新をサポートしています。Redisは非常に高速なことが売りで、トランザクションや変更監視の機能が備わっています。Cassandraは書き込みが読み込みよりも速いことから銀行や金融などのリアルタイムなデータ解析が必要になる分野で実力を発揮し、Cassandraと同じくJavaで作られているHBaseは億単位の行と数百万のカラムというBig Dataを扱え、月に1,000億を超えるメッセージを処理するFacebookのバックエンドに採用されています。 次々にプロダクトが生まれた
世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは：LINE Developer Conferenceまとめリポート（前編）（3/3 ページ） LINEにおけるネットワーク周りの高速化への取り組み LINEビジネスコネクトなどの利用が本格化していくと、サービスや通信の負荷は増大していく。LINEでは、サービスの高速化に向けてどのような取り組みを進めているのだろうか。 SPDYの最適化 LINEのクライアントとサーバー間は、HTTPを拡張して高速化を図ったプロトコルである「SPDY」をベースに通信を行っている。なぜSPDYの仕様をそのまま使っていないかというと、LINEサーバーの場合は、通信の相手はLINEアプリしかなく、UserAgentは1種類に限定される。UserAgentが未知の状態でサーバーがリクエストを受け付ける場合、どのプロトコルで相手と通信するかを最初に
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
Facebookが新しいサービス「Messages」の基盤として、NoSQLデータベースの「HBase」を選択したことを、先日の記事「Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった」で紹介しました。 HBaseは、Facebookによると次のような特徴を備えていると説明されてます。 負荷に対して非常に高いスケーラビリティと性能を発揮 CassandraよりもシンプルなConsistency Model（一貫性モデル）を備えている 自動ロードバランス、フェイルオーバー、圧縮機能 サーバーごとに数十個のシャードを割り当て可能、などなど このHBaseはどのようなデータベースなのでしょうか？ 情報を集めてみました。 HBase入門のプレゼンテーション 最初に紹介するのは「HBaseエバンジェリスト」Tatsuya Kawano氏のプレゼン
1. HBase at LINE ~ How to grow our storage together with service ~ 中村 俊介, Shunsuke Nakamura (LINE, twitter, facebook: sunsuk7tp) NHN Japan Corp. 2. 自己紹介 中村 俊介 • 2011.10 旧 Japan新卒入社 (2012.1から Japan) • LINE server engineer, storage team • Master of Science@東工大首藤研 • Distributed Processing, Cloud Storage, and NoSQL • MyCassandra [CASSANDRA-2995]: A modular NoSQL with Pluggable Storage Engine based on
1. 第2回 NHNテクノロジーカンファレンス （2012年8月18日） 日々進化するHadoopの 「いま」 株式会社NTTデータ ／ 日本Hadoopユーザー会 濱野 賢一朗 Copyright © 2012 NTT DATA Corporation 2. 自己紹介 濱野 賢一朗 （はまの けんいちろう） @hamaken 株式会社NTTデータ 基盤システム事業本部 シニアエキスパート • 『BizXaaS Hadoop構築・運用ソリューション』 『CDH Hadoopサポートサービス』 の中の人 日本Hadoopユーザー会 翔泳社 『Hadoop徹底入門』 監修者 話題になった経産省のHadoop報告書のPM • 経済産業省 『分散制御処理技術等に係る データセンター高信頼化に向けた実証事業』 • http://www.meti.go.jp/policy/mono
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
