前回のブログで、InterSystems IRIS Data Platform を新規開発した背景について説明しました。
その中で
IRIS は、従来製品の機能を引き継いでいるという話を中心に説明を致しましたので、IRISが従来製品と何が違うのかよくわからないという印象を持たれた方もいらっしゃるかもしれません。
そこで今回は、そういう疑問を払拭する意味で、前回ほとんど触れられていなかったIRISで新たに加わった新機能について紹介したいと思います。
まずデータベース機能としてシャーディングをサポートしました。
シャーディングは、大量データを高速に処理するために複数コンピュータノードにデータを分散させ、並行処理することで全体のスループットを向上させる手法で、オープンソースの NoSQL などで広く採用されている技術です。
もともと InterSystems のデータベース技術は、複雑（複数のデータが関連するような）で高性能が求められるトランザクション処理を最適化することを重視して設計されていました。
残念ながらシャーディングは、高速性という観点では、複数のデータがノード間に跨る可能性のあるトランザクション処理にはあまり効果がない（あるいは逆効果もあり得る）ため、InterSystems はいままでこの技術の採用には慎重でした。しかし IoT のように比較的処理が単純なストリーミング処理の場合は、トランザクションが複数ノードに跨ることもあまりないため、今後データが爆発的に増えることが想定される中、シャーディングのサポートは重要となっています。
そして、一般的なシャーディング技術には、一つ大きな課題があります。
それは、SQLのテーブル結合（JOIN）処理です。
複数のテーブルデータをシャーディングにより複数のコンピュータノードに分散したとしても、結合処理に都合の良い形でデータが分散配置されることはありません。つまり、分散処理できるようにデータを分割しても、テーブル間で結合処理をする際には、全てのノードの組み合わせで結合処理をする必要があります。これでは処理を複数ノードに分散して高速化するというメリットを全く享受することができません。
これはデータウェアハウスの様な分析システムでよくみられる処理パターンの１つです。
データウェアハウス用のデータベーススキーマではスタースキーマと呼ばれるデータ構造を取るケースが多いです。これは、簡単に説明すると、１つのファクトテーブル（通常は数値項目を中心としたトランザクションデータの集まり）とそれを様々な角度で分析するための軸（一般的にはディメンジョンと呼ばれることが多い）となるマスターテーブルで構成（ファクトテーブルの周りにマスターテーブルが星のような放射線を描く形で表現される形)されます。
こういう構造を SQL でアクセスする際には、必然的に複数テーブルの結合処理が発生します。
この状況に対する対策として、マスターテーブルは通常ファクトテーブルに比較するとデータ量は少ないはずなので、マスターデータを丸ごと全てのシャーディングを構成するコンピュータノードにコピーするという手法が考えられます。
しかし、この場合もマスターデータが更新されるとその更新データを全てのノードに反映させる必要があるなど、データ管理上のタスクが増えます。
IRIS では、InterSystems が従来から持っている分散データベースキャッシュ技術（ECP)をうまく利用することで、この分散結合処理におけるデータ管理タスクを不要にします。
次に運用関連の機能としてクラウド対応があります。
従来の Caché/Ensemble でもクラウド上で動作することは可能でしたが、IRISではさらにクラウド上で動作する上での様々な拡張が行われています。
まず、メジャーな３大パブリッククラウドプラットフォーム上でIRIS製品を簡単に調達できる環境を整えました。
アマゾンの AWS、マイクロソフトの Azure、グーグルの GCP 上で、自分で IRIS 環境のインストールキットを調達する必要なく、非常に簡単に構成できるようにしました。
また、複数のコンピュータノードで構成されるIRIS実行環境を簡単にセットアップできるよう、コンテナ技術であるDockerのサポートと、Dockerの構成情報を迅速に構築するためのツールICM（InterSystems Cloud Manager）を用意しました。
次にオープンな分析環境の提供があります。
昨今人工知能（AI）や機械学習（ML）が大きな注目を集めています。
IRIS Data Platform では、AI や MLをサポートするために AI、ML環境のデファクトスタンダードとなっている Apache Spark との連携を強化しています。さらに Tableau やマイクロソフトの PowerBI、Qlik などのビジュアル BI ツールとの連携を強化していきます。
オープンな開発環境の提供も大きなテーマです。
従来も Java や.Net などのポピュラーな開発言語や、開発環境からアクセスする手段は用意されていましたが、性能、効率、機能の面で、InterSystems のネィティブ言語である InterSystems ObjectScript 経由でアクセスする方法に劣っていました。それを機能強化して ObjectScript 経由のアクセスと遜色ないレベルのレイテンシー、スループット、機能を提供し、開発者が使いたい開発言語をそのまま使える環境を増やそうとしています。
さらに、開発者によって、開発言語だけではなく、開発ツール（コードを書くためのエディターなど）も好みが分かれます。このような様々なニーズに出来得る限り対応し、開発者にとって最高の環境を提供できるよう努力していきたいと考えています。
そのほかにも様々な今までにない機能強化が行われています。また、今後も様々なものが追加されていくと思います。
さて、既存の Caché/Ensemble のユーザー様の中には、
IRIS が将来に向けていろいろな機能強化をしたことは理解した。 でも今のアプリケーションを動かすだけだったら現状で十分なので、コードを一部書き換える必要があるのならば手間がかかるので、そのまま Caché/Ensemble で運用を続けたい
と思っている方が結構いらっしゃるのではないかと思います。
（ほとんどの方がそうかもしれません。）
お気持ちは十分理解できます。
しかし、前回もお知らせしましたように、Caché/Ensemble のサポート保証はいつかかならず終了します。
また、クラウド対応やデータ容量の増加などの環境の変化は想定を超えたスピードで進むかもしれません。
さらに製品強化の中には明確な機能として現れないものも多々あります。
例えば最新ハードウェアの対応などです。
IT のハードウェア環境も日進月歩です。今後もマルチコア、マルチCPU化は進んでいきます。
ところがマルチコア、マルチCPUが即性能向上につながるかといえば、そういう単純な話ではありません。
コア数が増えるとメモリーとの競合の管理が複雑化し、いままでの手法では本来の性能を引き出すことができないことも可能性としてあります。
実際 Caché の時代にも最新マルチコアシステム上でのメモリーアクセスのアルゴリズムを刷新することで２倍以上のスループットを達成したこともあります。それらの改善は継続的で綿密な計画とハードウェアアーキテクチャの深い理解、そして集中的なベンチマーク等の実施による検証を経て製品に反映されます。
そのような変更は、ほとんどが旧製品に簡単にバックポート（パッチの形で）できるものではありません。
ストレージも劇的に進化していくことでしょう。
５年前にはHCI（ハイパーコンバージドインフラストラクチャ）などの普及は予想できていませんでした。
今後も新しい概念に基づく新しいハードウェアインフラが形成されていくことでしょう。
コンテナ技術やクラウド技術もどんどん変化していくに違いありません。
気が付けば、回りのIT環境はすっかり置き換わっていることでしょう。
そこで旧来のままのソフトウェアがそのまま問題なく動く可能性もゼロではありませんが、何らか問題が発生してもおかしくありません。
こういう状況に対する最善の対処は最新のIRIS環境でアプリケーションを動かす。ということになります。
繰り返しになりますが、できるだけ早期にIRISへの移行をお勧め致します。
前回は IRIS の非互換性について若干強調しすぎたきらいがありますが、実際には移行に関してほとんど変更の必要のないアプリケーションもたくさんあることと思います。
是非今すぐにでもお手持ちのアプリケーションを IRIS 上にインストールして動作確認してみてはいかがでしょうか？
前回記事「InterSystems IRIS 誕生の背景 ―データを制すものはビジネスを制す」は
こちらをご覧ください。
