都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo

都内でサラリーマンやってます。SQL Server を中心とした (2023年からは Azure も。) マイクロソフト系(たまに、OSS系などマイクロソフト以外の技術も...)の技術的なことについて書いています。日々の仕事の中で、気になったことを技術要素関係なく気まぐれに選んでいるので記事内容は開発言語、インフラ等ばらばらです。なお、当ブログで発信、発言は私個人のものであり、所属する組織、企業、団体等とは何のかかわりもございません。ブログの内容もきちんと検証して使用してください。英語の勉強のため、英語の

db tech showcase 2014 Tokyo の Riak セッションに参加することができたので、Riak について書いてみる

 過去の記事でも Riak について取り上げていましたが、Riak の素人ながらも、概要レベルは触れてありますね。Microsoft Azure ( 当時は、Windows Azure ) 上で検証もしていました。

分散型 NOSQL データベースである Riak ( なんて読むんでしょうか? りあっく? らいあっく? りあーく? ) を試してみる - 都内で働くSEの技術的なひとりごと
 その後、あまり真面目に Riak には取り組んでいませんでしたが、今回 db tech showcase 2014 Tokyo にて、2つの Riak 関連のセッションがありましたので、両方とも参加させていただきました。
 今回は、少し気になった Amazon の Dynamo について少し触れたいと思います。DynamoはAmazonの一部分のサービスのために開発されました。ただ、リレーショナルデータベースを完全否定しているものではなく、可用性が必要で且つアクセスが KV でアクセスする要件である個所に使用されるものです。
 Amazon の Dynamoの最終目的は、下記の 3 つです。

  • 高い拡張性
  • 高い可用性
  • 低い運用負荷

 CAP の定理は、下記の 3 つから構成されています。(※Wiki から引用)

  • 一貫性 (Consistency)
    全てのノードにおいて同時に同じデータが見えなければならない。
  • 可用性 (Availability)
    ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。
  • 分断耐性 (Partition-tolerance)
    システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース(ネットワーク分断)を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計は可用性が成立しない。

 Dynamo は、上記の3つから、一貫性 (Consistency)を諦め、拡張性(Scalability) を足したものとなります。Riak はこの考え方をベースにして設計・開発されています。コンセプトを一言でいうと、100%書き込み可能でスケーラブルな分散型NoSQLですね。すばらし....
 あと、そのほかに Riak 2.0 で大幅に機能向上されたものとして、Riak Search 2.0 があります。Riak Search 2.0 は、Riak + Apache Solr といったところです。Apache Solr は、日本国内でも導入率の非常に高い全文検索システムです。これに、Riak の持つ非常に高い拡張性を元に、容易にスケールアウトすることが可能な全文検索システムが構築可能です。

非常に勉強になりました。Riak Search 2.0 は採用したいですね。
※セッション資料っていつ頃公開されるんだろう。早く復習したいです。
※Riak についての書籍は少ないです。

Riak Handbook (English Edition)

Riak Handbook (English Edition)