データ活用やDXがどんどん解る用語集　　　
NoSQL

NoSQL（ノーエスキューエル）とは、SQLに象徴されるような従来的なRDB（リレーショナルデータベース）とは異なる考え方で作られたデータベースエンジンのことを言います。
クラウドサービスが世の中に広まりはじめた時期に、かつてない大量のデータ、多種多様なデータ、非常に高速なデータ処理など、従来的なRDBでは実現が困難なデータ処理のニーズが高まっていました。そこで、RDBとは異なる考え方によるデータベースが開発されるようになり、それらがNoSQLデータベースと呼ばれるようになりました。

NoSQLという言葉は、2010年前後に出現して話題になった言葉です。ビッグデータやHadoopなどの言葉が流行したころに、同じく話題になりました。

2006年にクラウドコンピューティングという言葉そのものが生まれ、それまではWebブラウザを経由してITを利用する習慣がなかったところから、急速にクラウドサービスが普及しはじめたのが2010年ごろです。インターネット上に世界中の人が利用するかつてない巨大サービスが出現して運用される時代が到来しました。ちょうど同じころには、スマートフォンも普及をはじめるなど、IT活用がかつてなく急速に広がった時代でした。

そのようなかつてない状況において、「データ」の利活用もかつてない状況が到来していました。従来をはるかに超えるデータ量、はるかに多様なデータ、かつてない高速処理のニーズなど、それまでにないデータ処理のニーズが発生しつつありました。そして、それまで主流であったRDB（いわゆる世間的に「データベース」と呼ばれてきたもの）の性能を引き上げて対応する形では、新しいニーズに対応できなくなりつつありました。

そこで、そのような新時代のニーズに対応するため、新しい技術でデータベースを作り直し、それにより新時代のデータ基盤を開発する各種取り組みがあり、それらの新しい技術のことを「NoSQL」と呼ぶようになりました。従来的なデータベースであるRDBを利用する時にはSQLを使うことを比喩して、「RDB （SQL）ではない新技術」のことをNoSQLと呼びました。

NoSQL：Not-only SQLへの変化

初期には、本当にSQLを使わない新技術が多かったことから「NoSQL」と呼ばれていましたが、SQLも（補助的に）利用できる製品も出現するなど、SQLを使うかどうかが問題ではないとしてNoSQLとは「Not-only SQL（SQLだけではない）」の略とされるようになります。さらには、従来通りSQLを使うけれどもNoSQLが対象としているような新しい領域にチャレンジしている製品も出現し、それらは「NewSQL」と呼ばれるようにもなりました。

TOPへ

この観点でのNoSQL製品は良く知られた「Hadoop」があります。同じく当時生まれたビッグデータの言葉とともに大変なブームになっていたものです。

HadoopはもともとGoogleが自社クラウドのデータセンタを構築する技術を紹介していた学術論文、通称「MapReduce論文」を参考にして開発されたオープンソースソフトウェアです。

⇒ MapReduce: Simplified Data Processing on Large Clusters

あまりにもデータが巨大で、一つのマシンには到底格納できないような状況を想定した、まさに異次元の技術（当時）でした。大量のPCサーバに搭載した大量のHDDにデータを分散して記憶させ、それらPCサーバの群れに対して検索処理や集計処理、データの更新処理などを実現する分散データベースを実現しました。

大量のPCにI/O処理の負荷を分散させる当時の技術状況に応じた技術でもあり、このようなアーキテクチャであることもあってSQLの利用は想定されておらず、各ノードでの並列処理である「Map処理」と各ノードからデータを集めてくる処理である「Reduce処理」で記述する仕組みとなっており、確かに「SQLではない」技術となっていました。

MapReduceでの処理の記述は従来のデータベース利用とは考え方が大きく異なり利用が難しいことが多く、SQLでは簡単に書ける処理（テーブルにまたがるJOINなど）が実装困難なこともありました。のちに、SQLライクな記述をするとMapReduceに変換して処理してくれる技術（Hiveなど）も登場しましたが、性能が出なかったりすることが多く十分な解決策にはなりませんでした。

このため、当時大変なブームであったにもかかわらず、その後のデータベース技術のメインストリームにはなっていません。しかし、今では「非常に大量のデータでも格納して処理できる」特徴から「データレイクの技術的基盤」として使われていることがあり、名前を聞かなくなった現在においてもあちこちで活用されています。

このような「Hadoop」を一例として、あまりにも大量すぎるデータを処理できる技術の追求としてのNoSQLがまず存在します。

TOPへ

RDBでデータ処理をする場合、まずデータベースに入れるデータの型を定義する必要があり、データ定義を行ってから決まった形のデータを格納する必要がありました。そのようにした方がきちんと整った形でデータ処理はできますが、その一方で何かするためには事前準備をしないとデータの格納すらきちんとできないことを意味しました。

多種多様なデータが次々到着するような状況では、事前に決めて準備した形のデータしか格納できないことは問題でした。そこで開発されたのが、データの型に関係なくデータを格納できて処理できるスキーマレスなデータベースでした。

例えばJSONのような、データ構造は持っているが、それぞれのJSONで異なるデータ構造をもちうるようなデータを格納し、格納したデータに対して検索処理や集計処理、更新処理ができるデータベースです。

NoSQLは狭義にはこの定義を指していることもあるように思います、またNoSQLからさらに細分化してドキュメント指向と呼ばれることがあります。JSONを格納して処理できるMongoDBが代表的製品として知られます。

RDBではデータベースに書きこむ前にデータ型を意識して書きこむことになりますが（スキーマオンライト：Schema on Write）、ドキュメント指向のデータベースでは読み込むときに多様なデータがあることに配慮して処理する（スキーマオンリード：Schema on Read）ことになります。

システム開発でシステムの機能やデータを試行錯誤しながら開発する時には、RDBでは格納するデータ型が変わるたびにプログラミング作業を止めて、データベースに関連する手間のかかる作業が必要になりますが、ドキュメント指向なら格納されているデータの型が混ざっていることにはなるものの、データベース側の事情に煩わされることなくプログラミングでの試行錯誤を続けることができるため、プログラマにとってありがたい側面もありました。

今では、伝統的なRDB側においてもこのようなニーズに対応する新機能の実装が進んでおり、例えば広く使われているPostgreSQLがJSON型を備えており、JSONのデータに対してクエリを書くことができるなど、機能の取り込みが進んでいます。

TOPへ

従来のRDBでは処理速度が追い付かないので開発された新技術があります。

例えば大量のユーザが利用するクラウドサービスでは、利用が集中する時間帯では大量のログイン処理が殺到することになります。IDとパスワードの照合処理のようなデータベース処理を非常に大量に処理する必要が生じます。

このようなニーズに対して、アクセスに時間のかかるハードディスクなどを利用せず、オンメモリで単純なデータ型の処理を高速に行えるデータベースが作られました。代表的なものでは、キーバリュー型（Key-Value Store）と呼ばれるようなタイプのデータベースです。キーバリュー型では、検索キーを与えると値（Value）が帰ってくる程度の単純な処理を主としますが、その代わりにメモリ上で高速に効率的に動作しました。

代表的な製品としてはRedisなどがあり、基本的にインメモリで非常に高速に動作します。よく知られたクラウドサービスであるAmazon Dynamoもキーバリュー型のデータベースです。

TOPへ

従来のデータベースとは、考え方自体が大幅に異なるデータベースも存在します。一例を挙げると「グラフDB」があります。

グラフDBとは、数学のグラフ理論で言うグラフ構造、つまり「頂点」と「辺」からなるデータ、例えば鉄道の路線図のようなデータをネイティブに格納することを目的にしたデータベースであり、検索処理で検索したいことも異なるためにSQLとは異なる言語を用います。

他にも、時間経過で変化するデータについて時間経過を含めて記録して検索できる時系列データベースや、オブジェクト指向のデータをそのまま格納できるオブジェクト指向データベースなども存在します。

TOPへ

RDBの考え方に慣れると、RDB的なものがデータであって、NoSQLが言っているようなデータは例外的なものにも思えてきますが、世の中のデータは本質的に多様で、むしろRDBに自然に格納できるデータばかりではありません。

「ない」のではなく「気がついていない」だけ

例えばグラフDB、鉄道路線図を例に出しましたが、同じようなデータ構造は世の中のあちこちにあります。道路交通網、通信ネットワーク、人間関係（誰と誰が友達か）など、多くのデータが本来グラフDBで取り扱うべき構造をしています。

しかし従来、グラフ構造のデータをRDBに無理やり押し込むテクニックが活用されてきました。そういうデータは取り扱いが難しいものであると思われているだけで、グラフDBを活用すればシンプルで自然に解決できるケースもあることは意識されていないことがほとんどです。

他にも、Javaプログラムが動作中に取り扱っているデータは当然に「オブジェクト指向のデータ」ですが、これをデータベースに格納しようとするとRDBに格納できる形式に変換する必要があって大変苦労することがあります。せっかく美しくクラス設計をしたのにRDBに自動変換して入れたら性能が出なくて台無しになってしまうこともあります。これもデータベースがRDBでなければ解決するかもしれない問題です。

「運用が手間だった」が解消しつつある

しかし従来、RDB以外のパラダイムの有用性を認めても、多種多様なデータベースを「運用する手間」が大変であるハードルはありました。例えば、PostgreSQLだけにそろえてくれた方がITインフラ的には運用は簡単で効率的だというわけです。

しかし今、状況が変わりつつあります。RDB以外のデータベースをクラウドサービスとして利用する環境が整いつつあり、そうなると自分で運用する手間が不要にできるのです。例えばAWSではRDB以外に以下のように多種多様なデータベースが提供されています。

• リレーショナル（RDB）：旧来からのデータベース
  • -Amazon Aurora / Amazon RDS / Amazon Redshift
• キーバリュー型（インメモリデータベース）：
  • -Amazon DynamoDB / Amazon ElastiCache / Amazon MemoryDB for Redis
• ドキュメント指向
  • -Amazon DocumentDB (MongoDB 互換)
• ワイドカラム（大量データの処理に向いたタイプ）
  • -Amazon Keyspaces
• グラフDB
  • -Amazon Neptune
• 時系列
  • -Amazon Timestream
• 台帳（ブロックチェーンのような事後書き換え不能なデータベース）
  • -Amazon 台帳データベースサービス (QLDB)

以上は執筆時点のものなので、今後さらに増える可能性もあります。雑に分類するならばですが、上記の「リレーショナル」以外はすべて違うタイプのNoSQLということになります。

TOPへ

このようにして、多種多様なデータベースが存在し、今や運用不要で活用できる状況が整いつつあることも解ってきました。

これらを活用するためには「RDB以外があることを知る」「使おうと思うこと」も当然必要ですが、多種多様なデータベースの間、多種多様なデータを互いにうまく連携して組み合わせて利用する基盤も必要になります。

ドキュメント指向データベースに入っているJSONのデータをRDBに連携しようとしたら、データの変換処理などが必要になることは当然出てきます。考え方の違うデータベース同士を連携させる処理では、それぞれでのデータの意味を人が理解して変換処理を考える必要が生じることもあります。

そこで活躍するのがノーコードで様々なクラウドやシステム、データを連携できる手段です。例えば「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術の活用です。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータとの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できれば「業務の現場の担当者が自分たち自身で主体的に取り組む」ことが可能になります。何と何を連携すべきかについても同様です。ビジネスのことを一番良くわかっているのは現場の担当者です。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

一見使いやすくて今風のサービスに見えても、少し大きなデータすら十分に処理できないようでは、ビッグデータどころではありません。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。

データ活用を成功させる「データ基盤」として必要なこと

実業務をしっかり支えるためには大量のデータを処理できる高い処理能力も必要になります。その一方で、現場主導での柔軟かつ迅速な試行錯誤がどうしても重要になることもあります。

一般的には、高い性能や高度な処理の実現を求めると本格的なプログラミングや利用が難しいツールとなりがちで、現場での使いやすさを求めると利用しやすいが処理能力が低く簡易な処理しかできないツールになりがちです。しかしこれらを兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

TOPへ

「クラウド活用」「社内でのデータ活用」「業務の自動化」、これらをうまく進めるポイントは、自社で内製できる「データ連携基盤」を整備することです。

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider<」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は、各社の業務システムを支える基盤として長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。