5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

おまいらどの位の巨大テーブルみたことある?

1 :NAME IS NULL:2010/09/04(土) 19:17:25 ID:???
行数:15億行(某社業務サブシステムマスター。
累積10年。分割は一回も無し。2000トランザクション/日)
項目数:350余り(某金融機関。行数は守秘義務につきご容赦)

とか

2 :NAME IS NULL:2010/09/04(土) 20:17:26 ID:???
千人ぐらい座れるテーブル

3 :NAME IS NULL:2010/09/04(土) 22:51:08 ID:???
60レコード

4 :NAME IS NULL:2010/09/08(水) 01:32:28 ID:???
項目数:1000以上。基本的に単一のテーブルで運用という理由から

5 :NAME IS NULL:2010/09/13(月) 21:28:47 ID:???
>>4
そういう運用って、いちいちサブテーブルをサブクエリで
selectして使うのか?テーブル数が増えた場合の更新順序管理とか
が大変だということは事実だけどちょっとな〜

6 :NAME IS NULL:2010/09/15(水) 23:22:31 ID:gAS6FoVB
レプリケーションとかダンプとかどうしてるの?

7 :NAME IS NULL:2010/09/17(金) 00:43:26 ID:???
accessでレコード参照が好きなうちの課長涙目なテーブルばっかぢゃねーかw

8 :NAME IS NULL:2010/09/17(金) 22:26:23 ID:???
ディスクミラーリングという荒技以外考えられない

9 :NAME IS NULL:2010/09/29(水) 10:41:22 ID:???
>>1
これでselectしたらどのくらいの速度で目的のデータを抽出出来るのかな?

10 :NAME IS NULL:2010/09/30(木) 10:45:56 ID:???
俺のところの会社もデータ漏洩事故のもととして
テーブル数増大を嫌う傾向がある。
だから100万行クラスのテーブルも絡むSQL夜間バッチが
午後7時開始で終了は朝6時。
プロセッサ8基、メモリ100G積んだ専用鯖がフル稼働しても
終わってないことが時たまある。
サブクエリのネストが非常に深いからだろうけど。
トランザクション運用なんて無理w
>>1だと単純Selectでも相当の時間がかかるんじゃないかな?

11 :NAME IS NULL:2010/09/30(木) 13:40:05 ID:???
>>10
100万行でもそんなに時間かかるんだな。

MySQLスレだったか、どこかで1億レコードぐらい余裕とかって話聞いたが、
どう考えても無理じゃねぇかw

12 :NAME IS NULL:2010/09/30(木) 23:38:35 ID:???
OLTPだったら1億レコードぐらい余裕だけど
バッチ処理はMySQLでやったらアカンよ

13 :NAME IS NULL:2010/10/01(金) 12:41:19 ID:???
>>10
テーブル数が少なければデータ漏洩事故が発生し難いという理論が理解不可能。

広い生簀に散らばっていた魚が、一箇所に集まってしまったようなもんだな。
盗人が網で一気に大量に掬い出すことが可能になるなw

どうせ元コボラーがテーブル設計してるってのがオチだろうけどな。
あと、列の名前も意味不明な記号になってるんだろ。

14 :NAME IS NULL:2010/10/01(金) 23:17:21 ID:???
>>13
テーブル数が多ければ、というよりも多くの非マスタテーブルは
マスタから情報を濃縮したものであることが多いので、流用され
やすく悪用もされやすいという論理じゃね?

15 :NAME IS NULL:2010/10/07(木) 13:36:34 ID:???
テーブル丸ごと更新でもしない限り、元のテーブルの大きさはさほど処理時間に影響を与えないような気がするが。
毎回フルに参照しなきゃいけないようなデータってなんだろう?
通信ログ系の処理で、毎日100万行追加とかそんな感じ?

それとも、どちらかと言うと、そもそもの設計が適性になされていないというか、そういう感じか?
上の「単一テーブルでの運用だから項目1000以上」なんてのがその最たるものなんだろうな。
こんなの運用してる奴は、毎日データ設計し直せたらとか夢想してたり、飯食べながら無意識にモデリングとか落書きしてそうだw

そういう意味でも古い業務基幹系のシステムは触りたくないなぁw

テーブル数と漏洩の関係で言うと、最近のデータ漏洩はデータ丸ごとぶっこ抜くケースがほとんどだから、なるべく細かく分散させてリレーション把握してないと
使い物にならないようにしたほうが良いよね。
俺の知っているところは顧客データも名前、電話番号、住所等は別で保持していてそれぞれ別の方式で暗号化、複合の方はフロントエンドだけで個々にやるので、
そのまま抜き出してもほぼ使い物にならないようにしてる。

16 :NAME IS NULL:2010/10/07(木) 13:45:43 ID:???
イオンクレジット、加盟店情報も分析

イオンクレジットサービスは大規模なデータベースを備えた新顧客情報管理システムを約25億円投資して導入する。
同社が持つクレジットカード会員の情報だけでなく、加盟店の売れ筋情報などを取り込んで顧客の動向を分析し、
販売促進活動の効率を高める。

新システムの名称は「ターゲットマーケティングシステム」。
データベースの規模は156テラ(テラは1兆)バイトと顧客情報管理システムとしては国内最大級という。


こんなのになると、SAS入ったりするから、もはやテーブルの大きさがとかどうでもいい話になるんだろうなw

17 :NAME IS NULL:2010/10/07(木) 20:29:04 ID:???
> SAS入ったりするから、もはやテーブルの大きさがとかどうでもいい話になるんだろうなw



18 :NAME IS NULL:2010/10/08(金) 11:02:26 ID:???
マスターから見れば断片だが、別の意味に解釈されて一人歩きされ
かねないサブテーブルが流出するのも相当問題あるだろうし。
場合によってはマスタ流出よりも怖いケースもある。
まぁ業務内容に依存する話で一般論は難しいかな。

19 :NAME IS NULL:2010/10/09(土) 12:34:41 ID:???
顧客情報程度ならいくらでも偽装(暗号化とはちょっとちがう)できるからどうとでもなるけど、
ログだの経理情報だの、技術情報だの、図面だの機密書類系は悩ましい。

6 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)