第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か | gihyo.jp
はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート（根）と呼ばれるノードを始点として、（通常）複数のリーフ（葉）と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある「木」の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ（フォルダ）によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
PostgreSQL 9.4がリリース。ドキュメントDB並の性能でJSONBサポート、レプリケーション機能の高度化など
PostgreSQL 9.4がリリース。ドキュメントDB並の性能でJSONBサポート、レプリケーション機能の高度化など PostgreSQL 9.4の主な新機能は、バイナリ形式のJSONであるJSONBのサポート、高度なレプリケーションに利用できる新しいAPI、GINインデックスの高速化など。 一般的なドキュメントデータベース並の高速性 PostgreSQLでは以前のバージョンからJSON形式をサポートしていましたが、今回サポートされたJSONB形式は、バイナリ形式のJSONデータへの対応です。JSOBのサポートGINインデックスの高速化によって、ドキュメントデータベース並みの高速性を実現したとのこと。 JSONB supports fast lookups and simple expression search queries using Generalized Inverted In
［速報］Oracleデータベースをインメモリ化する「Oracle Database In-Memory」、性能を数百倍高速化、来月出荷へ
［速報］Oracleデータベースをインメモリ化する「Oracle Database In-Memory」、性能を数百倍高速化、来月出荷へ 米オラクルは、Oracle Database 12cをインメモリデータベース化し、従来と比較して数百倍の性能向上を実現する「Oracle Database In-Memory」を来月7月に出荷すると発表しました。 Oracle Database In-Memoryは、昨年9月に行われたOracle OpenWorld 2013の基調講演で発表されたもの。今回の発表には、そのときと同様に同社CEOのラリー・エリソン氏が登壇、熱のこもった説明を行いました。 エリソン氏は「Oracle Database In-Memoryは、アナリティクス処理を10倍も100倍も高速化し、OLTPも2倍、3倍と高速化する。しかもOracle RAC（Real Applicat
ストーンブレイカー氏が新たに立ち上げた「Tamr」は、ばらばらに存在する企業内外のデータを機械学習で自動的に整理統合
ストーンブレイカー氏が新たに立ち上げた「Tamr」は、ばらばらに存在する企業内外のデータを機械学習で自動的に整理統合 データベースの大御所として知られるマイケル・ストーンブレイカー氏。IngresやPostgresといったリレーショナルデータベースの先駆けとなる製品を開発、InformixのCTOを務め、またカラム型データベースのVerticaを創業、最近ではVoltDBを創業するなど、データベースの先端技術を商用化し続けてきました。 そのストーンブレイカー氏が共同創業者として立ち上げた企業が「Tamr」（テイマーと発音するようです）です。同社は5月19日、Google Venturesなどから1600万ドル（約16億円）の投資を受けるのと同時に、同社製品（社名と同じTamr）を発表しました。 高度なデータウェアハウスをほぼ自動的に作ってくれる Tamrとは、これまでストーンブレイカー氏が
なぜBTreeがIndexに使われているのか - maru source
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます（特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう？？ Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
RDBMSでコネクションプールが必要な理由、わからない。
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない（解放まで多少遅延する）ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ（要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか？なぜ(べき、べきでない)のか？どういう要請でそうなのか？と言う問いに僕は答えられません。 2013-09-04 09:31:22
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想
リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想 MySQLの次期バージョンとPostgreSQLの次期バージョンにどのような新機能が追加されるのか、昨日、一昨日の2本の記事で紹介しました。 MySQLの次期バージョンはMemcached APIを備える！ MySQL Conference & Expo 2011基調講演 PostgreSQLの現状と次期バージョン9.1の新機能。MySQL Conference & Expo 2011 この2つのデータベースの次期バージョンに共通しているのが、NoSQLの機能を取り込んでいることです。NoSQLに対するリレーショナルデータベースによる反撃が始まっています。 リレーショナルデータベースがNoSQLを取り込み始めた MySQLの次期バージョンであるMySQL 5.6に搭載予定の新機能の1
【チラ裏】あなたは本当にそのデータストアが好きで使うんですか？ - oranie's blog
チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか？みんなが使い慣れている物から変える理由は「有名な会社が使っていて＾＾」「他のチームが使っていて＾＾」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか？ もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか？ 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか？ まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか？ あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか？他のメンバーへの啓蒙や情報共有を率先
第1回 大規模データではRDBMSのどこがボトルネックになるのか？ | gihyo.jp
RDBMSはオワコン？ 「右を向いても左を向いても“ビッグデータ”というキーワードが闊歩する時代に、いまさらRDBMSの話題？」 本連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○（お好きなアーキテクチャを入れてください）の時代だ！」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
