jildin workers

SFA、CRM製品を開発するエンジニアのブログ

Cassandraでサービスを運用していく中で困ったこと/苦労していること

こんにちは。苦労で禿げそうです。

どうも、Jildinのハゲタカです。

f:id:jildin:20170319225556p:plain

先日Cassandraについて記事を書きました。

jildin.hatenablog.com

今日はその先のお話。実際にCassandraを使ってサービスを運用していく中で困ったことや苦労していることについて書きたいと思います。

Transactionという概念

CassandraにはOracleのようにtransactionという概念がありません。

なのでここからここまでの処理が全部終わったらデータベースに処理を反映してね、っていうことができないのです。いままでOracleがよろしくやってくれていたことができなくなってしまいます。

それでですね。なんでこのtransaction管理がないのが致命的にまずいのかちょっと事例を紹介したいと思います。

Transactionで困った話

Jildinは主にSFAの機能を備えた業務アプリです。なので当然、夜間バッチが裏で動いたりしています。この時、バッチの処理と人間の処理が同時に入ると、Oracleと違いtransactionでの管理ができないため不整合データができやすいです。

またバッチに限らず、大量の人間が同時に同じ画面を編集する時も、しっかりと実装側で制御をいれてあげないと簡単に不整合データができてしまいます。

特に夜間バッチでの大量データ処理はBtoBのアプリでは無視することができない課題です。不整合データができないように実装するだけでなく、うまく負荷を分散させて高速で終わらせる工夫なども必要になってくるのが、transaction管理で困ったところでした。

ISSUEを追い続けるのが一苦労

ご存知Cassandraはオープンソースです。なので突然の仕様変更なんてざらにあります。今まで我々が重宝していた機能が消えてしまうなんてこともざらにあるのです。

だからこそ、少しでも早く今後の動向をキャッチするためにもISSUEは欠かさず読むようにしています。

僕の日々の通勤時間の9割はJildinで使っているオープンソースのISSUEのチェックに消えています。ちなみに残りの1割はLINEの確認とその日に聞く音楽の選定です。笑

まとめ

これは特にOracleを使ってきたBtoB super Oracleマンに気をつけて欲しいです。

あなたがしっかりと知識をもってコードを書かなければCassandraはよろしくやってくれません。Oracleの時のように毛の生えた程度の知識で適当に設計してしまうと、いざデータが大量になった時に取り返しのつかない死に方をします。

そしてオープンソースは日々ものすごい速度で進化を続けます。Oracleさんのように公式に問い合わせできたり、差分資料を毎回しっかりと出してくれたりするわけではないのです。

しっかりと自分から興味を持って、変化についていかないと追いていかれ対応が後手後手になってしまいます。

是非アンテナを高くして、しっかりと設計にもコードにもこだわりと責任をもってCassandraと触れあいましょう。

corp.jildin.com

血涙流しながらCassandraと格闘してつくられたSFAアプリケーションがJildinです。

visit our corporation page
http://corp.jildin.com