リレーショナルとの違いを理解する
Q：実際に、HUEをCassandraベースで構築する上での苦労はありましたか?
堤：苦労の話を始めたら、1日中でも続くかもしれません。強いて挙げるなら、データ構造の問題でしょうか。リレーショナルからNoSQLになり、最初に躓くのはこのデータ構造です。私自身は、5年間Cassandraを扱ってデータ構造の違いには慣れています。しかし、長年リレーショナル・データベースをやってきた人は、データ構造を作る段階で悩むことになります。
たとえばCassandraでは、ソート済みのデータをあらかじめ作っておきますが、その際にそれがどう画面に表示されるかを想定しておく必要があります。リレーショナルのようにデータを正規化して入れておき、ソートして取り出すときに何とかするのとは考え方が異なるのです。
このあらかじめどう表示するかを想定しておくのは、慣れていないとかなり難しい。これについては、私が直接相談に乗ったり、レビューすることで浸透させていっています。また社内では、歴データをどう持つかなど、CassandraでのERPのデザインパターンとなるものを作成し、徹底的に解説しています。仕様として固まるものは、API化することでノウハウを蓄積しています。
たとえばOracleのオプティマイザーは頭が良いので、開発者がデータのカーディナリティ（データの偏り）などを考慮する必要はありません。そういうことに慣れた人が、Joinもない、カーディナリティも考えなければならないとなるとなかなかうまく行かない。データベースは得意じゃないけれど使っていた、という人は、苦労します。しかし、もともとデータベースが得意だった人は、比較的早く使いこなせるようになります。そういう人には、Cassandraをリレーショナル・データベースから機能を落としたものとして説明すると理解が早いようです。
もう1つ苦労するのは、Cassandraに限らずオープンソースのNoSQLデータベースの多くは、エンタープライズ向け機能がないことです。エンタープライズとは企業向けシステムの機能です。オープンソースのNoSQLデータベースは、シンプルな機能を幅広く世界に向け公開する用途向きです。そのため、多種多様なテーブルやマルチテナンシー、スマートなデータセンター間レプリケーションなどの機能を持っていないものも多いのです。
たとえば、COMPANYでは1つのプロダクトで6,000テーブル、ものによっては1万を超えるものもあります。NoSQLでは多数のテーブルを扱うとパフォーマンスに影響が出ることが多いです。そのあたりをどう解消すればいいのか。また、データセンター間のレプリケーションでも、すべてを複数データセンターにコピーする機能はあっても、データ単位で、さらにコピーするデータセンターも状況に応じ選択的に行うなどはできません。これらも自分たちで作ることになります。このように足りないので作った機能は、社内でライブラリ化しています。
Q：トランザクション処理はどうでしょう。ロールバックやコミットがどうしても必要なシーンはありますよね?
堤：ロールバック、コミットについては、がんばって自分たちで実装しています。これについては苦労してはいますが、分散処理を行うシステムでトランザクション処理をどう実現すればいいのかの情報はすでにたくさんあります。それらを参考に自分たちの処理に必要なレベルに合わせ、トランザクション処理を実装しています。
トランザクションと言ってもアイソレーションが必要なのか、それがシリアライズレベルなのか。処理によってすべてのレベルが必要ではありません。どこまで必要かを判断し、どの方法で実現するかを選びます。このどれを選ぶかの判断は、難しいところです。処理によっては、エラーが発生したらあとからリトライすればいいものもあります。どう区別するかは、業務知識も必要になるところです。
Q：Cassandraを実際に利用し評価できる点、評価できない点は?
堤：評価できるところは、信頼性が高いことです。すでに社内システムでCassandraが動いていますが、ノード単位でも過去1年に1度も落ちていません。そういったところは、パフォーマンスと信頼性が両立している良いNoSQLだと思います。
Lightweight TransactionsやCounter、Load Balanceなど、CassandraにはNoSQLデータベースに欲しい機能はだいたい揃っています。これは当たり前のように思えますが重要です。実際他のNoSQLデータベースでは、基礎的な機能が欠けているものもありますから。
それと、Sparkとの相性がいいのも便利な点です。Cassandraのバーチャルノード機能も、Sparkからきちんと扱えるのは便利なところです。
あとは、先ほども触れましたがマスターノードが必要なく、スモールスタートできるところも評価できます。ローリングアップデートで、無停止バージョンアップができるところは、さりげなくすごい。外向けサービスを提供する際には、なるべく停止時間をなくしたいので、これは重要なのです。
悪い点は、これは昔からずっとですが、メモリの問題があります。これはJavaで構築している宿命かもしれませんが。Cassandraのトラブルは、だいたいがメモリから始まる印象があります。処理が遅くなるのも、多くはJavaのガベージコレクションです。とはいえ、最近のバージョンではJavaの進化もありこのあたりもだいぶ改善しています。
これも先ほど触れましたが、テーブルが大量にあるときにどうすればいいかという問題もあります。しかし、これはそもそもNoSQLのデータベースにそんなにたくさんのテーブルを作るなという話でもあります。しかし、もう少し多くの情報を扱えるようになってくれたらとは思うところです。
Q：今後のCassandraはどのように進化して欲しいですか?
堤：エンタープライズ固有の難しさに対する対応がまだ遅れている印象です。我々自身がCassandraに要求を出したりパッチを送ったりして良くしていきたいと思っています。それ以外の部分は、概ね期待通りの進化をしていると思います。
進化ではありませんが、日本でCassandraを本格的に使うユーザーがもっと増えて欲しいです。そうすればCassandraの情報も増えてくるはずです。Oracleなどの商用データベースに比べ、圧倒的に情報が少ないのが現状です。
