「キャパシティ」と「スケーラビリティ」
「キャパシティ」と「スケーラビリティ」という言葉があります。
どちらもIT用語としてよく使われます。
「キャパシティ」についてはご存知の方も多いかと思いますが、「スケーラビリティ」については「キャパシティ」ほどではないようです。
以下に、ざっくりとした定義を示します。
キャパシティ:
「このやり方で、どこまで仕事をこなせるだろうか」という量的な限界のことを指します。
スケーラビリティ:
「このやり方の延長で、どこまで仕事をこなせるだろうか」という応用範囲の限界のことを指します。
微妙にニュアンスが違います。
「キャパシティ」は「このやり方で」。
つまり、「現状の限界点」を指しています。
「スケーラビリティ」は「このやり方の延長で」。
つまり、「将来の成長や変化に対応する能力」を指しています。
たとえばエクセルには1,048,576行の行があります。
100万レコードくらいのデータはいちおう格納できます。
ですが、「携帯電話ユーザの位置情報を時系列で大量に集めました。データ量は1,000万件です」というような「ビッグデータ」の扱いには向いていません。
1,000万件のデータを10枚のエクセルシートに分割すればいちおうデータを格納できますが、それでは集計等の作業を行うときに不便です。そのくらいであれば複雑な関数を組めばなんとかなりますが、ピボットテーブルのような対象が「ひとつの表」であることを前提とした集計機能などはもう使えません。
エクセル自体、データ量が多くなるとひとつひとつの動作の実行が重たくなるという問題もあります。
エクセルVBA(マクロ)を使えばいちおう処理はできますが、エクセルVBA自体かなり動作が重たいプログラミング言語ですので、ひとつひとつの処理にかなりの時間がかかります。
とある会社から「◯万件のCSVデータから条件にあうものを読み込むことが多いのだが、その都度40秒くらいかかる」という相談を受けたことがあります。
これでは担当のスタッフはたまらないでしょう。
求めているものがすぐに画面に表示されないというストレスはかなりのものです。
これが、業務上の要望が「複数のビッグデータをマッチングしてくれ」というものになったとしたらもう絶望的でしょう。
エクセルはあきらめてPythonを使うとなると、話は変わります。
Pythonのデータ分析用のライブラリ「Pandas」を使えば、1,000万行程度のデータなら、エクセルの場合の10分の1もかからない時間で読み込むことができます。「ひとつの表」として扱えるので、データの数が10行だったとき、100行だったときに行っていた作業をそのままストレスなく実行できます。
複数の大量データ間のマッチングのようなことも、一瞬で実行できます。
もともと、「エクセル」というのは、100万行を超える量のデータを扱えるようには作られてはいないのです。
これがエクセルの「キャパシティ」であり、「スケーラビリティ的限界」だとも言えます。
一方、Pythonでは、「データの量」がこれらの限界を既定することはありません。
「スケーラビリティ」の視点なしに「キャパシティ」にばかり目がいってしまうと、「今の仕組みのまま、無理やりにでもなんとかしてしまおう」という方向に発想がいってしまいます。
たとえば、「エクセルでは100万行のデータなら読める」という点に意識が向いてしまうと、「1,000万件のデータだったらシート10枚に分割すればよいだろう」とか「それらのシート10枚から合計値を算出したいなら、ちょっと複雑だけど、関数を作り込もう」とか、そういう発想になってしまいます。
「スケーラビリティ」という言葉が頭にあるだけで、「1,000万件ならば力わざでなんとかなるかもしれない。でも、2,000万件になったらもうムリだな」というところに意識が向くようになります。
今回はエクセルとPythonというデータ分析ツールを比較しましたが、「スケーラビリティ」という考え方は、ITは分野だけでのものではありません。
たとえば、人事管理の手法は、対象が数名のとき、10名を超えるとき、30名を超えるときで変わってきます。
「データが増えてもエクセルでなんとかする」というのがムリなように、人事管理の手法にも根本的な変化を必要とするときがきます。
学習法でも同じです。
「このやり方で成果を出せる」という学習法があったとしても、その手法が通じるのはある特定の範囲までであって、そこから先に進むには根本的な変化を必要とする場合があります。
勉強法を変えることで著しい成果が出た例を紹介します。
「手書きで勉強する」ということのスケーラビリティ的限界を、システムを作ることによって克服した例です。
僕は、英検1級を持っています。
ある時期、かなりの質量をかけて英語の勉強をしていました。
大量の英単語を覚えるのに、最初は紙の単語カードをせっせと作って覚えていたのですが、「自分の周囲に手書きの単語カードが大量にある」という状況になってしまいました。
「この大量の単語カードを管理するなんて、ムリ。これでは、かえって、効果的に復習できない」と思った僕は、自分でプログラムを書いて、単語カードのように問題と回答を表示するアプリを自作しました。
成績管理機能を追加して、「次にどの問題を出題するべきか」というところの判断を自分の代わりにプログラムにやらせるようにもしました。
四択問題を出題するときには、毎回、選択肢の表示順序が変わるようにもしました。(そうでないと、「この問題の正解は3つ目の選択肢」という感じで問題を解くようになってしまうので、練習にならないなと感じました)
ほかにも、穴埋め問題を作る機能や、「特に重点的に練習したい問題」だけを選んで印刷する機能などを作りこみました。
その結果、難関と言われる英検1級の1次試験では、98点(122点満点、合格最低点82点)という圧倒的な好成績で合格できました。
どちらもIT用語としてよく使われます。
「キャパシティ」についてはご存知の方も多いかと思いますが、「スケーラビリティ」については「キャパシティ」ほどではないようです。
以下に、ざっくりとした定義を示します。
キャパシティ:
「このやり方で、どこまで仕事をこなせるだろうか」という量的な限界のことを指します。
スケーラビリティ:
「このやり方の延長で、どこまで仕事をこなせるだろうか」という応用範囲の限界のことを指します。
微妙にニュアンスが違います。
「キャパシティ」は「このやり方で」。
つまり、「現状の限界点」を指しています。
「スケーラビリティ」は「このやり方の延長で」。
つまり、「将来の成長や変化に対応する能力」を指しています。
たとえばエクセルには1,048,576行の行があります。
100万レコードくらいのデータはいちおう格納できます。
ですが、「携帯電話ユーザの位置情報を時系列で大量に集めました。データ量は1,000万件です」というような「ビッグデータ」の扱いには向いていません。
1,000万件のデータを10枚のエクセルシートに分割すればいちおうデータを格納できますが、それでは集計等の作業を行うときに不便です。そのくらいであれば複雑な関数を組めばなんとかなりますが、ピボットテーブルのような対象が「ひとつの表」であることを前提とした集計機能などはもう使えません。
エクセル自体、データ量が多くなるとひとつひとつの動作の実行が重たくなるという問題もあります。
エクセルVBA(マクロ)を使えばいちおう処理はできますが、エクセルVBA自体かなり動作が重たいプログラミング言語ですので、ひとつひとつの処理にかなりの時間がかかります。
とある会社から「◯万件のCSVデータから条件にあうものを読み込むことが多いのだが、その都度40秒くらいかかる」という相談を受けたことがあります。
これでは担当のスタッフはたまらないでしょう。
求めているものがすぐに画面に表示されないというストレスはかなりのものです。
これが、業務上の要望が「複数のビッグデータをマッチングしてくれ」というものになったとしたらもう絶望的でしょう。
エクセルはあきらめてPythonを使うとなると、話は変わります。
Pythonのデータ分析用のライブラリ「Pandas」を使えば、1,000万行程度のデータなら、エクセルの場合の10分の1もかからない時間で読み込むことができます。「ひとつの表」として扱えるので、データの数が10行だったとき、100行だったときに行っていた作業をそのままストレスなく実行できます。
複数の大量データ間のマッチングのようなことも、一瞬で実行できます。
もともと、「エクセル」というのは、100万行を超える量のデータを扱えるようには作られてはいないのです。
これがエクセルの「キャパシティ」であり、「スケーラビリティ的限界」だとも言えます。
一方、Pythonでは、「データの量」がこれらの限界を既定することはありません。
「スケーラビリティ」の視点なしに「キャパシティ」にばかり目がいってしまうと、「今の仕組みのまま、無理やりにでもなんとかしてしまおう」という方向に発想がいってしまいます。
たとえば、「エクセルでは100万行のデータなら読める」という点に意識が向いてしまうと、「1,000万件のデータだったらシート10枚に分割すればよいだろう」とか「それらのシート10枚から合計値を算出したいなら、ちょっと複雑だけど、関数を作り込もう」とか、そういう発想になってしまいます。
「スケーラビリティ」という言葉が頭にあるだけで、「1,000万件ならば力わざでなんとかなるかもしれない。でも、2,000万件になったらもうムリだな」というところに意識が向くようになります。
今回はエクセルとPythonというデータ分析ツールを比較しましたが、「スケーラビリティ」という考え方は、ITは分野だけでのものではありません。
たとえば、人事管理の手法は、対象が数名のとき、10名を超えるとき、30名を超えるときで変わってきます。
「データが増えてもエクセルでなんとかする」というのがムリなように、人事管理の手法にも根本的な変化を必要とするときがきます。
学習法でも同じです。
「このやり方で成果を出せる」という学習法があったとしても、その手法が通じるのはある特定の範囲までであって、そこから先に進むには根本的な変化を必要とする場合があります。
勉強法を変えることで著しい成果が出た例を紹介します。
「手書きで勉強する」ということのスケーラビリティ的限界を、システムを作ることによって克服した例です。
僕は、英検1級を持っています。
ある時期、かなりの質量をかけて英語の勉強をしていました。
大量の英単語を覚えるのに、最初は紙の単語カードをせっせと作って覚えていたのですが、「自分の周囲に手書きの単語カードが大量にある」という状況になってしまいました。
「この大量の単語カードを管理するなんて、ムリ。これでは、かえって、効果的に復習できない」と思った僕は、自分でプログラムを書いて、単語カードのように問題と回答を表示するアプリを自作しました。
成績管理機能を追加して、「次にどの問題を出題するべきか」というところの判断を自分の代わりにプログラムにやらせるようにもしました。
四択問題を出題するときには、毎回、選択肢の表示順序が変わるようにもしました。(そうでないと、「この問題の正解は3つ目の選択肢」という感じで問題を解くようになってしまうので、練習にならないなと感じました)
ほかにも、穴埋め問題を作る機能や、「特に重点的に練習したい問題」だけを選んで印刷する機能などを作りこみました。
その結果、難関と言われる英検1級の1次試験では、98点(122点満点、合格最低点82点)という圧倒的な好成績で合格できました。
- スケーラビリティを超えたまま過剰な努力をくりかえしていることは身近にありますか。
あるとしたら、その根本的な限界はどこにあるのでしょうか。
2024年11月20日 21:41
小川 慶一さん
2024年11月20日 21:28
AIユーザさん
2024年11月14日 17:04
小川 慶一さん
2024年11月13日 18:12
AIユーザさん
2024年11月13日 18:11
田中 宏明さん