NoSQLのCassandraを使うときの注意点

こんにちは。Jildinのハゲタカです。

ハゲタカといいつつ髪の毛はもさもさです。

f:id:jildin:20170319225556p:plain

皆さんはCassandraはご存知ですか？

今流行りのNoSQLの一種です。慣れてしまうと使い勝手もよく、割とイケている子なのですがいかんせんロゴがキモいのが玉に瑕(たまにきず)です。

今日はそんなCassandraについて記事を書きたいと思います。

RDBに慣れ親しんだ開発者の多くがこの仕様に殺されるところを見て来ました。それはそれは酷い死に方でした…。

そうなんです。CassandraにはReadとWriteの概念しかないのです。つまりどういうことかというと「INSERT」「UPDATE」「DELETE」がぜ〜んぶ同じなんです。

すでに存在しているキーに対してUPDATEをかけるだけでなく、存在しないキーにUPDATEをかけることだってできちゃうんです。ちなみにDELETEはただの論理削除なので、こいつも結局データをWriteしているだけなんですよね。

ここ罠です。

ここもRDBマンの墓場になりやすいところです。そうなんです。Cassandraにはrollback機能なんてものはないのです。

つまり、大量データを順次INSERTしていくバッチ処理の途中で処理がコケたら、そこまでのデータが保存されてしまうということです。

なのでCassandraには不整合データが生まれやすいのです。ここで潔癖症のくせに不整合データの処理は全てDB任せだったRDBマン達は次々に息絶えて行くことになります。

※RDBと違いCassandraはデータ取得時(Readのタイミング)でデータの整合性を保とうとします(KeyでValをつるので)

RDBに慣れ親しんだ方々は、往々にしてDBの設計をしてから順次ビューを作り込んで行く開発スタイルの方が多かったのではないかと思います。

しかしCassandraでは逆です。まずビューを作ってからDBを作るべきなんです。理由は簡単。DBにテストデータを入れることができないからですね！っていうか開発途中にCassandraに不整合データが入ろうものであればそのデータを消すのに一苦労です。

データを削除しても論理削除なんでどんどんCassandraは太って行くんですよ。太った目ん玉なんて嫌でしょう。僕は嫌です。

なので、Viewから作って行くとCassandraでは失敗のリスクが激減するので、CassandraマンはViewからつくりましょう。

※論理削除されたデータはCompactionという処理が走るまで物理削除されません。Compactionは再起動した際に走るわけではないのでデータを消すのが面倒なのですが、それはまた別の記事でまとめます。

JildinはmariadbとCassandraのハイブリッドで動いています。両者の特性を理解して、適材適所の配置をすることで、今までになかった爆速でのデータ処理が可能になるのがNoSQLとRDBのハイブリッドの魅力です。

まだまだ日本国内にNoSQLのノウハウをもった開発者が少ないこともあり、RDBほどスムーズに開発や保守をするのは難しいですが、ちょっと頑張って英語と戦うだけであなたのアプリは大量データを相手にも夢の処理速度を実現できますよ！

jildin workers