「初心者向けにNoSQLを徹底解説」に関する誤りについて
「初心者向けにNoSQLを徹底解説」に関する誤りについて
以下の元記事では，初心者向けにあやまった情報で解説を行っているように見受けられたため，その訂正を目的とした記事である．
NoSQLのメリット
高速
処理を高速に行えるのはNoSQL最大のメリットと言っても過言ではない。トランザクションを必須とせず、データの厳密な一貫性を確保しないことで迅速にデータを処理できる。NoSQLはデータ量が増えてもRDBより処理速度が下がりにくい。
（中略）完全一貫性を必要としない
NoSQLでは、処理の結果が最終的に一貫性のある状態となれば可とする「BASE基準」を採用している。NoSQLは完全な一貫性を含む「ACID特性」を満たす必要はないので、高速処理の実現に大きく貢献している。逆を言えば、NoSQLはデータの一貫性が必要なシステムには不適である。
データの厳密な一貫性 や 完全一貫性 というものが具体的にどこまでの一貫性を指しているか不明だが，ここでは結果整合性ではないものと解釈する（BASEのEが結果整合性）
NoSQLのすべてがBASEや結果整合性ではない
以下は，結果整合性ではない構成をとることのできるNoSQLの一覧である
- Bigtable（シングルクラスタ構成）
- Apache HBase
- DynamoDB（ConsistentRead)
- Redis Raft
- TiKV
- Riak KV
- Google Cloud Datasore
- Amazon S3
- Google Cloud Storage
よってこの記述は誤りであり，強整合性が必要なときであっても，NoSQLは選択肢として残る．
本題からそれるが，主要な一貫性モデルについてはkumagiさんが解説しているQiitaがわかりやすい
NoSQLのメリット
高速
処理を高速に行えるのはNoSQL最大のメリットと言っても過言ではない。トランザクションを必須とせず、データの厳密な一貫性を確保しないことで迅速にデータを処理できる。NoSQLはデータ量が増えてもRDBより処理速度が下がりにくい。
それゆえ、ビッグデータなど大量のデータ処理が必要なシステムでも十分に活用できる。格納できるデータの種類が豊富
NoSQLはRDBとは違って以下に挙げるデータも格納できる。
- 画像や音声データ、センサーログなどのような「非構造化データ」
- XMLやJSONなどのような「半構造化データ」
元記事ではRDBではこれらのデータを格納できないかのような表現をしているが，RDBも画像や音声データなどバイナリデータの格納は可能だ．
しかし，クエリ時にメモリを多く消費するため，パフォーマンスの影響が発生したり，データの管理に複雑さが伴うため，適切な技術を選択したい
しかし，技術的な制約によってRDBにバイナリデータを保存できないというわけではないということを留意してほしい．
NoSQLのメリット
（中略）
格納できるデータの種類が豊富
- XMLやJSONなどのような「半構造化データ」
MySQLやPostgreSQL，Amazon Aurora， Google Cloud Spanner においてもJSONデータ型をサポートしており，半構造化データをNoSQLが得意とする領域という記載であっても誤りである．
JSONを保存しなければならないようなデータ構造においても，RDBの採用を見送らなくてはならないわけではない
Discussion