##TL;DR 負荷の変動が激しい環境でコネクションプールの設定のチューニングをさぼるためによくやるハックを紹介します。 ##問題 Go から https や mysql など外部のリソースにアクセスする場合、一般的にコネクションプールを使うことになります。 コネクションプールは、利用が終わった (idle) コネクションをプールしておき、次に使いたい時に再利用するものです。 (idle コネクションのプールを以後 free pool と呼びます。) ほとんどのコネクションプールの実装には、 idle なコネクションの最大数を制限するオプションがあります。 また、利用中の (active) コネクションと idle なコネクションを合計した全体を制限するオプションを持つものもあります。 例えば net/http パッケージの Transport は MaxIdleConnsPerHost
さて、今年も JPerl Advent Calendar の季節がやってきましたね。こんにちわこんにちわ zigorou です。 今回は拙作 Test::Fixture::DBI でデータベースのテストをするお話をしますよ！ このモジュールはモバゲーオープンプラットフォームの API 開発時に必要にかられて作り、今では DeNA の社内でも普通に使われて来ているモジュールです。 レポジトリは github です。 はじめに とりあえずはテスト用の table を用意しましょう。 USE test; DROP TABLE IF EXISTS location; CREATE TABLE location ( id int(10) unsigned not null, user_id int(10) unsigned not null, title varchar(255) not null
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
LevelDBはSQLをサポートせず、クライアント／サーバ型でもなく、シングルプロセスからアクセスされることを想定したいわゆるNoSQLの高速なキーバリュー型データストアを実現するためのライトウェイトなライブラリだと説明されています。 ChromeブラウザでHTML5の仕様として策定中のIndexedDBを実装するものとして開発されたようです（ドキュメントに明記されていないのですが）。 LevelDBを開発した理由 LevelDBのWebサイトによると、LevelDBは以下の主な機能を備えています。 基本的な操作は、Put(key,value), Get(key), Delete(key) 1つのトランザクションとして複数の変更操作が可能 データは自動的に圧縮し保存される Hacker Newsの記事によると、当初はLevelDBを開発する代わりに平林幹雄氏が開発したTokyo Cabin
ひとまず慣れるまでに使っていこうと思っている部分に付いてのメモです。 テーブル作成 普通のSQL Schema設定 ２つのファイルを作成。 下記のファイルでスキーマの設定を行なっていきます。 トリガーの設定やinflate/deflateの設定を行なっています。 上記では、insertに対してトリガーを設定しているのですが、「bulk_insert」を呼び出している時に、このトリガーが呼び出されないようです。 更新系 便利なメソッドが用意されています。 参照系 DBICなメソッドは上記のもの以外にも色々あるのですが、その他はSQLで書いていこうと考えています。 参考リンク DBIx::Skinny - JPerl Advent Calendar 2009
「Web API のすすめ」は割と概念的な話に終始していて、コードベースのもっとゴリっとした話を期待していた人には申し訳ありませんでした。 が、やはり既存の WAF を使っているだけだとわからないことっていうのが多いと思うので、もっと下のレイヤーに降りて、自分で実装するのもありなんじゃないのかなって思っています。 「let's database testing」では、割と見落とされがちなんじゃないかという、DB のテスト方法についてざっくばらんに話しました。ちょっと本質的でないことも書いてありますが、重要なのは、「実際に運用される環境に*なるべく*近い環境で、ローカルでテストをする」ってことです。DB テストのほんの足がかりになれば幸いです。 BD テストの話で使ったサンプルのリポジトリは以下になっています。 xaicron's Mayoi at master - GitHub 結構中途半
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。本日はそれを無停止、オンラインのままでできないかという話題です。 基本的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう
scale outの技術 首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は以下の記事の元原稿です。 首藤一幸, "スケールアウトの技術", クラウドの技術, pp.88-101, (株)アスキー・メディアワークス, ISBN978-4-04-868064-6, 2009年 11月 6日 アスキー・メディアワークス社の 書籍紹介ページ Amazon.co.jp の ページ 首藤一幸, "スケールアウトの技術", UNIX magazine 2009年 4月号, pp.78-91, (株)アスキー・メディアワークス, 2009年 3月 18日 データベースに求められる性能を試算したところ、 十台、百台…数万台のサーバが必要になった。 クラウドを構築する側はこういう問題に直面し、解決しようとしてきた。 台数に比例した性能を引き出すこと、つまりsca
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やその上位層で頑張りすぎるより、モデリングの仕方そのものを工夫して実装や保守のしや
私は家ではMongoDBを使用しています。では、何故RDBMS（種類は何でもいいですが）でないかと言いますと、家の外へ一歩でも出れば、やれORMがどうのこうの、スキーマがどうのこうの、SQLがどうのこうの、と日夜囲まれているのに、そんなもん家に入れたくないでしょう？ MongoDBはインタラクティブシェルとしてjavascriptシェルを持っているので、JSONでデータを格納出来ますし、今ややっとPerlドライバであるMnogoDB（元々は、ご存知Florian Ragwitz氏が手掛けられ、今のメンテナはKristina Chodorow女史です）が安定して来ましたので、Devel::REPLを使用すれば、Perlのハッシュのままインタラクティブに格納出来ます。私の個人的な記録はすべてMongoDBに放り込んでいます。卓上メモ代わりのようなもんです。 これを言うと必ず「じゃ、CouchD
BPStudy#25 : ATNDのメモ。 色々まちがって解釈してるところがあるかも知れませんが、間違いを発見したらDISらずに優しく指摘してください ＞＜ サイボウズ・ラボ 奥一穂さん Kazuho@Cybozu Labs Happy Optimization 正しい最適化 プロファイラを使うとか以前の話として 「30%速くなったよ」ではダメ 投入するコストを回収できるかどうか 処理速度には必ず上限がある 「理論上の最速値の70%まで到達」のようなものがgood ではどうやって上限を予測するか 一般的にはIPC(プロセス間通信)のコストがボトルネックになる サーバを単純化してもメリットは小さい とは言えC10Kだとアルゴリズム重要 速度の壁を突破する方法を考える SIMD、圧縮、グループコミット、Lock-free algorithmなど Scaling? 「スケール」とは ムーアの法則
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く