Subject | Re: [firebird-support] Re: FB database in RAM |
---|---|
Author | Kjell Rilbe |
Post date | 2011-08-12T19:35:52Z |
Den 2011-08-12 20:57 skrev karolbieniaszewski såhär:
data and metadata to find what the user is looking for. Sure, when the
complex query is constructed, it may actually execute very fast, but the
publish step also makes the query and search system simpler.
We're still waiting to see our hosting company's prices for a server
that has either an SSD-cache RAID controller or more than 16 Gbyte RAM.
I suppose those figures will tell us which ruote forward to follow.
I'm very grateful for all your valuable tips and ideas! Thanks guys!
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> --- In firebird-support@yahoogroups.comThis doesn't solve the issue of having to aggregate a lot of spread-out
> <mailto:firebird-support%40yahoogroups.com>, Kjell Rilbe
> <kjell.rilbe@...> wrote:
> >
> > Den 2011-08-12 14:50 skrev Leyne, Sean såhär:
> > > Kjell,
> > >
> > > > Den 2011-08-03 14:25 skrev Kjell Rilbe såhär:
> > > > > For performance reasons we're considering a setup where our 50+
> Gbyte
> > > > > Firebird database would reside on a RAM-disk.
> > > >
> > > > After the discussion here as well as a discussion between me and my
> > > > partner and after getting some info on the cost of a server with 60+
> > > Gbyte
> > > > RAM, we are now aiming at a solution where only the relevant
> parts of our
> > > > ~60 Gbyte database will be "published" to a separate and much smaller
> > > > database that will be structured and indexed for optimal search
> > > > performance. This smaller DB will be placed on SSD or RAM disk
> instead of
> > > > the huge one.
> > >
> > > Save yourself the "grief" of the whole separate database approach and
> > > simply go out and get a RAID controller which supports an SSD cache.
> > >
> > > The controller will do, internally, exactly what you are trying to do
> > > via "fancy" processes.
> >
> > Yes, but the structure of the data in the large database is not optimal
> > for searching, so we will probably want to publish it into a
> > search-tailored separate database anyway. Among other things, we have
> > data that we may not be allowed to publish, but this fact is not stored
> > directly into the search table, but about 5+ joins away... It's modeled
> > for data collection and data entry with full history and a lot of
> > metadata, not for searching.
data and metadata to find what the user is looking for. Sure, when the
complex query is constructed, it may actually execute very fast, but the
publish step also makes the query and search system simpler.
We're still waiting to see our hosting company's prices for a server
that has either an SSD-cache RAID controller or more than 16 Gbyte RAM.
I suppose those figures will tell us which ruote forward to follow.
I'm very grateful for all your valuable tips and ideas! Thanks guys!
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64