第1回 NoSQL、そしてCassandraとは | gihyo.jp
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF（単一故障点）を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach
Androidアプリでのデータベース基礎 ～速習！ Androidアプリケーション開発（4）～
package sample.bizcard.db; import java.io.Serializable; /** * 1レコードのデータを保持するオブジェクト * Intentに詰めてやり取りするのでSerializableをimplementsする */ @SuppressWarnings("serial") public class BizCard implements Serializable{ // テーブル名 public static final String TABLE_NAME = "biz_card"; // カラム名 public static final String COLUMN_ID = "_id"; public static final String COLUMN_PERSON_NAME = "person_name"; public static fi
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
SELECT文の処理の仕組みを説明してみた。 - いろいろ解析日記
SQLのSELECT文は非常に強力です。SQLを使うと複雑な処理も短い命令で行えることがあります。 ですが、複雑な処理を行うSELECT文を書くためには、SELECT文の処理の仕組みをきちんと理解しておく必要があります。 そこで、今回はSELECT文の処理の仕組みを、内部的な処理手順を仮定して説明してみます。*1 なお、今回は一つのテーブルに対する処理のみを説明します。複数テーブルの結合は説明しません。 目次 SELECT文の処理の基本。 SELECT文の処理は二つに分けられる。 テーブルを一行ずつ処理する。 条件に当てはまる行を出力する。 出力項目を編集する 複雑な条件を指定する 出力結果を並べ替える。 テーブル内の複数の行を集約する。 すべての行を集約する。 グループ毎に集約する。 SELECT文の処理の基本。 SELECT文の内部的な処理の基本は、テーブルの各行に対する繰り返し処理で
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
