| Subject | Re: [firebird-support] Re: FB database in RAM |
|---|---|
| Author | Lester Caine |
| Post date | 2011-08-05T07:04:27Z |
Ann Harrison wrote:
One of the earlier bulk storage methods had static RAM backed by bubble memory.
The bubble memory was too slow to really use, but it supposedly could maintain
data using no power for donkeys years. The trick the controller used was to pull
the data to static RAM to use it, but had a battery backup that allowed it to
run a store cycle when requested, or when external power was lost.
Large sections of a database are only going to be read, so is there any way that
the heavy read/write pages could be maintained in 'RAM' while pulling the bulk
of the data from an SSD array? Yes there is potential for corrupt database, but
if the data is stable even that should be manageable? It's only the actively
changing data that needs to be protected?
My own data from sites is slowly growing and has 10+ years of history much of
which will never be read again, but needs to be available, so I've started
moving the historic stuff to a second database which is read only except for an
'archive' cycle perhaps once every 6 months. This can then take advantage of the
read only mode and in my case a USB stick works as the off-line storage. That
feels like the right way to develop things, but which might benefit from better
'cross database' facilities? With bulk data static on an SSD array, while the
active stuff is in memory?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
> The default state of a transaction on a transaction inventory page (TIP) isJust thinking laterally for the moment ...
> "Active", so a read-only transaction generates two writes, one on start-up
> when it updates the next transaction on the header page and one to change
> the state on the TIP to committed. The next transaction and next connection
> ids on the header page are going to grind holes in SSD cells unless they're
> intelligently distributed.
One of the earlier bulk storage methods had static RAM backed by bubble memory.
The bubble memory was too slow to really use, but it supposedly could maintain
data using no power for donkeys years. The trick the controller used was to pull
the data to static RAM to use it, but had a battery backup that allowed it to
run a store cycle when requested, or when external power was lost.
Large sections of a database are only going to be read, so is there any way that
the heavy read/write pages could be maintained in 'RAM' while pulling the bulk
of the data from an SSD array? Yes there is potential for corrupt database, but
if the data is stable even that should be manageable? It's only the actively
changing data that needs to be protected?
My own data from sites is slowly growing and has 10+ years of history much of
which will never be read again, but needs to be available, so I've started
moving the historic stuff to a second database which is read only except for an
'archive' cycle perhaps once every 6 months. This can then take advantage of the
read only mode and in my case a USB stick works as the off-line storage. That
feels like the right way to develop things, but which might benefit from better
'cross database' facilities? With bulk data static on an SSD array, while the
active stuff is in memory?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php