第1回 RDBMSとNoSQLデータベース | gihyo.jp
はじめに NoSQL（Not Only SQL）という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで、不得意なところにはRDBMSにこだわらず、用途に合ったデータストアを使いましょう』という考え方です。最近では、いわゆるNoSQLデータベース （key-valueストアや各種データベース） が次々と登場してきています。 そこで今回から数回に渡り、それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。 RDBMSの強みとは そもそも、MySQLやPostgreSQLなどのRDBMSの弱みを補うため、様々なNoSQLデータベースが登場してきたわけですが、RDBMSにはたくさんの強みがあることも忘れてはいけません。 RDBMSの強み データの一貫性 （トランザクション） 更新時のコストが少ない（JOINが前提でテーブルが正規化されている）
MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
京都収納棚紅玉束縛： Rubyで簡単、DBプログラミング - mixi engineer blog
静かに暮らしたいmikioです。今回は、新進気鋭のDBMであるKyoto CabinetのRubyバインディングを駆使してお手軽にデータベースプログラミングを行う方法について述べます。 Kyoto Cabinetのおさらい Kyoto Cabinet（KC）は、Tokyo Cabinet（TC）に比べて、最適化された性能よりも保守性を重視したDBMの実装です。オブジェクト指向プログラミングの技法を用いて、少ないコード記述量で容易に機能追加できるように設計しています。また、実装としては、空間効率の向上と並列処理性能の向上を重視しています。以下のプレゼン資料も参考になると思います。 TCでもハッシュ表やB+木などのデータ構造を動的に切り替えて同じインターフェイスで操作するための「抽象データベース」という機構がありましたが、KCでは同じことを「多相データベース（polymorphic datab
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
角交換振り飛車とか 将棋棋譜五万局DBの作り方（Kifuexpl、２ちゃんねる棋譜）。無料。PC初心者用。
全てトップページにダウンロードする場所があります。 これらのファイルは日々更新されていますので、最新版を落して下さい。 ちなみにKifubaseも棋譜管理が出来ますが、kifuexplはKifubaseより遥かに優れているし、フリー版は１０００局しか登録できません。 kifuexplをお勧めします。 参考記事： 棋譜の管理 Kifuexpl の解説と批評 ■ダウンロードしたファイル： このように二つファイルがダウンロードできたと思います。 ファイル名は新しい更新が出たら変わりますので最新版をどうぞ。 落した場所は、普通デスクトップかマイドキュメント内の「Downloads」です。 ■ファイルの移動： ファイルの移動を強くお勧めします。 理由として、「2chkifu.exe」内には５万局以上の棋譜が入っています。 解凍（展開）したファイルを開こうとすると、ほぼ間違いなくフリーズしますので、注
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
YappoLogs: あなたがData::Modelを使う10の理由
« JPerl Advent Calendar hacker track で Module::Setup の事書いたよ | Main | Module::Requires について hacker track last day を書きました » あなたがData::Modelを使う10の理由 前口上 一昨年書いた『あなたがRuby on Railsを使わない10の理由』を書いたら、おおむね好評とともに読んでもらえたみたいで(ほんとかー?)うれしい限り。実際あのあとも記事の影響ってわけじゃないと思うけどRoR使ってくれた人もたくさんいるし、ますます広まってきているみたいでこれも私設営業の人としてはとてもうれしい。 略 (例によって書きかけなので今後もいろいろ変わったりするかも) Data::ModelはCPAN Moduleである まあ上でああいったけどやはりCPAN Moduleであることそ
Kazuho@Cybozu Labs: Perl で埋め込み SQL を使って楽をする話
« Japanize for IE バージョンアップのおしらせ | メイン | Filter::SQL を使って掲示板を書いてみました » 2008年04月16日 Perl で埋め込み SQL を使って楽をする話 DSL (ドメイン固有言語) は、プログラム開発の生産性を向上させる有力な手段です。そして、よく使われる DSL の代表例が正規表現と SQL だと思うのですが、前者に比して後者を嫌いな人が多いようです。なぜだろうと思ってつぶやいたところ、「SQL はリテラルじゃないから！」という答えが tokuhirom さんから返ってきました。そういえば例えば Pro*C のように C で Embedded SQL というのは良く聞く話なのに、Perl では同様の例がないような感じだったので、作ってみました。Perl で埋め込み SQL を実現するソースフィルター Filter::SQL で
テレビのリモコンを孫の手で押すなって！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 弊社でやっているSQL講座の最初の方でお話しする内容です。 どれぐらいの人が試すのかな……、知ってる人にとっては極めて当たり前のことですけれど、知らない人は、けっこうびっくりする人もいるので、実際にやってみることを強くおすすめします。（できないという人はセミナーに来なはれ） では、ちょっとしたサンプルを作るか、それなりにデータ量のある既存のテーブルのインデックスを張ったカラムに対して、以下のSQLの実行計画を取ってみてください。 【注意事項】 実行計画を取る前に、Oracleは一応、アナライズをしておいてください。SQLServerは主キー以外のインデックスがある列を使うこと。 【準備】 SELECT MIN（カラム） , MAX（カラム） FROM テーブル
Kazuho@Cybozu Labs: 高度に進化した分散データストアは RDBMS と見分けがつかない？ (shibuya.pm #12 スライド)
開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、なぜ RDBMS ベースのアプローチを採用したのかという背景を中心に説明させていただきました。概念的な話が多くて分かりにくかったと思います（すみません）が、細かな点についてはパフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)を参照いただければと思います。 また、中で出てきた「実体化ビュー」については、Materialized view - Wikipedia, the free encyclopediaが良くまとまっているかと思います。Incline は一言でいうと、RDBで構成されるshard群の上で read-only かつ eventually co
第21回 KiokuDB：マッピングが複雑すぎると感じたら | gihyo.jp
Shibuya.pm #12連動企画 本日開催のShibuya Perl Mongersテクニカルトーク#12のテーマは "No Perl, NoSQL, NoKVS" または "Not only Perl, Not only SQL, Not only KVS" ということなので、今回はそれにあわせてYAPC::Asia 2009でも紹介されていたKiokuDBについて簡単に取り上げてみます。 オブジェクトをまるごと保存する 牧大輔氏も『モダンPerl入門』のなかで、データベースをハッシュテーブルのようにとらえて、「基本的にプライマリキーからデータを持ってくる構成のみにすると、ORMを使用することによりキャッシュの導入も含めてチューニングが楽になります」と書いているように、Perlの世界では最近RDBMSやその上位層で頑張りすぎるより、モデリングの仕方そのものを工夫して実装や保守のしや
NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある
Webスケールのデータを扱うためにさまざまなデータベースが登場してきている、ということを昨日のエントリ「データベースは目的別に使い分けるべし」で紹介しました。 特にリレーショナルモデルをベースとしない、非SQL系（NoSQL）と呼ばれるさまざまな種類のデータベースが登場してきています。非SQL系のデータベースは以前からオブジェクトデータベースやドキュメントデータベース、階層型データベースなどが存在していましたが、最近注目されているのがキーバリュー型データストアと呼ばれるデータベース。 ブログ「High Scalability」にポストされたエントリ「A Yes for a NoSQL Taxonomy」では、これら非SQL系のデータベースを詳細に9分類し、それぞれの分類に属するデータベースをリストアップしています（基になったのは「NoSQL is a Horseless Carriage」
Tokyo TyrantとテーブルDBでリアルタイム検索 - mixi engineer blog
ドラクエは卒業して、もっと英語漬けをやっているmikioです。さて今回は、データベースサーバTokyo Tyrantとテーブルデータベースを使ってリアルタイム検索システムを構築する方法について語ります。 テーブルDBを分散させたい Tokyo TyrantでもテーブルDBがサポートされているわけですが、これはリアルタイム検索システムへの布石です。テーブルDBは任意のコラムにインデックスを張ることができ、時系列のコラムにインデックスを張ればその値によって古いコラムを効率的に消すことができます。チュートリアルの「Persistent but Expirable Cache」でもその方法を示しています。また、任意のコラムに分かち書きトークン方式もしくは文字N-gram方式で転置インデックスを張ることができます。これらを総合すると、最新のデータのみを保持してサイズと性能を一定に保ったインデックスを
［速報］AmazonクラウドがMySQLサービス開始、パッチもバックアップもおまかせ
Amazon Web Servicesがクラウド上でMySQLをホスティングする「Amazon Relational Database Service (Amazon RDS)」のβ公開を開始しました。 インストール不要でMySQLの利用を開始でき、パッチ当てやバックアップなどもAmazonクラウド側で実行してくれるため、MySQLの導入や運用の手間を大幅に削減可能です。 MySQLのインスタンスは規模に応じて5種類が用意されています。 Small DB Instance : （1時間あたり0.11ドル） 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), 64-bit platform Large DB Instance : （1時間あたり0.44ドル） 7.5 GB memory, 4 ECUs (2 virtual cores with
Amazon Relational Database Service (Amazon RDS)
Amazon Relational Database Service Easy to manage relational databases optimized for total cost of ownership Amazon Relational Database Service (Amazon RDS) is an easy-to-manage relational database service optimized for total cost of ownership. It is simple to set up, operate, and scale with demand. Amazon RDS automates the undifferentiated database management tasks, such as provisioning, configur
ZeroMQ
Why ZeroMQ? ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
YappoLogs: Data::Model っていう ORM みたいの CPAN にあげたよ
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 を参考にして開発しました。 他にも後述して
データベースの動的デフラグ - mixi engineer blog
ノートPCの冷却ファンがうるさいのを対処しようとしてWebで調べたら、そのファンの設計者が「静音性へのこだわり」を語ったページにたどり着いて複雑な心境のmikioです。今回は、Tokyo Cabinet（TC）の最新バージョンで実装された動的デフラグ機能について長々と説明します。 断片化とデフラグ 任意のサイズのデータを管理する記憶装置においては、利用可能領域の断片化（fragmentation）の問題が常につきまといます。ファイルシステム上で任意のサイズのファイルを管理する際にも、データベースファイル内で任意のサイズのレコードを管理する際にも、C言語のmalloc/free関数群でメモリの管理をする際にも、様々なレイヤで断片化が起きうるのです。なぜなら、データを削除もしくは移動した際の空き領域を再利用するにあたって、その領域と同じサイズのデータが常に入ってくるとは限らないからです。特にデ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
