RE: Timesten Vs. Oracle - Performance
- From: "Orr, Steve" <sorr@xxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 26 Mar 2004 07:22:10 -0700
> I think an analogy I like better is F1 vs B-747.
> It probably works on a lot of different levels
Yeah, my V-8 SUV is environmentally friendly if you consider mpgpp,
miles per gallon per passenger.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Cary Millsap
Sent: Thursday, March 25, 2004 11:49 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Timesten Vs. Oracle - Performance
I marvel at the in-memory database vendors' messages, because many of
the performance-challenged user actions I see on Oracle databases ARE
operating entirely in memory. The reason they're slow is that they
perform too many accesses upon the buffer cache. This stuff about TB of
Oracle buffer cache making "Oracle tuning a thing of the past" is
absolute rubbish. See "Why you should focus on LIOs instead of PIOs" at
www.hotsos.com/e-library for details.
I don't see how the in-memory guys could be doing any better than a
reasonably well-optimized Oracle system, unless they're bypassing all
the "horrible serialization operations" that an Oracle instance
executes. Thing is, without those serialization operations, a system
can't provide, for example, read consistency or recoverability.
One aspect of the F1 vs Tank analogy that I really like is that a
Formula 1 car is a single-user automobile. I think an analogy I like
better is F1 vs B-747. It probably works on a lot of different levels:
multi-user-ness, procurement and operational maintenance cost, storage
capacity, range, ... :)
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey
- SQL Optimization 101: 3/29 Dallas, 4/19 Denver, 5/3 Boston, 5/24 San
Diego
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
Sent: Friday, March 26, 2004 12:36 AM
To: oracle-l@xxxxxxxxxxxxx; LazyDBA.com Discussion
Subject: RE: Timesten Vs. Oracle - Performance
It's a bit like comparing the performance of a Formula 1 to the
performance of a tank. In-memory databases, in general, will vastly
outperform databases that rely on writing to disk, much like the Formula
1 car will vastly outperform traditional databases like Oracle on a
smooth track. An in-memory database generally requires that you have
enough RAM to hold the entire database and does not have anywhere near
the guarantees of durability (the D in ACID) that a traditional database
does. Tanks are built to withstand a lot more for a lot longer than a
Formula 1 car is.
If you have a small, read-only or read-mostly database where you can
afford to lose updates, an in-memory database is probably ideal.
Otherwise, stick with the traditional database.
Justin Cave
Distributed Database Consulting, Inc. http://www.ddbcinc.com/askDDBC
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of VIVEK_SHARMA
Sent: Thursday, March 25, 2004 11:05 PM
To: oracle-l@xxxxxxxxxxxxx; LazyDBA.com Discussion
Subject: Timesten Vs. Oracle - Performance
How does timesten compare with Oracle Database in performance,
availability etc?
Timesten in-memory Database - a brief :-
The database system needs an inexpensive, plentiful memory, and the
dramatic increases in processor speeds relative to the modest increases
in disk drive performance.TimesTen produces software that brings
real-time database performance to applications. With TimesTen In-Memory
Database Technology,throughput is measured in tens of thousands of
operations per second, and response times are counted in microseconds.
Though internally unique, TimesTen's products are accessed through
standards-based interfaces, and designed for easy integration into
existing software infrastructures.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
