書籍紹介 本連載は下記書籍から第5章を基に、@IT向けに再構成して掲載しています。 目次 序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基本概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 本連載は書籍『NOSQLの基礎知識』(リックテレコム刊、ISBN:978-4897978871)で解説されている内容から一部を抜粋し、本連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基本概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基本概念から、各プロダクトの特徴を理解できる内容になっていま
クラウド時代の新しいデータベースとして、非リレーショナルな構造を持つNoSQLデータベースが話題になっています(NoSQL=Not Only SQL。命名の経緯はこちら)。そのNoSQLの中で、もっとも注目されているデータベースの1つがApacheのCassandraです。 Cassandraは、Facebookで大規模データ処理のために開発され、その後オープンソースとなり、現在ではApache Software Foundationのプロジェクトとして開発されています。 現在、CassandraはFacebookやDiggなどで使われている、もしくは使うことが検討されているとされ、Twitterでも(ツイートデータの格納には使われないようですが、それ以外の用途で)利用されています。 TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由 Twitterが、Cassandr
まとめ 超長くなったのでまとめを上に持ってきた。 巷で言われているチューニングは結構嘘が多い事が解ってきた。 ツール等 workingSet Analyzer は信用ならない。(overSecondsはまあ良い) mongoperfの値は完全に参考にならない。 insert mongoperfの値はinsert性能と関連しない。(何を測ってるんだ?) カラムのプリアロケーションによるUPDATE時のデータ肥大化回避($setOnInsert)はMUST。 クリティカルな時間帯にストレージファイル(2GB)の生成を避けるチューニングの効果は懐疑的。 レコードプリアロケーション・チューニングは頑張る価値が無い。(むしろ逆効果) update 上記の通り必ずin-placeになるようにする。 paddingFactorが動くようだとお話にならない性能劣化 remove かなり高速。 全件削除の場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く