タグ

NoSQLに関するWhatAmILookingForのブックマーク (10)

  • RDBMSの苦手な処理をカバーする、気の利いたNoSQL「Redis」

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます NoSQL徹底研究の特集、第5回は「Redis」です。第1回でNoSQLを利用する企業が増えていると紹介しましたが、実際にはどのような企業がどのような理由でNoSQLを採用しているのでしょうか? ユースケースを軸に今回のテーマであるRedisを紹介します。 Redisとは Redisは、アクセスが高速なキーバリューモデルを採用するNoSQLです。非常に高速な読み書きとアクセスが可能で揮発型メモリキャッシュの「Memcached」とユースケースが似ており、永続化できるキャッシュとしても、今まで多く採用されています。 RDBMSでは面倒になりがちなケースを解決 多くのNoSQLが、一般的に文字列やJSONなどの構造情報を格納するのに対して、

    RDBMSの苦手な処理をカバーする、気の利いたNoSQL「Redis」
  • Cassandra、MongoDB、Redisなど主要NoSQL比較 | gihyo.jp

    ハンガリーの企業でCTOを務めるKristof Kovacs氏による記事です。各主要NoSQLプロダクトについて機能比較や利用ケースなどをまとめています。この記事ではCassandraやRedisなど6つのプロダクトを挙げています(表1⁠)⁠。 CouchDBは使い勝手に優れており、双方向レプリケーションやリアルタイム更新をサポートしています。Redisは非常に高速なことが売りで、トランザクションや変更監視の機能が備わっています。Cassandraは書き込みが読み込みよりも速いことから銀行や金融などのリアルタイムなデータ解析が必要になる分野で実力を発揮し、Cassandraと同じくJavaで作られているHBaseは億単位の行と数百万のカラムというBig Dataを扱え、月に1,000億を超えるメッセージを処理するFacebookのバックエンドに採用されています。 次々にプロダクトが生まれた

    Cassandra、MongoDB、Redisなど主要NoSQL比較 | gihyo.jp
  • Redisのメモリ使用量がmaxを超えた場合の挙動 - Gaishimo

    Redisのメモリ使用量がmaxを超えた場合の挙動について検証してみた。 環境: version: 2.4.16 Redisではタイムアウト時間を設定したキーは時間を超えると自動で削除され、タイムアウト時間を設定しないと永続的に保存される。 また、メモリの空き領域がなくなった場合、期限のあるものから削除されていく(デフォルトの設定の場合)。 注意すべき点は、期限が設定されていないキーは削除対象にならないということである。 実際にその挙動を検証してみた。 まず、検証しやすいようにメモリの使用可能な量を以下の値に設定しておく(redis.conf) #新たにキーを保存した際にmaxmemoryエラーにならないぎりぎりの値 maxmemory 910KB maxmemory-policy は 以下を設定 #LRUアルゴリズムを使用して期限切れになったセットのキーを削除 maxmemory-pol

    Redisのメモリ使用量がmaxを超えた場合の挙動 - Gaishimo
  • KVS系NoSQLのまとめ(Hibari、Dynamo、Voldemort、Riak編)

    序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 連載は書籍『NOSQLの基礎知識』(リックテレコム刊、ISBN:978-4897978871)で解説されている内容から一部を抜粋し、連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基概念から、各プロダクトの特徴を理解できる内容になっています。 連載では、この書籍の内容から、主要プロダクトを紹介している第5章を抜粋し、そのエッ

    KVS系NoSQLのまとめ(Hibari、Dynamo、Voldemort、Riak編)
  • blog.katsuma.tv

    当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real

  • SQL vs NoSQL、グーグルにおける戦い(前編)。Google I/O 2012

    SQLとNoSQLではどちらが優れているのか? グーグルの担当者がディベート(というより小芝居:-)を行ったセッション「Google I/O 2012 - SQL vs NoSQL: Battle of the Backends - YouTube」が公開されています。 このセッションは、先々週開催されたGoogle I/O 2012で行われたもの。SQLとNoSQLには機能的にどのような違いがあり、どう使い分けるべきなのか、明確な説明が参考になります。 ハイライトを紹介しましょう。 クラウドにおけるデータベースのメリット グーグルAlfred Fuller氏(NoSQL担当)。 クラウドはフォルトトレラントでメンテナンス不要、パッチも私たちが適用しており、利用者は運用について心配する必要がない、といったメリットがある。 データのレプリケーションや地域分散でデータも保全され、インターネッ

    SQL vs NoSQL、グーグルにおける戦い(前編)。Google I/O 2012
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • 2read.jp - このウェブサイトは販売用です! - まとめ ランキング 読書 ログイン 書籍 著者 小説 マンガ リソースおよび情報

    このウェブサイトは販売用です! 2read.jp は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、2read.jpが全てとなります。あなたがお探しの内容が見つかることを願っています!

  • NoSQLデータモデリング技法

    NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文:NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック

    NoSQLデータモデリング技法
  • NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る

    データベースの世界でいま注目されているのがNoSQL。特にキーバリュー型データストアは、グーグルのBigTable、FacebookやTwitterが内部で利用しているCassandraやAmazonクラウドが提供しているSimpleDBなど、すでに実際に使われ始めています。 ではそのNoSQLをリレーショナルデータベースの代わりに使ってシステムを構築するとどうなるのか? 身をもって体験したことを記したShinya Kawanaka氏によるプレゼンテーション「間違った方向にCassandraを使ってみた」が公開されています。 NoSQLを用いたシステム構築は、リレーショナルデータベースによる構築どう違うのか? とても分かりやすくまとめられています。ご人の承諾もいただいたので、その内容を紹介しましょう。 NoSQLを使ったときに起こる恐ろしい事例 プレゼンテーションのテーマは「NoSQL

    NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る
  • 1