タグ

RDBに関するmonochromekkのブックマーク (3)

  • データベース設計の際に気をつけていること - 食べチョク開発者ブログ

    皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ!”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。

    データベース設計の際に気をつけていること - 食べチョク開発者ブログ
  • DBの世界に起こる変革 | エンタープライズエンジニアの独り言

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

    monochromekk
    monochromekk 2013/01/07
    インメモリDB系の記事でいつも思うのは障害復旧。復旧元媒体は、通常処理用のメモリ媒体と別でないと耐障害性が保たれないし。 / まぁ、既存RDBのアーキテクチャはそれ程遠からず変わると思う。
  • 第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp

    RDBMSはオワコン? 「右を向いても左を向いても“⁠ビッグデータ⁠”というキーワードが闊歩する時代に、いまさらRDBMSの話題?」 連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○(お好きなアーキテクチャを入れてください)の時代だ!」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規

    第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp
  • 1