商用DBではOracle、SQL Server、DB2が有名でシェアもほぼこの3つで占めていますが、OSS-DBとしてはMySQLとシェアを2分しているのが、本連載で取り扱うPostgreSQLです。 本連載で想定している読者のスキルは以下の通りです。 RDBMS製品に触れたことがある 基本的なSQLについて知っている
Spring Bootでテストを走らせるときに、開発用・本番用とは違うDBに接続しないなど、設定を変えたい時があります。その場合のは設定方法について。 Test時には、設定ファイルの優先度が変わる MavenでもGradleでもいいんですが、例えばMavenを使っているならば、Springプロジェクトは以下のような構成になっているはずです。 /my/good/project ├── README.md ├── pon.xml └── src ├── main │ ├── com │ │ └── ... │ └── resources │ └── application.yml └── test ├── com │ └── ... └── resources └── application.yml
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ! Amazon AuroraはAWSの中で利用可能なマネージド(=運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
今月下旬に、J.セルコの『Trees and Hierarchies 2nd Edition』の邦訳が刊行されます。同著者の代表作『プログラマのためのSQL 第4版』のスピンオフの一つで、RDB/SQLで木と階層構造を扱うための方法論にフォーカスしたなかなかマニア度の高い一冊です。主眼となる「入れ子集合モデル」については、私もあちこちの記事や書籍で紹介したことがあるので、ご存じの方もいるかもしれませんが、より包括的かつ理論面までカバーした本格派の内容になっています。 表紙の女性はマリア様でしょうか。本家の方が刊行されたときも「このおっさん誰?」という質問が相次ぎましたが、ガリレオという説が有力なようです。そう言われてみると本家は『星界の報告』のような格調を感じます。本書の方は、長らく定説とされてきたモデルをひっくり返そうという意味では『天体の回転について』みたいな性格もあるのですが、大型本
第2回を読まれた方は、この両者を変換するSQLを紹介したことを覚えているでしょう。そのSQLを利用すれば、「列持ち」⇔「行持ち」の変換を行うことが可能なので、最悪、設計時点でどちらかのモデルを選択したあとに、「やはりうまくいかなかった」ということでもう一方のモデルへチェンジすることも、できないわけではありません(アプリケーション側の修正など、相応の工数は覚悟せねばなりませんが)。しかし、最初は可能な限り「行持ち」を選択するべきです。 その理由は、列持ちモデルの拡張性と保守性の低さです。実際、今は2008年なので年度ごとに作られた列も2008年まで用意していればよいとして、来年になったらどうすればよいのでしょう? 列をもう1つ追加するほかありません。すると毎年テーブルの構造を変えなければなりませんし、このテーブルへアクセスするSELECT文から結果を受け取るホスト言語まで、ほとんどシ
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる(その4) 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行(ロー)指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」(あるいはカラム指向データベース、カラムナーデータベース)です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの?:ITproという記事に対するブクマで次のようなIDコールが来た。(現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。) "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか? つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。(ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。)リレーショナルモデルについてちゃんと学習してい
Java の研修で DB(だいたいMDBかな) にアクセスするプログラムを作ることになったとき、講師はほぼ 100% 「JDBC Driver を使用するためには Class.forName を使用します」と言うはず。ただ、呪文のごとく。 で、Class.forName の API を見てみる。 forName(String name, boolean initialize, ClassLoader loader) 指定されたクラスローダを使って、指定された文字列名を持つクラスまたはインタフェースに関連付けられた Class オブジェクトを返します そして疑問が生まれる。「クラスをロードするだけでなんでDBにアクセスできるようになるの?」と。 講師はなぜできるかは説明しない。分かってないってことは無いと思うけど「まだ初心者だから覚えとけばいい」的な感じだろう。 けど、ここは言わせてもらう!
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
「データベースが輝くとき、 システムに安定がもたらされる」 システムが不安定になりがちなこの世界 いにしえからの言い伝えが人々の間で まことしやかにささやかれ始めた 「不安定なシステムでは、 これ以上やっていけない」 データベースに光を取り戻すために、 立ちあがった1人がいた
これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。
1960年代末頃に研究が開始されたオブジェクト指向のDBMSは、1990年前後より、実用的なデータベースとして、研究機関や大規模システムを必要とする分野で性能を発揮し始めました。しかし、一般的な企業がそのパフォーマンスに注目し始めてからは、まだ日が浅いと言えます。本連載では、オブジェクトデータベースとして注目のCache'(キャシエ)を解説し、一般的な企業におけるシステム開発・運用におけるメリットを浮き彫りにしていきます。 はじめに 1960年代末頃に研究が開始されたオブジェクト指向のデータベースマネージメントシステム(Database management system、DBMS)は、1990年前後より、実用的なデータベースとして、研究機関や大規模システムを必要とする分野で性能を発揮し始めました。しかし、一般的な企業がそのパフォーマンスに注目し始めてからは、まだ日が浅いと言えます。本連載
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く