key-valueストアの基礎知識
首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は Software Design 誌 2010年 2月号に掲載された以下の記事の元原稿です。 Software Design 誌編集部の了承の元に、本ウェブページに掲載しております。 首藤一幸: "key-valueストアの基礎知識", Software Design 2010年 2月号, p.14-21, (株)技術評論社, 2010年 1月 18日 クラウド、特にPaaS向けのソフトウェア開発が現実のものとなり、 そこではリレーショナルデータベースとは違ったデータベースが 勢いを増しています。 その代表であるkey-valueストアを解説します。 もくじ key-valueストアとは なぜkey-valueストアか key-valueストアの使いどころ key-valueストアとNoSQLの
マイクロソフト萩原正義氏MIJS講演「スケールアウト設計における問題点の考察と分析手法の提案」 : 小野和俊のブログ
昨年末にMIJSのコンソーシアム内での交流会があり、前回のはてな伊藤さん講演に続き、理事会の方から講演者の選定とコンタクトを依頼されたので、マイクロソフトの萩原さんに「クラウドの時代のデータモデリング」の講演をお願いした。 今回萩原さんに講演をお願いしたのは、以前参加させていただいたマイクロソフト系のイベントでの萩原さんの講演が大変興味深い内容だったからだ。 以下、今回の講演を聞きながら私がメモした内容である。 「スケールアウト設計における問題点の考察と分析手法の提案」 現在マイクロソフトでクラウドの技術のうち、開発の現場に対して、どういうやり方をしなければいけないかを提案する仕事をしている。 今日お話しする内容は、インターネットや書籍で紹介されているものよりも、深いところを話していきたい。とはいえ1時間という短い時間なので、ポイントを絞って話をしていきたい。マイクロソフトはWindows
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
株式会社マジカジャパンの羽生章洋が書いてるブログ:今日のCouchDB - livedoor Blog（ブログ）
メインフレーム時代とはCOBOL時代と言い換えてもいいでしょう（RPGやPL/Iの方には申し訳ない）。これは更に言い換えると固定長のパラダイムだとも言えます。オープンシステム時代になりRDBMSが主流となったときに一番のパラダイムシフトは、実は明細の扱い方だったと言えます。 COBOLをご存じの方はOCCURSを当然使っていたはずです。OCCURSとは繰り返しを表すもので、売上データというファイルがあったときに明細部分は繰り返しになりますから、OCCURSを指定します。ややこしい言い回しを使っていますが、要するに配列定義ということです。 さて、COBOLは固定長のパラダイムだと書きました。実はこのOCCURSで定義される配列は繰り返し数が事前に固定されます。例えばOCCURS 5.と書けば5回繰り返しということです。一応可変長が可能ということになってはいるのですが、多分今でも指定した上限を
グーグルはリレーショナルデータベースをクラウドに乗せるか
グーグルという会社は、例えばマイクロソフトやオラクルやアップルと比べると「戦略」といったものを積極的にはアピールしない会社です。 マイクロソフトやオラクルやアップルのような企業は、年に何度か大規模なイベントを開催し、現在の戦略や今後のロードマップを示します。しかしグーグルはそういった方法で将来像やスケジュールを明らかにすることはあまりなく、社内でこっそりと開発を続けて、ある日突然「こんなものができました」と発表する方を好むようです。 かつてGMailが登場したときも、そして先日Google App Engine for Javaが登場したときもそうでした。 そのためグーグルのクラウド戦略はどの方向に向かっているのか？ ターゲットとするデベロッパー層や、想定しているアプリケーションの姿といったものがどういったものなのか、次にどんな施策を打ってくるのか、といったことは想像するしかありません。
JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2008年12月22日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 今年のBlack Hat Japanには、はせがわようすけ氏が「趣味と実益の文字コード攻撃」と題して講演され話題となった。その講演資料が公開されているので、私は講演は聞き逃したが、資料は興味深く拝見した。その講演資料のP20以降には、「多対一の変換」と題して、UnicodeのU+00A5（通貨記号としての￥）が、他の文字コードに変換される際にバックスラッシュ「\」（日本語環境では通貨記号）の0x5Cに変換されることから、パストラバーサルが発生する例が紹介されている。 しかし、バックスラッシュと言えばSQL
「RDBMSの時代の終わりが見えてきた」についてそろそろ一言言っておくか - ひがやすを技術ブログ
2008-12-12 いくつか誤解を生みそうな表現があるので、それをまずは指摘しましょう。 プログラムモデルとしては、すでにRDBMSからの脱却の準備は始まっています。ORマッピングがそれです。 これが、意図的かはわからないけど、ミスリードを生んでいます。「RDBMSの時代の終わりが見えてきた」というタイトルで、こういう書き方をすると、「ORマッピングによって、すでにRDBMSからの脱却の準備は始まっている」という風に読めるでしょう。これが、ミスリード。 JPAが大切だと思っているのは、永続パラダイムの転換に、コーディングを変えることなく対応できるからです。もちろんJPA+RDBMSのシステムをJPA+非RDBMSに切り替えれるという話ではなく、プログラマのコードの書き方の対応の話です。 これをもう少し、噛み砕くと、JPAのJPQL(SQLもどき)を使えば、SQLとしては統一されていない複
RDBMSの時代の終わりが見えてきた - きしだのはてな
クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB
CodeZine にて KOF 2008 の記事と補足 - naoyaのはてなダイアリー
大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。 CodeZine で先日の KOF 2008 (あらかじめ言っておきますが King of Fighters ではないですよ、関西オープンフォーラムです) の発表を記事にしていただきました。ありがとうございます。 発表資料は以下のエントリーにありますので一緒にご覧いただければと思います。 http://d.hatena.ne.jp/naoya/20081111/1226395400 さて、記事内容について少し補足をしておきたいと思います。 メモリとディスクの速度比較について 「メモリはディスクの 150 倍」という話ですが、その後知人と話して検索のインデックスをシークする場合などは ms 対 ns くらい違
連載記事「スケーラブルなO/Rマッピングの実現手法」が面白い - 岩本隆史の日記帳（アーカイブ）
野村総合研究所の石田裕三さんがITA Issueに連載されている記事「スケーラブルなO/Rマッピングの実現手法」が面白く、今後に期待しています。 第1回 現状のO/Rマッピング手法に潜む問題点 第2回 O/Rマッピングの正しいモジュラリティを探る 第3回 Google File Systemに学ぶスケーラビリティの真髄【前編】――“富豪的”解決手段を超えて 第4回 Google File Systemに学ぶスケーラビリティの真髄【中編】――アプリケーションとプラットフォームの“協調設計” 私自身はサーバ数百台といった大規模システムとは縁がないのですが、オレオレフレームワークを作ろうと思っている関係上、データベースの扱いはやはり気になります。スケーラブルにできるものならそうしたいですよね。 第3回では、スケーラブルなO/Rマッピングの設計思想が書かれています。 （1）1回のクエリでアクセスす
データベースもアジャイル開発に対応したい！ （1/3） － ＠IT
Jiemamy作者が考える “データベースの進化的設計” データベースもアジャイル開発に対応したい！ アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく体制が必要です。アジャイル開発の考え方にのっとるなら、アプリケーションだけではなくデータベースについても設計の凍結はせず、また、ソースコードに限らずデータベースの構成・設計についてもリファクタリングが適用されるべきです。Jiemamyはこの問題に取り組むプロジェクトとして始められました。本稿ではこのJiemamyの取り組みを紹介します。 ソースやスキーマだけ管理しても意味がない 近年注目を集めている「アジャイル開発」は、リファクタリングが重要な要素の1つであることはご存じのとおりです。アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
性能大幅アップの「PostgreSQL 8.3」がリリース | エンタープライズ | マイコミジャーナル
PostgreSQLグローバル開発グループは4日 (米国時間)、オブジェクト指向リレーショナルデータベース管理システムの最新版「PostgreSQL 8.3」をリリースした。同プロジェクトのWebサイトでは、各種OSに対応するソースコードのほか、Windows、Red Hat Linux、Solaris用のバイナリパッケージが公開されている。 今回のリリースでは、Heap Only Tuples (HOT) を新たにサポート。テーブルやインデックスの肥大化が抑制され、大規模データベースにおける更新処理性能が大幅に向上、管理上のオーバーヘッドの3/4が取り除かれるという。同期スキャンにも対応、複数のセッションが同時に巨大テーブルを順スキャンするときの性能向上に貢献する。 システム全体のパフォーマンス低下を防ぐ目的で、「負荷分散チェックポイント」も追加。定期的にデータベースバッファとデータベー
PostgreSQL パフォーマンスチューニングまとめ - 徒然なるままにBlog
PostgreSQLをチューニングする機会があったので その時に調べたチューニング項目を備忘録として残しておきます。 バージョンの違いやサーバの規模などによっても 効果は変わってくると思うのであくまで参考程度のものですが。 ・shared_buffers 7系では8000〜10000程度まで引き上げる 8系では150000程度まで引き上げることが可能、100000程度が性能のピーク これに多く割り当てるよりOSのバッファ領域として使う方が性能が向上する テーブルサイズを割り出して設定するのがベスト 簡単に設定するなら搭載メモリ量の1/4、搭載メモリが多ければ1/2ぐらいでも可 ・max_connections 7系では256程度、8系では1000程度が性能のピーク ・work_mem(sort_mem) 適切なサイズに調整する、2048〜4096程度 プロセス毎
「1カ月1億2000万PVのR25.jpはPostgreSQLで動いている」---リクルート システム基盤推進室 米谷修氏
「4年前は採用できなかったが，1年前に再度挑戦してPostgreSQLを適用できた」---リクルート FITシステム基盤推進室フェデレーションオフィサーの米谷修氏は6月5日，「PostgreSQLカンファレンス2007」の講演で同社でのPostgreSQL活用事例を紹介した。 同社が最初にPostgreSQLの採用を試みた4年前「調査や検証，環境構築まで行ったにもかかわらず，採用を断念した」（米谷氏）。理由は，当時のPostgreSQL 7.1ではアーカイブ・ログを取得する機能がなく，障害が発生した際に更新データを完全に復旧できない場合がある可能性があったことだ。 それから3年が経過した1年前，PostgreSQLはアーカイブ・ログ機能を備えた。リクルートでは再度アーカイブ・ログの運用を含め調査，検証を行い，本番サービスに適用した。 それがR25およびL25のWebサイトである。1カ月約1
データベース操作ツールiSQL-Viewer、4年振りに一新して登場 | エンタープライズ | マイコミジャーナル
iSQL-Viewer project membersは3日(米国時間)、iSQL-Viewerの最新版となるiSQL-Viewer 3.0.0を公開した。iSQL-ViewerはJavaで開発されたJDBC 2/3互換のデータベースフロントエンドアプリケーション。Mozilla Public License version 1.1のもとオープンソースソフトウェアとして公開されている。 iSQL-ViewerがサポートしているデータベースプラットフォームはPostgreSQL、MySQL、Oracle、Informixなど。操作はひとつのUIに統合されており、対象のデータベース如何にかかわらず、同じインタフェースを経由して同じ操作を実施できる。 iSQL-Viewerの主な機能は次のとおり。 データベースの内容閲覧 データベーススキーマの閲覧 SQL命令を保持するためのSQLブックマーク
Google Research Publication: Bigtable: A Distributed Storage System for Structured Data
Bigtable: A Distributed Storage System for Structured Data Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber Abstract Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers. Many projec
2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要) - 最速配信研究会(@yamaz)
もう一ヶ月以上前の記事だけど,ニコニコ動画が1000万コメントを達成したというニュースがあった. 「24日で1千万コメント突破！ 「ニコニコ動画」が好調」 ドワンゴグループの1社で、メールポータルなどの事業を企画運営しているニワンゴは8日、同社がサービスを提供している「ニコニコ動画」（ベータバージョン）に投稿されたコメント数が、 オープンから24日で1,000万件を突破したことを発表した。また、1日のページビュー数が2,000万を突破していることもあわせて発表した。 http://www.rbbtoday.com/news/20070208/38344.html ニコニコ動画のすごいところは動画キャプション部は システム的に掲示板とほとんど同じで,おそらくその場に リアルでいる人の数はせいぜい数十人とかなのに,さも数100人 とかがその場にいるような臨場感を与えているところだと思う. モバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.itarchitect.jp/issue/-/129509.html