プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
（この記事は Scala Advent Calendar jp 2010 の1日目です。） Scala用のScalaで書かれたDBアクセスのためのライブラリ、querulousについて書きます。 とりあえず読み方がよくわかりませんが、クゥエルァラス？？みたいな感じです。すごく言いにくいので「クエララス」ってことにしましょう。英語の形容詞で、意味は「不平たらたらの、不平をブツブツ言う」らしいです。ヒドイ名前ですね。 querulousは以前紹介したKestrelと同様、Twitterで作られて使われているものです。もう辞めちゃったらしいですが、元 TwitterのNick Kallen氏が作ったそうです。今はGithub上でtwitterというIDの中で管理されています。 （12/8 追記 Nick Kallen氏はまだ辞めてませんでした。すみません、Alex Payne氏と勘違い。kzys
memcachedのように一時的なデータを高速に扱えながらもデータをファイル上に永続化できるサーバとして、「Kyoto Tycoon」という製品を開発することにした。もちろん、Kyoto Cabinetをストレージにしたネットワークサービスを提供するものである。実のところ、決まっているのはその点と名前だけで、設計は何も決まっていない。ここにあーだこーだ書きながら詰めていこう。 背景 先に明言すべきは、これはKyoto CabinetをストレージにしたTokyo Tyrant相当の製品ではない。TTはキャッシュサーバではないので、memcachedで言う所のexpireをサポートしていない。しかし、Kyoto Tycoonはキャッシュサーバとしての利便性を追求し、もちろんexpireをサポートするとともに、レプリケーションなどの重量級の機能は割愛する。 なぜこれを作るかという理由は大きく二つ
MongoDBのPerlドライバのメンテナでもあるKristina Chodorow女史のブログを読みますと、いろいろとtwitterで中傷されるそうです。これらの中傷は主として反NoSQL派の人によるものですが、私はそもそもtwitterを止めればいいのにと思っています。twitterをするから余計な雑音を否応無く目にするわけで、只でさえ情報過多な現代社会において、連絡用でなければ、文字制限があるショートメッセージサービスでまともな議論なぞ出るはずが無いと思っています。 もっと言えば、NoSQLとSQLと言う分類もまた可笑しいのです。そもそも、RDBMSモデルの提唱者である故コッド博士は、SQLを死ぬまで反対し、失意の内に亡くなられました。博士はもっと自然言語に近い、本当にクエリし易いものを望んでいたのですが、ボラクルのおっさんが博士のアイデアを適当に曲げて、SQLの原型を作り製品化しま
YAPCおつかれさまでした。YAPC中、今まさに課題になっているDB周りの問題を解消すべくDBIx::Encodingというモジュールを書きました。このDBIx::EncodingはDBIのサブクラスで、executeとfetchの際に指定した文字コードでencode/decodeしてくれるものです。そもそもDBの文字コード設定がUTF8なら余り悩むこともないのですが、世の中いろいろと事情があってDB側を変更できない事も多いでしょう。そんなときにこのモジュールを使うと、DBI側で文字コードをencodeしてinsert/updateしてくれ、selectしたときにはutf8 flagを有効にした文字列を返してくれます。使い方はSYNOPSISにもありますが、下記の通りmy @dsn = ( 'dbi:mysql:host=localhost;database=mysql;
BPStudy#25 : ATNDのメモ。 色々まちがって解釈してるところがあるかも知れませんが、間違いを発見したらDISらずに優しく指摘してください ＞＜ サイボウズ・ラボ 奥一穂さん Kazuho@Cybozu Labs Happy Optimization 正しい最適化 プロファイラを使うとか以前の話として 「30%速くなったよ」ではダメ 投入するコストを回収できるかどうか 処理速度には必ず上限がある 「理論上の最速値の70%まで到達」のようなものがgood ではどうやって上限を予測するか 一般的にはIPC(プロセス間通信)のコストがボトルネックになる サーバを単純化してもメリットは小さい とは言えC10Kだとアルゴリズム重要 速度の壁を突破する方法を考える SIMD、圧縮、グループコミット、Lock-free algorithmなど Scaling? 「スケール」とは ムーアの法則
コアライブラリを一生懸命書くとユーティリティやバインディングなどの周辺機能がおろそかになり、逆も然りで、工数割り当てのジレンマが歯がゆいmikioです。今回は余談として、Tokyo Cabinetのテーブルデータベース（TCTDB）を作る途中で思いついた更新機能と性能検証について述べます。 アトミックな更新 再び TCTDBで好評だったっぽいアトミックな更新機能をその他のデータベースでも実装してみました。例えばハッシュデータベース（TCHDB）では以下の関数が提供されます。 typedef void *(*TCPDPROC)(const void *vbuf, int vsiz, int *sp, void *op); bool tchdbputproc(TCHDB *hdb, const void *kbuf, int ksiz, const char *vbuf, int vsiz,
約半年間の沈黙を破ってOSSの世界に戻ってきつつあるmikioです。先日、Tokyo Cabinet（以下「TC」と呼びます）というデータベースライブラリをリリースしました。今回から数回に分けて、TCの設計と苦労話について連載してみます。 DBMとは TCは、いわゆるDBMの系譜のデータベースライブラリで、単純なハッシュテーブルをファイル上で永続化するだけの機能を提供します。DBMはAT&Tの古代UNIXの時代から受け継がれる伝統芸能なのですが、私はそういう枯れた技術が大好きなのです。 プログラマの皆さんは、PerlやRubyではハッシュ（連想配列）と呼ばれ、JavaやC++ではmapと呼ばれるような、何らかのキーに関連づけてなんらかの値を記録するデータ構造って実によく使いますよね。例えばmixiでは、ユーザアカウントに関連する情報（名前とかニックネームとか）は、ユーザIDをキーにしたハッ
全て 1.このサイトについて 2.作品DB開発/運用 3.ホームページ制作技術 4.Perl 5.C言語 / C++ 6.検索エンジン&SEO 7.サッカー 8.自分のこと 9.Linux 10.旅行 11.思ったこと 12.パソコン 13.Berkeley DB 14.その他技術系 15.企画 16.スマートフォン 17.鑑賞 18.皆声.jpニュース 19.インターネット業界 20.運用マニュアル(自分用) 21.技術系以外実用書 22.料理 23.ALEXA 24.アニメ 25.会計 26.漫画 27.設計書 28.色々サイト作成 29.サーバー 30.自分専用 31.生活 32.OP/ED/PV 33.ゲーム 34.DB整備 35.新規開始作品紹介 36.英語圏の話題 37.大道芸 38.映画 39.PHP 40.ダイエット 41.Mac 42.JavaScript 43.MySQ
本人が大まじめなので少し補足説明。 まず、 id:nowokay はコメントで書かれているような、Javaしか書けないとかSQLが書けないとかDBの知識がどうのというような、脊髄反射でDISられるようなレベルではない。寝坊についてはDISられても仕方がない。 自分が理解している、きしだ理論は以下のよう。 前提： JPAは永続化実装に依存しない永続化APIである SQL(RDBMS) < JPA+JPQL 実現したい機能が満たせる前提で、永続化実装に依存しないという意味で。もちろんこの時点でアプリケーション側はJPA(Java)に依存。 話題のターゲットは、参照が多く、REST的なURLにマップできるくらいの複雑さを持つWebアプリ RDBでしか実績が豊富にないような複雑な業務アプリはRDBのままでかまわない。 である時に、JPAでRDBに依存しないような考え方でプログラムを作っておけば、（
NAME DBIx::Skinny::Manual::JA - DBIx::Skinnyの設計思想など DESCRIPTION DBIx::Skinnyをなぜ作る事にしたのか、 また作るにあたっての設計思想など。 Please translate and read the person in the sphere in English. なぜDBIx::Skinnyを書いたのか PerlのORマッパーは色々あります Class::DBI, DBIx::Class, Data::ObjectDriber, Data::Model, etc... ここにあげたORマッパーは基本的には利用者が設定したtable構成を基にSQLを組み立ててdatabaseにクエリを投げます。 そしてその結果を各種オブジェクトにしています。 私はいままでClass::DBIやDBIx::Classを色々使ってきまし
Kazuhiro Osawa Kazuhiro Osawa <yappo <at> shibuya <döt> pl> Tokuhiro Matsuno tokuhirom yappo 大沢 和宏 <yappo> NAME Data::Model::Tutorial::JA - Data::Model::Tutorial日本語版 Data::Model とは id:yappo さんがつくっている O/R Mapper。新興のものでチュートリアル的なものがない ので自分でかいてみることにしました。 とはいえ、Data::Model 自体がまだまだαクオリティですので、チュートリアルもてぬき です。 現在の Data::Model のドキュメントは Data::Model Track - JPerl Advent Calendar 2009 に良質なドキュメントがありますので、そちらを参考に
Data::Model っていう ORM みたいの CPAN にあげたよ あざーす。循環参照しすぎるとバターになる。。なんでそんなに人の目を気にするのだろうと、マジレス。 早速ですが Data::Model っていう O/Rマッパー 的な物を CPAN にあげました。 Data::Model http://github.com/yappo/p5-Data-Model/tree/master 元来は MVC モデルで言う所の Model を一括でまかなえるつもりで実装していますが、ロジック処理は普通の Perl のクラスで書いちゃった方が潰しが聞くため、主にストレージを Perl のオブジェクトにマッピングする ORM 的な使い方が主流となっています。 そして、 Data::Model の多くの実装や設計などは Data::ObjectDriver を参考にして開発しました。 他にも後述して
先週末の YAPC::Asia 2009 のカンファレンスに引き続き、特別研修『Moose入門、モダーンなオブジェクト指向システム』に参加してきた。 研修の内容は、Moose とはなんぞやから始まり、以下（だいたい）7 部構成の入門講座。 Moose Concepts : コンセプト ざっと機能一通りみてみる なぜ Moose なのか Classes : Class の基礎から使い方 Moose::Object が何持ってるかとか BUIDLARGS, extends, override, super の使い方 Moose 使ったあとの後始末 (no Moose;) Role : Role の基礎から使いかた Role の持つ意味 使い方 alias で衝突回避 Basic Attributes : Attribute いろいろ required, default/builder, laz
CakePHPで作成したアプリケーションに対して、Javaアプリケーションから簡単なDB操作（実際はselectだけできればOK）をする必要があって、生のSQLを書くか、それともいい機会だしORマッパのライブラリを勉強がてら使ってみるか、、なんて悩んでいました。保守性を考えるとやっぱり生SQL案は無しで、ORマッパを使うことにしたのですが、Hibernateはどうもリッチすぎる印象があってなかなかやる気が進みませんでした。大規模アプリ開発ならまだしも、今回は上で書いた通り、最低限の参照だけできればそれで事足りる状況だったので、そのためだけにわざわざ設定用のXMLを書くのは気が引けていたのです。 3分で始められるORマッパ 3分間クッキングじゃないですけど、それくらい手軽に操作できるものをずっと探し続けていたら、ActiveObjectsなるプロジェクトに辿り着きました。 AcitiveOb
KVSでORマッパーを使うという事 ケイレキ.jpの中でケイレキ.jpに招待して欲しい人を呼びかけても絶賛スルーされてるYappoです。さて今回は今巷で大人気のKey Value StorageでORマッパーを使う事についてお話するのじゃ。 一般的にORマッパーとはオブジェクトとリレーショナルデータベースをマッピングする為の仕組みの呼び名だと言うのは知られている所です。はい、そうするとKVSってのはハッシュデータベースであるわけなのでおかしいですね。今回の話はData::Model::Driver::Memcachedを使う事を前提としてるので問題が無いのです。なぜなら「data/object mapper」とか書いてあるから。 いわゆるPerlなORマッパーってのは行データをHASHで管理します。それはRDBが一般的に表形式でデータを管理しているからなんだと思います。なんでKVSをオブジ
yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには？」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBはMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま
※この文書は、 [SQLAlchemy 0.4 for people in a hurry] の v.29 を翻訳したものです。 これは、 Pylons >= 0.9.6 と SQLAlchemy >= 0.4 のための SQLAlchemy 0.4 バージョンの記事です。もしまだ SQLAlchemy 0.3 を使用しているなら、[SQLAlchemy 0.3 for people in a hurry] を見てください。このバージョンは、 SAContext や pylons.database を使用しません。その両方とも廃止されました。 これは、他のコンポーネントを使い始めるための Pylons のクイックガイドのひとつです。それは Pylons 0.9.6rc2 (2007年8月) 現在、 PylonsとSQLAlchemy を使用するお勧めの方法を述べます。これは Pylons
Web2.0的システム構築―より進化したシステムの考え方をちょっと流し読んでたら、PythonでのO/R MappingとしてSQLObject — SQLObject 3.5.0 documentationの、ものすごい簡単な紹介があったので興味をひかれたので試してみる。 本当にものすごく簡単に紹介していて、ついでに「SQLObjectを使ったようなコードはJavaのような重量級言語では実現できないに違いない、これがスクリプト言語の醍醐味だ」みたいなことが書かれていて、ちょうど、寝る前に試すには良い規模かなー、なんて思ってしまった。 実際には、予定よりも5時間もオーバーして、朝になってしまった。orz とりあえず、基本的な使いかたは分かった気がするので、いろいろ不足する部分もあるが、ここで一区切りつけたい。 用意するもの Python2.5 SQLite3が同梱されているから SQLOb
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く