数十メガバイトのファイルをどんどん格納できるDB

**1ｹﾞﾄ** · 05/01/24 17:04:41

なんてありますか？

**NAME IS NULL** · 05/01/24 18:08:30

シラネ

**NAME IS NULL** · 05/01/24 19:22:04

そんだけでかいデータとなると、
もう4th Dimensionしかねぇな。

他のDBじゃ目が回っちまうぜ

**NAME IS NULL** · 05/01/25 13:09:31

>>4th Dimension
これはやめとけ。つぶしが効かないし、DBファイルやインデックスがすぐ壊れて何度もツールを
かける羽目に陥る。

やるとしたら、ファイルを格納するのではなく、ファイルのパスを格納する仕組みにしたほうがいい。

**NAME IS NULL** · 05/01/25 13:17:36

>やるとしたら、ファイルを格納するのではなく、ファイルのパスを格納する仕組みにしたほうがいい。

これサイアク。
バックアップとかもやり難いし、検索もままならない。

**NAME IS NULL** · 05/01/25 13:19:28

4は仕組みでも何でも無くて、素人がいつも使う手。
さらにそのＤＢにＭＤＢが使われる場合多し。

4みたいなことするくらいなら氏んだ方が良い。

**NAME IS NULL** · 05/01/25 14:32:42

そこでFM7ですよ。8TBまでOK。

やったことはないがな。

**NAME IS NULL** · 05/01/25 17:32:49

凄い期待してググったらシンセがひっかかった。

冷静になって考えたら、
File Makeのこと？

そんなんただのアプリじゃん。

**NAME IS NULL** · 05/01/26 23:29:48

WindowsならNTFS

**NAME IS NULL** · 05/01/27 19:29:12

>>8
YAMAHA のやつか。<FM7
富士通のはひっかからなかった？

>>1
Oracle でいいんじゃないの？

**NAME IS NULL** · 05/01/28 10:49:26

今まで格納した一番大きいファイルのサイズとDB名を書くスレ

**NAME IS NULL** · 05/01/28 12:30:17

MF7=FileMaker Pro 7

**NAME IS NULL** · 05/01/31 18:42:22

FM-7
富士通の８ビットパソコン＾＾

**NAME IS NULL** · 05/02/01 00:55:41

>>1 がBLOBっちゅう単語を知っているかどうかがポイントなのだが

**NAME IS NULL** · 05/02/01 01:49:41

あーあ、言っちゃった

**NAME IS NULL** · 05/02/01 01:59:57

>>1
Oracle

Longhornの宣伝文句だったWinFSとほぼ同じ事が出来るぞ。

**NAME IS NULL** · 05/02/01 09:46:17

逆に言うと、Oracle以外じゃ無理？

**NAME IS NULL** · 05/02/01 10:53:37

>>14
Blog？

**NAME IS NULL** · 05/02/01 11:10:39

>>17
blob使えるとか64bit化されてるDBならそんなこともないだろ。

**NAME IS NULL** · 05/02/01 11:48:46

でもDBに直接ファイル突っ込むのって、
ファイルに大量アクセスある案件とかだと使えなくないか？
DBのコネクション数がめちゃめちゃ増えそう。

**NAME IS NULL** · 05/02/01 11:54:56

ファイル書き込みは一瞬で終わらないんだから、
これに対してロールバックが大量に行われたらｶﾞｸﾌﾞﾙ

**NAME IS NULL** · 05/02/01 16:16:53

>>20
そこでキャッシュですよ。

**NAME IS NULL** · 05/02/01 16:19:17

>>22
cache'だっけか？
詳しく教えれ。

**NAME IS NULL** · 05/02/01 21:54:21

>>21
BLOB周りは研究してないから細かくはわからんけど、IBやFBなら履歴型アーキテクチャ
のおかげで性能面ではロールバックが大量に発生してもあまり問題なさそうだけどね。
フラグメントは必要になるだろうけど、ほっとけば一応自動でもやるし。

**NAME IS NULL** · 05/02/02 09:01:08

じゃ、FBにちょっとDelなんかでポトペタ画面足せば、
あっという間に動画ファイルサーバー？？？

**NAME IS NULL** · 05/02/02 13:47:15

FBなら問題無いんかもしれないけど、
今までふつーに安定してたRDBのファイルに、
バイナリどんどん入れるって違和感無い？

26 · 05/02/02 16:06:36

自己レスだが、RDBファイルを別にして、別RDBファイルにｶｷｺとﾖﾐﾀﾞｼをやってくれるファイルサーバーアプリを建てる、
という案はどうでつか？

**NAME IS NULL** · 05/02/02 17:07:24

単発質問の糞スレかと思ったら、中身はまともだなｗ

**NAME IS NULL** · 05/02/02 17:24:29

28=糞ス∪∩レ

**NAME IS NULL** · 05/02/04 08:42:17

ＤＢをファイルサーバーにするアプリ転がって無い？
NTFSがSQL鯖と一体になったような香具師。

**NAME IS NULL** · 05/02/04 09:08:54

test

**NAME IS NULL** · 05/02/04 09:54:35

>>30
Oracle iFS

**NAME IS NULL** · 05/02/04 10:00:42

ｻﾝｸｽ,ｱｯﾀﾝﾀﾞﾈ>>32
ｲｸﾗ?

**NAME IS NULL** · 05/02/04 10:03:53

>>33
機材まで含めたら1000万くらい。

**NAME IS NULL** · 05/02/04 10:35:57

>>34
日本円になおすとどれぐらい？

**NAME IS NULL** · 05/02/04 10:41:38

>>34
オプソ版iFSとDEﾙPCの組み合わせで20ﾏｿまで価格落ちまつか？

**NAME IS NULL** · 05/02/04 10:54:47

>>35
平均 \10,000,000
最安　\6,000,000 <- うちが今まで納品した中では最安
>>36
MicrosoftがLonghornでSQLServerと1個のHDD使ってパクリ製品を出そうとしているが
現状のHDDが遅すぎて頓挫報道が大量に出るくらい無理。

ｵﾌﾟｿであるか知らんがあればOracle代を節約できるだろうが、実用的な速度を出すには
機材には最低でもHDD(10000rpm以上)が8本以上のﾃﾞｨｽｸｱﾚｲが必要だと思う。
つまり現状だと安く実現しようにもソフトよりハードが追いついてこない。

**NAME IS NULL** · 05/02/04 11:12:55

>>37
>実用的な速度を出すには
あ、これってインターネット経由でローカルディスク並みに性能が出る製品？
データ＝ファイルが壊れない、壊れても復旧できる製品であれば、性能は要らない。

だからといって、M$のパク利新製品は信頼性ｶﾞｸﾌﾞﾙだし、そんなに激安でも無い。

**NAME IS NULL** · 05/02/04 11:15:58

性能要らないと書いたけど、格納ファイル数が何万何十万と増えても性能が劣化しないものが欲しいでつ。

**NAME IS NULL** · 05/02/04 11:23:08

少し昔に流行った、オンラインストレージサービスみたいな奴は、
どんなのを使ってたのかねぇ。

**NAME IS NULL** · 05/02/04 11:25:28

>>40
これから流行るんだと思うけど。
無料メールサービスでも鯖ｲﾊﾟｰｲ立ててたよ。
申し込み時期で鯖名変わってた。

**NAME IS NULL** · 05/02/04 12:26:52

>>40
下のようなの作ったことある。
ユーザー - アクセスサーバー2台(httpd) - アロケーションサーバー2台(database) - 大量のNFSサーバー

**NAME IS NULL** · 05/02/04 13:07:28

>>42
その構成のメリットは？
ユーザーから見ると１つに見えるのは良いね。
NFS鯖単位でﾊﾞｯｸｱｯﾌﾟできそうだけど、散在してて管理し難そうな。

**NAME IS NULL** · 05/02/04 14:10:13

>>43
NFSサーバー群が一つの巨大ディレクトリに見える。

**NAME IS NULL** · 05/02/04 14:16:41

>>43
アプリケーション側からNFS鯖群が一つの巨大ディレクトリに見える。
つまりアロケーション鯖でNFS鯖群で出来てしまう大量のディレクトリをRAID0のごとく１本化。

**NAME IS NULL** · 05/02/04 14:33:39

巨大ディレクトリには良いんだろうけど、DBによるデータ管理に比べると雑いな。

**NAME IS NULL** · 05/02/05 12:47:28

>>45
その用途なら間のDB抜いてNFSv4のpsude file systemだけで行けそう。
といってもpsude file systemをまともにサポートしてる実装が
あるかどうかは知らんけど…

**NAME IS NULL** · 05/02/07 08:49:24

フォルダのまんまじゃなくてアーカイブ1個で管理しやすくて、かつora以外が良いなー。
oraでも良いんだけど、\10,000,000 はきつくなーぃ？

**NAME IS NULL** · 05/02/08 08:40:23

これから文書サーバーとかこういう用途が増えそうじゃない？

**NAME IS NULL** · 05/02/09 04:56:22

>>47
それ以前に、NFSは…。

　　　　　NFSv2 NFSv3 NFSv4
Linux 　　△　　　×　　　×
*BSD 　 .○　　　○　　　△
Solaris 　○　　　○　　　○

Linuxに至っては未だにv2ですら一部変な動作するし、v3は同名を使った変な独自仕様で
他のUNIX環境と混ぜると中途半端に動きやがるし。
*BSD系はSUNからのソース提供を元に移植しているようで互換性は良いが如何せん常に
対応が少々遅れ気味だし。
結局の所、まともに実装しているのはSolarisくらいしかない罠。

**NAME IS NULL** · 05/02/09 08:40:55

NFSってただのネットワークドライブ割当なんじゃないの？

**NAME IS NULL** · 05/02/09 23:44:09

>>30
psqlfsとかは違う？

**NAME IS NULL** · 05/02/10 09:15:15

>>52
イメージ的にはそれなんだけど、それって情報無いけど、、、完成してんの？

**NAME IS NULL** · 05/02/10 16:19:57

>>52
WinFSみたいだね。
膨大なファイル数だったとしても、実態をアーカイブに纏めてくれるのかな。

**NAME IS NULL** · 05/02/10 20:52:33

>>1
ftp

52 · 05/02/10 22:07:44

最近登場したばかりだからまだ完成していないと思う。

WinFSが登場する前にLinuxでpsqlfsとかが安定して動作してくるとかなり面白いことになりそう。
テストできるマシンが手に入ったらためしてみます。

**NAME IS NULL** · 05/02/12 11:05:50

WinFSってOODBでセッションもガンガン保存するのかと思ってた

**NAME IS NULL** · 05/02/12 21:48:20

>>57
今までの発表内容からすると
・SQLServerにファイルを突っ込み、バージョン管理もする。
・あらゆるファイルの実体やメタデータを全文検索用にインデックス化し、要約表示。

psqlfs+subversion+namazuあたりをゴッチャにしたような感じかと。

**NAME IS NULL** · 05/02/14 00:42:44

>>58
なんとしてもディレクトリをLinuxから触られたくないって気持ちが手に取るようにわかるね。（ｗ

**NAME IS NULL** · 05/02/14 08:49:14

>>59
WinFSが目指すところとか、開発が遅れてる理由はそれだったのか（驚愕
確かに普通に作るんだったら開発自体無問題の筈だし。

60ｹﾞﾄ

**NAME IS NULL** · 05/02/15 04:16:28

>>60
WinFSが目指すモノ・掲げているモノは現状のOracle製品で全て出来る訳ですが、
遅れている理由は個人向けハードウェア(特にHDD)の性能が全くと言っていいほど
追いつかないからでしょう。

**NAME IS NULL** · 05/02/15 04:51:49

エクスプローラ含めアプリが用意できてないんじゃないかな。

**NAME IS NULL** · 05/02/15 08:43:08

>>61
とにかくﾎﾞﾗｸﾙは嫌だ

**NAME IS NULL** · 05/02/20 22:29:21

>>63
Oracleのボッタクリ価格以上の値を付けているハードウェアと同性能のPCが
30万程度で買えるようになったら、オープンソースコミュニティも活発化するでしょう。

**NAME IS NULL** · 05/02/23 06:09:17

昔、光ディスクのストレージ(MOジューク)をBLOB領域として使っちゃうシステムで開発やってたけど、
性能うんぬんよりも、MOメディアが途中で死にまくって
「おにいちゃん、BLOBにアクセスできないよぉ」
な状態になってアレだった。

**NAME IS NULL** · 05/02/23 08:34:14

で、そのシステムはどうなったわけ？

**NAME IS NULL** · 05/02/27 00:19:55

>>65
ん ?

光ディスク上に DB 作成したってこと ?

自分はアフォですって公言してるようなもんだと思うが。

**NAME IS NULL** · 05/02/28 10:33:01

んー。
昔ジョブスはそういうワークステーションを馬鹿高い値段で販売してたな。
印刷大手の会社で大量に見かけて一体...と思ったことあるが。

**NAME IS NULL** · 05/03/02 08:05:25

>>68
白黒ディスプレイのヤツ？

**NAME IS NULL** · 05/03/03 22:57:41

NeXTのことか?
あれはリムーバブルメディアとしてMOを採用してただけだよ。
普通にHDも載せてた。

ありゃ画面のレンダリングがDisplay PostScriptだったから
印刷業界には重宝されたんでないかな。
設計思想はずば抜けていたが、時代とハードが追い付いてなかった例。

**NAME IS NULL** · 05/03/04 17:14:19

最初はHDDなしだったよ。

65 · 05/03/05 05:27:59

>自分はアフォですって公言してるようなもんだと思うが。

いやいや、なにせ昔の話でさ、今考えるとアフォな話なんだけどさ、
なにせ、容量が容量だったんでRAIDで組むと値段が高いし、
収めるデータは参照の方が多いし、スピードよりも長期保存重視だし、
ハードウェアベンダーもサポートしまっせ、って話だったんで、
んじゃ、やるか、っつー話になったんだ。
(ちなみにMOジューク本体に収める予定だったデータが1TBぐらい、
そのMOに入ってる1TBの管理用の情報が数GB～数十GBぐらい)

結局ね、運用してみたら最初はまぁなんとか動いていたんだけどね。
最後の方はエラいことになったね。
なんせメディアだけじゃなくて、MOジューク本体が壊れまくって、
毎週ハードウェア保守でDBサーバ止めてたよ。

**NAME IS NULL** · 05/03/07 13:55:30

他に類似事例は無いの？

**NAME IS NULL** · 05/03/07 22:12:30

>>72
> (ちなみにMOジューク本体に収める予定だったデータが1TBぐらい、

ほう、MO で 1TB か...、ハードの型名書いてくれよ。

**NAME IS NULL** · 05/03/08 11:26:50

>>74
MOジュークって書いてあるやん。阿呆やなぁ…

**NAME IS NULL** · 05/03/08 16:38:13

1TBのジュークって何枚ぐらい積めるん？

**NAME IS NULL** · 05/03/09 08:46:38

つまりタイトルのシステムを作るのに、
MOジュークはダメでつ、
という結論ですね。

**NAME IS NULL** · 2005/06/22(水) 10:56:52

RDBに逝れてもおｋ？

**NAME IS NULL** · 2005/11/10(木) 00:42:39

？

**NAME IS NULL** · 2005/11/10(木) 00:43:00

#&9829

**NAME IS NULL** · 2006/05/05(金) 05:17:30

http://page11.auctions.yahoo.co.jp/jp/auction/n35806257

**NAME IS NULL** · 2007/05/16(水) 10:26:25

解決策は？

**NAME IS NULL** · 2007/05/17(木) 01:43:26

結局Oracleしかない

数年前と結論が同じとは進歩のねぇ分野だな

**NAME IS NULL** · 2007/05/17(木) 09:08:27

Ora以外のDBじゃだめなの？

**NAME IS NULL** · 2007/05/29(火) 08:55:09

比較的安くて、ファイルをストアーする製品とか無いですか？
かつ、信頼性があって、破壊されても復旧メソッドもあるやし。

**NAME IS NULL** · 2007/07/30(月) 14:46:31

で、みんなどうするよ？

一角 · 2007/09/08(土) 12:43:54

　　＿＿＿＿＿　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　／:＼.＿＿＿＿＼　／　 http://idol.bbspink.com/test/read.cgi/pub/1188877827/l50
　|:￣＼(∩( ;ﾟ∀ﾟ)　＜　　　やーんなにこれーやーんなにこれーーーーーーーーー！
　|:　　 |:￣￣￣∪:|　　＼　ヤーンやーんやーんなにこれーナニコレーぇぇぇぇぇ！！
　　　　　　　　　　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿

**NAME IS NULL** · 2007/09/08(土) 21:53:54

そんな用途にOracleと言うかRDB使うやつはいない。
そんなんうｐロダを自前の鯖で稼動させるだけで十分だろ。

信頼性とか復旧とか心配するなら、二重化しとけ。

**NAME IS NULL** · 2007/09/10(月) 09:09:13

＞うｐロダ

この中の人は何でできてんだ？

**NAME IS NULL** · 2007/09/10(月) 09:34:57

大抵は原始的なCSVまたはその派生テキストだろ
ファイルの中身検索する必要ないならせいぜいファイルのリストをRDBに突っ込むくらいで十分だよね

**NAME IS NULL** · 2007/09/10(月) 20:08:22

検索とか集計とかしないのに、ファイルをドカドカ入れるだけの目的で
RDB使うバカはいないだろうな。

**NAME IS NULL** · 2007/09/11(火) 08:46:30

じゃ、何使うわけ？

素でファイルをハードディスクに入れるのはキチガイだお。
一番ハードが壊れやすい。

**NAME IS NULL** · 2007/09/11(火) 09:09:50

>>92

**NAME IS NULL** · 2007/09/11(火) 21:26:11

とりあえず>>92がキチガイってのはわかった。

**NAME IS NULL** · 2007/09/12(水) 10:32:10

キチガイ言うものがキチガイ。

**NAME IS NULL** · 2007/09/12(水) 21:50:44

つまり>>95が害基地って事か

**NAME IS NULL** · 2007/09/15(土) 22:02:39

>>95の言うことを信じるならそういうことになる。

**NAME IS NULL** · 2007/10/15(月) 13:24:03

ttp://www.akibablog.net/archives/2007/10/hdd-1tb-071012.html

時代はテラバイトなのに、RDBのBLOBにファイル入れたら遅すぎるお＞＜

**bayyqUcn** · 2007/11/12(月) 13:36:53

rxa6Gn <a href="http://jtxgqectgvce.com/";>jtxgqectgvce</a>, [url=http://ebssxqhybwqs.com/]ebssxqhybwqs[/url], [link=http://ggazdosqunca.com/]ggazdosqunca[/link], http://fdeweitvkymx.com/

**NAME IS NULL** · 2007/11/12(月) 20:47:45

真面目な話、フェッチのコストでコネクションプールを食いつぶすハメにならない？
BLOBってシリアライズデータを保管したりするのが関の山じゃない？