Re: TimesTen and In Memory Databases.....
Date: Mon, 9 Mar 2009 15:16:05 -0700 (PDT)
Message-ID: <a3d5f4b9-bdbc-4991-8338-4056d2453c66_at_n33g2000pri.googlegroups.com>
On Mar 6, 11:23 pm, Mark Townsend <markbtowns..._at_sbcglobal.net> wrote:
> Solomon_Man wrote:
> > All,
> > I have been assigned to evaluate the TimesTen in memory database
> > software.
> > Please note I am not a DBA but I do have quite a bit of systems
> > knowledge.
>
> > From what I have seen I have not been that impressed based on the
> > price point and some of the issues I have read about.
>
> 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- Hide quoted text -
>
> - Show quoted text -
All,
First of all thanks for all the responses!
Secondly, I am in agreement with what Mark said about issues with remote data, tuning, and how TimesTen should be used. I am not going to lie and say our database is ultimately tuned. Like I said I am not a DBA, so my opinion is not really worth a grain of salt, but gut feeling tells me this is some of the problem and will be part of the final solution. Unfortunately we need to be able to scale further as we are really just getting started.
I will say that the systems I see in place will definetly support the decision to purchase an In Memory Cache Database System. The company has very decent web presence with very high traffic, all in house, not to mention a few external pieces of software that interact with those servers and other servers all by Oracle. External user interaction through one of the applications alone can be in hundred thousands per hour. Not the largest Oracle house I have work with but definetly decent size.
With this in mind we currently have a few in house DBAs and a few decent Oracle consultants. We had some very sharp DBAs but one guy took a big title jump and relocation at another company, another person jump ship after 25 yrs, and the recent recession has affected our normal IT/Systems/DBA staff. So to say the least we are very tight staff and due to the times tight on budget. Whether it makes a difference or not now, the systems from the ground up were all designed to perform under extremes with performance in mind. This included Oracle tuning and design on every project.
I just wanted to note that the stored procedure issue could be somewhat of a issue for us as a decent percentage of our Oracle form code leverages Stored Procedures as their datasource. I am sure this could be worked out in time but we are not talking 20-30 forms here so this is a concern with our current staff. Also there are many PLSQL jobs that are ran all through out the day and night which is one of the many reasons why we are looking at In Memory Cache Database System. The previous decision and architecture was all before my time at the company. :)
I am now looking for a general feeling on how implementations of TimesTen have gone. Also other options such as SolidDB from IBM.
I appreciate all the help,
Chris
Received on Mon Mar 09 2009 - 17:16:05 CDT