MySQLとMongoDBの違いの比較説明用

1. 比べてみよう
リレーショナル vs ドキュメント
今使っている、MySQL と これから使いたいMongoDBを参考に機能の違いを比較してみよう

2. それぞれの特徴
https://business.ntt-east.co.jp/content/cloudsolution/column-338.html
リレーショナルDB(MySQL) ドキュメントDB(MongoDB)
データ構
造
テーブルという表計算ソフトのような構造
正規化という手法を用いて適度に重複が発生し
ない構造(テーブル)を事前に定義する
正規化は1-3段階まであり厳密な設計思想が存在
する
JSON形式
スキーマレスなので事前に全ての定義をする必要はない
緩やかな設計思想で、JSONのモデリングを行う
主キーは自動採番で後からインデックスの設定もできる
遅いけどコレクション結合もできる
処理速度 インデックスの効率に依存する
細かいメモリチューニングができる
HDDに書き込むオーバーヘッドがある
インデックスはRDB同様に利用できる
インメモリで動くためオーバーヘッドが少なく高速
データの集計などの単純計算はRDBよりも高速にできる
特性 ☆ACID特性という原則を守る事ができる ※
とても厳格なので金融や基幹システムなどに向いて
いる
☆Base特性という原則を守る事ができる ※
ゲームのセーブデータや粒度の細かい操作ログ記録などに向い
ている
分散性 NDBクラスタという特殊なテーブルを使う以外
には基本的にレプリケーションを利用した読み
込み分散のみ
シャーディングとい機能を利用して書き込み分散ができる

3. MySQL(レプリケーション) MongoDB(シャーディング) ※レプリカセットの話は省略
分散化アーキテクチャ
https://thinkit.co.jp/article/1057/1?page=0%2C2
master
slave slave
バイナリログ
スレーブがマスターのリレーログを読みに行って自分のデータベースに
情報を書き込む
master ⇐> slave間の整合性を保持するための禁忌事項がいくつかある
日付を指定した削除更新クエリを発行してはいけないなど
読み取りのみ
書き込み
データの流れ
mongos
shard shard 書き込み
振り分け
shardingしているどのノードにも書き込みができる
mongsはキーを元にルーティングをしているだけ
1つのシャードがダウンした場合にデータを転送して別のシャードで復元
できる
chunkA ChunkB
垂直分散 水平分散

4. SQL構文の比較
https://statichosting-yiymv.mongodbstitch.com/createtable.html
MySQL MongoDB
1. スキーマ定義
create table customers (
id number(10) not null primary key,
name varchar(40) not null,
tell varchar(40) not null,
)
2. データの投入
insert into customers(id, name, tell) values(null, ‘test’, ‘080-0000-
0000);’
3. カラムを増やす
alter table customers add address column varchar(255);
4. データの投入
insert into customers(id, name, tell) values(null, ‘test’, ‘080-0000-
0000);’
1. コレクション定義
db.createCollection( "customers")
2. データを入れる
db.customers.insert([{name: ‘test’, tell: ‘080-0000-0000’}])
3. カラムを増やしてデータを入れる
db.customers.insert([{name: ‘test’, tell: ‘080-0000-
0000’,address:’Tokyo’}])
※1 初回のテーブル定義が省略されている
※2 テーブル変更のクエリが省略されている

5. spacely_webの業務プロセスに当てはめると・・・
MySQL MongoDB
1. スキーマ定義
1.1. ERDを書いて設計をする
1.2. spacely_webのrailsにマイグレーションファイルを作成
1.3. spacely_webのrailsにモデルを作成
1.3. PRを作成
1.4. レビュー
1.5. stagingリリース&テスト
1.6. masterリリース&テスト
2. データの投入
2.1. 投入用にAPIのバリデーションや設定などを行う
2.2. PRを作成
2.3. レビュー
2.4. stagingリリース&テスト
2.5. masterリリース&テスト
3. カラムを増やす
1.1. spacely_webのrailsにマイグレーションファイルを作成
1.2. PRを作成
1.3. レビュー
1.4. stagingリリース&テスト
1.5. masterリリース&テスト
4. データの投入
4.1. 投入用にAPIのバリデーションや設定などを行う
4.2. PRを作成
4.3. レビュー
4.4. stagingリリース&テスト
4.5. masterリリース&テスト
1. スキーマ定義
1.1. ERDを書いて設計をする (※ERDは不要だが設計は必要)
1.2. spacely_webのrailsにマイグレーションファイルを作成
1.3. spacely_webのrailsにモデルを作成
1.3. PRを作成
1.4. レビュー
1.5. stagingリリース&テスト
1.6. masterリリース&テスト
2. データの投入
2.1. 投入用にAPIのバリデーションや設定などを行う
2.2. PRを作成
2.3. レビュー
2.4. stagingリリース&テスト
2.5. masterリリース&テスト
3. カラムを増やす
1.1. spacely_webのrailsにマイグレーションファイルを作成
1.2. PRを作成
1.3. レビュー
1.4. stagingリリース&テスト
1.5. masterリリース&テスト
4. データの投入
4.1. 投入用にAPIのバリデーションや設定などを行う
4.2. PRを作成
4.3. レビュー
4.4. stagingリリース&テスト
4.5. masterリリース&テスト
https://product.st.inc/entry/2021/07/15/131459
不要
jsonフィールドの利用とプロセス的にはそこまで変らないが
トランザクションやDBで付与されるmongoIdの利用や
validatorの利用ができる
P4のSQLにもどって実際の業務と比較しましょう

6. 利用例
https://business.ntt-east.co.jp/content/cloudsolution/column-338.html
MySQL MongoDB
□ECサイトなどの商品管理
重複なく設計されたマスタ系のデータテーブルを保管し
て参照する
□銀行システム
厳格なトランザクションの下で、入金、出金、振り込み
などの操作を行わなければならない
□大量のログ保管
ヒートマップデータやアプリ操作ログなどの保管や統計
的集計
□ゲームのセーブデータ
特定個人のプレイデータで厳密排他制御の必要性がない

7. Railsを利用しないアーキテクチャ例(MongoDB)
https://www.mongodb.com/databases/what-are-microservices
マイクロサービスで情報の蓄積 閲覧にはクライアントツールを使う
☆視聴ログなどの蓄積にマイクロサービスを利用する
AWS
https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-mongodb-
atlas/serverless.html
Awsを利用したマイクロサービスのアーキテクチャ
Atlas
https://www.mongodb.com/databases/what-are-microservices
MongoDBの提供するマネージドサービス
☆蓄積されたデータの閲覧ツールを実装せずに閲覧する
■ Studio
https://studio3t.com/?utm_source=Guru99&utm_medium=listing&utm_campaign=leadg
en
MySQLだとnavicatというツールがあるがそれと同じもので
クエリさえ分かればデータが引き出せるというもの
■ HumongouS.io
https://www.humongous.io/
上記のWeb版
※1 とりあえずデータを取り出せればいいという状態までは
比較的早めにたどり着く方法が用意されている

8. 積極的に活用していきたい新機能

9. ジオコーディング
htps://business.ntt-east.co.jp/content/cloudsolution/column-338.html
MySQL MongoDB
MySQLにも空間データを扱う型が存在します
RDBの場合には、先の説明の通りマスタデータなどを保存するこ
とが多いので、緯度経度から近隣の物件を検索するなどの用途が
考えられます
https://dev.mysql.com/doc/refman/8.0/ja/spatial-type-overview.html
https://qiita.com/mitani/items/6909406ac4fe0db2d35c
MongoDBでは、複雑なGeometry(点、直線、多角形)をlon/latで扱
うものと
2Dの座標空間を扱えます(点、四角、多角形、円、Sphere)
球面空間でのクエリもサポートしているが、、、
何に使えるかな？spacelyのコンテンツで考えてみたけど、ちょっ
と思い浮かばず・・・一緒に考えましょう！
https://www.mongodb.com/docs/manual/geospatial-queries/
https://qiita.com/fetaro/items/7f110f18c6dd9ccd0c90
https://gihyo.jp/dev/serial/01/mongodb/0009

10. グラフ表現
htps://business.ntt-east.co.jp/content/cloudsolution/column-338.html
MySQL(MariaDB community edition) MongoDB
https://openquery.com/oqgraph-engine-for-mysql-mariadb-and-drizzle/
OSS版のMariaDBだとデータベースエンジンレベルでの用意があるが
AWSではサポートしていないさそう
https://docs.aws.amazon.com/dms/latest/sql-server-to-aurora-mysql-migration-
playbook/chap-sql-server-aurora-mysql.tsql.graph.html
https://www.mongodb.com/databases/mongodb-graph-database
ノード(頂点)、エッジ(リレーション)、プロパティ、ラベルを基本としてグラフ型のオ
ブジェクトとその検索をサポートしている
graphLookupという、agrreegation piplineの機能(プラグインみたいなの)を使
うだけで簡単に利用できる
ドールハウスのの活用例でいれば、ドアの接続情報や
ドールハウス自体の頂点座標の保存ができる
ノード
(Vertex)
ノード
(Vertex)
ノード
(Vertex)
エッジ
(Relation) ドア ドア
ドア
(x,x,z)
(x,x,z)
(x,x,z)
頂点
(x,x,z)
(x,x,z)
(x,x,z)
頂点
頂点
エッジ
(Relation)