Facebook: 永続的key-value型高速データストアRocksDBをオープンソースで提供 - ワザノバ | wazanova.jp
http://rocksdb.org/ RocksDBは、FlashSSDメモリ/RAMに高速でアクセスできる組込み型の永続的key-valueデータストアです。LevelDBのうえに構築されていてCPUコアがたくさんあるサーバでスケーラブルに実行され、高速のストレージを効率的に利用し、IO-bound / in-memory / write-once な作業をサポートします。 （GoogleのLevelDBは「Hood.ie: “noBackend & Off-line first” という考え方」でもちょっと話題にでてました。） 利用用途としては遅延を避けたいケース、例えば、 ユーザの閲覧履歴やステータスを保持するアプリ 大きなデータにすぐにアクセスしなくてはいけないスパム検知アプリ リアルタイムでデータにアクセスするソーシャルグラフ検索のクエリ Hadoopデータのキャッシュに利用し
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
きのう娘がボーイフレンドを連れてきたんだが・・・ - ICHIROYAのブログ
きのう、娘のボーイフレンドがやってきた。 僕は結城紬を着て和室で正座して、ふたりを迎えた。 カレと娘は二人並んで正座し、嫁がお茶を運んできて、湯のみに注ごうとしていたとき。 カレが唐突に、敷いていた座布団を横にはねのけ、がばっと両手をつき、「お嬢様と正式にお付き合いさせてください！」と言った。 そして、髭を触りながら、僕は思案する。 この男は、誠実だろうか？ この男は、パチンコや競馬や女装や、そのほかもろもろの僕には言えない趣味はないだろうか？ この男は、そもそも幸せになるチカラがあるのだろうか？ この男は、どれぐらい稼げるのだろうか？ この男は・・・・ 凍りついた雰囲気。 で、嫁が横から口を出す。 「まあまあ、先にお茶でも飲んでくださいな」 娘のボーイフレンドがやってきて、父の僕に挨拶するということは、昨今こういうことではない、ということは、ずっと前からわかっていた。 うちには娘がふたり
京都市での勉強会用の部屋の確保の難しさ
京都市で勉強会に使える部屋を確保するというのは、かなり難しいことが判明した。 今流行りの勉強会には、プロジェクターとマイクと電源とWiFiが必要だ。プロジェクターは資料投影に、マイクは、部屋広い場合に声を届かせるために必要になる。その性質上、多くの参加者はラップトップを使いたいだろうから、電源も必要になる。WiFiでインターネット接続が提供されていればさらによい。また、参加料を低く押さえるために、利用料が安くなければならない。 そういう場所は、意外と少ない。部屋自体はあるのだが、その他の点で、ほとんどの施設が候補から外れる。 公的な施設で、会議室を格安か無料で貸し出しているところもあるが、そういうところは、営利目的での利用を禁止している。実際にそのような施設に出向いて聞いてみたところ、施設の利用料を賄うために参加者から必要な額の参加料を徴収するのはかまわないが、企業の宣伝や求人といったもの
RDBMSのコネクションプーリングとかその辺の話 - wyukawa's diary
データベース技術の羅針盤 from Yoshinori Matsunobu これは素晴らしい資料で後半のキャリアの話とか面白いんだけど、今回書くのはp6,p8に書かれていた下記の話です。 PosgreSQLは接続がプロセスベースなのでLL言語との相性がよくない Pgpool(これはプロキシサーバー的に使うらしい)などのコネクションプールと併用することが多い MySQLは接続がスレッドベースなのでコネクションプーリングが使いづらいLL言語環境では魅力 なんでLL言語だとコネクションプーリングが使いづらいのかわからずつぶやいたらリプライもらってついでにちょっと前に話題になったRDBMSでコネクションプールが必要な理由、わからない。 - Togetterや7年前のブログエントリであるコネクションプーリングの話 - naoyaのはてなダイアリーを読み返してみて思ったことを書いてみる。全然まとまって
naoyaのはてなダイアリー - コネクションプーリングの話
かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続本数を節約する。 というもの。 mod_perl で DB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB
HTTP/1.1 の Transfer-Encoding: chunked をビジュアライズするツール書いてみた - blog.nomadscafe.jp
Chunked Transferとは 一般にHTTP KeepAliveを利用するには、レスポンスのボディがどこで終わり、次のレスポンスがどこから始まるかをクライアントが知る必要があります、そのためHTTP/1.0ではKeepAliveを行う為にボディの長さをContent-Lengthをヘッダに入れなければなりませんでしたが、サイズを測るためにデータをすべてメモリに読み込むなどの処理が必要になり、レスポンス開始までの時間もかかります。（一般的なアプリケーションにはあまり影響がありませんが） そこでHTTP/1.1ではChunked Transferという仕組みが入っていて、事前に全体のレスポンスの長さが分からなくても、chunk=固まり毎にサイズを記してレスポンスを返していき、最後に0byteと送信することで、コンテンツの切れ目がわかるようになっています。 HTTP/1.1 200 OK
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
