データ活用や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へ

従来のデータベース（RDB）とは、考え方自体が異なるデータベースも存在します。

グラフデータベース

グラフデータベースとは、数学のグラフ理論で言うグラフ構造、つまり「頂点」と「辺」からなるデータを取り扱うことに特化したデータベースです。例えば「鉄道の路線図」がそのようなデータの例になります。RDBとは格納するデータの構造が大きく違うのみならず、検索処理で行いたいことも大きく異なることから、SQLとは異なる言語（Gremlin、Cypher、SPARQLなど）が用いられていることも多いデータベースです。

時系列データベース

「IoTにおいてセンサーから送信され続けるデータ」や、「銀行の取引データ」など、時刻（タイムスタンプ）と他の値がセットになったようなデータの取り扱いに特化したデータベースです。時刻を用いた検索処理を効率的に行いたいことが多く、データが新たに届き続けることが多く、一方でデータの書き換え処理が行われることが少ないことなどを踏まえ、そのような用途に合わせて作られているデータベースです。

オブジェクト指向データベース

Javaなどのオブジェクト指向言語ではプログラム内で取り扱うデータはオブジェクト指向でモデリングがなされています。しかしITシステムとしては一般的にRDB（リレーショナルデータベース）が広く使われており、RDBとはデータモデリングの考え方が違うために、データを格納しようとすると考え方自体が違う世界のデータへの変換処理が必要になる問題があります。そこで、そのような問題をなくすべく「オブジェクト指向でモデリングされたデータをそのまま格納できる」ことを目指しているデータベースです。

ベクトルデータベース

生成AIブームで注目されるようになっているデータベースです。RAGの実現手段としても利用されています。ベクトル演算により「意味の近いデータ」などを探す手段として利用されています。以下に詳しい記事があります。

⇒ ベクトルデータベース（Vector database）｜用語集

⇒ 検索拡張生成（RAG：Retrieval Augmented Generation）｜用語集

TOPへ

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

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

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

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

また、Javaなどのオブジェクト指向言語がシステム開発で広く利用されていますが、これら言語をしっかり活用してシステム開発を行う場合、オブジェクト指向でモデリングを行い、プログラムが動作中に保持するデータも「オブジェクト指向できちんとモデリングされたデータ」となります。しかし、RDBではデータの考え方自体が違うため、データを格納するためには手のかかる変換処理が必要になり、せっかく美しくクラス設計をしたのにRDBに変換して入れたら性能が出なくて台無しになってしまうことがあります。

Javaを用いたシステム開発ではおなじみの「現実的な勘所」なのですが、これも「オブジェクト指向でデータを格納できるデータベース」があればこのような悩みそのものを無くせるかもしれません。

TOPへ

クラウド時代になって解消しつつある「運用の手間」

しかし従来、このような「RDB以外のパラダイムの有用性」を認めても、それらを実際に利用するためには、多種多様なデータベースを「維持運用する手間」をかける必要がありました。例えば、利用するデータベースをPostgreSQL一種類にそろえてくれた方がITインフラ的には運用が簡単で効率的で、他のデータベースが適するデータであってもRDBを工夫して使ってもらう方が現実的なところがありました。

しかし今、状況が変わりつつあります。RDB以外のデータベースをクラウドサービスとして利用できる環境が整いつつあり、それにより「運用の手間がかかるので」が解消しつつあります。例えばAWS（Amazon Web Services）では、以下のように多種多様なデータベースが提供されており、自前運用することなく利用できるようになっています。

リレーショナルデータベース（RDB）

広く使われているRDBは当然提供されています。

• Amazon Aurora
• Amazon RDS
• Amazon Redshift

キーバリュー型（インメモリデータベース）

「非常に高速に処理しなければいけない」ニーズを満たすNoSQLも提供されています。

• Amazon DynamoDB
• Amazon ElastiCache
• Amazon MemoryDB

ドキュメント指向

「データが多種多様すぎる」ニーズを満たすNoSQLも提供されています。

• Amazon DocumentDB (MongoDB 互換)

Hadoopや列志向データベース（大量データの処理に向いたタイプ）

「データ量が多すぎる」ニーズを満たすNoSQLも提供されています。

• Amazon Keyspaces（Apache Cassandra互換）
• Amazon EMR（Hadoop）

グラフデータベース

「頂点」と「辺」からなるデータ構造のデータを取り扱うことができるグラフデータベースも提供されており、自前で運用することなく利用できます。

• Amazon Neptune

時系列データベース

IoTなどで利用できる時系列データベースも提供されています。

• Amazon Timestream

ベクトルデータベース

生成AI関係、特にRAGでの利用で注目されているベクトルデータベースもAWSから提供されています。既存の各種データベースにベクトル検索が追加されていて併せて利用できる環境も用意されています。

• Amazon OpenSearch Service
• 各種データベース等にベクトル検索機能が追加されたもの
  • ◦RDBベースで利用できる：
    　AWSのPostgreSQL（Amazon Aurora PostgreSQL / Amazon RDS for PostgreSQL）に拡張機能「pgvector」が追加されたもの
  • ◦オブジェクトストレージで利用できる：
    　Amazon S3をベクトルストアとして利用できる「Amazon S3 Vectors」
  • ◦グラフデータベースで利用できる：
    　Amazon Neptuneの拡張機能「Amazon Neptune ML」
  • ◦NoSQL（インメモリデータベース）で利用できる：
    　Amazon MemoryDB のベクトル検索機能
  • ◦NoSQL（ドキュメント指向）で利用できる：
    　Amazon DocumentDB (MongoDB互換) のベクトル検索機能

以上は執筆時点のものなので、今後さらに増える可能性もあります。雑に分類するならばですが、上記の「リレーショナル」以外はすべて違うタイプの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の技術を用いて開発された「つなぐ」クラウドサービスです。

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