#今回は閑話休題編です・・
最近、MemSQLが業界の隅っこの方で、何となくゴニョゴニョ動き始めた様で、「因みに、どんな感じで使うのが良いの？」という、極めてシンプル且つ基本的な質問を頂く様になって来ました。

MemSQL自体は、以前にもご紹介させて頂いた通り

（１）ネイティブなインメモリデータベース（高速デバイス代わりのキャッシュライクなメモリ利用では無い）
（２）MySQLとのSQLレベルでの高い互換性
（３）スケールアウトが可能（勝手にスケールアウトはしませんが・・）な仕組みなので、変化に強い運用が可能

といった特徴が有ります。

少し噛み砕いて補足させて頂けば

（１）超高速のSQLトランザクションをインメモリテーブル間で実現出来る
（２）MySQLと連携出来る多くの周辺環境や、既存資源を効果的に活用出来る
（３）スモールスタートで利用を開始して、必要に応じてスケールさせる運用戦略を柔軟に取れる

という事になります。

#最近のデータ・コンピューティングについて・・・
ここで、最近のデータ・コンピューティングの周辺について考えてみたいと思います。

##データが作られる所・・・
この領域は、殆どのケースで特定のアプリケーションやシステムに紐ついた、日常の業務オペレーションから発生するデータを、きちんと保守本流・王道の設計手法で導入された仕組みとして存在する、現場業務の最前線活動により生成されるあらゆるデータベースシステムになっていると思います。
もちろん、近年主流派の構造化データ以外のデータ形式も、それらの対象として蓄積・運用される様になって来ていると思いますが、基本は、企業・団体活動における「コンプライアンス＆ガバナンス」や、各種の関連法規制に対するエビデンス的な位置付けとして、「とにかく安心・安全・確実に守る！」というポリシーで運用されているのではないでしょうか？また、この領域においては「緻密なサイジング設計」、「運用も含めた完璧な二重化対応」等の「絶対に譲れないポリシーが「それぞれの運用チームには存在している」のが特徴だと思います。

データは、会議室で生まれているのではなく、現場で生まれている！（某映画の名セリフより引用・・）

実は、これが非常に重要なポイントで有り、それらは「殆どの場合、極めてキチンと事前サイジングされた」環境で運用されている・・・という所が肝になるという事を「後付けの仕組み」は考慮すべきだという事になります。

##AIとかBIとかxx学習とか・・・
さて、ここ数年データコンピューティングの世界では、データ収集・登録・検索・修正・保管といった、従来型のデータ運用ではない「新しい方向性」が数多く提案され、実際に多方面での導入が始まってきています。
これらの新しい流れに共通している事は、基本的にデータを如何に活用するか？の方に重心が寄っており、従来型のデータ運用（出来れば静かに置いておく）ではない、有る意味「出来るだけ高速に掻き混ぜて、多様な結果を導き出し、その中から最適な解答を選択する」という、真逆のデータ運用が要求されている点が有ります。

##だとすれば、この新しいトランザクションを何処で処理するか？・・
もちろん、メインのデータシステムにこれらの新しいトランザクションモデルをサポート出来る余力が有れば、多分何の問題も無くこのリクエストに対応する事は可能だと思います・・・・・・。
しかし、現実的には如何でしょうか？
現業（データを生成している現場側の利用）時間に被せて、「アーでもない、コーでもない」的な・・有る意味複雑奇々怪怪なSQL等をリクエスト出来る余地が有るのか・・・は、正直かなり難しいというのが現状なのではないかと思います。
勿論、量を減らして・範囲を狭めて・回数を少なくすれば、もしかすると「データ運用側」と「データ利活用側」が「同じ仕組みに相乗り」出来るかもしれません。でも現実的には、この運用側と利活用側自体が被っているケースが多いと思いますし、何よりここで「サイロの壁」問題が大きく立ちはだかってくるでしょう。

##サイロの壁問題・・・
データ運用側では、有る意味影響の最小化という意味も有り、戦略的なサイロ化は正しい方法論だと思います。最近ではデータ統合・・・という話も出ている様ですが、この作業より発生するリスクとこのリスク起因で生じる新たなコストを考えた場合、何年も掛けて練り上げてきた既存システムを変える「必要が無ければ」変えたく無い！というのが正直な所なのではないでしょうか？
現場側から見れば、必要なデータは何時ものアプリ経由で普通に運用できる・・・というだけで必要条件は満たしているでしょうし、運用効率も「当初設計時想定のトランザクション範囲」で有れば、十分な性能での運用も可能だと思いますので、特に「後からチョッカイを出され無ければ」心静かに業務を遂行出来る訳です。

ここで大きな問題が有るとすれば・・・
そうです。先程の「後からチョッカイ」的に発生してきている、「データの利活用系トランザクション」の多くの場合に「サイロ横断的なデータ活用」を求められるケースへの対応になります。また、同時にこの領域では「ある種のシュミレーション的な利用」や、「今の問題を横断的に解決する為に必要な情報の高速抽出」等が存在します。
これらの「後付けのチョッカイ的なサイロ横断的重量トランザクション」の処理をどうするか・・・

#ここでMemSQLの出番です！
MemSQL的には、普通のデータベースとしての利用も可能ですが、シンプルにその特性を活かすとすれば、まさにこの「後付けのチョッカイ的なサイロ横断的重量トランザクション」処理エンジンとして、それ以降に展開する各種のAI/BI/xx学習系ソリューション等への、専用高速トランザクションエンジン的利用が有ります。

オリジナルは、練り上げて枯れた上流域に存在しますので、この部分の仕組みは「性能と柔軟性」優先で構築されれば良いと思いますし、テーブルの設計も、Equalumなどの仕組みと組み合わせる事により、シンプルな必要テーブル（無用なリレーションは戦略的に取らない）をメモリ上に一気に展開して、シリコンパワー全開の特性を活かした高速処理で結果をどんどん出していく様にすれば、最大の投資対効果が得られるでしょう。

PythonやR、また各種のSQLクライアントに対する、MySQL互換性の高さを活かした、柔軟で発展的な利活用の仕組みに対する超高速なSQLトランザクションエンジンとして、極めてシンプルかつ分かり易い適用先が、このDx時代における「データドリブン・プラットホーム」になります。

#少し補足・・
ここで、大きな欠落点が有るとすれば、シンプルに・・・
では、上流側の既存データベースから、必要なデータを高速に引っ張ってきて、活用側のMemSQLに展開する仕組み・・・・
という部分になります。

安心してください。Equalumが有ります！

Equalumの高度なCDCリアルタイム・ストリーミング技術を活かして、MemSQL上に必要なテーブルを超高速に展開し、データ利活用側の仕組みが「上流側へのトランザクション負担無し」で同じ時間を共有し（夜間バッチとかで、翌日利用可能。。ではなく）、データ運用側への「リアルタイムな各種データ支援：データドリブンの高度化」や、集計系バッチ処理間隔の短縮化による、各種の業務高度化（経営戦略的な領域とか市場戦略的な領域））、また顧客対応、IoT・５・６G環境の活用等、今までとは異なる視点での「デジタルトランスフォーメンション」が可能になるでしょう。

この辺は、別途改めてEqualumの回に・・・・・

##今回のまとめ
既存のデータシステムに迷惑を掛けない様に、後付けのデータトランザクション負荷を切り分けて利用する為の、超高速・インメモリSQLデータベースとして、MemSQLの典型的な適用先が存在し、「時間遅れではない」各種のデータ支援を実現できる仕組みとして、ぜひMemSQLをご検討頂ければ幸いです。
本稿冒頭で書かせて頂いた
（１）超高速のSQLトランザクションをインメモリテーブル間で実現出来る
（２）MySQLと連携出来る多くの周辺環境や、既存資源を効果的に活用出来る
（３）スモールスタートで利用を開始して、必要に応じてスケールさせる運用戦略を柔軟に取れる
は、まさにDxを強力にサポートできる「データドリブン・エンジン」としてMemSQLがお役に立てるかと思います。

##謝辞
本解説に転載させて頂いているスクリーンショットは、一部を除いて現在MemSQL社が公開されている公式ホームページの画像を使わせて頂いております。また、本内容とMemSQL社の公式ホームページで公開されている内容が異なる場合は、MemSQL社の情報が優先する事をご了解ください。