Kyoto Cabinet 1.0登場、C++以外の主要言語に対応 | エンタープライズ | マイコミジャーナル
Kyoto Cabinet: a straightforward implementation of DBM Kyoto Cabinetの初の安定版リリースとなるKyoto Cabinet 1.0が公開された。Kyoto CabinetはC++で開発されたキーバリュー型のデータベース。GPL3のもとで提供されている。高い並列性と移植性があり、利便性が高い。ハッシュデータベース使用時はO(1)、ツリーデータベース使用時はO(log N)の計算時間量を実現。マルチスレッドセーフでレコード単位/ページ単位での読み書きロックが可能。Kyoto Cabinet 1.0における主な特徴は次のとおり。 更新能力100万qps以上 レコードあたりのフットプリントがハッシュデータベースで8-16バイト、ツリーデータベースで2-4バイトと軽量 自動リカバリ機能 自動/手動トランザクション機能 C, Java、
NoSQLの本命となるか？ memcachedの開発者らが新たなオープンソースプロジェクト「membase」を立ち上げ | OSDN Magazine
Webインフラ企業の米NorthScaleは6月23日（米国時間）、オープンソースのNoSQLプロジェクト「membase.org」を立ち上げたことを発表した。プロジェクトのサイトでは、「Membase 1.6」ベータ1のバイナリとソースコードを公開している。 NorthScaleは分散メモリキャッシュシステム「memcached」の主要開発者が立ち上げたベンチャー企業で、memcachedをベースにした「NorthScale Membase Server」や「NorthScale Memcached Server」などの製品を開発・提供している。今回、membaseの早期ユーザーである米Zynga、韓国NHNの2社と共に、オープンソースプロジェクトとしてmembase.orgを立ち上げた。今後は、membase.orgをオープンソースプロジェクトとし、商用版としてMembase Serv
Flareを使う(複数台構成)
各役割のサーバは以下の働きをします。 インデックスサーバ Flareクラスタ内に1台存在し、各ノードの死活監視、各ノードへのサーバリストの通知、各ノードへの指示を行います。インデックスサーバの冗長化は、2010年5月現在のバージョン1.0.9では実装されていません。 ストレージサーバ データを格納します。上記の通りマスター、スレーブの2種類が存在します。 プロキシサーバ memcachedプロトコルをアプリケーションに提供し、リクエストをFlareクラスタへ中継します。 サーバ設定 Step1. インデックスサーバの設定と起動 以下の設定ファイルを/home/admin/flare/flarei.confとして保存します。 data-dir = /home/admin/flare log-facility = local0 server-name = 192.168.13.21 monit
Flareを使う(インストール編)
カテゴリー DX (2) 一般 (59) 研究会 (6) 働き方 (4) 技術 (352) Edge AI (2) Edge Computing (13) Erlang (1) FIWARE (2) Fog Computing (10) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (5) RealTime Web (14) SRE (3) Webサービス (42) インフラ (8) コンテナ (4) ストレージ (93) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (215) 仮想化 (111) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティン
Key Value Storeについて
主な3つの機能について実装状況を示してみました。 「データ永続化」とは、ストレージサーバを再起動してもデータが失われないようにデータをメモリではなくHDD等に格納できる機能です。例えば、memcachedはメモリにデータを置くため、ストレージサーバを再起動するとデータが失われます。 「データ冗長化」とは、格納したデータがストレージサーバ側で自動的に複数のストレージサーバにコピーが作られる機能です。1台(または数台)のストレージサーバがダウンしてもデータが失われることはありません。 「データ分散」とは、キーのハッシュ値等を元にデータの格納先のサーバを振り分ける機能で、負荷分散を図ることができる機能です。なお、memcached、Tokyo Tyrantにはサーバ側での分散機能はありませんが、クライアント側のライブラリによって格納先サーバを分散させることも可能です。 memcachedプロトコ
RDBに代わるスケーラブルなデータモデルの必要性 - sdyuki-devel
このあたりの内容を卒業研究にする予定で、中間報告書まで書いたけど、整理と裏付けが全然追いつかなくて卒論なんて書けそうにないので、とりあえずテキトーにブログに書いておくなど。 データストアには、状態を永続化して共有する機能と、データモデル（状態を操作する意味論）を規定する機能の、２つの機能がある。この２つの機能を、より使いやすく、より高速に、よりスケーラブルに提供することが求められる。そうでないとシステム全体が成り立たない。 冗長化とか負荷分散とか、ハードの質に頼らない高性能なシステムを構築したいときは、「状態を持たないようにする」のが定石になる。同じ状態を２台のホストで同期し続けたり、状態を分割しながら整合性を保ち続けるのは、非常に難しい。このため、状態は共有データストアに保存しておくのがもっとも簡単で、現実的な解になる。 MVCアーキテクチャにおけるViewとControllerはMod
分散KVSの使い方 - sdyuki-devel
今流行のkey-value storageの利点と欠点など。小さいデータをたくさん扱うタイプで、単純なkey-value型のデータモデルを持つ分散KVSについて。 Webアプリをとりまく最近のKVS事情、雑感を読んで、ちゃんと整理して把握しておかないといけないな、と思ったので少し整理。 それは違うぞーという事があったらコメントくださいm(_ _)m ※2009-11-17 追記：現在、KVSという用語の意味は定義されておらず、使う人によって揺れています。ここで言うところの分散KVSは、Dynamo や kumofs や ROMA など を想定しています。 分散KVSの利点 スケールアウトできる 簡単にサーバーを追加して性能を上げられる 単体の性能が高い スキーマレス 最初は少ない台数で安く、後からサーバーを足してスケールアウト！という運用ができる。アプリケーションに影響せずに、ストレージ側
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IIJ社における分散DB技術「ddd」（2）
IIJ社における分散DB技術「ddd」（1）
Google Groups