サーバレスでApache Cassandraを提供する「Amazon Keyspaces for Apache Cassandra」正式リリース。事実上無制限スケール、使った分だけ課金
サーバレスでApache Cassandraを提供する「Amazon Keyspaces for Apache Cassandra」正式リリース。事実上無制限スケール、使った分だけ課金 Amazon Web Servicesは、代表的なNoSQLデータベースの1つであるApache Cassandraをマネージドサービスとして提供する「Amazon Keyspaces for Apache Cassandra」を正式版としてリリースしたと発表しました。 New #AWSLaunches! Amazon Keyspaces (for Apache Cassandra) is now generally available AWS IQ waives fees until June 30, 2020 Amazon Aurora with PostgreSQL Compatibility for
本番環境でcassandraの運用を開始してみた - joker1007’s diary
職場でcassandraの運用を開始したので、選定理由とか運用してみて得た知見や所感等を書いてみようと思う。 (まだ十分に知見を得たとは良い難いので、間違った印象を得ていたり、より良いオペレーションに気付いていない可能性があります。) cassandraの採用理由 そもそもの目的はホットデータの書き込み先としての利用です。要件としては以下の様なものがあります。 エンドユーザー端末の数に比例するので、書き込みのスケーラビリティが必要 書き込みデータは更新される 一件単位、もしくは数秒単位の短かいサイクルでバッファチャンクを書き込む必要がある prestoで読み込める (最悪connectorは書いてもいいが、できれば避けたい) 一度に数百万件ぐらいまで読み込む可能性があるので、それなりに読み込みもスケールして欲しいし、レンジスキャンにもある程度効率が求められる。 元々、データ加工で潰しが効く
Cassandraのストレージエンジンを入れ替えて高速化した「Rocksandra」、Instagramがオープンソースで公開。Javaのガベージコレクションによる遅延を大幅に解消
Cassandraのストレージエンジンを入れ替えて高速化した「Rocksandra」、Instagramがオープンソースで公開。Javaのガベージコレクションによる遅延を大幅に解消 Instagramは、NoSQLデータベースのCassandraで発生していたJavaのガベージコレクションに起因する遅延を解消し、高速化した改良版Cassandraをオープンソースで公開したと発表しました。 ストレージエンジンとしてキーバリューストアの「RocksDB」を用いたことから、同社はこの改良版Cassandraを「Rocksandra」と呼んでいます。 JavaのガベージコレクションがCassandraの遅延を発生させている 同社がRocksandraの開発に至った経緯は、エンジニアブログ「Open-sourcing a 10x reduction in Apache Cassandra tail
Cassandra 3.0 Materialized Views Technical Deep Dive – DOAN DuyHai's blog
In this blog post, we’ll dig into the brand new materialized view feature of Cassandra 3.0. We’ll see how it is implemented internally, how you should use it to get the most of its performance and which caveats to avoid. For the remaining of this post Cassandra == Apache Cassandra™ Why materialized views ? Being an evangelist for Apache Cassandra for more than a year, I’ve spent my time talking ab
最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita
最近では珍しくもなくなった"Quorum"という言葉。Zookeeper, etcd, Serfといったクラスタ中でデータのレプリケーションを行ってくれるようなツールや、Cassandra, Riakといった分散データベース(NoSQL系)のようなツールにおいても、データの複製に一貫性を持たせる仕組みとしてよく聞かれます。 しかしながら、多くのスライドやWebの記事を読んでも、"Quorum"という語が意味するところは要するに「過半数ノードによる多数決」というような説明が多いように感じていました。 にも関わらず、"Quorum"と呼ばれているのはなぜか？そんな疑問を持っていたので、この機会に調べてみました。 そうしたら、"Quorum"は過半数/多数決という概念を一般化した非常に抽象でパワフルな概念だということがわかりましたのでここにまとめておきたいと思います。 分散システムにおけるデータ
持続的なプラットフォームのための難しい決断
先日フォーラムでお知らせいたしましたが、今まで提供してきたツイートボタンとフォローボタンのデザインを一新すると同時に、今後はツイートボタンにツイート数を表示しなくなります。変更は2015年11月20日までに完了する予定です。Twitterでは、開発上のトレードオフが生じることが度々あります。今回の変更もそのような事情によるもので、ここではその背景を説明いたします。 Twitterの目標の一つは、皆様のウェブサイト、アプリケーション、ビジネスにとって、信頼のおけるプラットフォームを作ることです。また、このプラットフォームがTwitterエンジニアリングチームに確実にサポートされていることも重要です。その結果、APIを廃止することによって生じる問題を抑えるために、永続的なデザインを選択することにしました。多くの皆様と同様にTwitterの開発リソースにも限りがあり、どのプロダクトやパブリックA
『fluentd + Elasticsearch + kibanaでCassandraモニタリング』
はじめまして。インフラ＆コアテク本部の鳥垣と申します。普段はAmeba Smart Phone PlatformやAmebaの基幹系サービス全般のインフラを見る仕事をしております。 昨今fluentd + Elasticsearch + kibanaを使ったリアルタイムモニタリングが流行っていますが、これを使ってCassandraのステータスをモニタリングするシステムを作ってみましたので、そのお話をさせていただければと思います。 構築のきっかけこちらのサイトにてdstatのモニタリングをkibanaでやっている記事を拝見し、Cassandraのステータスも同じようにリアルタイムグラフの描画ができないかと考えました。 以前にWebSocketで監視もリアルタイムにという記事でもあるとおりリアルタイムモニタの仕組みはありましたが、kibanaの検証も兼ねてリアルタイムのグラフ描画にチャレンジし
Cassandra Data Modeling Best Practices, Part 1
This is the first in a series of posts on Cassandra data modeling, implementation, operations, and related practices that guide our Cassandra utilization at eBay. Some of these best practices we’ve learned from public forums, many are new to us, and a few still are arguable and could benefit from further experience. September 2014 Update: Readers should note that this article describes data modeli
Riak vs. Cassandra - A Brief Comparison
January 11, 2017 Riak vs. Cassandra blog update January 27, 2014 On the official Riak docs, we compare Riak to multiple other databases. We are currently working on updating these comparisons, but, in the meantime, we wanted to provide a more up-to-date comparison for one of the more common questions we’re asked: How does Riak compare to Cassandra? Cassandra looks the most like Riak out of any oth
Cassandraをバックエンドにして掲示板を作る | Ore no homepage
iPhone5sを買った。やっぱ動きが軽快でいいね。auを長らく使ってるんだけど、2年前に買ったAndroidが動きが遅いわ電池はすぐ減るわでクソだったんだよね。やっと買い替えることができて感無量。いい買い物したよ。 さて、久々のCassandra。同僚が新卒向けの課題として「Cassandraを構築してそれをバックエンドにして掲示板アプリケーションを作れ」という面白課題を出していたのでおれもやってみた。ただのソース晒し。 0. ソース Simple BBS https://github.com/hiroakis/simple-bbs-cassandra 1. メモ 機能仕様 スレッドは更新日時が新しい順にソート スレッド数上限は101 スレッド数上限を超えると更新日時がもっとも古いスレッドから削除 スレッドへの投稿数の上限は1001 スレッドへの投稿数の上限を超えた投稿は、エラーにはせず
HBase論争に釣られてみる - 科学と非科学の迷宮
HBaseコミッター達による、NoSQLの記事への反論が面白かったので翻訳してみました。 著者の許諾取得済み。Thanks Stack and the other authors! 本文 原題: Taking the Bait Information Weekは先日、「HBase はNoSQL を支配するのか?」という記事を掲載した。MapR の Michael Hausenblas は HBase の事例に「賛成」の論陣を張っており、Apache Cassandra の Jonathan Ellis とベンダーである DataStax は「反対」の側だった。 この「ディベート」をベンダーのセールストークとして却下し、Apache HBase に立ち戻り、HBase を使用し、改善していくのは、簡単な話である。しかし、この記事は特別に問題のある例だった。記事では、「賛成」と「反対」の双方と
Cassandra nodetool repairの挙動について教えて貰ったのでまとめ - oranie's blog
題名そのまま。repairの挙動をdatastaxのドキュメント読んでも良く分からない、ヽ(｀Д´#)ﾉ ﾑｷｰ!!となっている所をまたも@yukimさんに教えて貰いました。 なので忘れないようにメモです。 nodetool repairとは nodetool --helpで出力されている使い方は以下の通り repair [keyspace] [cfnames] - Repair one or more column family (use -pr to repair only the first range returned by the partitioner) 直訳すると一つ以上のcolumn familyを修復します。-prオプションを付けて実行するとパーティショナーの初めのレンジだけrepairを実行しますこの直訳だけではなんのこっちゃですね。 repairを実行する目的 rep
RE:cassandraを運用していて困っていること
re.md @oranie さんのブログ記事への返信です。 たいへん遅くなりました。申し訳ないです。 repairとcompactionのコストが高すぎる Cassandraにノードを追加する(Bootstrap)と、そのノードが担当するレプリカのデータを他のノードから取得します。 Repairはノードが保持するレプリカの整合性を検証して修復します。 どちらもデータを他のノードから取得しますが、ファイルを1つづつやり取りするため時間がかかるのは事実です。 この部分にまだまだ改善の余地があります。次のメジャーバージョンで抜本的に見直します。 ファイルのストリーミングはデフォルトで400Mbit/secに制限されています。帯域に余裕があれば設定(cassandra.yaml の stream_throughput_outbound_megabits_per_sec)を変更しても良いかもしれませ
cassandraを運用していて困っていること - oranie's blog
※2013/03/05に追記 Yuki Morishita(@yukim)さんより以下のエントリについてアンサーを貰いました！！！ https://gist.github.com/yukim/5086476 - なんか呟いたら「m9(^Д^)ﾌﾟｷﾞｬｰ」な意味なのかRTとかがついたので、まとめておこう。きっと「これやれば解決するのに・・・プークスクス！」って教えて貰えるに違いない。半分くらい僕の技術力の低さから来ているのが多いので、Cassandra特有の問題から外れている気がするけど気にしない。 前提条件として HW：CPU12core メモリ64GB Disk:SSDやHDD(RAID10)を使用（詳細な構成は割愛） Cassandra 1.1.5 JDK 1.6.0_33-1 Simple Strategyを使用 1ノード辺り100〜200GB程度のデータを想定 クラスタの数とかは
Cassandra運用に活躍したスクリプトたち : toda_k
弊社検証環境で半年ほど10数台規模のCassandraクラスタを運用してきたのですが、運用に使っているスクリプトがある程度固まってきたのでまとめてみます。更なる簡素化・便利化を進めるための棚卸しという感じです。古いものも混ざっていて若干申し訳なくはあるのですが……どなたかの役に立てば幸いです。では見て行きましょう。 スクリプトの運用体制について すべてのスクリプトはSubversionで管理され、主にJenkinsによって自動的に実行されます。多数のノードに対する同時処理を行なうためにGNU Parallelを使うことがあります。 またCassandraサーバはAWS EC2上で運用されているため、AWS SDK for RubyによってIPアドレスの取得などを行なっています。 各ノードでのnodetool ring実行結果を集約 クラスタが不安定なとき、実際は動いているのに一部のノードか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - scylladb/scylladb: NoSQL data store using the seastar framework, compatible with Apache Cassandra
http://patrickmcfadin.com/2014/02/11/mongodb-this-is-not-the-database-you-are-looking-for/
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
これがCassandra
Riak Documentation