タグ

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

  • 書評:「7つのデータベース 7つの世界」

    訳者、角 征典氏より献御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDBNeo4j、Redisである。書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。 正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。当に辛口になるのでその点は容赦して頂きたい。 何が問題なのか

    書評:「7つのデータベース 7つの世界」
  • Clojureの作者が作ったデータベースDatomicが凄い

    プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ

  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
  • ソーシャルゲームのためのデータベース設計

    ・データベース的な観点でのソーシャルゲームの特徴 ・データモデル ・ソーシャルゲームに従来型RDBMSを使うべきか、�流行りのNoSQLで行くべきか ・負荷対策 (アーキテクチャ面) ・負荷対策 (ツール面) ・インフラエンジニアのキャリアについて

    ソーシャルゲームのためのデータベース設計
  • NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance

    ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ

    NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
  • Drizzleプロジェクトの目指すもの、その先を読む(1/3) - @IT

    クラウドコンピューティング環境のような“massively concurrentな世界”で使えるデータベースを目指すDrizzle。その開発の方向性からこれからのWebシステムで求められるデータベースのあり方が見えるかもしれない。一足先にDrizzleに触れてみよう(編集部) Drizzleとは Drizzle とは、MySQLのもともとの目標である、使いやすさ、信頼性、そしてパフォーマンスに重点を置いたMySQLの派生プロジェクトで、Brian Aker氏(米サン・マイクロシステムズ CTO/Labs:元MySQL Director of Architecture)によって立ち上げられました。 MySQLと比較して機能面におけるDrizzleの大きな違いは、サーバアーキテクチャをマイクロカーネルにすることで、サーバ(MySQLでいうmysqld)には必要最小限の機能しか搭載せず、代わりに

  • その分析、Hadoopなら速く安くできます

    ビジネスデータを分析するビジネスインテリジェンス(BI)分野の新たなプラットフォームとして注目されているHadoop。Hadoopでは、どのようなデータ分析が可能なのでしょうか? 現在、Hadoopビジネスの牽引役であるClouderaのJeff Hammerbracher氏が、Hadoopでデータ分析が可能なビジネス上の課題を示した「10 Common Hadoop-able problems」(Hadoop化可能な10の一般的課題)と題したプレゼンテーションを公開しています。 Hadoopにとって得意な処理とは、複雑で複数のデータソースからなる大量のデータの分析であり、それをバッチ処理の並列実行によって実現することです。 従来は、データがあまりに複雑だったり膨大だっために、計算時間やコストなどの理由で実現が難しかった処理でも、Hadoopによる低コスト化、計算時間の短縮、高い柔軟性など

    その分析、Hadoopなら速く安くできます
  • 4万件を誇る、ダジャレのデータベース | ライフハッカー・ジャパン

    こんにちは。ココロ社です。 21世紀に入ってからというもの、ダジャレを聴く機会もめっきりなくなってしまいましたよね。まあ、20世紀でも使ってる人はそんなにいなかったような気もしますが...。 .しかし、ダジャレをいくつか覚えておくことは悪くないことです。当たり前ですが、いまダジャレを言っても、面白いと思われることは絶対にないですが、「ここ一番で、あえて超つまらないことを言いたい!」というときには、ダジャレが有効です。 この「ダジャレナビ」は4万件の規模を誇るダジャレの宝庫。4万件っていうとどれくらい詳しくなるかというと、このスクリーンショットからもわかるとおり、「アイオワ州」ですら5個もダジャレが用意されていて、そもそも「アイオワ州」という言葉を発音せずに一生をすごす日人の方が多いんじゃないかと思いますが、何かあったときも安心ですね。 そして、twitterのbotも用意されていて、30

    4万件を誇る、ダジャレのデータベース | ライフハッカー・ジャパン
  • 続、グーグルはリレーショナルデータベースをクラウドに乗せるか?

    先週、グーグルはリレーショナルデータベースをクラウドに乗せるかというエントリを書いたところ、いくつかのコメントやトラックバックをいただきました。 いずれも興味深いコメントだったにも関わらず、コメント欄に利用しているTypePad Connectがなぜかうまく動作しておらず、表示できませんでした。しかしそれではもったいないので、このエントリとして紹介させていただこうと思います(TypePad Connectには障害報告しました)。 元になったエントリの主旨をまとめると、Google App EngineはJavaに対応したし、企業内のデータセンターとセキュアな通信もできるようになった。これはGoogle App Engineが企業向けのサービスとして方向を定めたことを示す。だとすると、企業システムに不可欠なリレーショナルデータベースもきっとGoogle App Engineにのせてくるのでは

    続、グーグルはリレーショナルデータベースをクラウドに乗せるか?
  • TableAdapterで手動トランザクションを使う方法 (.NETの覚え書き)

    MSDTCが止まっている状態でTransactionScopeは使えないため、代わりの方法を試してみました。 決してきれいな方法ではないです。 TableAdapterのPartialクラス定義を考慮すればもう少しマシになると思いますが、それでも無理矢理な感じは否めない。 やっぱり素直に TransactionScope を使いましょう。 サンプルとして、みんなのお約束 Northwind を使います。 (下のコードの処理自体は全く無意味) 1. Windowsアプリのプロジェクトを新規作成 2. DataSetを追加。 3. Customers(列は CustomerID, CompanyName, City)テーブルとSuppliers(列はSupplierID, CompanyName, City)のTableAdapterを追加 4. CustomersTableAdapter(S

  • PostgreSQL 7.2.1 - 日付/時刻関数と演算子

    4.8. 日付/時刻関数と演算子 Table 4-17 は日付/時刻の値の処理を行う関数を示しています。 Table 4-16 は(+、* 等のような)基的な算術演算子の振舞いを説明しています。フォーマッティング関数については Section 4.7 を参照ください。日付/時刻データ型に付いての背景となっている情報に精通していなければなりません( Section 3.5 を参照)。 以下に示す日付/時刻演算子の振舞いは時間帯付きおよび無しのデータ型に似通っています。

  • NoSQL登場の背景、CAP定理、データモデルの分類

    その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLORM(Object-Relational Mapping)では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ

    NoSQL登場の背景、CAP定理、データモデルの分類
  • 物書きがネットを使い倒すための7つの検索

    ==ネタ編== まだ書こうとするものがはっきりと見えて来ない段階や、曖昧模糊とした「原初のスープ」にスパイスの一撃を加えたい時など、探してみて見るとよい検索たちです。 ■物語要素事典 古典、民話から小説映画漫画に至るまでを対象に、物語のパーツとなる「物語要素」(物語素)を拾い出し、分類、整理したもの。いわば定番的あらすじ/エピソードの集成なので、ストーリーを考えたり、必要な要素を加えたりする際のヒントになる。 (使用例)上の検索ボックスをつかって ・「"犬" site:http://www.aichi-gakuin.ac.jp/~kamiyama/」で犬が活躍する物語を探す。 ・「"雨宿り" site:http://www.aichi-gakuin.ac.jp/~kamiyama/」で雨宿りにまつわるエピソードを探す。 (サイトURL) http://www.aichi-gakuin.

    物書きがネットを使い倒すための7つの検索
  • ウェブログ図書館 Weblog(Blog) Library (jienology.com)

    【ウェブログ図書館 Weblog(Blog) Library】 ((・∀|lll| (jienology.com)■ [雑感]昨日のオフ会で喋った事の補足 (煩悩是道場) ■ [雑感]一日平均10時間座り続けているid:ululunが今使っている椅子 (煩悩是道場) ■ [はてな]はてなキーワードについて少しだけ (煩悩是道場) ■ []SF再読(3)「そしてわたしは失われた道をたどり、この場所を見いだした」 ジェイムズ・ティプトリーJR (煩悩是道場) ■ []SF再読(4)「エイン博士の最後の飛行」 ジェイムズ・ティプトリーJR (煩悩是道場) ■ [雑感]ツンデレテレビ (煩悩是道場) ■ []SF再読(2)「楽園の乳」 ジェイムズ・ティプトリーJR (煩悩是道場) ■ []SF再読(1)「すべての種類のイエス」 ジェイムズ・ティプトリーJR (煩悩是道場)

  • 1