Sergio Martinez · Feb 12, 2019

Which is the benefit of using cachetemp to store temp globals? Is it possible to use them if we plan to use ECP?

Suppose we need to store millions of values temporarily, that means, we don't care about them if we lose them but our application use them to get realtime information. Should I use Cachetemp or whatever other DB without journaling enabled? If answer is Cachetemp, shouldn't be a problem if we decide to scale using App Server + ECP? I'm not sure what would happen with the app logic in such architecture as I guess I couldn't map and share cachetemp...

Any idea/suggestion?

0 657
Discussion (5)3
Log in or sign up to continue

You wouldn't share CACHETEMP, but you could easily create a database that is non-journaled that you can share across ECP application servers.

OK, so using CACHETEMP seems not an option if we need to scale through ECP. But, using other DBs instead, wouldn't impact in the performance? I mean, all the data would be stored on disk and will have to be synchronized through the net with the other APP servers.

If the data needs to be synchronized, it needs to live on the database server. If not, then you could improve performance by having it live locally on the application server(s). 

First, CACHETEMP doesn't maintain a Journal. (could be a minor advantage) .

Second, CACHETEMP follows a different storage strategy as it is kept in memory (global buffers) as long as affordable.
While for the other DBs data (global buffer blocks) get written to disk as soon as possible it is the opposite for CACHETEMP.

Third, CACHETEMP is common to all namespaces.

Forth, CACHETEMP is cleared at every restart and total empty after.
 I doubt that this could be useful in an ECP setup. 

Continuing Robert's list:

5) CACHETEMP is always local on APP servers (= ECP clients). As to our experience, it's very important feature, because it allows to keep processing of temporary data locally, without extra network and ECP server disk i/o workload. One of surprises of ECP I've got:  while it's relatively easy to achieve high speed of intra-ECP networking (as far as ~10Gbit/s hardware is available), ECP server disk i/o subsystem can easily become a bottleneck unless you accurately spread data processing among ECP clients.

6) Sergio, you wrote:

I mean, all the data would be stored on disk and will have to be synchronized through the net with the other APP servers.

If you really need to synchronize even temporary data, then simple horizontal scaling with ECP without some optimization of data processing  (see p.5) can be less cost-effective than comparable vertical scaling solution.