はじめに
ブンブンHello World.
どうも開発です。
最近はNoSQLというものがだいぶメジャーになってきましたね。
プロダクト開発統括部でも過去にAzure Cosmos DBを用いたPoCを行ったことがあり、その可能性にはとても驚かされました。
そのCosmos DBは最近ではオンラインセミナーなども開催されており、かなりホットな内容であると感じています。
そこで今回は、PoCの経験も踏まえてCosmos DBについて語っていきたいと思います！
今回は、「NoSQLとは？」「Cosmos DBとは？」といったことに焦点を当てて解説したいと思います。
Cosmos DBとは
Cosmos DBとは、Azureで提供されているNoSQLサービスです。
まずはMicrosoft公式の説明を見てみましょう。
Azure Cosmos DB は、最新のアプリ開発に対応するフル マネージドの NoSQL データベースです。 数ミリ秒 (1 桁台) の応答時間と、自動および即時のスケーラビリティにより、あらゆるスケールで速度が保証されます。 SLA に基づいた可用性とエンタープライズグレードのセキュリティにより、ビジネス継続性が保証されます。 世界中のあらゆる場所でのターンキー マルチマスター データ分散と、人気のある言語用のオープン ソース API シリーズと SDK により、アプリの開発をより速く、より生産的に行うことができるようになります。
つまるところ、
- 速い
- アプリケーション開発への組み込み容易性
- 高可用性
が売りのマネージドサービスであることがわかります。
何となく速くて便利そうなDBであることはわかりました。
では「NoSQLなデータベース」とは何でしょうか。
まずは「NoSQL」という部分から掘り下げてみましょう！
RDBとNoSQL DB
そもそもNoSQLとは何だろうか？
その謎をあきらかにすべく我々はインターネットの奥地へと向かった…。
RDB
そもそもNoSQLは「Not only SQL」の略で、「SQL以外のDBもありだよね」というムーブメントが事の起こりとされています。 NoSQLという文脈で用いられるSQLは、一般的にRDB(Relational Database)を表し、SQLを用いて問い合わせを行い表形式のデータ群から特定のデータを取得します。
上記の操作を行うためのRDBMS(Relational Database Management System)は、有償であればSQL ServerやOracle Database、オープンソースのものであればMySQLやPostgreSQLなどがあり、皆様も耳にしたことや利用したことがあるかと思います。 これらのDBはACID特性を持ち、トランザクション処理ができることが大きな特徴です。
ACID特性
ACID特性とは原子性（Atomicity）、一貫性（Consistency）、独立性（Isolation）、永続性（Durability）の4つの特性を指し示します。
| 性質 | 詳細 |
|---|---|
| Atomicity | トランザクション内のタスクがすべて実行されるor全く実行されない |
| Consistency | トランザクションの前後でDBに矛盾が発生しないこと |
| Isolation | トランザクション中の操作がトランザクション外のタスクから隠ぺいされること |
| Durability | トランザクション処理結果が永続的であること |
多くのRDBMSは上記４つの特性を有するように設計されています。
まとめ：RDBはACID特性に基づいたトランザクション処理を実現している。
NoSQL
近年ではデータが大容量化していることや、クラウド化の推進によって従来のRDBでは高いパフォーマンスを維持できない事例があります。 そのため、「複数サーバに分散」した「大量データ」を効率よく処理するためにNoSQLが流行っています。
究極的にざっくり言ってしまうとNoSQLは、「RDB以外のDB」くらいの認識になります。
では、RDB以外のDBはどのような特性、仕組みを有しているのでしょうか？ もう少し掘り下げてみましょう。
CAP定理
NoSQLを語る際に、よく「CAP定理」といった定理が語られます。 これは、一貫性（Consistency）、可用性（Availability）、ネットワーク分断耐性（Partition Tolerance）を表しており、すべてを満たすことは出来ず、どれか１つは必ずあきらめなければいけないという定理です。
| 性質 | 詳細 |
|---|---|
| Consistency | 誰かがデータを更新したら、その後は必ず更新後のデータが参照できること |
| Availability | クライアントは必ずデータにアクセス可能であること（データが壊れたり、ロック待ちにならないこと） |
| Partition Tolerance | データを複数サーバに分散して保管できること（データが複数のサーバに分散されており、1つサーバに障害が発生し、データが破損した場合でも、別サーバによりデータが参照可能であること） |
特にクラウドで提供されているNoSQLはネットワーク分断耐性は必須、また高い可用性を維持することがサービスとしての価値が高くなりやすいことから、一貫性の多くと一部の可用性を犠牲にしていることが多いかと思います。
ちなみにRDBは一貫性と可用性(CA)に重点をおいていることが多いです。 NoSQLはCPかAPに重点をおいているため、RDBとNoSQLはそもそも完全に代替できるものではないことを念頭においておく必要があります。
上記のようなクラウドサービス向きのトランザクション特性モデルをBASE特性といいます。
BASE特性
BASE特性は、以下の表のような特徴を持つトランザクション特性モデルを指し示します。
| 性質 | 詳細 |
|---|---|
| Basically Available | 複数サーバにスケールすることで可用性が高く、特定のサーバが死んでも別のサーバでサービスを提供可能である |
| Soft-State | あるデータは外部から送られてくる情報によって状態が変化する |
| Eventually Consistent | 最初に要求を受けたサーバが、処理結果を他のサーバに伝えて最終的に結果が同期する。同期までの間は各サーバの一貫性が保たれない。 |
上記の表を見ても分かるとおり、BASE特性は一貫性についてあまり考慮しないようなモデルとなっており、可用性とネットワーク分断耐性（AP）重視です。 そのため、スケールアウトが容易で高い可用性を実現するDBがクラウド環境で提供可能です。
まとめ：NoSQLはCAP定理に基づいたBASE特性によってスケールが容易である。
Cosmos DBの特徴
大変長らくお待たせいたしました。 ここからがCosmos DBの特徴になります。
これまでのNoSQLについての解説で、NoSQLとはどういったものかがなんとなく理解できたかと思われます。 上記に示したようにCosmos DBはBASE特性を有するDBです。
RDBではデータを正規化し、行と列のテーブルに格納することで保存します。 データを取り出す際には複数のテーブルから必要な情報を取り出し、それぞれを結合することで一塊のデータとして取得します。
一方のCosmos DBではデータをキーバリューの状態やドキュメント、グラフとして構造化し格納/取得することができます。 これらの機能はCosmos DBのSQL API、Cassandra API、MongoDB API、Gremlin API等から選択することで実現することができます。
また、.NET、Java、Node.js、Python等メジャーな言語で提供されているSDKを利用することで、Cosmos DBを利用したアプリを構築することができます。 こちらについてはSQL APIであれば上記のすべて、それ以外は言語ごとに対応状況が異なるので、利用したいAPIに合わせて言語を選択する必要があるかと思います。
以下にCosmos DBの得意なこと、苦手なことを列挙してみましょう。
Good
- JSONドキュメントとして保存可能
- いつでもドキュメントのプロパティを追加可能
- 様々なAPIを使って構成、クエリを構築可能
- とにかく速い
- 可用性が高く障害に強い
Not Good
- 処理内容を考えないと性能が出ない場合がある
- APIによっては提供されていないサービスがある
- RDBのような厳密な一貫性を維持することは難しい
従来のリレーショナルなDBと比べてDBの拡張性や取り回し易さといった部分が強みになるかと思います。 逆に厳密な一貫性やサービスの拡充度合いといった部分はRDBに比べ苦手な部分かと思います。
また、処理内容を考えないと性能が出ない場合がある点についてはRDB・NoSQLどちらも有している問題ですが、Cosmos DBに関しては「パーティションと課金体系（RU）」が固有の問題であると言えます。
パーティションとRU
詳細は次回に説明する予定ですが、Cosmos DBには「論理パーティション」と「物理パーティション」、そして「RU」という概念があります。
論理パーティションは、関連するデータすべてに対して付与する共通の属性で、データの分割の境界線となります。 同じパーティションキーを持つものはそれらでひとまとまりのデータとして管理され、基本的に分断されることはありません。 つまるところ、データのグルーピングの基準になる属性です。
物理パーティションは、論理パーティションによってまとめられたデータを保存するための境界になります。 その名のとおり物理的なデータの保存先についてであり、基本的にユーザーが制御することはありません。 論理パーティションとデータ量に応じてCosmos DBが自動で制御します。
そして、Cosmos DBに対してクエリを流したりする際の処理量を表したものがRUとなります。 こちらはクエリの複雑さやデータ構造、データ量で値が変化し、RUに応じて課金額が決定されます。
パーティションとRUは密接な関係にあり、データをどのようにまとめるか、どのように分散させるか、どのようなクエリを構成するのが処理効率が良いか…といったことを考慮する必要があります。
Cosmos DBの性能を十分に引き出すためには各物理パーティションに対して均等に処理を割り当てる必要があり、各物理パーティションに属するデータ集合は論理パーティションによって決定されます。論理パーティションの選択によって物理パーティションに対する処理が均等になったり、特定の物理パーティションに偏ったりしてしまうので注意が必要です。
これらの概念についてはCosmos DB特有のものであり、RDBとは違った観点で処理内容を吟味する必要があります。
メリデメを踏まえたうえで最適な利用をしたいですね。
実際のCosmos DBの使い方については、次回以降の記事で解説したいと思います！
お楽しみに！
おわりに
結構根っこから掘り返してしまったため、思った以上の長文になってしまいました。
半分くらいCosmos DBにたどり着くまでの前提の説明になってしまったことを反省…
上記でも散々書きましたが、Cosmos DBはスケーラビリティと可用性が高くかなり期待値の高いものです。
実際にソリューションに利用する際は整合性の面がネックになることがあり、結果RDBに落ち着くといった事も多いかもしれません。
ここに関してはソリューションの構成の仕方や、サービスとしての在り方の問題かもしれませんね。
例えば商品一覧だけCosmos DBを用いたアーキテクチャで構築し、支払い系など厳密な一貫性が求められる処理についてはRDBを用いたアーキテクチャでサービスを構成すると、それぞれの利点を生かしたソリューションが実現できるかもしれません。
参考文献
https://www.nri.com/jp/knowledge/glossary/lst/alphabet/nosql https://www.atmarkit.co.jp/ait/articles/1703/01/news204_2.html
～ecbeingでは、NoSQLについて興味、知見があるエンジニアを大募集中です！～
careers.ecbeing.tech
