Re: TimesTen and In Memory Databases.....

Times Ten is not magic - it enables a specific architecture to a specific problem. There is no magic 'go faster' software. There is good architecture design.

>
> Such as
>
> 1. You can easily get resource contention (CPU, memory, I/O) between
> oracle and TimesTen. This can hurt TimesTen performance (and Oracle
> performance). So we can get around alot of this by putting the
> TimesTen Databases on another Box. This is not a big issue in our case
> as we are in a Grid configuration situation but still its additional
> cost.

You are supposed to put it on another box. Why would you put it on the same box as the backend Oracle database - you could just give the resources to Oracle. Stick it on each box in your application tier. That's the whole point of it. It enables a multi tier data architecture

>
> 2.The TimesTen should run on the same machine as the application and
> be accessed using direct mode not client/server to maximise
> performance. This could be a problem but not in our case. This fact
> could force some upgrades to existing machinery in our case and the
> additional cost is a factor.

Right - link Times Ten into your application memory, then all SQL statements happens in the same memory segment as the application - very, very fast.

>
> I am more worried about issues with data table sizes. We have very
> large data tables. We are talking many millions of rows and hundreds
> of columns is very typical in a few of our temporary tables.

Only load the data you want to process into each Times Ten cache. Leave the rest of it sitting in the back end database. If you have lots of machines in the middle tier, load subsets of data to each. Think scale out.

>
> Anyone had experience using Times Ten with very large Data Tables?
>
> 3. Users must optimize the Times Ten Database besides the Oracle
> Database.
> Most likely not a problem but still a learning curve.

Two products, two learning curves. Neither are that difficult.

>
> 4. No Procedure on the TimesTen Database at this point (release). This
> is a major issue, in my opinion, is there ways around this?

Not at the moment. But what do you need stored procedures to do in the application memory that you can't already do in the application code. The whole point about stored procedures in the database is that they are remote - the whole point of Times Ten is that the data is not remote, it's in the same memory space as the application.
>
> What can I expect for speed improvements, 5X , 10X, 100X with Times
> Ten?

10x ;-) But more importantly, millisecond response times for DML in your application for the data it is caching locally. Note that if you do not need millisecond DML, then you do not need Times Ten

>
> I understand the advantage of moving things into memory and avoiding
> some of the I/O issues. Would I be better off adding an additional
> processor or another rack then more memory instead of adding the
> complexity of another piece of Software and machinery. Or even the
> possibility of a data warehouse and update tables on X amount of
> time.

If your data is remote (i.e across the network) from your application, then you will never be able to remove the network latency from your transaction. If the network latency is a problem for the speed of your transaction, then use Times Ten and architect you application to remove the need for the network - there is little alternative, and this is exactly what TT is designed to do. If network latency isn't a problem in your transaction, then consider other approaches to making the back end database scale better, such as SQL Tuning etc. Note that if your application and database design doesn't scale, then adding more hardware to the back end server is just going to make it scale even less, faster.

>
> Opinions are welcome.
>
> Thanks,
> Chris
>
>
>
Received on Fri Mar 06 2009 - 21:23:30 CST