データを取り巻く環境の変化
ビックデータという言葉が旋風の様に市場を席捲していた時期がありましたが、最近ではあまり声高には聞こえなくなってきている気がしています。確かにこの単語を使うと、間違いなく集客や問い合わせを獲得出来た・・ある種のバブルの様な時期が有った事は間違いありません。
しかし、本当にそれがユーザレベルで根付いたのか？？という事が重要でしょう。
空前のHadoopブームから多くのオープンソース系を中心としたソリューションが登場し、海外においては極めて急速かつ大きく市場が立ち上がったのも事実であり、クラウド系の環境における、データ層の決定打！的な流れまで到達して行きました。恐らく現在でもその進化はクラウド型のユーザ（サービス提供事業者）の内部で、着実かつ更なる使い勝手の向上を求めてて進化を続けているのだと思います。そういう意味では、バブルが弾けて着実な成長曲線に移行し、ある種の市場淘汰が発生して収まるところに収まった・・というのが今の状況なのかもしれません。
また、オンプレミスを中心とした一般的な企業・団体において、特に情報システムを電子帳簿として進化させて来たような場合、その殆どはシステム毎の縦割りサイロとして一定期間の間をオンラインで更新・検索する形になっていると想定されるので、その単位においてビックデータ・・という概念が根付きにくい環境であった事も事実でしょう。
しかし見方を変えれば、これらのサイロの壁を取り払い、処理対象期間を延長させる事で「トータル」としてのビッグデータ活用は、実は非常に現実的な状況で有る事も事実なのです。但しこのサイロの壁は、多くの場合既得権の壁でもありますので、その壁を超えて横展開を一気に行うという事は、ある種のギャンブルでもあり,状況としては非常に厳しいとは思いますが、最近改めて浮上してきている「データの仮想化」や、透過利用を容易に行える各種のツールやソリューション等を用いれば、以前よりは格段に実現可能な段階に移行してきている事も事実だと言えます。
この辺の最新動向等は、また別の機会に紹介させて頂くとして、取り急ぎ今回の「MemSQLを使ってみよう」では、仮説的に・・・
（１）ITインフラ上に散在するサイロ化された既存のデータベース
（２）BI/AI等での透過的利活用（マイニング）を実施
（３）IoT等の新規データ収集と既存データベースとの連携
等を前提に、MemSQLを使ってどのような解決が出来るかを、実際に試用環境の導入からステップアップしていくイメージで展開していこうかと考えております。
MemSQLとは・・・
MemSQLは米国のMemSQL社が開発を進め、既に北米市場を中心とした海外においては、多くの導入実績を持っており、各領域における著名な企業等の重要なデータプラットホームとして稼働しています。
また、その特徴としては
（１）インメモリ技術を活用した、クラスター型分散データベースシステム
（２）MySQLと高い互換性を持つピュアSQLデータベース（ストアード・プロシージャもサポート）
（３）スケールアウト運用が可能で汎用のIAサーバで利用可能
（４）物理環境・仮想環境（最新版ではKubernetes環境でも利用可能）を問わない配備が可能
（５）インメモリ層とストレージ層に最適化されたテーブル利用を実現
最新版のバージョン７では、（５）の利用形態が進化しており、通称「ハイブリッド」と呼ばれる利用を実現する為の実装が行われていますが、今回の一連の紹介では、市場での実績十分なバージョン６の最新版を使って話を進めて行きます。
バージョン７については、後日改めて評価を行って報告させて頂ければと思います。
インメモリの活用・・・・
MemSQLはインメモリで稼働する事を前提に設計されており、通常のSQLでテーブル宣言を行うと、メモリ空間上に所定のテーブルを配備します。SQL自体はMySQLとの高い互換性を持っていますので、今回の一連の紹介におけるSQL関連の説明は省略させて頂き、サンプル的に生のSQLをそのまま掲載させて頂きますが（但し、MemSQLに特有な部分は、その都度説明を入れさせて頂きます）、原則的に「メモリが持つ特性や利点を最大限に活かして」各種のSQL処理を進めていく形になります。
この部分は、MemSQLの最も特徴的な部分であり、同時にI/Oキャッシュ的な利用ではなくある意味「ガチ」にメモリを使う実装になっているので、適切なテーブルデザイン（ここは、MemSQLの性能を引き出す重要ポイントの一つになります）を行う事で、今までのデータベースでは到達できなかった、圧倒的な処理性能を獲得する事が可能になります。
また、最近ではメモリ領域を束ねて大きなI/Oキャッシュとしてアドオン出来る様なソフトウエアソリューションも数多く出てきていますが、コアのレベルまでネィティブにインメモリ実装したピュアなSQLが普通に利用できるデータベースは、まだあまり普及していない状況だと思います。（I/Oキャッシュ的な実装と分ける為に、以後はオンメモリとインメモリの2種類に分けて話を進めます）
ビッグデータに対応出来るピュアSQLデータベース・・・
最近では、Hadoopベースのビッグデータ環境に向けて進化した、SQL的なクエリでアクセス可能なデータソースが幾つも出てきています。また、一方では従来型のSQLデータベースの弱点を補完する形で、クラスター型のメモリキャッシュを活用したり、並列処理を高度化させる為にGPUエンジンと組み合わせたりする等の、非常に野心的な試みを実用化し始めてきてます。
MemSQLのアプローチは、ユーザやデータ・アプリケーション層に対しては極めて普通の従来型SQLデータベース（MySQL互換）のように振る舞い、それらを支える裏側の仕組みは最先端の分散並列処理技術と、クラスタリング技術を高度に組み合わせ、高い処理性能を高次元で維持し続けられると同時に、従来型のSQLデータベースがメインに使っている、ストレージ側に対してその特性をフルに活かせるような仕組みを独自に実装する事により、メインのメモリテーブルと相互に最適な補完関係が確立出来る構造を実現しています。
オンメモリ型との違い・・
従来型のSQLデータベースの出入り口にメモリをクラスタリングして、スケールアウト出来る型のソリューションを良く見かける様になりましたが、MemSQLの場合はコアのレベルから、分散SQL処理や（集約系の処理は流石に統一的に処理をする形式ですが。。）繰り返しのSQL処理に強いコンパイル型クエリの活用（データがメモリ上に展開されている場合、極端に単純化して考えれば、俗にいうアセンブラレベルにSQLを落とし込んで、そのレベルでの処理が実現できれば、デバイス効果を最大限に活用出来る事になります。）等の、SQLエンジン自体のメモリ最適化と分散処理を有する、ピュアなインメモリSQLデータベースだと言えるでしょう。また、この完全にメモリアクセスをCPU（コア）レベルで最適化した環境は、現在注目されている不揮発性のメモリ（よりCPUに近ずくSSD？）等のデバイス進化を、より効率的に活用出来る事も重要なポイントになります。
では、どの領域に活用すれば良いか？
国内において、オフコンやｎ次オンラインｘｘの誕生以降連綿と続いてきた、電子帳簿型データシステムの発展は、関連する企業やOSSに貢献されている皆さんの努力により、かなり高度で枯れた（良い意味で）領域まで進化してきています。また、ユーザ領域においても、継続的に積み上げてきた運用経験や、各種ドキュメント類、また何か起きた際の対応手順等も十分練り上げられていると思います。
MemSQLをこれらの現場業務直結型システムのデータベースに適用する事も、仕様的には可能なレベルまで練り上げられてきていますので、かなり大きなドラスティック・チェンジをしてでも、高速で将来的にスケールUP&OUTが可能な環境へ移行する！という判断にも対応が可能ですが、それよりも、まずはこれら日々連綿と積み重なってくる、各業務毎のデータベースから必要なデータを参照し、インメモリ空間を活かした透過的展開をサイロの壁を越えて実現して、各種表計算のグラフ作成（CI)からスタートして、最近脚光を浴びているBI、また今後飛躍的な進化・展開が期待されているAIの領域をサポートする、Dxデータエンジンとして位置付ける事を検討されるケースが急増してきています。
現在稼働中のデータベースでは、基本的に現業側からの通常業務（元々想定している入出力作業）以外に、前述のデータの利活用型ユーザが大挙して、若しくはかなり重い作業を被せ始めているのが現状であり、この状況の悪い点が基本的に忙しいタイミングが重なる傾向に有る！という点が各所・各局面で顕在化し、現業側と利活用側のDBトランザクションの取り合いによる性能問題に直面しているケースが増えている気がしています。
もちろん、この為にDWHとかデータマートとかといった概念・方式論が生まれ、オペレーションを分離する事でこの問題を解決しようとしてきましたが、現実的には時間を掛けて下準備を行った各種の結果テーブルを、目的や用途毎に小分けに展開する事で（各種のSQL処理に対する時短対応）以降のデータアプリケーション層への対応を効率的に行えるようにしてきたのが過去の経緯かと思います。
またその結果として多くの場合では、
（１）サイロ化したデータソースから必要なデータを吸い上げる
（２）ETL処理等で事前処理を実施する
（３）目的・用途別に作業等のサイロを再構築する
という形になり、実際には意外にコスト（データベースエンジン数やH/Wの最適化）が下がらない（若しくは上がる）事や作業効率（再設定・やり直し等）が悪かった事が多かったのではないのでしょうか？
MemSQLが貢献出来る事・・・たぶん・・
そこで、今回ご紹介するMemSQLをこの領域（データ利活用の為のSQLデータエンジン）に適用した場合何が出来る様になるか・・・について解説というなの自己完結型仮説論証をしていきます。
MemSQLを使っても、基本的なデータ利活用に対する作業ステップは同じですが、それぞれの項目における中身がかなり異なってきます。
（１）サイロ化したデータソースから必要なデータを吸い上げる
（２）インメモリの高速分散SQL処理で事前処理を実施
（３）サイロ化を前提としないシンプルなテーブル展開
最初のステップとしては、データが無ければ何も出来ませんので、従来と同じ様に散在するデータソースから必要なデータを収集してくる作業を行いますが、MemSQLの場合は著名なデータソースへのパイプライン経由の標準アクセスと、効率的なCDC（OSSを活用可能）機能経由で、どんどん自動的にMemSQL内の所要のテーブルを埋めて行く事が可能です。特にCDC機能は既存のサイロ化したSQLデータベースから、所要のデータ（カラム群）をSQLベースで引き抜いてくる作業を効率化出来るので、データがMemSQLに書き込まれると同時に各種の利活用層に対するSQLサービスを実施する事が可能になります。
また、MemSQLの場合は、その高速性を活かしてIoT系のデータをKafka環境を経由して、その他の既存データと透過的にSQL処理が可能な、MemSQL上へのテーブル書き込み（更新）を標準機能のパイプラインと呼ばれる処理で実施する事か出来ます。これは、利活用層に対して（特にML/AL等）非常に大きなアドバンテージとなると同時に、その即時性を活かした、新たなサービスや問題解決のベースを構築する事が出来る事を意味します。
さらに、昨今良く目にするようになってきた、IoTや即時系のストリーミング処理に対しても最適なデータエンジンだと言えると同時に、スケール可能でストアード・プロシージャを含めたピュアSQLでの利用が可能な、非常に面白いSQLデータベースがMemSQLの特徴の一つだと言えます。
2番目ののステップにおけるSQL処理の高速性は、圧倒的な活用アドバンテージをユーザに対して提供する事が可能です。（MemSQL社が公式に使っている資料では、某社おける24時間のETL処理時間を40分台に短縮した・・・という記述があります）このステップの時短は、そのまま直接「データを諦めない」利活用を可能とし、より精度が高く、詳細にドリルダウン可能な各種利活用への応用展開の為の環境を提供出来ます。
1日1回の事前処理が、1日複数回可能になれば、シュミレーションする範囲や方向性、また他の想定されるデータ群との連携を容易に行えるようになりますので、データ・ドリブンでのデジタルトランスフォーメーションの実現を大きく後押し出来る事は間違いありません。
3番目のステップで重要な点は、抽出されたデータをメモリ空間上をその特性を活かして出来るだけシンプルに所要のテーブルに展開する事で、圧倒的なSQLトランザクション性能、すなわちデータ利活用層に対するサービス性能を手に入れる事が出来るという事を意味します。各サイロから抽出され効率的に再構成されたデータは、データの利活用層に対して透過的な利用環境を提供し、その上で効果的なSQL処理を行う事で現業側に対して負担を掛けない形で、従来型の仕組みよりも高速・高効率に作業を進められるようになります。
また、データ利活用層で使用するソリューションとのコミュニケーションがSQLで可能な場合、（高いMySQLとの互換性を活用）利活用層で新たに生成したデータ（高度な分析エンジン等による数値演算結果やAIエンジンからの評価結果等）をMemSQL上で必要な共有領域として再活用する事も出来ます。
さらには、BIまでは必要ないけど・・・データの量やサイロの壁を越えて表計算上でのCI（グラフ等による可視化）を、もっと高速（ユーザ数も大量になる事が想定出来るので、非常に重要なポイントになります）で、効率的に作業を行いたい！といった、ライトなBI層のユーザに対しても、高い投資対効果を発揮できると思います。（MySQL接続のODBC://設定で各テーブルと連携）
今後の進め方
次回は、試用環境に関するご紹介をさせて頂き、基本的な評価環境の構築までを行いたいと思います。また、その後は順次具体的な作業を進めつつ、実際に利用する際のポイントや留意点を数回に分けて書かせて頂く予定です。
最後に
また、今回ご紹介しているフリー試用ライセンスに対するサポート等は有りませんので、自己責任・自己解決を前提にお使い頂くようにお願い致します。なお、コミュニティー的な情報交換の場がありますので、疑問点等があればそちらに問い合わせてみるのも良いかもしれません。
謝辞
本解説に転載させて頂いているスクリーンショットは、一部を除いて現在MemSQL社が公開されている公式ホームページの画像を使わせて頂いております。また、本内容とMemSQL社の公式ホームページで公開されている内容が異なる場合は、MemSQL社の情報が優先する事をご了解ください。