アーキテクチャ設計のアンチパターン集～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のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
Jenkins+schemaSpyでHTMLテーブル定義書を生成する - TrinityT's BLOG
DBスキーマからテーブル定義書を生成する方法を探していた所、schemaSpyというツールを発見。 これとJenkinsを組み合わせて、常に最新のHTMLテーブル定義書を生成する方法を確立できた。 前提 UbuntuServer11.10 MySQL5.1 JDK1.6系がインストールされていること Jenkins実行サーバで対象のDBにアクセス可能なこと 手順 JDBCコネクタインストール sudo apt-get install libmysql-java # 確認 ls /usr/share/java/mysql.jar schemaSpyのjarを配置 mkdir /var/lib/jenkins/schemaSpy cd /var/lib/jenkins/schemaSpy wget http://jaist.dl.sourceforge.net/project/schemasp
cybozu.com のデータ管理 - サービス | サイボウズ クラウドサービス「cybozu.com（サイボウズドットコム）」
cybozu.com のデータセンター cybozu.comは東日本のデータセンターで運用し、西日本のデータセンターにもバックアップデータを保管しています。データセンターは自家発電装置を備え、不意の停電の際にもサービスに影響はありません。 また、24時間365日の有人監視体制を取っております。 cybozu.com のサーバー構成およびバックアップ環境 お客様のデータは3台1組のストレージサーバー群で運用することで、リアルタイムレプリケーション（同期）や、無停止のバックアップを実現しています。 ストレージサーバーのハードディスク構成 まずはじめに、各ストレージサーバーのハードディスク構成についてご紹介します。 ストレージサーバーは、1サーバーにつき12台のハードディスクで構成されています。 そのうち10台をRAID 6で冗長化しているので、万が一、同時に10台中2台が故障してもデータが
はじめてのMongoDB
16. { "_id" : ObjectId("4dcd3ebc9278000000005158"), "timestamp" : ISODate("2011-05-13T14:22:46.777Z"), "binary" : BinData(0,""), "string" : "abc", "number" : 3, "subobj" : {"subA": 1, "subB": 2 }, "array" : [1, 2, 3], "dbref" : [_id1, _id2, _id3] } 17. { "_id" : ObjectId("4dcd3ebc9278000000005158"), "timestamp" : ISODate("2011-05-13T14:22:46.777Z"), "binary" : BinData(0,""), "string" : "abc", "num
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
FriendFeedにおけるMySQLへの大規模データ格納 - masayang's diary
非RDBだのKey-Valueだのと騒がしい今日この頃ですが皆様いかがお過ごしでしょうか。私は元気です。先日、ベイエリアクラウド勉強会で教えてもらったHow FriendFeed uses MySQL to store schema-less data(FriendFeed流・スキーマレスデータのMySQLへの格納)を適当に翻訳してみますよ。(原文はCreative Commonsライセンス) 背景 FriendFeedではすべてのデータをMySQLに格納している。利用者の増加に伴い、FriendFeedのデータベースも拡大してきた。現時点では2億5000万件以上の記事が登録されており、これにコメントやお友達一覧のお気に入りなどのデータが加わる。 データベースの急成長に伴ない、規模に関する課題にも段階的に対処してきた。基本的な対処はおこなってきたつもりだ。具体的には、読み取り専用スレーブの
kumofsをベースにRDBMS用ストレージエンジンって作れないものか | 独り言v6
まだ自分でインストールして確かめていないが、kumofsに興味津々である。何が興味深いかというと、まあスケーラブルで且つ耐障害性に優れるところだ。もちろんそれだけなら分散KVSということである程度予想された機能である。個人的な興味としては「この種のKVSを使ってRDBMSもどきが作れないか」というところにある。 この構想は 超 並列RDBMSは成立するか – L.star的デザイン（１） でずいぶん前から暖めているものであるが、ここでいうリソースノードをkumofsで代用できないかというものだ。引用して、機能的な実装の必要でないものを除くと リソースノード storage engineである DDL的には、テーブルスペースに近い位置づけとして定義可能であると考えている。 sequential scan, index scan, seq scan+sortを行い、その結果を返すDBである。M
Kazuho@Cybozu Labs: 高度に進化した分散データストアは RDBMS と見分けがつかない？ (shibuya.pm #12 スライド)
開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、なぜ RDBMS ベースのアプローチを採用したのかという背景を中心に説明させていただきました。概念的な話が多くて分かりにくかったと思います（すみません）が、細かな点についてはパフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)を参照いただければと思います。 また、中で出てきた「実体化ビュー」については、Materialized view - Wikipedia, the free encyclopediaが良くまとまっているかと思います。Incline は一言でいうと、RDBで構成されるshard群の上で read-only かつ eventually co
Bigtableと分散KVS・その2 - スティルハウスの書庫の書庫
ありがたいことに古橋さんに前回のエントリをご覧いただいたようで、大変ためになるつぶやきをされてたので、ここで引用させていただきます。 @frsyukiさん： 「分散KVS」という名前は何も考えていなくて、別に分散KVSにBigTableを含めても良くて、効率の話を問題にしていたけど、分かりにくかっただろうか…：http://bit.ly/IMFUs それはそれとして、効率について。概念的には、データモデルがmultidimentionalであることで、BigTableはアプリケーションに依存した情報をより多く知ることができる。これによって最適化をしやすくなり、効率が上がる。 例えば、Every read or write of data under a single row key is atomic を効率的に保証する、reads of short row ranges are effi
最速並び替え研究会 - Yappo::タワシ
1000万行とか10億行でも何でもいいけど、いっぱいデータが入ってるテーブルのsortカラムの値を並び替えたい。 例えば以下のようにsort_testテーブルを作る use strict; use warnings; use DBI; my $dbi = DBI->connect('DBI:mysql:database=test'); $dbi->do('DROP TABLE IF EXISTS sort_test'); $dbi->do(<<SQL); CREATE TABLE sort_test ( id INT, sort INT, index(id), index(sort) ) ENGINE=InnoDB SQL my $sth = $dbi->prepare('INSERT INTO sort_test VALUES' . join(', ', ('(?,?)')x10_000
XMLデータベース - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "XMLデータベース" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2023年2月) XMLデータベースとは、XMLを扱うための機能を持つデータベースである。 狭義ではXMLのツリー構造をそのままデータ構造として持つ物を言うが、実際は伝統的な関係データベースにXMLを格納するものや、単にテキストファイルとしてXMLを格納するものなど様々である。現在ではXPath、XQueryで検索するデータベースをXMLデータベースと呼ぶことが多い。 現在でも広く用いられている関係データベースでは、一度作成されたデータ構造を運用中に変更することが一般
第1回 検索エンジンとは | gihyo.jp
はじめに 検索エンジンと聞くと、みなさんは何を思い浮かべるでしょうか？ GoogleやYahoo!などの検索ページを思い浮かべる方がほとんどだと思います。近年は、それら企業の努力によって検索エンジンというものが非常に身近になり、私たちの生活に欠かせないものとなりつつあります。 しかし、検索エンジンと一言で言っても、上記のような一般の方々へのUI（ユーザインターフェース）を指す場合もあれば、そのUIの裏側（バックエンド）にあるシステムを指す場合もあります。 本連載では、Google,Yahoo!などを代表とする検索エンジンの裏側のしくみに着目し、検索エンジンというシステムのアーキテクチャやその内部で使われているデータ構造やアルゴリズムを、近年の手法や研究事例などを交えて解説していきたいと思っています。 検索エンジンとは 検索エンジンには、さまざまな種類があります。GoogleのWeb検索のよ
真のデータベースエンジニアを目指そう！（1/3） ― ＠IT
本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局） はじめに 本連載は、データベースを利用したアプリケーション開発にプログラマとして携わっている読者を対象として、データベースの利用者から設計者へとステップアップするために、いまから身に付けておきたい必須知識を解説していきます。いまはまだ「データベースエンジニア」が何であるか、どんな仕事をするのかがよく分からないといった方にも、本連載を通じて少しでもこの職種に興味を持っていただければ幸いです。 第1回は、「データベースエンジニアの役割、およびデータベースエンジニアに必要とされるスキル」について解説します。 データベースエンジニアとは？ データベースエンジニ
インデックスの基礎知識
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
サーバは仮想化されるべきだが、データベースには気をつけろ － Publickey
StorageIOblog » Blog Archive » Should Everything Be Virtualized? The Server Storage IO Groupのアナリストが書いているブログ「StorageIOblog」に、「Should Everything Be Virtualized?」（すべては仮想化されるべきなのか？）というエントリがポストされました。 すべてのサーバ、I/O、ストレージは仮想化されるべきなのか？ という問いに答えるエントリになっています。 Unfortunately consolidation is commonly misunderstood to be the sole function or value proposition of server virtualization given its first wave focus.
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
つみきWeb
jssst.dvi