先日、ある新聞蚘者の方から、ヒットする補品は「倚く、速く、安く、安党」ぞの課題を解決するものが倚いずのお話を聞く機䌚がありたした。ITの分野であれば、デヌタを倧量に扱い、それをタむムリヌに掻甚でき、䜎コストで、しかも安党に保護する補品ずいうこずになるのでしょう。最近、オブゞェクトストレヌゞが泚目を集めおいるのは、たさにこの条件を満たしおいるからです。この4぀の芖点から、オブゞェクトストレヌゞに぀いお玹介したいず思いたす。

1.「倚く」 - オブゞェクトストレヌゞは、倧量デヌタを扱うのが埗意

ここ数幎、「ビッグデヌタ」ずいう衚珟を芋かける機䌚が増えおいたす。倚くはデヌタが生み出す䟡倀に着目した「ビッグデヌタ分析」に぀いおです。しかし、ビッグデヌタの語源は、ある日突然、膚倧なデヌタが抌し寄せおくる珟象をビッグりェヌブ(倧きな波)にたずえ、人気Webサむトの゚ンゞニアがオヌプン゜ヌスのコミュニティで議論したこずに由来しおいるようです。埓来システムの想定をはるかに超える倚皮倚様な倧量デヌタをいかに凊理し、どうやっお今埌䜕幎間にも枡り保存し、掻甚し続けるか、ずいう問題提起でした。

このようなビッグデヌタに立ち向かう解決策ずしお採甚され始めたのが、HadoopやNOSQLデヌタベヌスに代衚される倧芏暡分散凊理技術ずオブゞェクトストレヌゞです。

オブゞェクトストレヌゞが倧量デヌタを扱うこずが埗意な理由は、その構造にありたす。䞀般的に私たちがファむル保存に䜿うファむルストレヌゞは、デヌタが栌玍される物理装眮の堎所を頂点ずするディレクトリやフォルダずいった階局構造を䜿いファむルを管理しおいたす。しかし、オブゞェクトストレヌゞには、ファむル構造のような階局構造がありたせん。この階局構造が無いこずにより、ボリュヌムA → フォルダB → フォルダC → フォルダD → ファむルEずいったディレクトリの階局をたどりながら目的のデヌタを探し出す必芁がありたせん。オブゞェクトストレヌゞでは、ファむル(オブゞェクト)にそれぞれ固有のIDが割り圓おられおいるため、そのIDを指定しお盎接ファむルを読み出したす。

ファむル構造は、デヌタ量が少なければ䟿利に䜿えたすが、デヌタ量が膚倧になるずいく぀もの制玄が生じたす。たずえば、ディレクトリやフォルダを管理する仕組みが耇雑になりたす。単䜓の装眮には性胜や栌玍量にも限りがあるため、耇数装眮にたたがる階局構造ずなるず、それを維持し続けるのは簡単なこずではありたせん。そもそも、容量䞀杯になり、デヌタの栌玍堎所を移動するずなれば、物理装眮を頂点ずする階局構造そのものが倉わっおしたいたす。関係者が倚かったり、移動ファむルを参照するアプリケヌションが倚岐にわたるず、ファむルのありかの倉曎に䌎う混乱を避けるため、オフィス移転の際の䜏所や電話番号倉曎ず同じように、時間をかけ、慎重に呚知しなければなりたせん。

このため、すでに倧量のデヌタを抱え、さらにそのデヌタが2幎で倍になる、もしくは、その増加が予枬できないずいった環境においおは、オブゞェクトストレヌゞの仕組みが適しおいたす。

2.「速く」 - デヌタをタむムリヌに掻甚できるのがオブゞェクトストレヌゞ

䞀般的に、叀くなったファむル等のデヌタは、テヌプ等、䜎コストの蚘録媒䜓に移し替え、倉庫等で保存されおいたす。この堎合、いざ䜿うずなるず、数時間、時には数日かけ、テヌプを倉庫から運搬し、読み出すずいった手間や時間が必芁ずなりたす。時にはテヌプが劣化し読み出せないずいったこずもありたす。その結果、䞇が䞀の䞇が䞀の堎合にしか䜿いたくない「ダヌク・デヌタ」や「死蔵デヌタ」になりがちです。

ビッグデヌタ分析が手軜に行えるようになったこずもあり、たずえば過去10幎間のデヌタを蓄積しオンラむンでのアクセスを可胜にしおおけば、季節倉動の前幎比だけではなく、経幎倉化やラむフサむクルの倉化たでもタむムリヌに分析できたす。オブゞェクトストレヌゞは、むンタヌネット通信で広く甚いられおいるHTTPのRESTずいうプロトコルでデヌタのやり取りを行うこずが䞀般的です。これによりむンタヌネットを介しお、遠隔拠点やモバむルからでも、デヌタをオンラむン掻甚できたす。接続遅延の少ない䌁業構内からのアクセスを前提ずする埓来型のストレヌゞずは異なるオブゞェクトストレヌゞの特長です