タグ

Databaseに関するriki0084のブックマーク (11)

  • Cache-Oblivious データ構造入門 @DSIRNLP#5

    9. なぜ B-Tree の方が良いか? 大事な前提(若干雑) 1. ディスクの読み込み時間 >> 計算時間 2. ディスクである箇所を読み込むと周辺も含 めてそこそこ大きく読まれる 前提より • ディスクを読み込む回数だけを考える – 普段の議論:「O(ほげ) 時間」 – 今回の議論:「ディスクI/O 𝑂(ほげ) 回」 • 一度に読み込まれるサイズを 𝐵 とおく Cache-Oblivious データ構造入門 (@iwiwi) 10 10. データの探索にかかる I/O 回数 二分探索木 • 𝑂 log 𝑛 回 一回の I/O で 2 分岐 B-Tree • 𝑂 log 𝐵 𝑛 回 一回の I/O で Θ(𝐵) 分岐! ↑ノードのサイズをブロックサイズ 𝐵に合わせる B-Tree のほうが log 𝐵 倍ぐらい早い これは平気で 10 倍とかになるので大違い! Cac

    Cache-Oblivious データ構造入門 @DSIRNLP#5
  • DBの世界に起こる変革 | エンタープライズエンジニアの独り言

    エンタープライズシステムのエンジニアをやって10年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化(CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど)するのにディスク(ストレージ)が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて

  • アーキテクチャ設計のアンチパターン集~44のアンチパターンに学ぶDBシステム - プログラマの思索

    「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載!「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog(ブログ) 【SQLをしっかり学習したい人におすすめミック。 | プラプラ式技術系 Access流! 【まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな

    アーキテクチャ設計のアンチパターン集~44のアンチパターンに学ぶDBシステム - プログラマの思索
  • 開発者が知っておくべき、ドキュメント・データベースの基礎

    開発者が知っておくべき、ドキュメント・データベースの基礎:特集:MongoDBで理解する「ドキュメント・データベース」の世界(前編)(1/3 ページ) ドキュメント・データベースの最大の特長は、「パフォーマンス、大量データ、スケーラブルといった課題を克服するためのシンプルなセットを提供している」という点だ。 もちろん既存の多くのリレーショナル・データベース(以下、RDB)でも、ドキュメント・データベースが備えている特徴的な各機能に類似することが実現可能だし、さらに広範な概念や機能性を提供している。例えばシャーディング(Sharding。詳細後述)についても、既存の多くのRDBでデータの分散化が可能だ。しかしドキュメント・データベースでは、「そもそもデータ構造がこうした構成に適している」という点と、「それに付随して、考え方もシンプルである」という点が優位な特徴である。 万人が、データベースが

    開発者が知っておくべき、ドキュメント・データベースの基礎
  • ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI

    これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。

    ありがちなデータベース設計を共有することができる『DB Patterns』 | 100SHIKI
  • Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    Rails で、Controller に定義されている action を一度に取得する方法はありますか? - QA@IT
  • アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経

    「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である

    アジャイルとデータモデル、DB進化設計のこと - 勘と経験と読経
  • データベース負荷テストツールまとめ(5) - SH2の日記

    というわけで、JPOUG> SET EVENTS 20120721 | Japan Oracle User Groupに参加して発表をしてきました。通常の勉強会と比べて発表者と聴講者の一体感を増すための工夫がなされていて、とても良かったと思います。有限コーヒーかと思ったら無限ビールだったのも驚きです。JPOUGの運営メンバのみなさま、会場を提供してくださった日オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは、データベース負荷テストツールまとめ(5)と題して過去4回分のまとめと自作ツールの紹介をさせていただきました。JdbcRunnerはOracle DatabaseMySQLとPostgreSQLの間でTPC-BとTPC-Cの性能比較ができる唯一のオープンソースソフトウェアですので、いろいろ試してみていただければと思います。試した結果

    データベース負荷テストツールまとめ(5) - SH2の日記
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想

    リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 MySQLの次期バージョンとPostgreSQLの次期バージョンにどのような新機能が追加されるのか、昨日、一昨日の2の記事で紹介しました。 MySQLの次期バージョンはMemcached APIを備える! MySQL Conference & Expo 2011基調講演 PostgreSQLの現状と次期バージョン9.1の新機能。MySQL Conference & Expo 2011 この2つのデータベースの次期バージョンに共通しているのが、NoSQLの機能を取り込んでいることです。NoSQLに対するリレーショナルデータベースによる反撃が始まっています。 リレーショナルデータベースがNoSQLを取り込み始めた MySQLの次期バージョンであるMySQL 5.6に搭載予定の新機能の1

    リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想
  • DB設計時のサイズ見積もり - よねのはてな

    ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ

    DB設計時のサイズ見積もり - よねのはてな
  • 1