NoSQL
NoSQL
NoSQLとは
NoSQLとは、主にインターネットを介した不特定多数の大量アクセス、ソーシャルネットワークにつながるデータ群の分析、いわゆるビッグデータ解析や利用などが想定されるサービスに対応すべく既存のRDBMSとは別の仕組みを模索する過程で必ずしもSQLに依存しなくとも処理が可能ではないかというアプローチをとるデータ管理技術の総称です。
これは、RDBMSに取って代わるものではなく、これまでとは異なる視点でデータ分析、データ管理する必要があるケースに対応すべく開発されているもので、特定の1つを指すのではなく、複数の方向性を持ったプロジェクトとその研究・開発及び製品の総称であり、RDBMSとは、必要とされる背景も前提も異なるものであるがためにRDBMSを基準として見てしまうと他の多くを捨ててしまったかのような齟齬が生まれ本質からずれてしまいます。
しばしば、総称の由来は、そのまま"No SQL"、語気が強すぎると云う意見も多数あり、"Not only SQL"とするのが望ましいとされます。
ただ、その用語自体は、SQLインターフェイスを持たない軽量な関係データベースのオープンソースソフトウェアの名前として最初に用いられた1998年当時は前者、近年の意味合いでは後者の意味であるとするのが妥当である気がします。
・RDBMSは、主に企業内(WAN/)LANにおけるC/Sシステムのようにある程度トラフィックを想定できる前提で作られており、不特定多数の大量アクセスは考慮されていない。
↓
・RDBMSの性能向上策を検討してみよう
↓
・RDBMSは、スケールアップ(当該サーバ自体の性能アップ)には向くが、スケールアウト(サーバ台数増設による性能アップ)には不向き
↓
・サーバ資源の重複がデメリットだけどサーバ増設すれば性能アップできるスケールアウトは魅力的
↓
・ただスケールアウトだと既存RDBMSみたいなデータ一貫性保持は無理
↓
・ならRDBMSじゃ無理ってことで、この際、データの一貫性は、ほどほどでいっか
↓
・データ更新時の干渉どうしのぐ？
↓
・記憶装置も安くなったし、データ大きくなるけどDELETE/UPDATEなくしてINSERTだけで処理すればいいんじゃない？
↓
・それがアリならSQL要らない、RDBMSじゃなくてもいいっと。。。それなら。。。
↓
・ハッシュみたいのでもいっか
→KV/Key and Valueタイプ
・初めから入れる箱作らなくてもXMLとかJSONとか型も列数や行数も関係なく自由にいろんなデータ入れられるようにするのもありかな
→ドキュメント指向タイプ
・ソートも相当重要だよね、行をキーにして列にデータ持たせるのもありだね
→カラム指向(ソート済み)タイプ
・データとデータ、ノード間の関係性を重視するのもありだよね
→グラフタイプ
...etc.
NoSQLとRDBMS
RDBMSに代わるデータ管理を模索した当時は、既存のRDBMSに一石を投じたフレーズとして"No SQL"としたようですが、その名称を流用していると言って良さ気な近年に至っては、「大量アクセス考えると実は既存のRDBMSだと対応しにくいよね？RDBMSの大前提気にしなくていいとか、なんならSQL使わなくてもいいよって話なら、なんとかなりそうな気がするんだけどな～」といった語気の弱いものと考えれば近年の意味合いは、当時のそれとは別に、そもそも"Not only SQL"が妥当と言えるでしょう。
つまり、誤解を恐れず簡潔に言えば、「RDBMSの性能向上に限界を感じるケースが一部出てきちゃったんだけど、ブレークスルーって言えるほど革新的なアイデアがあるわけでもない、でもなんか手を打たなきゃ、そんな模索中の一策としてのNoSQL」といったところでしょう。
否定からは何も生まれないので肯定的に考えた時、既存のRDBMSと違って「結合ができない」、「トランザクションがない」、「ソートができない」、「データ反映遅延」、「データの一貫性を維持できない」。。。等々をバッチ含め、アプリケーションで補完する必要があると言われています。
しかし、要求や背景自体が異なる中では、そんな比較自体が不要であって、そもそも「RDBMSとNoSQLは、使用目的が異なり、RDBMSを採用できないケースには、NoSQLの各種タイプからマッチするものを検討、条件が合えば対応してみましょう」と割り切るべきでしょう。
ただ、スケールアウトにおける複数台サーバ管理の手間の増大、それぞれにバックアップサーバが必要になった場合の想定以上のサーバ台数増大、アプリケーションに依存する部分が増えれば増えるほど良くも悪くも多様性が生まれ、いろんな流儀ができてしまう(一貫性がなくなる)ことで「技術の継承」、「システムの保守」、「システム更新時の引き継ぎ」、「プログラムの再利用」などが難しくなるなど、これまでのIT/ICT業界の流れとは、逆行するものになってしまうことは必至ですが、その善後策まで十分に練られているとは思えず、気になるところです。
これは、これまで意識する必要すらなかったRDBMSの洗練された機能をシステム開発者がハッキリと意識した上でアプリケーション対応する必要があり、ましてデータベース設計・開発者が別途存在したようなプロジェクトにおいてもNoSQLの場合、専任チームが設置されない可能性すらあると思われ、開発現場の負担が、その分、大きくなる可能性も十分にあり得ます。
また、従来のシステムにおいても運用後のシステム改修は付きものと言えるほどであり、多様性があるなら尚の事、システム開発会社の担当プロジェクト、または十二分に引き継ぎを受けたチームや担当者が当たるべきですが、実際には、そうではないケースも多いことでしょう。
例えば、運用後のシステム改修はもとより、第2フェーズ含む以降がある場合は当該フェーズ、システム大幅改修による再開発、システム更新などにおいてもシステム開発会社内の人事異動や退職等々、入札や諸事情によるシステム開発会社の変更、システム開発会社の倒産、吸収合併に伴う消滅等々に伴う引き継ぎ不備などは、日常茶飯事とも言え、いたずらなシステム及びアプリケーションの複雑さは極力回避したいところでしょう。
往々にしてこうした事態への対応策と様々なバリエーションが生まれる可能性のあるアプリケーション対応は逆行します。
こうした場合、性能アップのためのチューニングは別として極力機能を集約・隠蔽してシステム開発者が意識すらせずに済むようにする方がベターである中でのRDBMSの洗練された機能集約であると思われ、NoSQLにおいて機能の取捨選択、アプリケーションによる代替策を行わざるを得ないとしても、より慎重に行われるべきものと思われます。
ApacheやMicrosoft、Google始め多くのプロジェクトが進行中で、それぞれ政府機関や研究機関などで実運用、試験運用もされているようですが、今後、集約されていくのか、逆にもっと細分化されていくのか、状況に合わせて併用していくのか、市場性や成長戦略含め未知数な部分もあるからこその(NoSQLという)総称なのでしょうから、その辺りは、今後洗練されていくのでしょう。
