タグ

dbに関するruiccのブックマーク (54)

  • SQLで木と階層構造のデータを扱う――入れ子集合モデル

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    ruicc
    ruicc 2011/10/15
    RDBのrigidなスキーマ上での木構造定義
  • Hamster DB – A Data Science Blog

    Online data science provides the students with a flexible and affordable path towards a very lucrative data science job. According to the bureau of Labor Statistics the projected employment growth for database administrators is 11% with the current average salary for database administrators standing at $87,020. The increasing popularity of data analytics and data base administrators adds to the ev

    ruicc
    ruicc 2011/08/04
  • NoSQL at Twitter (NoSQL EU 2010)

    A discussion of the different NoSQL-style datastores in use at Twitter, including Hadoop (with Pig for analysis), HBase, Cassandra, and FlockDB.Read less

    NoSQL at Twitter (NoSQL EU 2010)
    ruicc
    ruicc 2010/12/14
    あとで
  • Microsoft PowerPoint - ycsb-v4.ppt

    1 Yahoo! Cloud Serving Benchmark Overview and results - January 29, 2010 Brian F. Cooper cooperb@yahoo-inc.com Joint work with Adam Silberstein, Erwin Tam, Raghu Ramakrishnan and Russell Sears System setup and tuning assistance from members of the Cassandra and HBase committers, and the Sherpa engineering team 2 Motivation • There are many “cloud DB” and “nosql” systems out there – Sherpa/PNUTS –

  • 第1回HBaseとCassandraの討論会のメモ - ひしだまの変更履歴

    HBaseとCassandra討論会のつっこみー。 (豊月) 2010-11-08 10:51:55 >HBaseはキーが偏ると一部のノードだけに負荷がかかる これは「Cassandraは、キーが偏ると一部のノードだけに負荷が掛かる」です。 HBaseの場合は、リージョンファイル毎に分散させているので、リージョンファイルの指定サイズを越えてまで大きくなったら自動で分割されて、別のノードへ移ります。 Cassandraの場合、キーのハッシュを元に担当を決めるので巧くキーの生成ルールを考えないと特定ノードに負荷が集中する事になります。 >「このトークンはこのリング」 「Ring上で、このTokenはこのノード」という情報を管理している、が正しいです。 >Cassandraは構築は楽だが、故障時が面倒(リバランスに時間がかかる) Cassandraに於いて面倒なのは、故障時じゃないです。 故障後

    第1回HBaseとCassandraの討論会のメモ - ひしだまの変更履歴
  • redis 使ってますか? - Twisted Mind

    redis という KVS 知っていますか? 自分は名前は知ってはいるけど ... 程度の認識だったのですが、新しいサーバを買った際、んーやっぱり社内で簡単に VM 上げたり下げたり出来る環境が欲しいなぁと思っていたところ @shibukawa から OpenStack いいよという話を聞いてドキュメントを呼んでいたら Redis を使っていると書いてあったので、へーと興味津々になって調べてみたら ... メイン開発者2名は VMware がスポンサーになってフルタイムで redis の開発をしているというわけです。こらなんとまぁと。 そして色々ドキュメントを呼んでいたらなかなか素敵な KVS で、自分が欲しい KVS にたどり着いた感じです。 redis - Project Hosting on Google Code 魅力 日語訳 redisドキュメント日語訳 redis v2.0

    redis 使ってますか? - Twisted Mind
  • MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記

    InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia語版のデータベースをダウンロードし、記事文の格納されているtextテーブルをMySQL 5.1+InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト:今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip:元テキストをgzipコマンドで圧縮したものです。 MyISAM:記事をMyISAMのテーブルに

    MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
  • NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現

    モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか? それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範(まつのぶよしのり)氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」(英語)をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で

    NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ/秒を実現
    ruicc
    ruicc 2010/10/27
  • Hadoopと3つのRDBMSの比較評価。 Hadoop World: NYC 2010

    先週10月12日に、ニューヨークでHadoopのイベント「Hadoop World: NYC 2010」が開催されました。主催はHadoopのディストリビューションベンダであるCloudera。参加者は900名を超えたともいわれ、日からも30名程度が参加しました。 このイベントでClouderaはNTTデータとの提携を発表。両社でアジア太平洋地域と日でのHadoopビジネスを積極展開することを明らかにしています。NTTデータによる講演のなかでリクルートの米谷修氏が行ったHadoopに関する比較評価を紹介します。 この記事はHadoop WorldでClouderaと提携したNTTデータが目指すもの。Hadoop World: NYC 2010」の続きです。 3種類のデータベースとHadoopを比較 リクルート MIT United システム基盤室エグゼクティブマネージャー 米谷修氏。

    Hadoopと3つのRDBMSの比較評価。 Hadoop World: NYC 2010
  • myNoSQL

    Autoscaling allows customers to build more cost effective and resilient applications. Using Compute Engine Autoscaling, you can ensure that exactly the right number of Compute Engine instances are available at any given time to handle your application’s workload. This saves you money when your application’s usage is low, and ensures your application is responsive when utilization is high. Autoscal

    myNoSQL
    ruicc
    ruicc 2010/10/18
  • 信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ

    僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという

    信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
  • クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future

    クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(

    クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
    ruicc
    ruicc 2010/10/17
    CAP定理。Consistency,Availability,Partitionの3つのうち、2つしか同時に満たせない。
  • HBase 基礎文法最速マスター - Stay Hungry. Stay Foolish.

    基礎文法最速マスターが流行のようなので、 便乗して勉強がてらにHBaseの基操作について纏めてみます。 Perl基礎文法最速マスター - Perl入門ゼミ はてな的プログラミング言語人気ランキング - Life like a clown これを読めばGoogleのBigTableのクローンであるHBaseの基操作について何となく理解できるかも?です。 他の基礎文法最速マスターと同じように簡易リファレンスを兼ねていますので足りない部分をあればご指摘ください。 HBaseは2010-02-01時点で最新のHBase0.20.3を対象としています。 インストール方法については前記事を参照ください。 Cygwinを利用してWindowsにHBaseをインストール - Stay Hungry. Stay Foolish. 対話式シェルの実行 基 HBaseではHBase Shellという対話式

    HBase 基礎文法最速マスター - Stay Hungry. Stay Foolish.
    ruicc
    ruicc 2010/10/08
  • B-Tree インデックス - オラクル・Oracleをマスターするための基本と仕組み

    B-Tree インデックス (B-Tree Index) オラクルのインデックス、すなわち、デフォルト時のインデックスは B-Tree インデックス(※1) になる。 B-Tree インデックスとはバランスド・ツリーインデックスの略である(1969 年頃に既に考案されている)。プログラミングを始めたときにソートアルゴリズムやデータ構造で勉強したであろうと思う二分木 (Binary-Tree) の進化版みたいなものである。 一部のブランチが異常に成長しないように平衡を保つように再編成(バランス)する仕組みによって、常にインデックスによる検索性能を高い状態に保つことができる(※2)。 RDBMS によっては色々な種類のインデックスが存在しているが、現在においても B-Tree インデックスが多くのケースで優れたパフォーマンスを出していることには変わりないようである。 (※1) B-Tree に

    ruicc
    ruicc 2010/10/05
    B-Treeインデックス
  • ALTER TABLEを上手に使いこなそう。

    テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。(エキスパートとおぼしき方々からも度々質問を受ける。)そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを!?と思うかも知れないが、テーブル定義(スキーマ)の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。(動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。)デフォルトで利用出来るMyISAMはInn

    ALTER TABLEを上手に使いこなそう。
    ruicc
    ruicc 2010/09/28
    alter table挙動
  • 大人のためのInnoDBテーブルとの正しい付き合い方。

    InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか?」というものがある。InnoDBMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

    大人のためのInnoDBテーブルとの正しい付き合い方。
  • NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance

    ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ

    NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
    ruicc
    ruicc 2010/09/21
    Redisについて書かれてる珍しい。結構内部挙動理解してないといけないのだな。MySQLと使い分けるなら当然か。
  • MVCC(多版型同時実行制御)

    Table of Contents9.1. はじめに9.2. トランザクションの隔離9.3. リードコミッティド隔離レベル9.4. シリアライザブル隔離レベル9.5. アプリケーションレベルでのデータの一貫性チェック9.6. ロックとテーブル9.6.1. テーブルレベルロック9.6.2. 行レベルロック9.7. ロックとインデックス MVCC(MultiVersion Concurrency Control:多版型同時実行制御)とは、マルチユーザ環境におけるデータベースの性能を向上させる高度な技術です。 PostgreSQLのために、Vadim Mikheev( <vadim@krs.ru>)が実装のを貢献をしました。 9.1. はじめに 多くのデータベースシステムでは、同時実行制御のためにロック機構を使用していますが、PostgreSQLではデータ整合性の維持に多版方式を使用しています。

    ruicc
    ruicc 2010/09/10
    ロックしないトランザクション制御
  • MapReduceとパラレルRDBでベンチマーク対決、勝者はなんとRDB!

    大量のデータを処理する手法として登場したMapReduce。クラウドに対応した分散処理の定番として話題に上ることが増えてきました。 MapReduceは、大量のデータを分割し、分割したデータを分散したノードに投げてノードごとに処理を実行、結果を集約して最終的な答えを求める、といった手法です。 しかしMapReduceが登場する以前から商用レベルで使われていた分散処理手法があります。データを分散したデータベースに格納し処理を行うパラレル・リレーショナルデータベース(パラレルRDB)がその1つです。 パラレルRDBは、データを複数のデータベースに分散して配置、データベースごとに処理を行い、結果を求める手法です。中央に共有メモリを配置するなどの方法で分散したデータベース同士の連携を行うことが一般的です。 ではパラレル・リレーショナルデータベースはMapReduceより遅いのか? 劣るのか? 両者

    MapReduceとパラレルRDBでベンチマーク対決、勝者はなんとRDB!
  • 独り言v6 » VoltDBは何故早いのかは問題ではない。何をするためのシステムなのかが問題だ

    ちょっと小旅行に出ている間にアクセスが伸びていて、おかげさまで前回のVoltDBのエントリが大人気だったようだ。まだまだ書き足りない部分がいっぱいあったので、補足する意味も込めて書き足してみたい。それは、H-Storeが従来型RDBMSとどれほど異なったシステムか、ということだ。インターフェースの話や大まかな話はしたが、前提となる部分の話はずいぶん抜けてしまっていた。 NoSQLを超えるSQLデータベース「VoltDB」。Cassnadraとベンチマーク対決! で、実際にCassandraと比べて検討している Key-Value Benchmarking という記事が紹介されていて興味深い。で、なおかつ勝っていると言うから痛快だ。まあ個人的にはこの勝負は高々3ノードしか使っていない時点でスケーラビリティに勝るKVSにずいぶん不利な内容だな、と言わざるを得ない。せいぜい12ノードぐらいでしか