ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回DBエンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々DBエンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました! 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース(以下RDB)は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
[速報]オラクル、Oracle 12cにインメモリとカラム型データベースの追加機能を発表~Oracle OpenWorld 2013 米オラクル主催のイベント「Oracle OpenWorld 2013」がサンフランシスコで開幕しました。 同社CEOのラリー・エリソン氏は最初の基調講演に登壇。現在データベースの新しい技術として注目されているインメモリとカラム型データベースの機能をオプションとしてOracleDatabase 12cに追加すると発表。さらにインメモリ処理に優れた32TBメモリ搭載可能な新型SPARCサーバも発表しています。 基調講演の内容をダイジェストで紹介します。OracleDatabaseのIn-Memroyオプション発表 米オラクルCEO ラリー・エリソン氏、ご機嫌な表情で登場。
カラム型データベースでトランザクション処理を実現するカラクリとは? インメモリとカラム型データベースの可能性を調べる(その5) SAPのHANAは、最初からインメモリデータベースとカラム型データベースの技術を用いて高速な集計や分析処理と高速なトランザクション処理とを両立させることを目指して開発されたと、HANAの開発者でありSAPの共同創業者であるハッソ・プラッタナー氏はHANAの設計思想と実装を解説した著書「In-Memory Data Management」で書いています。 ここでは、その書籍および公開されている論文「Efficient Transaction Processing in SAP HANADatabase – The End of a Column Store Myth」(SAP HANAデータベースにおける効果的なトランザクション処理 ― カラムストア神話の終焉)から
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる(その4) 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行(ロー)指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」(あるいはカラム指向データベース、カラムナーデータベース)です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの
従来のデータベースをメモリに載せるだけではだめなのか? インメモリとカラム型データベースの可能性を調べる(その2) 現代のサーバは1台で複数のプロセッサを備え、数百ギガバイトから数テラバイトのメインメモリを搭載可能です。これは多くの企業で利用されているデータベースがそのままメモリに載るほどの容量です。 大量のメモリを搭載したサーバを用いれば、OracleDatabaseやSQL ServerやDB2など従来のディスクベースのデータベースでも、データベースをまるごとメインメモリのバッファキャッシュに載せることができます。そうすればディスクアクセスのボトルネックは事実上ほとんどなくせるため、高速なデータベースアクセスが実現します。 だとしたら、データベースをすべてメモリに載せる機能を備えたインメモリデータベースを、わざわざ使う必要はあるのでしょうか? この疑問は、以前の記事「キャッシュの大き
インメモリデータベース、カラム型データベースは使い物になるのか? インメモリとカラム型データベースの可能性を調べる(その1) ERPベンダ最大手のSAPは2010年、新規に開発したデータベース「SAP HANA」(当時の名称は「SAP High-Performance Analytics Appliance」)を発表しました。 HANAの製品化を背景に、SAPは2012年5月にデータベース市場への本格参入を宣言し、オラクルやIBM、マイクロソフトとデータベース市場で競合していくことを表明。そして今年2013年2月にはついにERPと組み合わせた「SAP Business Suite powered by SAP HANA」の出荷を開始し、業務アプリケーションのバックエンドデータベースとしてHANAの本格利用を開始しました。 HANAには、これまで主流だったリレーショナルデータベースとは異なる
2013年3月26日から発生していた住民基本台帳ネットワークシステム(住基ネット)の障害の原因が、データベース(DB)に情報を書き込む際の文字コードの誤り(文字化け)にあったことや、障害が影響した市町村の合計が231に及んでいたことなどが分かった。総務省が4月2日に発表した(関連記事:全国200の自治体で住基ネットが利用不可能になる障害が発生)。 今回の障害は、自治体にある住民基本台帳システムと住基ネットを接続する「コミュニケーションサーバー」のハードウエアとOSを231の自治体で更新し、それに伴い、コミュニケーションサーバーのアプリケーションに対して、新OSに対応させる修正プログラムを適用することで発生した。 コミュニケーションサーバーのアプリケーションは、氏名・住所・生年月日・性別という4つの「本人確認情報」を、DBサーバーである「OracleDatabase」に保存する際に、住基ネ
Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗(アンチパターン)があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。本書への称賛の声 監訳者まえがき はじめに I部 データベース論
SQLとNoSQLではどちらが優れているのか?グーグルの担当者がディベート(というより小芝居:-)を行ったセッション「Google I/O 2012 -SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。 ハイライトを紹介しましょう。 クラウドにおけるデータベースのメリットグーグルのAlfred Fuller氏(NoSQL担当)。 クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。 データのレプリケーションや地域分散でデータも保全され、インターネッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く