
(最終回)オンプレミスRDBでのビッグデータの蓄積【データ圧縮編】
前回のおさらい 前回までに、ビッグデータ蓄積・利用時の課題の対応策として以下の方法を挙げ、インデックスチューニング、パーティション分割について記述しました。 インデックスチューニング パーティション分割 データ圧縮 今回は、最終回ということでデータ圧縮について記述していこうと思います。 データ圧縮とは データ圧縮は、データの余分な空白部を切り捨てたり、未使用のページを削除するなどでデータ量を削減す
カテゴリ

前回のおさらい 前回までに、ビッグデータ蓄積・利用時の課題の対応策として以下の方法を挙げ、インデックスチューニング、パーティション分割について記述しました。 インデックスチューニング パーティション分割 データ圧縮 今回は、最終回ということでデータ圧縮について記述していこうと思います。 データ圧縮とは データ圧縮は、データの余分な空白部を切り捨てたり、未使用のページを削除するなどでデータ量を削減す

前回のおさらい 前回は、ビッグデータ蓄積・利用時の課題を考え、以下の対応する方法を挙げました。 https://itport.cloud/?p=1130 インデックスチューニング パーティション分割 データ圧縮 上記に対応することで、ビッグデータを取扱う際の主にレスポンスを改善することに有効と考えました。 今回はデータパーティショニングについて記述していこうと思います。 データパーティショニングと

前回のおさらい 前回は、以下のような前提条件からデータ量(ヒープデータ量)を見積りました。 全国に10箇所の生産ライン工場を持つ 工場は24時間稼働 長期的(10~20年)にデータを蓄積 収集するセンサデータの生成頻度は1分とし、センサの数は3000個/1工場 上記の条件から、10年間蓄積時のヒープデータ量は9テラバイト程度となることが推定されました。 今回は9テラバイトのデータ量を蓄積した場合に

前回のおさらい(前提条件) 前回、検証を進めるにあたり、以下のような条件を想定しました。 製造業の企業 全国に10箇所の生産ライン工場を持つ 工場は24時間稼働 工場で稼働するセンサのデータを収集し、長期的(10~20年)にデータを蓄積し、効率的な稼動を分析するためにデータを利用したい 収集するセンサデータの生成頻度は1分とし、センサの数は3000個/1工場 データは非構造化データ 工場のシステム

はじめに 2010年代からビッグデータというキーワードがトレンド化し、様々な企業で大量なデータを蓄積し、ビジネスに活かす動きが活発化しました。 多量データの蓄積~分析・可視化においてクラウド利用が進む一方で、セキュリティに対する懸念等で日本企業はクラウド利用に抵抗を感じており(「Oracle Autonomous Data Warehouse Cloud(ADWC)の機能調査開始について」を参照)