Design Patterns for Distributed Non-Relational Databases
The document discusses design patterns for distributed non-relational databases, including consistent hashing for key placement, eventual consistency models, vector clocks for determining history, log-structured merge trees for storage layout, and gossip protocols for cluster management without a single point of failure. It raises questions to ask presenters about scalability, reliability, perform
Google 技術講演会に行ってきた
Google 技術講演会に行ってきた Permalink URL http://www.magicvox.net/archive/2007/02062254/ Posted by ぴろり Posted at 2007/02/06 22:54 Trackbacks 関連記事 (0) Comments コメント (1) Post Comment コメントできます Category 先日2月2日、渋谷セルリアンホテルで行なわれた Google 技術講演会を聴講してきました。Google Japan でソフトウェア エンジニアをされている3名の方から夫々興味深いお話しを聞くことができました。講演の後は気さくな軽食パーティもあって、Google Japanの社員の方々ととても充実した時間を過ごせました。 目次 講演メモ 講演メモ - 南野 朋之さん 講演メモ - デリック トングさん 講演メモ -
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
A BILLION ROWS PER SECOND Metaprogramming Python for Big Data
Ville Tuulos Principal Engineer @ AdRoll ville.tuulos@adroll.com We faced the key technical challenge of modern Business Intelligence: How to query tens of billions of events interactively? Our solution, DeliRoll, is implemented in Python. Everyone knows that Python is SLOW. You can't handle big data with low latency in Python! Small Benchmark Data: 1.5 billion rows, 400 columns - 660GB. Smaller e
Being healthy dev and ops in Cookpad
Talked at DevOpsDay Tokyo 2013 http://connpass.com/event/3052/ http://togetter.com/li/569904
Google の大規模データ処理: Days on the Moon
Google の鵜飼文敏さんによる講演会「大規模データ処理を可能にする Google の技術」に行ってきました。内容的には筑波大学で開かれたものと同じではないかと思います (「新ビジネスモデル」がそのままだったことなどから)。以下、上記記事に載っていないことを中心にメモから抜書きを。 此頃 Google にはやる物 現在 Google では Google の使命 (Google's mission is to organize the world's information and make it universally accessible and useful...) の早打ちが流行中。鵜飼さんは 50 秒程度、一番速い人は 30 秒程度。 Google の扱う情報 Google のいう「情報」はインターネット上のものだけに限らない (例: Google ブック検索)。 データセンター
GPUへのMapReduceの適用に関する調査 - nishio-dens's diary
概要 近年、GPUの性能は飛躍的に向上しており、グラフィック専用の処理装置としてではなく、数値計算等の汎用向けの処理に利用する、GPGPUに関する研究が盛んに行われている。GPUは内部に多くのコアを備えており、NVIDIA社のGeForce GTX 580では、512個ものコアを保持している。これらのコアすべてを効率よく利用することで、GPUの持っている高いパフォーマンスを引き出すことが出来るが、GPUの高い並列性を利用するためにはGPU特有の処理を実装する必要があり、GPUプログラミングになじみの無い利用者にとっては処理の記述が困難である。 そこで、GPUを大量のコアを持ったプロセッサだと考え、これらに対してMapReduceを適用することを検討する。親しみやすいMapReduceインターフェースにあてはめて処理を記述するだけで、GPUの高い並列性を生かしたプログラムが実装可能となる。加
Dead Letter Channel Pattern with RabbitMQ
メッセージングシステムで送信されたメッセージが正常に処理されなかった場合どうするのか? RabbitMQ 2.8 以降では expire したメッセージや拒否されたメッセージを dead letter として専用の exchange に転送する事ができる。 dead letter になるユースケース 以下のケースで、メッセージは dead letter になる The message is rejected (basic.reject or basic.nack) with requeue=false The TTL for the message expires Enterprise Integratin Patterns との対比 Gregor Hohpe & Bobby Woolf の “Enterprise Integratin Patterns” では 前者は Invalid M
ØMQをつかってLevelDBをClient-Server型にする
Google が開発する KVS の LevelDB はライブラリーとしてのみ提供されており、そのままではクライアント-サーバ型では使えない。 There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library. http://code.google.com/p/leveldb/ ググったところ、ØMQ(zeromq) を使ってサーバサイドを実装した LevelDB Server というプログラムがあった。ØMQ のお勉強を兼ねて実装をメモ。 LevelDB Server 概要 2011年11月に github 公開。その後、放置(LevelDB は2011年
Kestrel:Reliable Read
メッセージングシステムで、dequeue 後に正しく処理できずに異常終了したらどうなるのか? Twitter などで利用されている Kestrel には reliable read という仕組みがあり、一度 dequeue したアイテムの処理中にエラーが発生しても、キューの先頭に enqueue できる。 この動作を実際に確認してみた。 Reliable Read Command Memcached プロトコルで reliable read をするには、キューからアイテムを取得する際に / に続けて以下のオプションを指定する。 /open : 一時的に dequeue /close : dequeue を確定 /abort : dequeue を取り消し、queue の先頭に enqueue Reliable Read Examples 以下の4パターンについて、キューの処理と peek
TwitterでつぶやいたStormの雑多な情報まとめ（その３ - 夢とガラクタの集積場
こんにちは。 #stormjp のタグでStormの雑多な情報まとめその３です。 段々前置きとかが思いつかなくなってきましたが、とりあえず入ります＾＾； ○19.StormとKestrelを組み合わせることで『Kestrelから取得したメッセージをStormで処理完了したことを保証する』 アプリケーションが構築可能。 Kestrelは「Transaction」という仕組みを持っており、 ackが返されなかったメッセージは一定時間でメッセージを復旧させるため。 そのため、Storm側で成功したらackを返し、失敗／タイムアウトしたらfailを返すように Kestrelとやり取りをすればＯＫ。 上記の動作をする雛形はStorm-Kestrelにある。 ○20.Nimbus、Supervisor、workerは各々ローカルに一時ファイルを出力する。 出力先は【STORM_HOME】ディレクトリ配
BigData Counts
During work and play, many times one has to make ‘back of the envelope’ calculations. Sometimes it is hard to get a perspective on scale and various aspects of big data – numbers like millions and billions or even GB/TB/PB et al. So I have started collecting a few representative numbers that can add perspective to any calculation. Please suggest more … PetaByte vs ExaBytes vs ZettaByte vs YoottaBy
Metaprogramming Python for Big Data
For many companies, understanding what is going on in your business involves lots of data. But, how do you query 10s of billions of data points? How can a company begin to make sense of so much information? Ville Tuulos, Principle Engineer at AdRoll, a company producing tons of big data, demonstrates how AdRoll uses Python to squeeze every bit of performance out of a single high-end server. They m
オンラインブックマークという移り変わりの激しいWebサイトについて
オンラインブックマークというサービスの価値に、私は当初、懐疑的だった。だが、実際のところ、ブログのネタを探す目的には、非常に役に立っている。 大勢の人間が、わざわざオンラインブックマークをするからには、そのURLには、大勢の人間の興味を惹きつける、何らかの要素がある。それがいいものにせよ、悪いものにせよ、だ。とくに、個人が最近書いた秀逸な技術的なブログ記事などは、このようなオンラインブックマークで話題にならなければ、なかなか見つけにくい。 日本語圏では、このオンラインブックマークは、はてなブックマークが事実上独占しているようだ。ただし、はてなブックマークは、英語圏のオンラインブックマークが提供している、ある根本的な機能が欠けている。フォーラムだ。はてなブックマークのコメント機能はとても貧弱で、到底、汎用的なフォーラムの代替とは成り得ない。英語圏で有名なオンラインブックマークは、いずれもフォ
ITエンジニアのCAPの定理 - from scratch
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
Webサービスの基礎知識 | OSDN Magazine
物理的に離れたコンピュータのプログラム間で情報を交換できることは、今日の企業における標準的な要件の1つだ。そしてリモートリソースへの最も一般的なアクセス方法が、HTTPによるサーバからクライアントへのHTMLファイルの転送、要するにWebサイトである。こうした情報伝達のやり方が功を奏している理由は、シンプルで身近に利用できるテクノロジと標準規格が使われている点にある。しかし、Webサイトには根本的な限界がある。Webページの情報を理解できるのは人間だけで、コンピュータにはそれができないことだ。 Webサービスは、コンピュータどうしを直接結んでリモートリソースにアクセスする方法の1つである。本稿では、SOAPのような基本的なWebサービス標準規格と、WS-*規格群として知られる高度な拡張機能を紹介する。 Webサービスがほかの手法と違うのは、シンプルなXMLメッセージを使って情報を送る、転送
STORM
1. STORM COMPARISON – INTRODUCTION - CONCEPTS PRESENTATION BY KASPER MADSEN MARCH - 2012 2. HADOOP VS STORM Batch processing Real-time processing Jobs runs to completion Topologies run forever JobTracker is SPOF* No single point of failure Stateful nodes Stateless nodes Scalable Scalable Guarantees no data loss Guarantees no data loss Open source Open source * Hadoop 0.21 added some checkpointing
TwitterでつぶやいたStormの雑多な情報まとめ（その８ - 夢とガラクタの集積場
こんにちは。 #stormjp のタグでStormの雑多な情報まとめその７です。 段々、終わりが見えてきたような感はありますｗ ○81.Stormクラスタ自体のアップデートは起動しっぱなしでは無理。 安全確実を期すなら下記のフロー。 １．Topology全部落とす ２．Storm-Nimbus、UI、Supervisorを落とす ３．ZK上とローカルのファイルを全部削除 ４．Storm-Nimbus、UI、Supervisorを再起動 尚、Stormにとっては動作しながらのクラスタ自体のアップデートへ対応する優先度は低い。 ○82.storm.yamlのworker.childoptsでWorkerプロセス起動時のJVM引数を指定できるが、 その際「%ID%」と指定すればWorkerプロセスのIDに置換されて実行される。 83.LinearDRPCですとSpout/Boltの生成タイミング
リアルタイム分散処理Stormの耐障害性は？ - Tech-Sketch
リアルタイム分散処理とは 「ビッグデータ」処理のためにHadoopを用いますと、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易に可能となります。 ところがHadoopの弱点としまして、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理が行われますので、処理データが発生してからそれに対する処理結果が得られるまで必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサーデータなどでの異常値検出のようなリアルタイムなレスポンス(低レイテンシー)が要求されるビッグデータ分野へのHadoopの適用は向いておりません。 このような随時発生する大量データ（ストリーミングデータ）を、蓄積せずにリアルタイムに処理する「リアルタイム分散処理」が求められています。 今回は、リアルタイム分散処理のソリューションとしてTwitter社より公開された
Akka vs. Finagle vs. Storm
Akka, Finagle and Storm are 3 new open source frameworks for distributed parallel and concurrent programming. They all run on the JVM and work well with Java and Scala. They are very useful for many common problems: Real-time analytics Complex website with different input and outputs Finance Multiplayer games Big data Akka, Finagle and Storm are all very elegant solutions optimized for different p
Announcing JBoss DNA 0.6 - JBoss.ORG
To download the release go to . UPGRADING Before upgrading refer to for a complete list of changes. ALL RESOLVED ISSUES ENHANCEMENTS * [Documentation] - Configuring trusted certificates - Fully specify truststore path dist/quarkus BUGS * oidc - Java… In this tutorial, we’ll learn how to integrate Redis into a Jakarta EE application using the Lettuce client library. Redis is a powerful in-memory da
Big Data Real Time Analytics - A Facebook Case Study
Building Your Own Facebook Real Time Analytics System with Cassandra and GigaSpaces. Facebook's real time analytics system is a good reference for those looking to build their real time analytics system for big data. The first part covers the lessons from Facebook's experience and the reason they chose HBase over Cassandra. In the second part of the session, we learn how we can build our own Real
なぜ akka を使うべきなのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
馬鹿にはマルチスレッドは複雑すぎる わたしマルチスレッド怖いんです。なんでかっていうと、あれ、これってスレッドセーフだっけ？とか考えないとだめだし、えーっとこの変数は別のスレッドからアクセスされる可能性があるから〜とか考えないとだめ。あとロックをここで取得して〜とか本番運用してたら考慮漏れで「あー不整合が〜！！」とかそういうの。そういうの追うの大変だし、わたしは馬鹿だから、やってて辛い気持になるんですよそういうの。 で、これ、要するに複数の平行に走ってる処理がひとつのミュータブルなものを共有しているから起こることなんですよね。「ミュータブルなデータを共有する」からロックが必要になるし、「どこで書き変わるかわからない」っておびえることになる。そしてスレッドセーフでないコードにトラウマを負わされ、「よくわかんないけどマルチスレッドってなんとなく怖い！」みたいな恐怖を覚えたプログラマーが a =
『Javaではじめるakka入門』
はじめまして。 ブロググループ所属の見原と申します。 今回は先日担当した案件で利用した、akkaを紹介させていただきます。 はじめにakkaはtypesafeが提供する、イベント駆動の分散並列型アプリケーションフレームワークです。 並列処理が簡単に記述出来るほか、複数のマシンを用いた分散処理の実現、 「let it crash」という設計思想に基づいたロジックとリカバリ処理の分離などが特徴です。 akkaのサンプルはscalaが多いのですが、今回はjavaで説明していきます。 まずはMavenを利用したアプリケーションを作成します。 akkaを利用するため、以下をpom.xmlに記載します。 <repositories> <repository> <id>typesafe</id> <name>Typesafe Repository</name> <url>http://repo.type
"Hbase at Facebook" に行ってきた - たごもりすメモ
名称表記が揺れてて微妙だけど Hbase at FaceBook on Zusaar このイベントに行ってきた。Facebookの人は "HBase Tokyo meetup" と認識していたようだ。 内容のまとめはやらないので、以下の各ページなどをご覧になると良いのではないでしょうか。 Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… Hbase at FaceBookのまとめ - Togetterまとめ FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編） － Publickey FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編） － Publickey セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。
Xldb2011 tue 0940_facebook_realtimeanalytics
This document summarizes Facebook's real-time analytics systems. It describes Data Freeway, which uses a scalable data streaming framework to collect log data with low latency. It also describes Puma, which performs reliable stream aggregation and storage by sharding computations in memory and checkpointing to HBase. Future work may include open sourcing components and adding scheduler support.Rea
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How big is a Petabyte, Exabyte, Zettabyte, or a Yottabyte? - High Scalability -
ChangeLog を支える英語