Open research data Tracking public money flows Open mapping Data for equal development Saint Catharines On March 5th come to Cowork Niagara to help create a map or other technological design to help to explain... Where citizens can give food Where citizens can find food You do not need any special skills to attend this event. We welcome all! Please feel free to join us. If possible, please bring a
翻訳について¶ このドキュメントは、RedisのWiki(http://code.google.com/p/redis/wiki/)の内容を参考にしながら、構成などはSphinxに合わせつつ翻訳しています。また、必要に応じて、配布物の中のファイルなども引用しながら訳しています。
@doryokujinです。本エントリーから数回にわけてMongoDBの紹介をつらつら書いていきたいと思います。日々、MongoDBの魅力にどっぷりな僕でして、それを少しでも多くの方に共有できたらというモチベーションで書いています。今回はチュートリアルとして主要な機能を少し詳しめに紹介していきます。アジェンダは以下の通りです： はじめに ちょっと詳しいチュートリアル オープンソース NoSQL・ドキュメント指向データベース ドライバとして多くの言語サポート 完全なインデックスサポート リッチなクエリー MySQLに類似した機能群 レプリケーション機能 オートシャーディング 巨大ファイルを扱うGridFS 今後の予定 本家ドキュメントの翻訳 より深い機能説明 勉強会での発表 Production Deploymentsとして弊社の名前を掲載する はじめに 僕は現在MongoDBをソーシャルア
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
「いまは新しい技術への大規模な移行をする時期ではないと確信している」。Twitterは、サービスの核となるツイートを保存するデータベースを、MySQLによる大規模分散データベースから、NoSQLデータベースであるCassandraへ移行しようとしていました。しかしCassandraへの移行作業を中止し、引き続きMySQLでの運用を継続すると、Twitter Engineering Blogへのエントリ「Cassandra at Twitter Today」で明らかにしました。 これは戦略の変更だ Twitterは利用者からのツイートを、Scalaによって独自開発したミドルウェア「Gizzard」とMySQL、そしてmemcachedを用いた大規模分散データベースに保存しています。 しかしこうした複雑なシステムによる運用は非常に手間がかかり、人的コストを中心としたコストの増加が非常に大きくな
機能と技術からわかる！システム基盤の実力 第4回とぎれなく流れ来る大量データを処理する「ストリームデータ処理技術」①ストリームデータ処理とは？ 近年、電子マネーや電子商取引が普及し、RFID利用による物流管理など、ビジネスで扱うデータの量が爆発的に増加しています。またビジネスのスピードも急激に加速しており、次々に流れてくる大量のデータをリアルタイムに処理することが求められています。 しかし、こうしたリアルタイム処理に従来からあるデータベースを使用すると、クエリなどを用いて蓄積されたデータを一括処理するため、データ検索などのクエリ実行時にタイムラグが生じてしまいます。そこで、現在注目されているのが、ストリームデータ処理技術です。 ストリームデータ処理技術とは、無限に到来する時刻順のデータ（ストリームデータ）をリアルタイムに処理するデータ処理方法です。たとえば、株価のテクニカル指標やランキング
Tuesday, May 18, 2010 Comparing PNUTS, HBase and Cassandra A lot of NoSQL systems have been sprouting up recently and an increasing number of people are using NoSQL data stores and moving away from RDBMS systems. There's nothing wrong with relational database systems but they are optimized for certain use cases, which they handle very well. NoSQL systems (Bigtable, Dynamo, PNUTS, CouchDB, MongoDB,
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
@marqsさんと@muranetさんと一緒にhbstudy#11で発表させていただきました。 これを機にとか言うとでかすぎる気がしますがCassandraが国内でも盛り上がるといいなーと思います。 懇親会でも結構使おうとしている方がいたりしてうちもうかうかしてられないですねｗ 資料をあげましたのでこちらよろしかったらどうぞ！ インフラエンジニアのためのcassandra入門 View more presentations from Akihiro Kuwano. これだけはかかないと！ 素晴らしい会を開いて下さっているハートビーツの方々や、スピーカーの方々、来ていただいた方々に感謝しております 非常に楽しかったです！ ただいま二日酔いですw
18.2 XML最大の災厄 XMLという技術を襲った最大の災厄とは、“僕の賢さ”を誇示しようとする“精神の子供たち”の大挙流入にあるといえる。ここでいう“精神の子供たち”とは、自分自身を自らの能力以上に優れた存在だと思い込んでいる者たちを指す。別のいい方をすれば、自己評価と社会からの評価にギャップがあるという問題を抱え込んでいる者たちだともいえる。つまり、「僕は本当はもっと優秀なのに、社会はそれを認めてくれない」という屈折を抱えた者たちである。 通常、社会と触れ合うことで、このような「思い込み」は「錯覚」であることが思い知らされ、自己評価を下げることで社会的評価との整合を取る。これが、精神的な意味で「子どもから大人になる」ということである。 ところが、XMLが生まれた前後の時代、1990年代後期から2000年代にかけては、インターネットが世界を変えるというある種の幻想が社会に蔓延し、インタ
原文(投稿日：2010/03/31)へのリンク 3月25日にMongoDB("humongous"より)1.4がリリースされた直後に、そのクリエータであるDwight Merriman氏(DoubleClickの前CEOおよびCTO)は、10gen(オープンソースのドキュメント・データベースを支援する企業)が、この製品の商用のトレーニングおよびサポートを提供する予定であることを発表した。 InfoQはこの機会を利用し、MongoDBについて、またその機能、適用範囲、NoSQLデータベースのコミュニティにおける立場についてMerriman氏に話を聞いた。Merriman氏の回答は、本記事の該当セクションで引用している。 MongoDBの概要 MongoDBは、スケーラブルでハイパフォーマンスな次世代データベースです。MongoDBのデータはドキュメントとして1つのデータ・オブジェクト内にすべ
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
If you look at the early days of this blog, when web scalability was still in its heady bloom of youth, many of the articles had to do with leveraging MySQL and memcached. Exciting times. Shard MySQL to handle high write loads, cache objects in memcached to handle high read loads, and then write a lot of glue code to make it all work together. That was state of the art, that was how it was done. T
ここを見てもらってる人に、「MongoDBって何がいいの？」と改めて聞かれてしまって、ああ、そっか、そういうこと書いてなかったな、と思ったので、なぜ自分がMongoDBに興味を持っているのか、ということを書いてみた。いざ自分の思いを書いてみたらRails中心の話になってしまったけど、モダンなフレームワークならそんなに話は変わらないのかな、と思っている。 そもそものきっかけは、ここ半年間くらいRuby on Rails(以下RoR)で開発していることにある。 ここ半年弱ほどRoRで開発をして、それなりに満足しているのだけど、ActiveRecordに関しては色々とひっかかるところがあった。 「ActiveRecordがRoRの素晴らしいところそのものだ」と評価している人もいるが、自分の中では逆で、ActiveRecordはRoRの中でもかなりいまいちな部分。 いや、ActiveRecordと
Scalable SQL and NoSQL Data Stores Rick Cattell Originally published in 2010, last revised December 2011 ABSTRACT In this paper, we examine a number of SQL and so- called “NoSQL” data stores designed to scale simple OLTP-style application loads over many servers. Originally motivated by Web 2.0 applications, these systems are designed to scale to thousands or millions of users doing updates as wel
Indexed Database API 3.0 W3C Working Draft, 7 November 2024 More details about this document This version: https://www.w3.org/TR/2024/WD-IndexedDB-3-20241107/ Latest published version: https://www.w3.org/TR/IndexedDB/ Editor's Draft: https://w3c.github.io/IndexedDB/ Previous Versions: https://www.w3.org/TR/2024/WD-IndexedDB-3-20241015/ https://www.w3.org/TR/2024/WD-IndexedDB-3-20241015/ History: h
苦労もノウハウもコミュニティで共有、Club DB2 次はIBM DB2のコミュニティ、Club DB2です。商用データベース製品の中ではオフラインの活動が活発なところです。普段は隔週で勉強会をしていますが、毎年年末には盛大なイベントを開催します。 今年は「IOD Winter Forum with Club DB2 冬の5時間スペシャル」でした。第1部はみっちりとDB2 pureScaleテクノロジー解説が行われ、この様子はWeb配信されました。途中の質問タイムは20分も続くなど、参加者の関心や熱意が高いのがClub DB2らしいところです。 DB2 pureScaleは前回もレポートした通り、超スケーラブルでシェアード型なDB2 9.7のオプションです。ある人は「IBMが出す（オラクルの）RACみたいなもの」と称していました。当たっているような、いないような？ 第2部はDB2事例などの
1. Key-Value stores: a practical overview Marc Seeger Computer Science and Media Ultra-Large-Sites SS09 Stuttgart, Germany September 21, 2009 Abstract Key-Value stores provide a high performance alternative to rela- tional database systems when it comes to storing and acessing data. This paper provides a short overview over some of the currently avail- able key-value stores and their interface to
This document discusses different database technologies, including Oracle RAC, Salesforce Force.com, and Google App Engine Datastore. It then focuses on PHP RDBMS options like MySQL Cluster and potential open source alternatives. The rest of the document summarizes the Incline and Pacific databases from Cybozu Labs. Incline provides horizontal sharding for MySQL and supports ACID transactions acro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
