「#未来のためにできること」に応募してみました⑥本物のSustainability先行者は、そもそも同じ周回上にいない？
以下の投稿についてのプロダクション・ノート的まとめ。
なお、冒頭に登場する会社は特定されても困るので複数の案件をそれぞれ微妙に改変しつつ混ぜ合わせてあります。もし万が一、ピッタリ条件の合う企業が存在したとしても、それこそ私の関知するところではないので悪しからず。そもそも、あの種の扉のセキュリティ・ログは1日分だけでもとんでもない分量になるので、それこそ人工知能技術かCognitive Computingの援用でもなければ迂闊に近付けないというのが正直な所な様です。それでも緊急事態で調べざるを得なくなって地獄を見た話も聞いた事があります。
こちらの画像もまた、適当にデッチ上げたもの。そういうものだと適当に読み流してくださいませ。
三田村鳶魚辺りが「江戸時代には岡っ引きがあえてまだ物心もつかない丁稚を検挙して締め上げ、有る事無い事自白させる事、という俗説があった」と書いてた様な…当時の岡っ引きにはそういうタイプの破落戸(ごろつき)も混じっていて、それでしばしば禁止令が出た模様。
ぶっちゃけ実在と非実在の境界線をあえて曖昧にする事で新たな価値観を産み出そうとする「もくりこくりの領域」の話という訳ですね。
そして昨今の自然言語検索ブームの前史にもpowersetなる「もくりこくり」が登場。それ自体は「史上最長のベーパーウェア」ザナドゥ(Xanado)計画同様、まだ全てが神秘のベールに包まれたままだったりするという…
そもそもSAP HANAとは何？
本文中では全く触れられませんでしたが「一切HDDにアクセスせず、メモリ上のみで完結するカラム型データベース」という怪物。SQLも受け付ける一方で非構造データも簡単に扱え「既存のRDBMSの処理が重過ぎるのでNoSQLが開発された経緯は一体何だったのか？」という話になってきます。
SAP HANAは、SAP社が開発したインメモリデータベースであり、データ処理速度の向上とリアルタイム分析を可能にする点で特徴的です。以下にその主な特徴を簡潔に説明します。
SAP HANAの主な特徴
インメモリ技術:
データを従来のディスクベースのストレージではなく、主にメモリ上に保持することで、高速なデータ処理とリアルタイム分析を実現しています。これにより、従来のデータベースに比べて数百倍のパフォーマンス向上が可能です。
統合データプラットフォーム:
トランザクション処理（OLTP）と分析処理（OLAP）を単一のプラットフォームで行える「ハイブリッドアーキテクチャ」を採用しています。これにより、データの複製や移行が不要で、効率的なデータ管理が可能になります。
カラムストア:
データを列ごとに格納する「カラムストア」方式を採用しており、特に集計やフィルタリングなどのクエリにおいて優れたパフォーマンスを発揮します。
リアルタイム処理:
大量のデータをリアルタイムで分析し、ビジネスインテリジェンスや意思決定のスピードを劇的に向上させます。これにより、ビジネスプロセスの最適化や即時対応が可能です。
マルチモデルデータ管理:
SAP HANAは、リレーショナルデータ、グラフデータ、文書データなど、様々なデータモデルをサポートし、異なるデータタイプを統一的に管理できます。
スケーラビリティ:
小規模から大規模なデータセットまで、スケーラブルに対応可能で、オンプレミスからクラウド環境まで幅広いインフラに対応しています。
まとめ
SAP HANAは、そのインメモリ技術と統合データプラットフォームにより、企業のリアルタイムデータ処理を大幅に改善し、迅速な意思決定をサポートします。多様なデータ管理能力とスケーラビリティも特徴であり、現代のビジネスニーズに対応する強力なツールです。
NoSQLという言葉は1998年に『カルロ・ストロッツィ氏』の著書で提唱されたことにより生まれました。当時は「SQLインタフェースを持たないリレーショナル型データベース管理システム（RDBMS）」に向けて用いられておりました。一見ネガティブなワードにも捉えられることから（SQLは不要という解釈）問題へと発展し、「Not only SQL」と解釈しようと『エリック・エバンス氏』が唱えたことでその解釈が一般的なものとなりました。
NoSQLデータベースは、従来のリレーショナルデータベース（RDBMS）とは異なるアプローチを採用し、特に大量のデータを扱う現代のアプリケーションに適したスケーラビリティや柔軟性を提供します。以下にNoSQLの歴史を簡潔にまとめます。
1. 初期の背景と誕生（2000年代初頭）
背景: 2000年代初頭、インターネットの急速な普及とともに、データ量が爆発的に増加しました。従来のリレーショナルデータベース（RDBMS）は、大規模で多様なデータを効率的に扱うのが難しくなり、スケーラビリティの限界が露呈しました。
誕生: これに対応するため、分散システムの概念を取り入れたデータベースが開発され始めました。「NoSQL」という用語は、2009年にエリック・エヴァンスが用いて広まりましたが、その技術的基盤は2000年代初期から始まっています。
2. 主要なNoSQLデータベースの登場（2000年代中盤）
2004年: Google Bigtableが発表されました。これは、分散ストレージシステムで、Googleのインフラを支える基盤技術の一つです。
2006年: Amazon Dynamoが登場し、Amazonのショッピングカートシステムなどで使用されました。これは、キーと値のペアを持つデータストアの一種で、分散データベースの一例です。
2007年: Apache CassandraがFacebookで開発され、オープンソースとして公開されました。これは、分散型で高い可用性とスケーラビリティを提供するNoSQLデータベースです。
2009年: MongoDBが登場しました。これは、ドキュメント指向のデータベースで、JSONライクなドキュメントを柔軟に扱えるため、Webアプリケーションの開発に広く採用されました。
3. NoSQLの普及と進化（2010年代 - 現在）
普及: 2010年代には、クラウドコンピューティングの普及に伴い、NoSQLデータベースがさらに広く採用されました。特にビッグデータ、リアルタイムデータ処理、IoT（Internet of Things）などの分野でその重要性が増しました。
多様化: NoSQLデータベースは、用途に応じて様々なタイプに分かれました。主な種類として、キー・バリュー型（Redis、DynamoDB）、ドキュメント型（MongoDB、CouchDB）、カラム指向型（Cassandra、HBase）、グラフ型（Neo4j）が存在します。それぞれ、異なるデータモデルと処理特性を持っています。
統合とハイブリッド化: 近年、NoSQLと従来のRDBMSの利点を統合するハイブリッドデータベースも登場しており、ユーザーのニーズに応じた柔軟なデータ管理が可能になっています。
まとめ
NoSQLデータベースは、インターネットの発展に伴うデータ量の増加や多様化に対応するために登場し、2000年代から急速に進化しました。現在では、スケーラビリティ、柔軟性、パフォーマンスの観点から、ビッグデータやリアルタイムアプリケーションで広く採用されています。
HANAと同時期に開発されたMeta(旧Facebook)のCassandraやPowerset社のHbaseといったカラム志向DB。
元はFacebook社(現Meta)において大規模データの格納のために開発されたものである。2008年7月にCassandraをオープンソースソフトウェアとして公開され、2009年3月からApache Incubatorプロジェクトとなり、2010年2月にはトップレベルプロジェクトに引き上げられた。2015年にApache Cassandra 2.2がリリースされJSONに対応。
Facebookのデータチームを率いるJeff HammerbacherはCassandraをAmazon DynamoDBのようなインフラストラクチャ上で動作するBigTableデータモデルであると表現している。
Amazon Web Servicesが提供するフルマネージドNoSQL（key-value/ドキュメント）データベースサービスである。Amazon CTOのWerner Vogelsが2012年1月18日に発表。当初はアメリカ東海岸のリージョンでのみ提供されていたが、2012年3月1日より東京リージョンでの提供が始まった。マネージド版のApache Cassandraと比較される。
他のAmazonのサービスとは異なり、データ量だけでなく、スループットに基づき購入する。自動的にデータとトラフィックをSSDを搭載した適切な数のサーバーに分散し、応答性を一定の速度に保つ。Amazon Elastic MapReduceを併用し、Hadoopと併用できる。
オープンソースの、列指向、分散データベースであり、GoogleのBigTableをモデルとし、Javaにより書かれている。Apacheソフトウェア財団のHadoopプロジェクトの一部として開発され、HDFS (Hadoop Distributed File System)の上で実行され、Hadoopに対しBigtableのような機能を提供する。
大元としてはPowerset社が自然言語処理を扱う上で必要とした大規模データ処理を行う為に開発着手。今はApacheのトップレベルプロジェクトであり、注目を集めている。
古典的なSQLデータベースを直接置き換えるものではないが、近年ではパフォーマンスが向上し、FacebookのMessaging Platformなど、データ駆動型のWebサイトでも使用されている。
アメリカ合衆国のシリコンバレーにあるIT企業であり、または会社が開発している検索エンジンのことである。
その検索エンジン自体はまだ公開されていないが、現在では日本語版も開発中である。また、Powerset Labsというサービスがクローズドベータ版で公開された。一部専門家は、この仕組みによる検索エンジンが未来のインターネットの世界の主流になるであろうと考えている。このため将来は、世界で一番のシェアを誇るGoogleをもしのぐ存在になりうるともいわれ 2008年7月マイクロソフトが買収発表した。（約1億＄）
大規模データの分散処理を支えるオープンソースのソフトウェアフレームワークであり、Javaで書かれている。Hadoopはアプリケーションが数千ノードおよびペタバイト級のデータを処理することを可能としている。
GoogleのMapReduceおよびGoogle File System(GFS)論文に触発されて開発が恥前り、2006年最世のバージョンが発表された。
Hadoopは、大規模なデータセットを分散処理するために設計されたフレームワークであり、その設計上、ビッグデータを扱う場合に最も効果的に機能します。以下に理由を簡潔に説明します。
1. 分散処理のオーバーヘッド
Hadoopは、データを複数のノードに分散して処理するため、分散処理に伴うオーバーヘッド（データの分割、ネットワーク通信、タスクの調整など）が発生します。このオーバーヘッドは、データセットが大きいほど相対的に小さくなり、Hadoopのスケーラビリティのメリットが発揮されます。
2. HDFSの特性
HadoopのファイルシステムであるHDFS（Hadoop Distributed File System）は、大規模データの格納と処理に最適化されています。小規模なデータでは、HDFSのブロック管理や冗長性機能が過剰となり、パフォーマンスが低下する可能性があります。
3. マップリデュースモデル
Hadoopの基本処理モデルであるマップリデュースは、膨大なデータを並列に処理するのに適しており、データが多いほど効率的に処理できます。小規模データでは、並列処理の利点が生かされず、かえって処理に時間がかかることがあります。
まとめ
Hadoopはビッグデータの処理に最適化されており、データセットが大規模であればあるほど、そのスケーラビリティと分散処理の利点を最大限に引き出せます。一方で、小規模なデータでは、分散処理に伴うオーバーヘッドが大きくなり、パフォーマンスが低下する傾向があります。
カラム志向DBの一種。Googleの大規模なサーバ上の大量のデータを管理するために設計された、データ圧縮機能を持つ高性能なNoSQL型のプロプライエタリのデータストレージシステムである。Googleが自社でデータベースを開発した理由はコスト、スケーラビリティ、パフォーマンス特性のより良いコントロールなどであるとされる。
2004年から開発が始まり、2006年には設計が論文として公開された。2015年5月6日にはパブリックバージョンのBigtableが、Google Cloud Platformのサービスの1つとして公開された。BigtableはGoogle Cloud Datastoreのバックエンドとしても利用されている。
Snowflakeわかっているようで実はよくわからんかったけど「GCP以外でもBQみたいなことができる」という嬉しみだったわけね Hadoop戦国時代を生き抜いてきた人は面構えが違うhttps://t.co/sJw5Qs4ehN pic.twitter.com/KDBtwyidMM
— Jun Naito / 内藤 純 (@njun_data) June 18, 2024
まぁ、なまじの業務システム経験者だと「日次/週次/月次処理における列単位での全件シーケンシャル・アクセス」とか「トランザクション処理における一貫性維持」のイメージが強過ぎて、まずもってそもそも「そういうのは比較的苦手なDB」という発想に辿り着けないとい代物。まぁ「比較的苦手(重い)」といっても全体速度が桁違いなので、工夫を凝らしてうまく誤魔化してしまう様です。
例えば、顧客の普通預金口座から当座預金口座に500ドルを移動させる典型的な銀行のトランザクションを考えて見る。このトランザクションは銀行側から見れば1つの操作であるが、コンピュータから見れば少なくとも2つの操作から構成される。普通預金口座から500ドルを引き落とし、当座預金口座に500ドルを入金するのである。引き落としが成功して入金が失敗した場合（あるいは逆の場合）、銀行の帳簿はその日の営業完了時点で不整合を生じる。したがって、2つの操作が両方成功するか、両方失敗することを保証する必要があり、それによって銀行のデータベースに不整合が生じないようにする。トランザクション処理はそのような保証をするよう設計されている。
なお、インテルが不揮発メモリーを開発したので停電によって全データが失われる心配もなくなりました。まさしく新時代に対応したデータベースという訳ですね。
不揮発メモリーの開発史は、データの持続性と保存技術の進化を示しています。以下にその歴史を簡潔にまとめます。
1. 初期の不揮発メモリー
磁気コアメモリー（1950年代）: 最初の実用的な不揮発メモリーは磁気コアメモリーでした。この技術は、磁化されたコアによってデータを保持し、電源が切れてもデータが失われないという特性を持っていました。1960年代まで、コンピュータの主要なメモリー技術として使われていました。
2. 半導体ベースの不揮発メモリー
ROM（Read-Only Memory, 1950年代後半）: ROMは、一度書き込まれたデータが電源を切っても保持される不揮発メモリーで、プログラムやデータの永続的な保存に使用されました。これは、プログラムやファームウェアの格納に重要でした。
EPROM（Erasable Programmable ROM, 1970年代）: EPROMは、紫外線でデータを消去し、再プログラムできるタイプのROMです。これにより、デバイスの再利用やアップデートが可能になりました。
3. フラッシュメモリーの登場
フラッシュメモリー（1980年代）: 東芝の舛岡富士雄博士が1980年代に開発したフラッシュメモリーは、不揮発メモリー技術の大きな進化です。フラッシュメモリーは、データの書き込みと消去が可能で、従来のEPROMに比べて高速かつ効率的です。これがUSBメモリ、SDカード、SSD（ソリッドステートドライブ）などのデバイスの基礎技術となりました。
4. 進化と多様化（2000年代以降）
SSDの普及: 2000年代には、フラッシュメモリーを使用したSSDが普及し、従来のHDD（ハードディスクドライブ）に比べて高速かつ耐久性が高いストレージとして広く使われるようになりました。
新しい不揮発メモリー技術: フラッシュメモリーに続いて、ReRAM（抵抗変化型メモリ）、MRAM（磁気抵抗メモリ）、PCM（相変化メモリ）など、新たな不揮発メモリー技術が登場しました。これらは、さらなる高速性、低消費電力、耐久性を目指して研究開発が進められています。
まとめ
不揮発メモリーは、磁気コアメモリーから始まり、半導体技術の進化とともにフラッシュメモリーやSSDなどの形で大きく発展してきました。現在では、より高性能な次世代メモリー技術が開発されており、データストレージのさらなる進化が期待されています
この様に俯瞰すれば全ての進化ベクトルが同じ方向を向いているのが丸わかりな訳ですが、まず人間がそれについて活発に論じないとネット上に有意味な分布意味論的空間が発生せず、人工知能が深層学習によって学ぶ事もないという限界が存在する訳ですね。
SAP創業者「イノベーションのジレンマ」を語る。
本文中の引用は以下より。
個人資産を使って、情報技術の研究を目的とした大学と大学院を作ったんだ。ここで、企業の論理に流されることなく、新技術の研究をじっくりと腰を据えてやることに決めた。
従来の発想にとらわれない、若くて情熱的な学生にあふれていた。彼らには、プレッシャーとなりそうなものを極力取り除いてあげた。「何か新しい発見をしろ」「採算が合うか」といった言葉は一切かけない。大学の近くに、気兼ねなく議論できるように家も借り上げた。
そんな中から、HANAの根幹をなす技術のアイデアが生まれた。SAP社内で開発していたら、間違いなくこの構想は途中で潰されていただろう。前例のない技術、採算が合うか不透明、おまけに開発者の実績はなし。絶対に話が進まなかったはずだ。
HANAはプロトタイプができるまで、できるだけSAPから遠ざけ、伏せておいた。結果的に製品として完成したのはSAP社内だが、その芽と情熱は社外から注入したものだ。インプラント型の改革と呼んでもいいかもしれない。
社外で開発することに加えて、イノベーションのジレンマを克服するもう一つのポイントは、製品の切り替えをいつ決断するかだと思う。
例えば、自動車業界を見ればそれがよく分かる。彼らが直面している課題は、ガソリン車の時代から電気自動車にどう移行するかだ。BMWなどガソリン車で築き上げた成功企業は、簡単には移行できないだろう。
もちろん、BMWだって電気自動車は開発済みだ。米テスラ・モーターズと同じ性能のクルマを作ることなど難しいことではない。問題は、新しい技術にいつ全面移行するかを決めるかだ。顧客にいつ、「5シリーズはもうガソリン車ではなくなります」と宣言するのか。BMWの消費者はあのガソリンエンジンの音を聞くためにBMWを買っている。それを変えるのは、とても大変な作業だ。
大切なのは、既存のマーケットで収益を稼ぎつつ、一方で新ビジネスに力を入れる必要があるということだ。イノベーションは決して博打にしては駄目で、常に継続的な収益のある中で考えなくてはならない。
遅れれば、命とりになる。ソニーのウォークマンが米アップルのiPodに、ノキアの携帯電話がiPhoneにとって代わられように、タイミングがずれれば会社自体の存亡に影響しかねない。自動車業界も、テスラが急成長している。
じゃあ、決断のタイミングはいつなのか？ 正直言って、それは私にも分からない。アートのようなものだ。
しかし、だからと言って、諦めることはできない。会社を永続させたいと考えるならば、常に準備をしておく必要がある。次の自分の競合は誰なのか、アンテナを張っておくべきだ。
やっと本当に聞きたかったSustainabilityの秘訣について聞けた気がします。
そんな感じで以下続報…