気軽に始めてみよう！クラウド時代のデータウェアハウス超入門 | DevelopersIO
始めに 私は8年ほど前に情報処理試験でデータウェアハウスというものがあるということを知りました。当時は4択問題で問題文に 意思決定支援 というキーワードが出てきたら何なのかよく分かんないけど選択してました。それからずっと興味がありながら実物に触ったことはなかったのですが、クラウド型のデータウェアハウスが登場し触る機会を得ることができました。以前に比べデータウェアハウスはかなり身近なものになってきたのではないでしょうか。弊社でもAmazon RedshiftというAWSのサービスを利用した案件が増えてきています。 クラスメソッド、POSデータ数十億件をリアルタイム分析する基盤を「Amazon Redshift」「Tableau」で開発 この記事ではデータウェアハウスの知識から分析ツールを使ってAmazon Redshiftに接続するところまで簡単にまとめています。実際にどんなものか、触ったこ
テーブル設計のテクニックについて
これまでクライアントサイドのプログラミング中心できたこともあり、あまりサーバーサイドやDB設計をした経験がないのですが、最近になって基幹系のDB周りの業務も担当するようになってきました。 直近では、すでにあるTBLに削除のフラグのような列があるのを見たとき、最初は何に使うのかわからなかったのですが、インターネットで色々調べるうちに"論理削除"というやり方があるのかと知ったぐらいです。現状がこんな状態なのですが、識者の方に質問があります。 １．登録日時・ユーザー、更新日時・ユーザーのカラムについて ２．TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて １．登録日時・ユーザー、更新日時・ユーザーのカラムについて 参考にするために他システムのTBL定義などを見ているのですが、多くのTBLにレコードの登録日時と登録ユーザー、レコードの更新日時と更新ユーザーとい
技術解説Wiki「PostgreSQL Internals」を立ち上げました
今年1月に筑波大学で開講された「情報システム特別講義D」での私の講義内容「Inside PostgreSQL Kernel」の内容をWikiにして公開しました。 PostgreSQL Internals http://www.postgresqlinternals.org/ もともと学生さん向けの講義ということで、RDB技術とトランザクション処理の入門的な内容になっておりますが、PostgreSQLにおける実装に興味のある向きにはぜひご覧いただけると幸いです。 講義の当日は時間の都合上説明できなかったところや、そもそも準備が間に合わなかったところなどもいろいろありますが、せっかくWikiにしたので、これから少しずつメンテナンス・拡充していければと思っております。成長していくコンテンツ、ということで。 「ココが間違ってるぞ」とか「アレも書いてほしい」というご指摘・リクエストがありましたら、G
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
ナチュラルキーとサロゲートキーについての議論
とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
RDS for PostgreSQLの中を覗いてみた（追記あり）
皆さんお待ちかねの、RDS for PostgreSQLが昨日リリースされました。 Amazon Web Services ブログ: 【AWS発表】Amazon RDS for PostgreSQLがご利用可能になりました！ http://aws.typepad.com/aws_japan/2013/11/amazon-rds-for-postgresql-now-available.html 既にインスタンスを立ち上げてみた方もいるようです。 Amazon RDS for PostgreSQLがやってきた！！ ｜ Developers.IO http://dev.classmethod.jp/cloud/amazon-rds-for-postgresql-now-on-sale/ cloudpackブログ: Amazon RDS で PostgreSQL が利用可能に http://bl
MongoDBを半年運用してみた（のフォロー） - matsukaz's blog
某社との合同勉強会のLTで発表したMongoDBを半年運用してみたが、えらいはてブされててびっくり。。。あのままだとMongoDBは絶対使わないって結論になっちゃいそうなので、自分をフォローする形でエントリを書きたいと思います。 資料はこちら。 Mongo DBを半年運用してみた View more presentations from Masakazu Matsushita コネクションエラー多発 これは、7月にmongosの場所がmongodからSocketサーバ／Webサーバ／管理サーバに移動した件と関係しています。 まず、Socketサーバ／Webサーバ／管理サーバともにJavaで実装されているので、MongoDBへの接続はJavaの公式ドライバーを利用しています。当初のドライバーの利用方法は、 // Shard1, Shard2, Shard3のPRIMARYと同居してるmong
関数プログラミングのボトルネックとしてのRDBMS
プログラム開発は、多くの人々が目的達成のため、もがき苦闘するタールの沼である – Frederic P. Brroks, Jr., 人月の神話 モジュール性はプログラミング成功の鍵である – John Hughes, 関数プログラミングはなぜ重要か タールの沼の底から タールの沼と聞いて連想するのは大規模なSIである。業務アプリケーションやWebアプリケーションは規模が大きくなればなるほど、複雑さが増し収拾がつかなくっていく。そしてそのようなアプリケーションを大きな単位で上手くモジュール化し、さらには再利用することは不可能に近い。 その技術的な原因の一端、そして問題を解く鍵は、そのようなアプリケーションが常に携えているRDBMSの周辺にあり、さらに言えばおそらくRDBMSとアプリケーションロジックの組み合わせにあると考えている。 ここでは、アプリケーションロジックの実装に関数プログラミング
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
インメモリデータベース「MemSQL 2.0」公開。数百ノードへスケールアウト可能で大規模データベース対応へ － Publickey
データベースをまるごとメインメモリ上で処理することにより、従来のハードディスクベースのリレーショナルデータベースよりも劇的な高速化を実現するインメモリデータベースであるMemSQLの最新版「MemSQL 2.0」が公開されました。 MemSQL 2.0はインメモリのスピードとSQLでの問い合わせ、スケールアウト機能、そしてエンタープライズ対応の可用性など、4つの特徴を持つと説明されています。 In-memory architecture Ad hoc SQL-based analytics Horizontal scale-out on commodity hardware Enterprise-grade durability and high availability スケールアウトでデータウェアハウスに対応 MemSQL 2.0はインメモリデータベースの特徴である高速な処理に加えて、
monによるMySQLのデッドロック検知とロギング - FAT47の底辺インフラ議事録
更新が激しいDB（MySQL)でInnoDBのロック競合が発生し、アプリケーションサーバが詰まる状況が発生してしまいました。 障害監視はmonというアプリケーションで行なっているのですが、 今回はこのmonを使ってMySQLデッドロックの検知とロギングを行いたいと思います。 monについては下記の資料をご参照ください。 Mon, Muninによる楽々監視生活 デッドロック解析は下記サイトのSQLを利用しています。 MySQL InnoDBにおけるロック競合の解析手順 前提 ・MONのサーバは既に構築済みであること ・DBサーバはMySQL5.5であること（MySQL5.1+InnoDB pluginでも可） 〜〜〜 以下、監視対象のDBサーバにて作業 〜〜〜 SNMPインストール yum install net-snmplockを検知するスクリプト作成 vim /usr/local/sbi
衝撃的なデータベース理論・関手的データモデル 入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使
高速なトランザクション処理をうたうSQLデータベース「VoltDB 3.0」リリース | OSDN Magazine
米VoltDBは1月22日、リレーショナルデータベースシステム「VoltDB 3.0」を公開した。クラスタ環境におけるトランザクション処理アーキテクチャの改善により、さらに低遅延を実現するという。 VoltDBは、「Postgres」や「Ingres」などのデータベースプロジェクトを手がけたMichael Stonebraker氏が設計したデータベース。高速なトランザクション処理を特徴とし、ACIDに遵守した次世代のリレーショナルデータベースを標榜している。GPLv3で公開するオープンソース版（Community Edition）と、サブスクリプション形式の商用版（Enterprise Edition）の2つがリリースされている。 バージョン3.0は2011年9月にリリースされたバージョン2.0以来のメジャーリリース。性能側では、トランザクションのアーキテクチャを再設計し、クラスタにおける
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
デイヴィッド・スピヴァックはデータベース界の革命児か -- 関手的データモデル - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース技術の羅針盤
コンテキスト境界を使って大きなドメインモデルを小さくする
Amazon.co.jp: IT技術者なら知っておきたい ストレージの原則と技術: EMC Education Services (著), 株式会社クイープ (翻訳): 本
