タグ

rdbに関するy-kobayashiのブックマーク (8)

  • RDBとスキーマレスDBの使い分けについて | さにあらず

    はじめに#RDB とスキーマレス DB をどういう基準で使い分けるのかを、会社で聞かれた際に答えた雑な回答をメモ書きしておく。 他にも多くの基準があるだろうし、スキーマレス DB というか KVS は様々な実装があり、そのそれぞれが微妙に違うので議論として曖昧な部分はある。 特に、運用面やデータ量がペタバイトクラスになる状況については考慮していない。 僕は SI 戦士なので、最終的には金を無限に突っ込んだ Oracle 先生が最高のデータベースであると考えている。 そういうバイアスのある人間の意見だと思って以下の文章は読んで欲しい。 念頭に置いているデータベースについて#このエントリを書くにあたって念頭においているデータベースは以下の通り RDBOraclePostgreSQLMySQLスキーマレス DBMongoDBAmazon DynamoDB最初は Redis を DB と書いていた

    RDBとスキーマレスDBの使い分けについて | さにあらず
  • トランザクションの設計と進化

    2016年7月27日 Database Lounge Tokyoで話した内容。 タイトルは名ばかりでリカバリとIn-MemoryDBの話が主体Read less

    トランザクションの設計と進化
  • DBパフォーマンスチューニングの基礎:インデックス入門

    2012/06/22 のCLUB DB2 第145回の資料です。 RDBパフォーマンスチューニングの基礎であるインデックスについて、基礎から解説しています。Read less

    DBパフォーマンスチューニングの基礎:インデックス入門
  • 従来のデータベースをメモリに載せるだけではだめなのか? インメモリとカラム型データベースの可能性を調べる(その2)

    従来のデータベースをメモリに載せるだけではだめなのか? インメモリとカラム型データベースの可能性を調べる(その2) 現代のサーバは1台で複数のプロセッサを備え、数百ギガバイトから数テラバイトのメインメモリを搭載可能です。これは多くの企業で利用されているデータベースがそのままメモリに載るほどの容量です。 大量のメモリを搭載したサーバを用いれば、Oracle DatabaseSQL ServerやDB2など従来のディスクベースのデータベースでも、データベースをまるごとメインメモリのバッファキャッシュに載せることができます。そうすればディスクアクセスのボトルネックは事実上ほとんどなくせるため、高速なデータベースアクセスが実現します。 だとしたら、データベースをすべてメモリに載せる機能を備えたインメモリデータベースを、わざわざ使う必要はあるのでしょうか? この疑問は、以前の記事「キャッシュの大き

    従来のデータベースをメモリに載せるだけではだめなのか? インメモリとカラム型データベースの可能性を調べる(その2)
  • 業務に役立つかもしれないデータベース入門 | Glob

    A-Yan 第07回 業務に役立つかもしれないデータベース入門(第1回).pdf ちょっと前に勉強会での発表用に作成した資料です。 IPAの試験は、特に更新の必要が無いので、継続して学び続けるインセンティブが弱くなりがち(?)なので、データベーススペシャリスト(自分が取得したときは、テクニカルエンジニア データベースでしたが)の復習もかねて発表させてもらいました。 リレーショナルデータベースって身近なので、みんな結構わかった気になって軽んじる気がしないでもないのです。 エレガントな理論、40年かけて熟成した安定感とたまったノウハウ、清濁併せのむ懐の広さ。 すばらしいですけどね。 XML DB や NoSQL やら インピーダンスミスマッチ やら、もちろんRDB万能とは思わないですが、RDBを単なるファイルとしか思ってなかったり、正規形がどんなモノかもわからないような人がRDB批判とかちゃん

  • 【BPStudy#64】RDBじゃだめな理由を2つほど

    皆さん、昨日はお疲れ様でした。 また、運営していただいたBeProudの皆さん、ありがとうございました。 10人くらいだったら完全非公開にしようと思ったんだけど、30人くらい来てくれたので公開することにしました。 UST録画はこちら BPStudy20121221 from Shinichiro Takezaki BDBの代わりにRDBのインスタンスを複数配置するんじゃだめなの?というのはよく聞かれる質問だけど、昨日も当然のように質問された。 いつもうまく答えられなくて歯がゆいけど、それは、O/Rマッパーも必要なくなって、RDBを導入管理する必要がないから。だけど、そこはやっぱり伝わんなかったかな~。 O/Rマッパー無くしてソフトスキーマで 開発の4割がマッピングといわれ、 それに、テーブル設計、正規化、SQL、チューニングなど、 ほとんどがデータベースまわり。要は、これを全否定したいわけ

  • スキーマ不定のデータをRDBに永続化する方法の比較 — ありえるえりあ

    Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ

  • エンタープライズクラウドでも破壊的イノベーションを

    昨日の記事はちょっとわかりにくかったと思うので補足したい。 RDB不要論 浅海先生よりコメントをいただいた。(ありがとうございます) CQRSも、伝統的なオンラインとバッチによるアプリケーション・アーキテクチャに新しく名前をつけたと考えると過去との技術の連続性も見えてきて面白いところ。よく考えてみると昔から普通にやってきたことだよなぁ、と。もちろん登場人物が変わってきているので新しい革袋に入れなおす必要はある。 — 浅海智晴さん (@asami224) 6月 28, 2012 全くおっしゃるとおりで、「昔から普通にやってきたこと」で今でも大変有効な技術は多いと思う。ISAMやVSAMのKSDSにしても昔は実際にオンライン処理をやっていたわけだからできないはずがない。というより、もしかしたらRDBより向いているんじゃないか?というのが私の率直な印象。結局のところ、データの集計や分析では、わざ

    エンタープライズクラウドでも破壊的イノベーションを
  • 1