Francisco Reyes ?????:
>On Thu, 18 Mar 2004, Anton Nikiforov wrote:
>
>
>
>>But i'm worry about mentioned centeral database that should store 240
>>millions of records daily and should collect this data for years.
>>
>>
>
>I have not worked with anything even remotely so big.
>A few thougths..
>I think this is more of a hardware issue than a PostgreSQL issue. I think
>a good disk subsystem will be a must. Last time I was looking for my ex
>employer at large disk subsystems I think the one we were leaning towards
>was an IBM disk subsystem. I think it was in the $100,000 range.
>
>Regardless of architecture (ie PC, SUN, etc..) SMP may be of help if you
>have concurrent users. Lots and lots of memory will help too.
>
>
>
>>And the data migration problem is still an opened issue for me - how to
>>make data migration from fast devices (RAID ARRAY) to slower devices (MO
>>Library or something like this) still having access to this data?
>>
>>
>
>Don't follow you there. You mean backup?
>You can make a pg_dump of the data while the DB is running and then back
>that up.
>
>Or were you talking about something else like storing different data in
>different media speeds? (Like Hierarchical Storage Management)
>
>
I do not exactly know how to deal wth such a huge amount of data. The disk subsytem is the must and i do undrstand
this.SMP architecture is the must also.
I was asking is there any way that data will migrate from fast disk subsystem to slower but relyible automaticaly. Like
inNivell Netware (i used to work with it 7-8 years ago) you could ask the system if the file is untached for a month -
thenmove it from one disk to magnetic-optical or tape but if this file is requested OS could move it back to the
operationalvolume.
Anton
