本番環境でcassandraの運用を開始してみた - joker1007’s diary
職場でcassandraの運用を開始したので、選定理由とか運用してみて得た知見や所感等を書いてみようと思う。 (まだ十分に知見を得たとは良い難いので、間違った印象を得ていたり、より良いオペレーションに気付いていない可能性があります。) cassandraの採用理由 そもそもの目的はホットデータの書き込み先としての利用です。要件としては以下の様なものがあります。 エンドユーザー端末の数に比例するので、書き込みのスケーラビリティが必要 書き込みデータは更新される 一件単位、もしくは数秒単位の短かいサイクルでバッファチャンクを書き込む必要がある prestoで読み込める (最悪connectorは書いてもいいが、できれば避けたい) 一度に数百万件ぐらいまで読み込む可能性があるので、それなりに読み込みもスケールして欲しいし、レンジスキャンにもある程度効率が求められる。 元々、データ加工で潰しが効く
CassandraでOSが不安定になったので調査したらLinuxメモリ管理設定が原因だった - YOMON8.NET
事象 環境 S/W H/W 原因 対策 Direct Reclaimを避ける 設定方法 結果 その他のチューニング項目 対策② HugePage 対策③ THP無効化 結果②・③ 参考にした情報 カーネルソースコード SlideShare WEB Page 書籍 事象 Casssandra起動してから、ある一定期間経つと突然nodetoolがとても遅くなり、ring情報見るだけでも10秒ほどかかる場合も出ていました。CassandraだけでなくOS全体が不安定になり、SSH経由の操作すらも遅くなる事象が発生しました。 Nagiosで監視をしているのですが、nrpe自体や個別のコマンドが遅くなるのでTimeOutのアラートがいくつも飛んできて何度も夜中に起こされました。 CPUやメモリ、Diskもぱっと見た数字上では余裕があり、処理自体も遅くなっていない状態。Cassandraを再起動すると
cassandraの運用時に必要な定期バッチ処理の考察
cassandraを運用する上でどういった 定期バッチ処理が必要かについてまとめる。 しかし、cassandraの前提知識がないと 必要性を理解しにくいため、 下の流れで若干遠回りしながら説明していく。 ◆ 分散システムの予備知識 ◆ 修復機能の予備知識 ◆ 定期的に必要となる処理の概要 ◆ 定期的に必要となる処理の詳細 ◆ 分散システムの予備知識 cassandraのような分散システムではノード間のデータで 同時に次の３つを保証することは難しい。 すべてを満たすためにはレイテンシー(遅延)を許容する必要がある。 CAP定理 Consistency：一貫性 Availability：可用性 Partition Tolerance：分断耐性 cassandraは可用性と分断耐性(AP)を重視し、一貫性を犠牲にしているが、 遅延とのトレードオフで一貫性を得ることができる。 コンシステンシレベル
実用段階に入ったNoSQLをおさらい 「Cassandra」の概要と導入手順・基本設定
ビックデータとは はじめに、Cassandraが得意としているビックデータについて解説します。ビックデータという言葉が一般的に使われていますが、実際のところ何を指すのか、これまでとの違いは何かを説明します。 何に使われているのか 「ビックデータ」とは、通常の処理では処理不可能な膨大な蓄積データを指す言葉です。これまでは、処理することをあきらめていた膨大なデータを処理対象とすることで、新しい答えを見出すことを目指しています。しかも短時間で処理することで、タイムリーな活用を目指すのです。 これまでは、ばらばらに発生していたデータが、通信環境の発達でリアルタイムに収集することが可能になりました。個々のデータは小さくても、大量に集まれば膨大なデータです。せっかく集めた膨大データを活用するために時間が掛っては何もなりません。大量に集めたデータを短時間に効率よく処理して、処理結果を得られる必要がありま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cassandra勉強会
