作ろうとしている業務システムの要件を整理していた。
・ビジネスマン向けニュースが毎日数万件追加される
・ユーザーは好きなニュースを閲覧できる
・もちろんカテゴリによる絞り込みやキーワード検索にも対応
・ある程度古い記事も読めるようにしないといけない
・会員制ではあるが非会員でもニュースは閲覧できる（一部機能制限あり）
…などなど
そんな中、非機能要件を考えているときにふと思った。
「これはRDBで開発していいのか？」
最近ではDynamoDBやneo4jなどRDB以外のそれぞれのソリューションに特化した様々データベースがリリースされている。
そんな中、思考停止して無条件にRDBを採用するのはいかがなものか。
というわけでRDBとNoSQLデータベースについて整理したうえでどちらを採用する方がいいのかを考察してみた。
RDBとは
Relational Databaseの略称。
関係テーブルと呼ばれるカラム(列)×レコード(行)で構成された表で下図のようにデータが管理される。
代表的なものとしてMicrosoft SQL Server Oracle, PosgreSQLが挙げられる。
| id | name | password | |
|---|---|---|---|
| 0001 | Hiroro | hiroro@example.com | hrr0001 |
| 0003 | Harara | harara@example.com | hrr0003 |
| 0012 | Kiroro | kiroro@example.com | krr0012 |
長所
データ構造が明確に定義されている時は強い
トランザクション処理ができる
検索が柔軟にできる
短所
スケールアウトができるようにはなっていない、スケールアップでは限界がくる
半構造データは不向き、スキーマ定義して格納するか検索や更新の利便性を犠牲にしてJSON形式で格納するしかない
NoSQLとは
Not only SQLの略。No SQL(SQL不要)の意味ではない。最近はクエリが発行できるものも増えてきましたが。
RDB以外のデータベースを指し、Key-Valueストア(KVS)やドキュメントDB(DocDB)、グラフDBと様々なデータモデルがある。
ここでは導入可能性の高いDocDBについて考える。
DocDBは以下のように階層構造データをJSONフォーマットで格納することができるデータベース。
MongoDBやFirebase、Amazon DocumentDBがある。
{
"id": 0001,
"name": "Hiroro",
"email": "hiroro@example.com",
"password": "hrr0001"
},
{
"id": 0003,
"name": "Harara",
"email": "harara@example.com",
"password": "hrr0003"
},
{
"id": 0012,
"name": "Kiroro",
"email": "kiroro@example.com",
"password": "krr0012"
}
長所
スケールアウトでき、これによりビッグデータを分散して高速に処理ができる
スキーマが定義されていなくても格納できる
短所
検索が弱い
整合性が保証されない
標準化されていない、技術者が少ない
判断のポイント
DB選定にあたり今回の要件で注目すべきポイントを踏まえて考えてみる。
1. スキーマの変更可能性
スキーマ定義をすることは可能で、破壊的変更が加わることはおそらくないと思われる。
なのでスキーマ課題についてはRDBを採用しても特に問題はない。
2. スケールアウトの必要性
スケールアウトする必要があるかどうかは保持するデータ量とユーザーからのアクセス量について考慮する必要がある。
まずデータ量だが、毎日50000記事アップロードされるとして、3年間だと
50000 × 365 × 3 = 54,750,000 記事で、1記事当たり平均1kBだとすれば必要な容量は大体54.75GB。
…思ったより少ない。
ここはデータの保存期間が3年なのか10年なのかで変わってくるし、1記事当たりの容量の変化でも変わってくる。それでも10倍の誤差があったとしても547.5GBである。
もちろんデータベースにはほかの情報も格納されているが、そのほとんどは記事データで占められると考えられるので記事データ量がこの程度であれば1サーバーに収まるだろう。画像や動画を管理することになると対策を考えないといけないかもしれないが。
次にユーザーからのアクセス量についてだが、ユーザーが増える可能性があるものの業務システムなのである程度予測可能。
世界展開することになれば話は変わってくるかもしれないが、そうでもなければスケールアップで裁くことは可能だと思われる。
以上よりスケールアウトしやすいDocDBのほうが安心だが、RDBを採用しても大丈夫そう。
3. 複数のand/or条件およびキーワードでの検索
DocDBは複雑な条件での検索ができない。RDBでならある程度可能となるが、キーワード検索となるとRDBの機能だけでは検索時間がかかりすぎる。
検索機能においてはRDBのほうがましだが、いずれも十分ではなく、SolrやElasticSearchといった全文検索エンジンを採用する必要がある。
4. トランザクション機能の必要性
ニュースサイトなのでユーザーを閲覧することがほとんど。プロフィール変更程度はあるもののトランザクションは必要としないため、ここはRDBでなくてもよい。
**ただし決済システムが導入されるとなると別問題。**決済は成功したが、決済中にサーバーエラーが発生して決済は行われたものの変更が適用されていないと大問題となるのでトランザクション機能が必須となる。
結論
今回においてはRDBを採用したほうが良いとみられる。むしろDocDBを採用するメリットが少ないことが分かった。
個人的にはスケールアウトの可能性について懸念していたが、試算すると大きな課題にはならなさそう。
そういえば、記事データはDocDB、それ以外はRDBといった具合にデータベースを使い分けるのはありなのだろうか？
MySQL8.0からはDocument Store機能がついて、RDBなのにDocDBとしても使うことができるとか。
調べてみる価値はありそうだ。