タグ

データベースに関するnodatのブックマーク (16)

  • データベースについてのそもそも論

    先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle(ハカタクル?)」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物(=私)が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか(あるいは使う

    データベースについてのそもそも論
  • その候補、国会で何してました? 議員活動が丸わかりのDB

    期日前投票が始まり、14日に投開票日を迎える衆院選。どの候補を選ぶか迷っていませんか。そもそも、選挙ポスターやチラシだけでは、どんな人物か判断するのは難しい。「どういう活動をしてきた人なのか、わかれば良いのに」という人にお勧めのサイトがあります。 国会での発言、質問、出席数など一覧に 東京大の菅原琢客員研究員(政治過程論)が公開している「46期衆議院議員活動統計」。全衆議員の国会会議、委員会での発言数、発言文字数などが一覧できます。名前順や発言数順などに並び替えることもでき、実際にどういう発言をしたかは、国会会議録へのリンクで確認できます。 例えば、会議での発言数がゼロの議員、委員会での発言もゼロの議員も簡単に探せます。政党や当選回数が同じ議員の中でも、発言数や内容に差があることがわかります。 菅原客員研究員にサイト公開の目的や意義について聞きました。 「議員の活動は知られていない」

    その候補、国会で何してました? 議員活動が丸わかりのDB
  • ベネッセの情報漏えいをまとめてみた。 - piyolog

    2014年7月9日、ベネッセホールディングス、ベネッセコーポレーションは同社の顧客情報が漏えいしたと発表を行いました。ここではその関連情報をまとめます。 (1) 公式発表と概要 ベネッセは同社の顧客情報が漏えい、さらに漏えいした情報が第三者に用いられた可能性があるとして7月9日に発表をしました。また7月10日にDM送付を行ったとしてジャストシステムが報じられ、それを受けて同社はコメントを出しています。またさらにその後取引先を対象として名簿を販売したと報じられている文献社もコメント及び対応について発表しています。7月17日にECCでも漏えい情報が含まれた名簿を使ってDMの発送が行われたと発表しています。 ベネッセホールディングス(以下ベネッセHDと表記) (PDF) お客様情報の漏えいについてお詫びとご説明 (PDF) 7月11日付株式会社ジャストシステムのリリースについて (PDF) 個人

    ベネッセの情報漏えいをまとめてみた。 - piyolog
  • 運用が楽になる分散データベース Riak

    [D25] 分散Key-Valueストア「okuyama」&「Riak」の同時書込み性能検証 by Yusuke KuramataInsight Technology, Inc.

    運用が楽になる分散データベース Riak
  • ストーンブレイカー氏が新たに立ち上げた「Tamr」は、ばらばらに存在する企業内外のデータを機械学習で自動的に整理統合

    ストーンブレイカー氏が新たに立ち上げた「Tamr」は、ばらばらに存在する企業内外のデータを機械学習で自動的に整理統合 データベースの大御所として知られるマイケル・ストーンブレイカー氏。IngresやPostgresといったリレーショナルデータベースの先駆けとなる製品を開発、InformixのCTOを務め、またカラム型データベースのVerticaを創業、最近ではVoltDBを創業するなど、データベースの先端技術を商用化し続けてきました。 そのストーンブレイカー氏が共同創業者として立ち上げた企業が「Tamr」(テイマーと発音するようです)です。同社は5月19日、Google Venturesなどから1600万ドル(約16億円)の投資を受けるのと同時に、同社製品(社名と同じTamr)を発表しました。 高度なデータウェアハウスをほぼ自動的に作ってくれる Tamrとは、これまでストーンブレイカー氏が

    ストーンブレイカー氏が新たに立ち上げた「Tamr」は、ばらばらに存在する企業内外のデータを機械学習で自動的に整理統合
  • 『C.J.Dateのデータベース実践講義 - エンジニアのためのリレーショナル理論』 雑感(途中) - kmizuの日記

    データベース実践講義 ―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE) 作者: C.J.Date,株式会社クイープ出版社/メーカー: オライリージャパン発売日: 2006/02/01メディア: 大型購入: 4人 クリック: 170回この商品を含むブログ (52件) を見る 実はまだ完読してないのだけど、結構刺激的で面白いなのでブログ再開ついでに紹介してみよう。 まず断っておく必要があるのは、このは、SQLや特定ベンダのRDBMSの取り扱い方のノウハウではないということ。その意味でこのを読むことで即座に実践に何かを活用できるかは不明である。彼は関係モデルの祖であるCoddと共同作業をしていた時期があったこともあってか、このではRDBの基礎であるべき(と彼が主張する)リレーショナルモデルをきっちり理解しなければならないという主張で一貫しており、こ

    『C.J.Dateのデータベース実践講義 - エンジニアのためのリレーショナル理論』 雑感(途中) - kmizuの日記
  • NoSQLデータモデリング技法

    NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文:NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック

    NoSQLデータモデリング技法
  • ER図の目的とは? 初心者向けに書き方を教えます

    ER図(Entity Relationship Diagram) ER図とは、データベースのテーブル(Entity)とテーブル同士の関連(Relationship)を図に表したものであり、データベースのテーブル設計に用いられる。ER図において、エンティティは四角形の記号、リレーションは四角形同士を結ぶ線で表現される。 書き方 ER図の書き方は、エンティティとリレーションを記号で表して書く。ER図の書き方には、以下に示す2種類がある。 IDEF1X記法 IE記法 エンティティ 論理モデルのER図の場合、エンティティ(実体)は業務におけるひとまとまりのデータを表している。物理モデルのER図の場合、エンティティはデータベースのテーブルを表す。 エンティティには2種類あり、非依存実体と依存実体に分けられる。 非依存実体 非依存実体とは、他のエンティティに依存せずに存在できるエンティティである。例え

  • 分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi

    分散Key-Valueストア kumofs を、日オープンソースソフトウェアとしてリリースしました! kumofs@SourceForge kumofs関連資料まとめ kumofsとは? kumofs(クモエフエス)は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装

    分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi
  • データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ

    データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 OracleSQLServer、MySQLと色々なDBのチューニングをしてきましたが、

    データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
  • progress.from.tv » Google App Engine JDO に関してのメモ

    最近、ようやくJDOをメインで使うようになりました。 Google App EngineはJDOをサポートしており、JDOを使用することでオブジェクトの永続化が簡単に行えます。 自分が使ってみて、癖があるなと思った点を、簡単にメモとして残しておきます。 エンティティの定義 永続化対象のクラスを定義する。 クラスはごく普通のPOJOで書き、アノテーションを付与することで永続化が可能となる。 シンプルなエンティティ 一番分かりやすい、他のオブジェクトと関係が無い場合の例。 import javax.jdo.annotations.*; @PersistenceCapable(identityType = IdentityType.APPLICATION) public class Employee { @PrimaryKey @Persistent(valueStrategy = IdGen

  • IT news, careers, business technology, reviews

    Heads on: Apple’s Vision Pro delivers a glimpse of the future

    IT news, careers, business technology, reviews
  • Google Sites: Sign-in

    Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode

  • 「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine
  • 最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro

    ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの

    最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro
  • 「MySQL,PostgreSQLとFirebirdの性能をユーザー会メンバーが徹底比較,判明...

    「更新とJOINが多ければMySQL,シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB(OSC2007.DB)」で,各オープンソースDBのコミュニティのメンバーによる性能比較が披露され,従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは,オープンソース関連コミュニティが主催するイベントで,OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは,日MySQLユーザ会の堤井泰志氏,日PostgreSQLユーザ会の片岡裕生氏,Firebird日ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって,最速,最新マ

    「MySQL,PostgreSQLとFirebirdの性能をユーザー会メンバーが徹底比較,判明...
  • 1