サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
読み込み＞書き込みなデータベースだと、実体化ビュー (materialized view) を使って読み込み速度を上げるってのは有効な手法 ちなみにMySQL や PostgreSQL だと実体化ビューはトリガーを使って書く *1 では、トリガーベースの実体化ビューを後から追加した場合に、どうやって既存データを新しいビューに反映させるのか。 UPDATE トリガを、ビューの側に対応するデータがない場合は INSERT トリガと同様の動作をするように実装すればいい (典型的には REPLACE INTO 文を使う)。ビューの初期データ充填は UPDATE src_table SET id=id;MySQL だとCREATE INDEX CONCURRENTLY がないから副インデックス作成はスレーブでやったりする*2けど、上の UPDATE を LIMIT つきで回すことで、ビューをイ
ErmodellerはJava製のオープンソース・ソフトウェア。最近はデータが主体になったシステム開発が多い。データは大抵がデータベースによるものだ。そうなるとデータの定義が固まればコントローラの仕組みも大抵決まってくる。データベースを適切に設計することが、システムの組みやすさやパフォーマンスに大きな影響を及ぼすのだ。 各種DBに対応したモデリングができる そうなるとデータモデリングソフトウェアに対する期待が大きくなる。その点、マルチプラットフォームで動作するJava製のモデリングツールは優位だろう。Ermodellerは多数のデータベースに対応したモデリングソフトウェアとして便利に使えそうだ。 Ermodellerが対応するのはMySQL/PostgreSQL/Oracle/PointBaseとなっている。モデリングは概念、論理、物理型の3つに対応している。データベースからのリバースエン
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
サーバを安全に運用する施設として構築されるデータセンターですが、グーグルではそのデータセンターですら"落ちる"ことがあると想定してアーキテクチャを構築しています。 米グーグルが今年の5月に行ったイベント「Google I/O」で、同社のGoogle App Engine datastore leadであるRyan Barett氏が行った講演「Transactions Across Datacenters (and Other Weekend Projects)」のビデオがYouTubeで公開されました。 Barett氏は、担当しているGoogle App Engineのデータベースに関してグーグルが「multihoming」（マルチホーミング）と呼ぶ複数のデータセンターを用いた処理を実現している理由として、データセンターが自然災害や停電に見舞われたり、メンテナンスなどによるデータセンターの
SQLJet is an independent pureJava implementation of a popularSQLitedatabase management system.SQLJet開発チームは15日(米国時間)、SQLJetの最新版となるSQLJet 1.0.0を公開した。SQLJetはJavaで実装されたSQLiteデータベース操作用ライブラリ。SQLite 3.6のデータベースフォーマットに対応。GPLのもとでオープンソースソフトウェアとして提供されている。SQLJetを使うにあたってSQLiteやほかのネイティブライブラリは不要。Javaで開発されたSQLJetのみで動作する。SQLiteを使って作成されたデータベースファイルの読み込みと操作、または自らSQLiteデータベースファイルを作成する機能を提供している。今のところAPI経由の操作のみ提供し、S
Voldemort is a distributed key-value storage system Data is automatically replicated over multiple servers. Data is automatically partitioned so each server contains only a subset of the total data Server failure is handled transparently Pluggable serialization is supported to allow rich keys and values including lists and tuples with named fields, as well as to integrate with common serialization
Excelで作ったデータをデータベースに取り込む、なんて要件はよくある。面倒だがExcelデータをCSVに変換して、1番目のカラムが名称、2番目のカラムが価格…なんて定義したりした経験はないだろうか。 ビジュアル的にデータのインポートを定義する それがさらに関連しているテーブルに渡って処理しないといけないなんてなったらパニックだ。そこで使ってみたいのがdbTubeだ。 今回紹介するフリーウェアはdbTube、ビジュアル的にモデル定義ができるインポートプログラムだ。ソースコードは公開されているがライセンスは明記されていなかったのでご注意いただきたい。dbTubeの良さは何と言ってもビジュアル的にデータの定義ができることだ。Open-jACOB Draw2Dを使って元になるExcelデータとテーブルのマッピングがドラッグアンドドロップでできる。さらにExcelデータは何行目から読み出すかと言
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数のRDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS がRDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
ノートPCの冷却ファンがうるさいのを対処しようとしてWebで調べたら、そのファンの設計者が「静音性へのこだわり」を語ったページにたどり着いて複雑な心境のmikioです。今回は、Tokyo Cabinet（TC）の最新バージョンで実装された動的デフラグ機能について長々と説明します。 断片化とデフラグ 任意のサイズのデータを管理する記憶装置においては、利用可能領域の断片化（fragmentation）の問題が常につきまといます。ファイルシステム上で任意のサイズのファイルを管理する際にも、データベースファイル内で任意のサイズのレコードを管理する際にも、C言語のmalloc/free関数群でメモリの管理をする際にも、様々なレイヤで断片化が起きうるのです。なぜなら、データを削除もしくは移動した際の空き領域を再利用するにあたって、その領域と同じサイズのデータが常に入ってくるとは限らないからです。特にデ
メインフレーム時代とはCOBOL時代と言い換えてもいいでしょう（RPGやPL/Iの方には申し訳ない）。これは更に言い換えると固定長のパラダイムだとも言えます。オープンシステム時代になりRDBMSが主流となったときに一番のパラダイムシフトは、実は明細の扱い方だったと言えます。COBOLをご存じの方はOCCURSを当然使っていたはずです。OCCURSとは繰り返しを表すもので、売上データというファイルがあったときに明細部分は繰り返しになりますから、OCCURSを指定します。ややこしい言い回しを使っていますが、要するに配列定義ということです。 さて、COBOLは固定長のパラダイムだと書きました。実はこのOCCURSで定義される配列は繰り返し数が事前に固定されます。例えばOCCURS 5.と書けば5回繰り返しということです。一応可変長が可能ということになってはいるのですが、多分今でも指定した上限を
先日ERDレッスンがどうのとかRDBMSありきとか書いておきながら何ですが、Pythonに加えてCouchDBが楽しいです。CouchDBのMapReduceを実行するView ServerのデフォルトはJavaScriptですが、これもPythonに差し替えてみたりしてます。でも試行錯誤中なのと、私の環境では日本語の扱いがPythonだと上手くいかないので、世の中のサンプルをコピる場合はJavaScriptを使ってます。Pythonを使うときはIDEはPyScripterを使っているのですが、ぶっちゃけメモ帳でもOKな気分です（笑）。大きなアプリケーションを作ってないからだとは思います。あとはコマンドプロンプトとブラウザで済んでます。軽くていいです。 不思議なもので、JavaのときはIDE上でやらないと落ち着かない体になっていたのですが、Pythonだとコマンドラインのほうが気持ちいい
以前に読んだGoogleに関する本にも同じような技術に関する記述があった（タブレット辺りだろうか）。Googleで使われている技術はGoogleだからこそ（圧倒的台数のコンピュータ、ネットワーク、その需要など）できることだが、その論文を元に同様の技術を一般のサービスでも利用できるレベルに落とし込んでくれる人たちがいる。 サーバを起動した所 オンメモリのKey-Valueデータベースと言えばmemcachedが有名だ。だがmemcachedは再起動すればその内容が消えてしまう。逆に常にHDDに書き込めば内容は保持されるが、ディスクアクセスが多くなってしまい利点が活かせなくなる。その中間を担うのがRedisだ。 今回紹介するオープンソース・ソフトウェアはRedis、永続化にも対応したオンメモリKey-Valueデータベースシステムだ。 RedisはKey-Valueのデータベースではあるが、一
正月早々インフルエンザにかかって寝込んだmikioです。電車に乗る時や繁華街などに出る時はマスク着用が必須ですね。さて今回は、Tokyo Cabinetで実装したテーブル方式のデータベースについて紹介します。意外にどうして強力な機能なので、このネタは連載することを予告します。 テーブルデータベースとは 簡単に言えば、リレーショナルデータベースのテーブルのように、複数の列からなるレコードを格納できるデータベースです。SQLや表結合などの複雑な機能はサポートしませんが、そのぶん高速に動作します。つまり、DBMの速度で動くリレーショナル風データベースです（厳密にはリレーショナルデータベースではありません）。 TCの基本となるハッシュデータベースは、単純なkey/value型のデータベースであり、つまりキーにも値にもスカラ（数値や文字列などの特に構造を持たない単一の値）しか格納することはできません
Jiemamy作者が考える “データベースの進化的設計” データベースもアジャイル開発に対応したい！アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく体制が必要です。アジャイル開発の考え方にのっとるなら、アプリケーションだけではなくデータベースについても設計の凍結はせず、また、ソースコードに限らずデータベースの構成・設計についてもリファクタリングが適用されるべきです。Jiemamyはこの問題に取り組むプロジェクトとして始められました。本稿ではこのJiemamyの取り組みを紹介します。 ソースやスキーマだけ管理しても意味がない 近年注目を集めている「アジャイル開発」は、リファクタリングが重要な要素の1つであることはご存じのとおりです。アジャイルの考え方においては、実装前にシステム要件・設計を確定させることはせず、常に変化を受け入れていく
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
