★★★ SQLサーバ VS オラクル ★★★
■ このスレッドは過去ログ倉庫に格納されています
00011
NGNGお前ら教えてください。
0587デフォルトの名無しさん
NGNGレスがつかないのでこっちで質問させてください
SQLなのですが
dump tableでテーブルのバックアップを取り、
load tableで復元しようとしたのですが
ﾒｯｾｰｼﾞ 8403、ﾚﾍﾞﾙ 16、状態 1
ﾃｰﾌﾞﾙ '〜〜' はｲﾝﾃﾞｯｸｽを二重に定義しています。
ﾃｰﾌﾞﾙ '〜〜' のﾛｰﾄﾞは中断されました。
というエラーがでてしまいます。
インデックスの削除もできないようでドツボにはまっています。
どうかテーブル単位で復元させる方法を教えてください。
よろしくお願いします。
0588デフォルトの名無しさん
NGNGODBCでSQLにつなげると通信は暗号化、圧縮されているのでしょうか。
おしえてください。
http://www.zdnet.co.jp/mobile/news/0108/08/fast.html
こういう商品があるところを見ると圧縮されていないようですが。
現在VBでADOを使いODBC経由でインターネット上のSQLServerにアクセスしてます。
0589デフォルトの名無しさん
NGNGあ〜、すみません。つぃ勘ぐっちゃって・・・(w
0590デフォルトの名無しさん
NGNGｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0591デフォルトの名無しさん
NGNGネットワーク パケット内のデータ
SQL Server では、クライアントとサーバーの間で送信されるデータを暗号化できます。
これにより、アプリケーションまたはユーザーがネットワーク上のデータ パケットを傍受しても、
機密データ (SQL Server のインスタンスへのログイン時にネットワークを介して送信するパスワードなど)
を表示することができなくなります。SQL Server では、Secure Sockets Layer (SSL) を使用して、
アプリケーション コンピュータと、SQL Server のインスタンスとの間でやり取りされるすべてのデータを
暗号化できます。
0592デフォルトの名無しさん
NGNG暗号はSQLに機能としてあるんですか。スマソ。
通信量の方が気になってたので見落としてました。
0593デフォルトの名無しさん
NGNGではございません。某中小ベンチャー超零細企業のとあるシステムを開発してます。
>>590
はい。インターネットに晒してます。セキュリティー気になりますが・・・・・・・・。
0594デフォルトの名無しさん
NGNG0595デフォルトの名無しさん
NGNG自分のことだね
0596デフォルトの名無しさん
NGNGちとDBの話題とはかけ離れてしまいますが、無法地帯の経路上は
IPSecやPPTP(って大丈夫か？)でVPNにしていないのですか？
アクセスポイント固定としている場合のことですけど。
0597デフォルトの名無しさん
NGNG取りあえずそれらの技術がどんなもんか理解して物言ってますか？
0598デフォルトの名無しさん
NGNGIPsecでVPNって、IPsecなPublicNetworkがあるのかと小一時間
0599デフォルトの名無しさん
NGNG0600デフォルトの名無しさん
NGNG自分のことだね
0601594=599
NGNG俺に悪意があれば、経路盗聴より直接鯖アッタクするし。
後さぁ、ＶＢ（ＡＤＯ−ＯＤＢＣ）の位置も解り難いし。
データの圧縮ってどの程度のデータやり取りするんだろ？
はぁ…
質問すら出来ない。
素の馬鹿って、見てて微笑ましいな。
0602デフォルトの名無しさん
NGNG自分のことだね
0603デフォルトの名無しさん
NGNGそうだね。
0604デフォルトの名無しさん
NGNG0605デフォルトの名無しさん
NGNG0606デフォルトの名無しさん
NGNG0607デフォルトの名無しさん
NGNG0608デフォルトの名無しさん
NGNG0609デフォルトの名無しさん
NGNG>>598 問い詰めちゃってください。つか芸(ヒネリ)が無いですね。
0610デフォルトの名無しさん
NGNGお前ら教えてください。
0611デフォルトの名無しさん
NGNG煽りすら出来ない馬鹿って可哀想だな。
0612デフォルトの名無しさん
NGNG煽りがいの無いﾔｼにどうしろと？
0613デフォルトの名無しさん
NGNG「煽り」以外の手段を考えよ。
0614デフォルトの名無しさん
NGNG結局のところ、ＲＤＢＭＳを技術で判断するフェーズは終わったのかも知れん。
後は､政治、経済、夢、慣れ、情報、希望、そんなところで判断スレ。
0615588
NGNG俺にこんなことやらせる会社に文句言いたいんだけどさ、
素の馬鹿っていってるやつにさ、こっちの会社はいってセキュリティー関係の
対策とってもらいたいね。
はっきりいって納期短いのに、毎日サービス残業でさ、やってらんねーよ
君採用するようちの会社おいで。
まあそれ以前に言葉のつかいかた覚えろや
ほかのやつらも気分害してるみたいだぜ？
DB使ったシステムの開発はじめてだぜ？
セキュリティーも問題あるのに勉強するひますらないんだぜ？
鯖の直接攻撃？そりゃいくらでも方法あらーな
0616デフォルトの名無しさん
NGNG逆切れの見本だな。
まぁ馬鹿なりに、ちょっと進歩したからまじレスすると、
暗号化の事を本当に聞きたいの？
暗号化じゃなくて通信量の圧縮じゃねーの。だと邪推するが。
0617588
NGNG>質問の仕方を覚えてから、言葉使いを指摘しろ。ばーーーーーか。
> 逆切れの見本だな。
>
> まぁ馬鹿なりに、ちょっと進歩したからまじレスすると、
> 暗号化の事を本当に聞きたいの？
> 暗号化じゃなくて通信量の圧縮じゃねーの。だと邪推するが。
びびってんじゃねーぞ。
おたくまるだしだな？あ゛？
0618デフォルトの名無しさん
NGNGはぁ。まいいや。
本当の馬鹿を見た気がするな。
0620デフォルトの名無しさん
NGNGネットワーク関係だから、通信技術板でスレ立てれば。
またＩＰ晒したりしないようにね。
0621デフォルトの名無しさん
NGNG0622デフォルトの名無しさん
NGNGクライアント数とかグレードによって値段違うのはわかるけど
一番トータル的な機能、価格で。オラクルが馬鹿高いとは知ってるけど
他のに比べるとそんなに馬鹿たかいの？
postgresとかMySqlとかいわないでね。
0623デフォルトの名無しさん
NGNG0624デフォルトの名無しさん
NGNGOracleがいいよ
0625デフォルトの名無しさん
NGNG0626デフォルトの名無しさん
NGNGんで、クライアントツールはでべろっぱedition買うと。
0627デフォルトの名無しさん
NGNGトランザクションがありません。ロールバックできません。
ストアドプロシージャが記述できません。
でも仕事でやらされてるんです…。なんでも Oracle や SQL Server の
何十倍という速度でデータをロードすることができるんだそうで…。
Oracle Loader ってそんなに遅いんですか？ 最近では 一時的にインデックスを
オフにしてロードしてインデックスを張りなおすとかできるって聞きました。
SQL Server にも Bulk Insert という高速ロード方法があるとか聞きました。
Infomix RedBrick がロード最速なんてウソですよね？
どなたか、比較した方いませんかね。
RedBrick 捨てて、まともな DBMS 使いたいんですよぉ。
0628デフォルトの名無しさん
NGNGオラクルやＭＳＳＱＬより高速じゃないとつとまらないのか？そんな仕事ある？
それともクライアントがインフォミックス使えやっていってるの？
0629デフォルトの名無しさん
NGNGInfomix RedBrickはスタースキーマ理論に基づいていなかった？
もしそうならロードは遅くなったはず。データウェアーハウスに
特化したデータベースとして面白いとこもあるDBだけど。
６２７の業務がOLTPバリバリだったら上司が馬鹿なんで直ぐに逃
げ出せ、データウェアハウスの仕事だったら、めったに無い機会
なので真剣にやってみたら。
0630デフォルトの名無しさん
NGNGヤツが間違ってるのでは？ 速度を稼ぐためにそう言う実装もアリだよ。
サーチエンジン系なんてトランザクション要らないし。
で、私は RedBrick 知らないので何とも言えないけど、実は単にＤＢ
を no log モードで構築してるダケって事ないの？
0631627
NGNGOLTPは皆無のDWHです。データは夜間の一括ロードでのみ追加され、
Update文, Insert文, Delete文が流れることは一切ありません。
>>628 全国の店舗(500店舗)の売上明細データ(40万件)を夜間の4時間程度の
間にデータベースへ取り込まないとなりません。当初、Oracleを使っていた
らしいのですが、データロードに半日以上かかっていたということで、
RedBrickになったようです。
けど、Oracle も SQL Server も OLAP に力を入れてますよね。
ですから、現状ではかなりロードの手法も改善されているのではないかと思うのですが…。
DWHだったらトランザクション・ストアドなんて不要なのでは？
とお思いでしょうけど、実際やってみると明細データだけでは十分な
レスポンスが得られず、集計データを作成しています。
この集計データが問題で、
場所軸では 店舗別, 地域別, 県別。
時間軸では 時間帯別, 日別, 週別, 月別。
商品軸では 単品別, 小分類別, 中分類別, 大分類別。
これら各軸の粒度を任意に組み合わせた 3 x 3 x 4 = 36通りの集計データを作る…
のは困難なので、クライアント要望から必要な集計データを 10通りくらい作成しています。
OLAPでキューブを作成すれば、36通りの集計データを自動で作成できると思うのですが…
OLAPを使ったことがないので良くわかりません。
Oracle, SQL Server の OLAP でこのような業務をこなすことはできないでしょうか？
0632629
NGNG>レスポンスが得られず、集計データを作成しています。
これじゃ、RedBrick使う意味ないねぇ。一度、IBMの技術的サポートに
金積んで設計から見てもらったら？自分とこもInfomix時代に来て貰った
ことがある。（IBMに吸収されてやってくれなくなったかも。しかし、これ
やらんとこのDBは普及せんと思うが。）
0633627
NGNGということは分かっているつもりなんですが…。
2年分の明細データ件数は 4億件になっています。設計の見直しをしても、
4億件の生データのみで運用(集計データ不要)ができるとは思えないのですが…。
>>629さんのところでは、設計見直しでどの程度の効果がありましたか？
RedBrick自体が「事前計算ビュー」という仕組みを搭載して、
集計データの作成を薦めているようですし。
結局、生データからの自由な分析なんて理想論だったのではないかと思っています。
集計データを作らないといけないのであれば、OLAP が良さそう…。
OLAP経験者いましたら意見聞かせてくれませんか？
0634厨房２号 ◆OjTjK0LY
NGNGＯＬＡＰ、ＤＷＨ、ＲＤＢを少し誤解してるような気がする。
どんなやりかたしても、結局のところ４億件のデータを処理する
時間は必要な訳で…
統計処理（多変量解析や頻度分析）をやってるならともかく、足し算引き算レベル
ならＯＬＡＰとかの問題じゃなくて、泥臭いチューニングの問題じゃないかな？
0635627
NGNGでも、ユーザーが「8月のA店のスナック菓子の売上が見たい」と思ったときに
4億件をリアルタイムで集計するのは無理があると思うのです。
先輩がいろいろとインデックスやらチューニングしたそうなのですが、
実用できる速度にならず、集計データという道を歩んだようです。
OLAPキューブについて誤解しているようなので教えてください。
OLAPキューブというのは、各軸の組み合わせ結果を
事前集計して格納しておくものではないのでしょうか。
統計処理をやりたいとユーザーには言われていますが、
まだそこまでたどり着けていません。CRMや年代別売上傾向やバスケット分析…
到底リアルタイムで処理できるとは思えません。あぁ地獄だぁ。。
0636厨房２号 ◆OjTjK0LY
NGNGうーん。データ量ユーザニーズと君の問題意識が恐ろしくずれてる。
ＯＬＡＰって何？どう？何てレベルの人が困ってると言われても
そりゃ困るだろうなぁ。ユーザーはもっと困るだろうな。
そうとしか言えない。パソオタは死ねって感じかな（ｗ
0637デフォルトの名無しさん
NGNG0638629
NGNGいいのでまじレス）
636は言葉は悪いけど自分も同意見。技術サポート受けるとか以前の話
みたい。4億件のリアルタイム集計とか問題点書き出して上司と相談して
みたら？あと、ひまだったらMSがSQLサーバの技術資料として公開している
ものの中にOLAPキューブの入門編があるので読んでみて。RedBrickについ
てはDBマガジンに以前、設計者へのインタビュー記事が載っていたのでこち
らも興味があったら。
0639627
NGNGユーザーニーズと私の問題意識のズレを指摘していただけませんか？
(自分では方向性の間違いに気づけずにいます。)
ユーザーは、任意の粒度でデータを抽出したいと言っていますが、
現状 良く使われるであろう視点で 10程度しか集計データをつくっておらず。
この集計データには、たとえば「月単位, 店単位, 単品単位」がありませんので、
ユーザーが「8月のA店のコカコーラ350mlの売上数量を見たい」と思った場合、
生データをリアルタイムで集計しなければなりません。
「月単位, 店単位, 中分類単位」であれば集計データからひっぱれるのですが…。
結局のところ、すべての組み合わせについて事前集計データが必要なのではないかと。
634さんのおっしゃる通り、「4億件のデータを処理する時間は必ず必要」なのですが、
要求時集計と事前集計ではレスポンスがまったく違うはずです。
それで、「すべての組み合わせについて事前集計」を満たすのが
OLAPキューブではないかと考えています。
CRM, 年代別売上傾向なども同様に,あるタイミング(月に一回とか)で
事前集計を行わないと不可能だと考えています。さらに、この処理は
OLAPキューブ作成のような単純な足し引きでは行えませんので、
ストアドプロシージャおよびトランザクションが必要だと感じています。
JavaやVBなどの外部プログラムからJDBCやADOでのアクセスできますが、
オーバーヘッドが大きく更新処理に利用できるようなものではありません。
正直なところ、OLAPという方向で進めようとは思っていて、
OLAPの使用経験などが聞けたらいいなぁ、と思って書き込みさせていただきました。
0640627
NGNG月ごとにデータベースを分けるということはできません
(アクセス時の切り替えがわずらわしくなるので)が、セグメントを分けて
別のディスクコントローラーにぶら下がるようにはしています。
>>638
SQL Server BooksOnline の OLAP に関する説明は読んでみました。
これを読んで OLAP にかなりの期待を持っています。
Oracle での OLAP経験者の話など聞けたら…。
余談ですが。この案件は以前、H社が受注してシステム構築を行ったことがあるもので、
ユーザー問い合わせから結果が出るまでに 20分から数時間かかるため、実用に絶えずボツになりました。
それで、なぜかうちで請け負うことになりました。一応、事前集計データから引っ張れるものであれば
3分程度でレスポンスを返すことができています。しかし、いま H社と同じ状況に立場におかれようとしています。
H社のハードウェアがどうなったのかは知りませんが、うちの営業曰く
「契約不履行によるリース解約で、ハードウェアを引き上げないといけなくなる」とか。
0641厨房２号 ◆OjTjK0LY
NGNG0642厨房２号 ◆OjTjK0LY
NGNG＞OLAPの使用経験などが聞けたらいいなぁ、と思って書き込みさせていただきました。
猿自爆。死ね。
0643厨房２号 ◆OjTjK0LY
NGNG技術的なことを聞きたかったら、先輩が頑張ったのにとか、
Ｈ社が失敗したなんてことは関係無いんだな。
先輩が施したチューニング内容とかが大切。
Ｈ社の失敗内容が大切。
ミドルウェアは銀の弾丸じゃないんだから。
君の質問レベルだと、マシン構成、予算も、比較検討材料になってくるし、
想定利用ユーザの数、１ユーザのデータ利用量、全部材料としてＵＰしなきゃ
答えようがない。
勘違いするなよ、そんなものＵＰされても適格なアドバイスにならんぞ、
君自身が問題点の切り分け出来てないし、理解してないから、アドバイス
受けたとしても鵜呑みが精一杯だろう。
結局またユーザを困らせる事になる。
ここまで言っても理解してないだろうな…
まぁＯＬＡＰだろうが、RedBrickだろうが､猿でも触る事は出来るんで、
また一つデスマーチが始まるんだろうなと思って俺は終わりにするよ。
0644627
NGNG貴重なコメントありがとうございます。
私の認識ですが…
・先輩ががんばったインデックスチューニングとは、
一般のRDBMS,OLTP業務で使われるものであり、DWHの理想論を実現できるものではない。
OracleやMSSQLでいかに効果的なインデックスチューニングを行っても,
テーブル全体の 1割程度以上のレコードを必要とする場合(オプティマイザの判断により)テーブルスキャンが行われますよね。
DWHで生データ処理でまかなおうとしたら、対象レコードが多く、ほとんどの場合テーブルスキャンが最善の策ということになります。
ですから、インデックスチューニングでなんとかなるという発想自体に無理があったのではないかと私は考えています。
ところが、>>634さんも足し引き程度ならチューニングの問題だとおっしゃっていましたので、
大量データの取り扱いが チューニングで改善された事例等あればお聞きしたかったわけです。
・H社の失敗は、DWHの理想論を引きずるあまり,
集計データの作成を怠ったことにあると思います。
>>632さんも、RedBrickで集計データを作成したら意味がない、とおっしゃっていましたが
実際のところ, パフォーマンスが出ないのです。IBM(Infomix)自体が
事前計算ビューによる集計データの作成を推奨していますし。
以上のことから、私は RedBrickというミドルウェアの限界を感じているわけです。
システムパフォーマンスということでは、おっしゃる通りハードウェアなどを含め
システム構成全体の情報が必要になるのですが…。
> 勘違いするなよ、そんなものＵＰされても適格なアドバイスにならんぞ、
> 君自身が問題点の切り分け出来てないし、理解してないから、アドバイス
> 受けたとしても鵜呑みが精一杯だろう。
勘違いするつもりもなくて,「○○な構成で遅くて困ってます。
どうしたら良いですか？」などと聞くつもりはありません。
私なりに OLAP に着目していて、「OLAPってどうですか？」と聞いているわけです。
また、Oracle, MSSQL で OLAPシステムを構築しようとした場合、データをロードする必要があるわけで、
一番はじめの「Oracle, MSSQL でのデータロードはいまだに遅いのでしょうか？」という質問になったわけです。
先輩は 40万件/日 のロードに 半日以上かかったと言っていましたから、これでは OLAP 以前の問題で
Oracle, MSSQL が採用できなくなってしまうわけです。
0645627
NGNGうちの会社には専任SE自体がおらず、みな実務者(SE兼PG)です。
デスマーチは避けたいと思っていますので、十分な工期は確保しようと思っています。
ちなみに CRM, 年代別統計などの案件はまだ受注していません。
いまの売上問合せ業務でも(レスポンスに関する)問題解決ができていないのに、
安請け合いすると、それこそデスマーチになりかねないですからね。
0646デフォルトの名無しさん
NGNG0647デフォルトの名無しさん
NGNG0649厨房２号 ◆OjTjK0LY
NGNG0650デフォルトの名無しさん
NGNGﾖﾑｷﾆﾅﾗﾝﾉﾀﾞﾖ
0651デフォルトの名無しさん
NGNG同意するです。
厨房２号ってしょせん（以下略
0652デフォルトの名無しさん
NGNGそうか？
初質板にいるような、回答者が質問し返して初めて重要な情報を
小出しにしてレスつける奴とさほど変わらんようにしか見えん・・・
0653629
NGNG>>632さんも、RedBrickで集計データを作成したら意味がない
別に集計データ否定したつもりでは無いのですが。。。。632で
書いた技術支援もInfomix Vistaによる集計データ管理の改善
だったもんで。
なんか意図が伝わっていないみたいだけど。。。。ただ、
Infomix Vistaの方を使い
Infomix Vista
0654629
NGNG0655デフォルトの名無しさん
NGNG質問者はピンポイントで必要な質問をしていたと思われ。
1)オラクルのロード遅いのけ？
2)レッドブリック遅いのでＯＬＡＰどう？
それに対して
「オラクルのロード速度が問題になる仕事なんてあるのか？」
「レッドブリックの使い方が悪いだけちゃうんか？」
「インデックスいじっとるんかいな？」
と的外れな質問ばかりだから質問の意図を説明しないといけなくなったんだろ。
0656655
NGNGオラクルで４０万件のロードに半日かかるってのはちょっと信じがたいな。
さまざまな要因でロード速度は変わるけど４０万件なら君の言う
夜間更新で処理できることが多いと思う。
ロード後に複雑な更新処理を行っているとかないのか？
0657627
NGNGこういった場所なら、技術面・機能面だけでなく事例などの話も聞けると
思ったのですが… なかなか事例を聞くことはできないようですね。
(Oracle, MSSQL使いの方々はやはりOLTPが多いのかな…？)
ちなみに、雑誌等の事例紹介はあまり信用しないほうがいいですよ。
今回の事例も雑誌では成功事例として紹介されていますし。
私もユーザーの担当者もシステムに満足していませんが、
会社の上役は双方ともなぜか満足しているようです。
0658デフォルトの名無しさん
NGNG0659デフォルトの名無しさん
NGNG１．クライアントから実行してる？
→ネットワークのトラフィック低減のためにDBサーバーと同じマシンで実行してみる。
（ただし、セキュリティ的に許されるならば）
２．従来型パスでなく、ダイレクトパスロードを試してみる。
→インデックスの重複チェックなどが省かれるため通常のに比べて早いが、もしデータの
整合性が取れていない時に面倒なことに。
４０万件のロードに半日ね。
初期化パラメータがデフォルトのままなら考えられなくもないが、今までの会話を見てると
それなりにやってそうだしな…。
0660デフォルトの名無しさん
NGNGデータ ウェアハウジングと OLAP
http://www.microsoft.com/japan/developer/library/olapdmad/agaboutolap_9i5s.htm
"データ ウェアハウジング" と "オンライン分析処理 (OLAP)" という用語は同じ意味で使用されることがありますが、
実際にはそれぞれ意志決定支援システムまたはビジネス インテリジェンス システムと呼ばれる異なったシステムの
コンポーネントを指す言葉です。この種のシステムは、データベースとアプリケーションにより構成され、組織における
アナリストの意志決定を支援するために必要なツールを提供します。
データ ウェアハウスとは、主に組織の業務履歴を表すデータが蓄積されるデータベースのことです。蓄積された業務
履歴データを分析することによって、戦略的計画の立案から組織別の実績評価に至るまで、さまざまなレベルで企業
の意志決定を支援します。データ ウェアハウスでは、オンライン トランザクション処理 (OLTP) システムのように、トラ
ンザクションをリアルタイムに調査することよりも、分析を支援することを目的にデータが編成されます。
OLAP とは、データ ウェアハウスを使用してオンライン分析の効率を高め、繰り返される複雑な分析クエリに迅速に応
答できるようにする技術です。OLAP では、マルチディメンション データ モデルとデータ集計テクニックにより、大量の
データを編成および集計します。これらのデータは、オンライン分析ツールとグラフィカル ツールを使用して迅速に評
価できます。アナリストが回答を求めたり、可能性を探ったりするため、業務履歴データに対してあるクエリを実行した
結果、さらなるクエリが必要になる場合もあります。OLAP システムは、分析の速さと柔軟性により、アナリストをリアル
タイムで支援します。
0661627
NGNGこの文章は以前に読んだことがありました。
(SQL Server BooksOnline にも収録されていますよね。)
マイクロソフト(SQL Server)の視点では、
DWHとは、単なる「業務履歴を表すデータ(生データ)が蓄積されたデータベース」であり、
OLAP層で「大量データの編成・集計」を行うと。SQL Serverでは、データベースエンジン自体は
OLTP用と同じものを使用して OLAPサービスを追加する形になっていたと思います。
ところが、Infomix(RedBrick)の視点では、
DWHとは、データベースとともに意思決定支援システムを構成するための機能も備えたもの
と捉えているようです。具体的には、DWH向けのSQL関数(ランク関数など)が豊富に用意されていたりします。
(まぁ、用意されている関数だけではどうにもならないので、ストアドが欲しいのですけどね)
InfomixにはOLAP層は用意されておらず、集計データの作成はビスタオプションを使って行うのですが、
これがOLAPと違い網羅的ではないので、非常に開発コスト・管理コストがかかります。
>>659
この案件を Oracle でやっていたときは私はからんでいないので詳細については分かりません。
さすがに「なんで半日もかかっていたんですか？ 設定とかちゃんとしていなかっただけじゃないんですか？」
なんてことを先輩に言えませんし。。
OracleからRedBrickへの載せ換えは社内ではかなり有名な赤字案件でした。
そのため社内では、「OracleではDWH(大量データのロード)はこなせない」という
レッテル？が貼られてしまっていて、反論・再評価しようとする人間はおりません。
(私もOracleのチューニングについてはほとんどわかりませんし…)
0662デフォルトの名無しさん
NGNG0663デフォルトの名無しさん
NGNG0664デフォルトの名無しさん
NGNG0665デフォルトの名無しさん
NGNG0666デフォルトの名無しさん
NGNG0667デフォルトの名無しさん
NGNG0668デフォルトの名無しさん
NGNG0669デフォルトの名無しさん
NGNG0670デフォルトの名無しさん
NGNG0671デフォルトの名無しさん
NGNG0672デフォルトの名無しさん
NGNG0673厨房２号 ◆OjTjK0LY
NGNG>これがOLAPと違い網羅的ではないので、非常に開発コスト・管理コストがかかります。
文学の世界でも印象批評ってのは、あんまり好まれないよ。
0674627
NGNG失礼しました。
たしかに、OLAPでシステムを構築したことのない私が、客観的評価資料も出さず
(OLAPに比べて)非常に開発コスト・管理コストがかかると表現するのは失礼ですね。
ただ、網羅的に集計データの作成を行い、その整合性をエンジニアがすべて管理する
というのは 擬似的にOLAPキューブ(のようなもの)を作るのと同じことだと思います。
同じことをするのであれば、それを実現できるミドルウェア(OLAP)を
使うほうが コストが低減できると判断したわけです。
(そもそも、OLAPと同等のものをゼロから実装できる(技術的な)自信なんてありませんけどね！)
実際、いまは管理が煩雑になりすぎるということで 集計データを 10程度に絞っていますから、
これを本当に全集計軸の組み合わせを網羅しようと思ったら…
どれだけの時間と人手が必要なになるのか… 考えただけでもゾッとします。
0675627
NGNG管理するよりも、データベースを使った方が 開発コスト・管理コストを大幅に抑えることができる。」
というのは、客観材料を出してはいませんが、多くのエンジニアに支持されていると思います。
同様に、
「すべての集計軸の組み合わせ結果を、アプリケーション独自実装で
無数の集計テーブルに格納するよりも、OLAPキューブを使ったほうが
大幅に開発コスト・管理コストを抑えることができる」と言えないでしょうか？
OLAPキューブ自体がそれを目的としていますから、余計にコストがかかるということは
考え難いのです。私の妄想なのかもしれませんが…。
0676デフォルトの名無しさん
NGNG知識もないくせに屁理屈ばかりでいちゃもんつけてるだけなんだからさ。
仕事でやってない割にOLAPの概要とか勉強してるみたいだし、
何人かがORACLEでも40万件ロードできそうだって言っているし、
ORACLEのロードテストとOLAPの評価してみるといいんじゃないか？
0677デフォルトの名無しさん
NGNGﾏｼﾞﾃﾞｳｻﾞｲｶﾗｻ
0678厨房２号 ◆OjTjK0LY
NGNG問題点の切り分け出来てる？
１、レスポンス（利用者運用時）
２、レスポンス（データ工逐時）
３、コスト削減（運用時）
４、コスト削減（ハード投資）
５、コスト削減（開発投資）
話がゴチャゴチャになっているよ。
>>676-677
うるせーーーーー
ばーか、ばーか、ばーか、糞、変態、キチガイ。
死ね、死ね､死ね､
0679627
NGNG申し訳ないです。書き込みではごちゃまぜに
なっているかもしれませんが、それなりに考えてはいます。
1.レスポンス(利用者運用時) → 改善のために集計データ必須と考えています。OLAP導入の主目的。
2.レスポンス(データ構築時) → 40万件のロードの可能性が出てきた。キューブ作成の時間については未検証。
3.コスト削減(運用時) → ミドルウェア(OLAP)で管理できるので削減できるようになると考えています。
4.コスト削減(ハード投資) → 特に何も考えていません。ユーザー要望で PCサーバしか選択できないのですが、
COMPAQの最上位IA-32サーバ Proliant を導入しています。より一層のハードウェア増強となると
ファイバチャネルくらいしか残っていませんし…。
5.OLAP同等機能をゼロスクラッチする技量はありませんので、そもそもコスト比較できません。
よって 有限コスト対無限コストで OLAPの方がコストが低いと(笑)
(何十人月かけても出来ないものはできないと考えています。)
0680デフォルトの名無しさん
NGNG一連の流れを見てたけど文字通り厨房で全然役に立つこと言ってないしな。
実際のところ、627のほうがこの辺の技術に詳しいんじゃねーの？
0681デフォルトの名無しさん
NGNGお前が話をゴチャゴチャにさせてるのでは？
頭悪いよ＞厨房２
0682デフォルトの名無しさん
NGNGうるせー。氏ねよカスが
0683デフォルトの名無しさん
NGNG0684デフォルトの名無しさん
NGNG0685デフォルトの名無しさん
NGNG0686デフォルトの名無しさん
NGNGRedBrickでできているならそれでいいんじゃない
「経験はないが」できそうに思うけど？
４０万追加だけなら６時間以上はかからないはず
10通り毎回４億件分処理は不要
（２年以上経過データ削除して集計後に追加分を加算すればよいだけ）
場所軸：店舗があれば他は１意に決定する
時間軸：時間帯があれば他は１意に決定する
商品軸：単品別（商品コード）が他は１意に決定する
なぜ６時間（半日）かかったかテーブル構成を知りたいです
627要約
データ保存期間２年
生データが２年分４億件
１日の追加件数４０万件 ：全国の店舗(500店舗)の売上明細データ(40万件)
集計データ
場所軸では 店舗別, 地域別, 県別。
時間軸では 時間帯別, 日別, 週別, 月別。
商品軸では 単品別, 小分類別, 中分類別, 大分類別
クライアント要望から必要な集計データを 10通りくらい作成
■ このスレッドは過去ログ倉庫に格納されています