知ってて損はないはず！いろいろなNoSQL達
・KeyValue型 ・カラム型 ・ドキュメント指向型 ※上記に記述したNoSQLの種類ごとにミドルウェアがあります（後記） NoSQLはRDBMSとは違うデータベース技術ですので、RDBMSが得意ではない箇所を補うためにNoSQLを利用するという使い方が多いです。RDBMSの苦手なところというのは大量のデータと高速に読み書きをすることです。NoSQLは大量のデータの読み書きが得意とされています。 その他にもNoSQLの特徴はいろいろあるのですが、いくつかあげるとすれば以下になります。 上記で説明させていただいた内容ですと、RDBMSとセットで使用するように思えますが、Webシステムの性質によってはNoSQLだけを利用した方がパフォーマンス的にも向上するといった場合もあり、RDBMSを利用せずにNoSQLだけを利用するというもよくあります。 それでは、NoSQLの概要もわかったいただいたと
Cassandra
本書は、NoSQLミドルウェアの代表格であるCassandraについて包括的に解説する書籍です。Cassandraの概要、インストール、データモデル、データの読み込みと書き込みなどの基礎から、モニタリングやメンテナンス、パフォーマンスチューニングなど、実践的な事柄までをサンプルコードを多用して詳しく解説します。さらに、Hadoopとの連携や、Cassandra以外の非リレーショナルデータベースについてもカバーしています。日本語版では、正式リリースされた1.0の基盤であるバージョン0.8を中心に新機能についても収録。Cassandraに関心のある開発者、運用管理者に必携の一冊です。 目次 序文 はじめに 1章 Cassandraとは 1.1 リレーショナルデータベースの何が問題なのか？ 1.2 リレーショナルデータベースの簡単な復習 1.2.1 RDBMS：よい点、よくない点 1.2.2 W
「NoSQLデータベースファーストガイド」を執筆しました - (ﾟ∀ﾟ)o彡 sasata299's blog
2011年04月28日19:00 NoSQL 執筆 「NoSQLデータベースファーストガイド」を執筆しました 最近あまりブログを書けていなかったわけですが、実は初めて本の執筆をしていました。こちらです！でで〜ん！！(＊ﾟ∀ﾟ)っ NoSQLデータベースファーストガイド NoSQLデータベースについて書かれた 国内初 の入門書です！（多分） 最近では NoSQL というキーワードがバズワードになりつつあり、「いったい NoSQL って何だろう？」とか「リレーショナルデータベースとどう違うの？」と疑問に思われている方も多いのではないかと思います。が、勉強しようにも最初の一歩を踏み出すのってなかなか大変ですよね。何かいっぱい種類があるし。そこで、本書をきっかけとしていただけたら、、＞＜ NoSQLデータベースは細かいチューニングを行い「リレーショナルデータベースでは扱えないような大規模な処理を扱
開発メモ: オンメモリDB＋スナップショットで爆速永続キャッシュ
Kyoto Tycoonに自動スナップショット機能が実装され、オンメモリDBでも永続化できるによになり、高速性と永続性を両立できるようになったよという話 自動スナップショットとは 「永続化したキャッシュサーバ」としてのコンセプトを掲げるKyoto Tycoonだが、それはメモリ上でなくファイル上でデータベースを表現するからである。今回の自動スナップショットによる永続化は、それとは異なる。オンメモリDBの中にあるレコードを定期的にファイルに書き出すことで永続化するのだ。 ファイルDBの場合、データベース内のレコードは常にファイルに書かれている。よって、サーバプロセスを再起動してもレコードは消えない。その代償として、ファイル上で更新された領域をディスクに書き込むためのIO処理にかかるオーバーヘッドが無視できない。ファイルシステムのページキャッシュによって緩和されるとはいえ、IO処理がランダムア
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
HandlerSocket plugin for MySQL
1. handlersocket plugin for mysql 2010/06/29 Tech セミナー @ 代々木 株式会社 DeNA システム統括本部 IT 基盤部 樋口 証 <higuchi dot akira at dena dot jp> 2. Who am I? DeNA IT 基盤部 システムのパフォーマンス最適化 障害の分析 ミドルウェア開発 IPA 未踏 スーパークリエータ (2005 年 ) 1993 年ころから GNU/Linux 利用 Fedora: yum install KoboDeluxe Debian: apt-get install kobodeluxe サーバソフトウェアを多数開発
HandlerSocketソースコード公開しました | BLOG - DeNA Engineering
はじめまして、樋口と申します。 先日のDeNA Technology Seminar #2でお話させていただきました HandlerSocket Plugin for MySQL のソースコードを公開しました。 HandlerSocketとは？ 簡単に言うと、MySQLデータベースへのアクセスを高速化するためのプラグインです。MySQLのSQLパーザをすっ飛ばし、ネットワーク通信とマルチスレッド処理周辺を置き換えることによって、InnoDB等のデータベースエンジンの性能を限界まで引き出します。 このHandlerSocketですが、すでにモバゲータウンにて実際に運用しています。従来MySQLとmemcachedの構成で運用していた箇所を、HanderSocketを組み込んだMySQLだけの構成に置き換えました。その結果、MySQLサーバの負荷軽減、memcachedの負荷軽減、ネットワーク
Cassandraemon
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
逆襲のLua - mixi engineer blog
こんにちは。開発部最後の良心、mikioです。今回はLua処理系の並列化とそこでのKyoto Cabinetの利用法についてご紹介します。 サーバサイドスクリプティングといえばLua Kyoto CabinetのLuaバインディングは後回しにしてKyoto Tyrant的なサーバの設計を進めていたのですが、やはりそのサーバにもスクリプティング機能を持たせたくなりました。つまり、サーバがデフォルトで提供する機能群だけでなく、ユーザがスクリプト言語で記述した任意の機能を追加して利用できるようにするということです。 Tokyo TyrantではLua拡張と呼ばれる機能を用いてそれを実現しています。サーバの起動時にLuaのスクリプトを記述したファイルを読み込ませて、そこで定義した関数をリモートから呼び出せるようにしています。そこで実行されるLuaの処理系にはTTが管理するデータベースを操作するため
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
第1回 RDBMSとNoSQLデータベース | gihyo.jp
はじめに NoSQL（Not Only SQL）という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで、不得意なところにはRDBMSにこだわらず、用途に合ったデータストアを使いましょう』という考え方です。最近では、いわゆるNoSQLデータベース （key-valueストアや各種データベース） が次々と登場してきています。 そこで今回から数回に渡り、それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。 RDBMSの強みとは そもそも、MySQLやPostgreSQLなどのRDBMSの弱みを補うため、様々なNoSQLデータベースが登場してきたわけですが、RDBMSにはたくさんの強みがあることも忘れてはいけません。 RDBMSの強み データの一貫性 （トランザクション） 更新時のコストが少ない（JOINが前提でテーブルが正規化されている）
kumofs-0.4.0リリース - CAS操作をサポート - Blog by Sadayuki Furuhashi
新たにCAS（Compare-And-Swap）をサポートした、kumofs-0.4.0をリリースしました。 memcachedのテキストプロトコルで、getsコマンドとcasコマンドを新たに使うことができます。 後方互換性は保たれています*1。新機能を利用するには、kumo-gatewayとkumo-serverを更新してください。 CASとは？ CAS（Wikipedia）は Compare-And-Swap の略で、ある値を取得したあと、その値が別のプロセスから更新されていなければ（Compare）変更を適用する（Swap）という操作を、アトミックに実行することができます。 CASを利用することで、kumofs上にキューやカウンタ、連想配列、ロックなどを実装することが可能になります。 例えば kumofs でキューを実現する擬似コードは、次のようになります： KEY = "myque
The Kumofs Project - Blog by Sadayuki Furuhashi
分散key-valueストア Kumofs のWebサイトをオープンしました！ The Kumofs Project Webサイトには、LinkedIn で開発された分散Key-valueストアである Voldemort との速度比較を掲載しています。 kumofsはVoldemortと比べて、倍以上の読み込み性能を、半分以下のCPU使用率で達成できます。 kumofsは並列イベント駆動I/Oを基盤とした、マルチコアCPUに特化したスケーラブルな実装です。 ノード間の通信には、MessagePack のゼロ･コピー化されたデシリアライザを活用しています。 MessagePackのストリームデシリアライザは（kumo-gatewayのmemcachedプロトコルのパーサも）、ちょっと賢いバッファリング戦略を実装しています。 コマンドを受け取るたびに新しいバッファを確保するのではなく、複数のコ
高密度小池 ／ KVS を使って Web アプリケーションを作ることについて
KVS を使って Web アプリケーションを作ることについて KVS を使って Web アプリケーションについて、一般論。 従来 KVS は、キャッシュや特に更新が激しいデータを保存することに主に用いられて、メインのストレージには RDBMS を使うことが多かったけど、 KVS をメインのストレージとするアプローチも最近いくつかある。 KVS にデータを保存するという場合、 Value にシリアライズしたデータをぶちこむというケースが多いのではなかろうか。そうすると、標準状態では、キーでしか検索出来ないので、インデックスを転置するということになる。 インデックスの転置先としては、 Facebook や SimpleResource でやっているように、 RDBMS に転置するというやり方や、 Cassandra 採用前の Twitter のように KVS に転置するというやり方があ
KVSをWebサーバーとするとどうなるのか？ベンチマークを取ってみた。 - クリティカルスピード開発日誌
一昨日公開した拙作のクリティカルスピードですが、ベンチマークを公開していなかった為、 どの程度使えるのかよくわからないというご意見を頂きました。 クリティカルスピードについてはMOONGIFT様の紹介をご覧下さい KVSを使った高速配信Webサーバ「クリティカルスピード」 そこで古いサーバーでベンチマークを取ったので結果のみご紹介いたします。 Celeron 430 1.80GHz メモリ2Gのサーバーで実験 WRITE性能 ファイルベースの場合（普通のウェブサーバー） 静的に1万ディレクトリ5万ページを作成する time perl make_static_benchmark_htmls.pl 27.81s user 6.59s system 93% cpu 36.935 total クリティカルスピードの場合（KVSをウェブサーバーとして使う） 1万ディレクトリ5万ページを作成する ti
memcachedプロトコルについて
※ memcachedプロトコルの仕様書は以下にあります。 http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt データの保存を行うコマンド(set,add,replace,append,prepend)は、以下のような文法となります。 <コマンド> <key> <flags> <exptime> <bytes> <data> <key>は保存するためのキー名を指定します。実装によっても異なりますが、最大長は250byteです。 <flags>はアプリケーション特有の32bitの値(0〜4294967295)を指定することができ、データの取得時に格納した時の値が返されます。 <exptime>はデータの有効期間を秒数で指定します。指定した時間経過すると、自動的にキーが削除されます。0を指定すると自動削除され
kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RethinkDB: the open-source database for the realtime web
Sensei DB