「Apache HBase」がバージョン1.0に到達、開発開始から7年で
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で行われた改善点や新機能として以下が上
halook -Hadoop・HBaseの可視化-
halookとは 大量のサーバで構成されるHadoopクラスタの状態把握にお困りではないでしょうか？ halookとは、当社が開発しているWGP、ENdoSnipeを用いて、Hadoop・HBaseの内部を直観的に見える化するツールです。 halookを利用することで、今まで多くの人手と時間が必要だった、問題個所の発見・解決が容易に行えます。 halookでは、HDFSのサーバごとの使用サイズ・空きサイズ、各タスクの状況、HBaseのRegion数などを見える化することができます。 (2012/11/08現在の機能です。) ニュース ■2013/02/05(火) 日経コンピュータにHadoopのシステム開発・運用を容易にする国産OSSツールとして、当社のhalookが紹介されました。 ■2013/01/22(火) 当社の落合が、Hadoop Conference Japan 2013 Wi
HBase 0.96 で導入される新しいコンパクション「Exploring Compaction」 - 科学と非科学の迷宮
Hadoopアドベントカレンダー2013、3日目を担当する @shiumachi です。 今回は HBase 0.96 の新機能を一つ紹介します。 要約 HBase 0.96 は賢くなったのでみんな使おう。 コンパクションのおさらい HBase では、Log Structured-Merge tree (LSM-tree) というデータ構造を使っています。 LSM-tree を簡単に説明すると、入力されたデータをログとメモリ上のデータストア(Memstore、メモリストア) に書き込みます。 メモリストアがいっぱいになると、まとめてディスクにフラッシュし、新しいストアファイルを生成します。 このストアファイルがたまってきたときに、少しづつ一まとめにしてなるべくファイル数を少なくするようにします。これがコンパクションです。 コンパクションを実行することにより、ファイルは一つにまとまります。こ
HBase論争に釣られてみる - 科学と非科学の迷宮
HBaseコミッター達による、NoSQLの記事への反論が面白かったので翻訳してみました。 著者の許諾取得済み。Thanks Stack and the other authors! 本文 原題: Taking the Bait Information Weekは先日、「HBase はNoSQL を支配するのか?」という記事を掲載した。MapR の Michael Hausenblas は HBase の事例に「賛成」の論陣を張っており、Apache Cassandra の Jonathan Ellis とベンダーである DataStax は「反対」の側だった。 この「ディベート」をベンダーのセールストークとして却下し、Apache HBase に立ち戻り、HBase を使用し、改善していくのは、簡単な話である。しかし、この記事は特別に問題のある例だった。記事では、「賛成」と「反対」の双方と
Hadoopのディスクあふれ対策(補足) - 科学と非科学の迷宮
最近流行りのディスク容量があふれたときの挙動、Hadoop編を書こうと思ったらwyukawaさんが既に書いてくださったのでやめました。 ……と思ったのですが、せっかくなので id:wyukawa さんが書いてない箇所を補足してみようと思います。 ( この記事は @kernel023 にレビューしてもらっています。ありがとうございます ) wyukawaさんの記事へのコメント まずHBaseを使っている場合はcompactionがある関係上Disk使用率は50%以内に抑えておくのが無難だと思います。この辺はCassandraと同じですね。 全データを同時にコンパクションするケースはまずないので無理に50%以下に抑えなくていいとは思いますが、意識はしておいた方がいいですね。 私は60%での警告を推奨しますが、この辺はケースバイケースです。 MapReduce の出力結果など、いきなり容量増える
Cloudera Searchってのが出たらしい（とりあえず、雑感？）
AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。 英語力はあやしいので、おかしいとこがあったらツッコミを。 Cloudera Searchとは？ CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？ 基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。 どんな仕組み？ 次のものを利用しているようです。（GithubのREADMEから。） 使ってるもの Apache Solr(4.3.0＋α？) Apache Lucene（Solrつかってるからね） Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？）
HbaseとHadoopMR - 急がば回れ、選ぶなら近道
Hbase勉強会のまとめの延長として 今後の考え方をまとめておきます。 まずは前提として <一般論> Hbaseにかぎらず、NoSQL系一般に言えることではあるが Usecaseを意識して利用する事が必要だ、ということだと思う。 最近の傾向としては、Googleでも顕著だけど、 一定の用途をターゲットにして 特定のミドルを開発するという方法が結構多い。 Hbaseもその流れはあるので、 そのあたりは意識する必要はあるかもしれない。 Hbaseついては、注目するとすればFacebookになるかな。 http://www.cloudera.com/resource/hw10_hbase_in_production_at_facebook いずれにしても、割とうまくいっているUsecaseの情報の有用性は 他の技術よりも高いと思う。 基本的に単純に分散KVSを使いたいならHbaseにこだわる必要
次世代アーキテクチャ - 急がば回れ、選ぶなら近道
次世代アーキテクチャについての考えをまとめておく。 まずは、Hbaseの勉強会のお話。 某界隈では割と話題になったので、 細かいブログやサイトは結構、紹介されている。 ので特に詳細は省く。 一応tatsuyaさんのSlideshareは Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… slideを見ているだけでは、よくわからないと思うが Jonathanとの会話では、FBはバックエンドの部分を含めて バッチ処理は別のHadoopクラスターで行っている。 相当バリバリ使っているようだ。 したがって、割と話題になっているHbase上でHadoopMRはどうよ？ っていう話は「分ける」ってのが正解に近く、 フロント処理とバック処理は明快にわけることが基本になるようだ。 その上での印象で、 自分の思ったこ
分散データベース「HBase」の安定運用を目指して - Preferred Networks Research & Development
1年経ってiPhone4の電池がヘタってきた、太田です。 指数関数的にエントリ数が少なくなってきた本ブログですがw、景気付けのためにエントリを投稿したいと思います！本日はHBaseについてです。 Linux と Hadoop と HBase と ZooKeeper に詳しいあなた！あなたがターゲットです。 HBaseとは? HBaseとは、HDFS (Hadoop Distributed File System)上に構築された分散データベースです。大量の非常に細かいデータをリアルタイムに読み書き出来るのが特徴です。最近ではFacebook Messageの基盤技術として使用された事で注目を集めています。 HBase公式サイト Apache HBase ブック 保存されたデータはHDFS上に保存され、HDFSの仕組みによってレプリケーションされるため安全にデータを保持することが出来ます。 ま
Facebookの新しいリアルタイム解析システムとは？ - nokunoの日記
Facebookの新しいリアルタイム解析のシステムでは、HBaseで1日200億件のイベントを処理しているそうです。以下の記事の翻訳です。High Scalability - High Scalability - Facebook’s New Realtime Analytics System: HBase to Process 20 Billion Events Per DayFacebookがまたやってくれた。彼らは巨大なリアルタイムデータのストリームを処理するもう1つのシステムを構築したのだ。以前にもFacebookはリアルタイムなメッセージシステムをHBaseで構築している(http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.ht
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
Hypertable のリード開発者が Hadoop と分散データベースを語る
最近、データベース関連の話題が盛り上がっている。IBM はこのほど(source)、Amazon EC2 上で動作するクラウドエディションをサポートする EnterpriseDB (source)に出資したし、Amazon は去年の終わりごろに独自のクラウドデータベースをリリースした。Google の BigTable(source) も、オープンソースではないにもかかわらず、コミュニティによる学習や研究の対象となっている。このような流れの中(source)、ふたつのオープンソースプロジェクト HBase(source) と Hypertable (source)が、 BigTable にインスパイアされたスケーラブルなデータベースを実装するために Map/Reduce プラットフォームである Hadoop (source)を活用している。InfoQ は Hypertable 産みの親で、
RwJ:Apache Hadoopのデータベース「HBase」を設定してみた
このサイトページは次の URL に移転しました。 0秒後に新 URL に転送します 自動で移動しない場合は恐れ入りますが下記をクリックしてください。 RwJ
Runtime error - Meta Search
Error message : Directory is not found or not writable (DATA_DIR) Directory is not found or not writable (DIFF_DIR) Directory is not found or not writable (BACKUP_DIR) Directory is not found or not writable (CACHE_DIR) Site admin: whitestar Copyright © 2006-2023 whitestar. All Rights Reserved. Icons powered by famfamfam. PukiWiki 1.5.0 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HBaseを使って簡易アクセス解析サービスを作ってみよう