|
Founded by embedded
database and real-time systems experts, McObject offers proven data management
technology that makes applications and devices smarter, more reliable and more
cost-effective to develop and maintain. McObject counts among its customers
industry leaders such BAE Systems, Siemens, Phillips, EADS, JVC, Tyco Thermal
Controls, F5 Networks, CA, Motorola and Boeing. McObject, based in Issaquah, WA,
is committed to providing innovative technology and first-rate services to
customers and partners. The company can be reached at +1-425-888-8505, or visit
www.mcobject.com.. |
.... |
|
see also:-
McObject's paper - In-Memory
Database Systems: Myths & Facts |
| |
| . |
editor's comments:-
McObject is in the SSD
software market ecosystem and among other things markets in-memory database
systems for deployment in applications ranging from small footprint embedded
appliances upto Terabyte scalable in memory databases for high availability
enterprise servers.
This was once regarded as a specialist performance
driven market but since the advent of
DIMM wars
and the availability of terabyte tiered memory in DIMM sockets originally
designed for DRAM - the adoption of big memory software is trickling down to all
markets and will become mainstream. |
| . |
|
|
In November 2012
-
McObject
announced that it has run
benchmarks of its intrinsically
designed for in-memory database systems software - with transaction logging
enabled - on a number of different devices - and in particular
Fusion-io's ioDrive
SSDs. |
| . |
 |
| . |
selected SSD aricles
on StorageSearch.com
the SSD Heresies
SSD controllers & IP
Can you trust SSD specs?
this way to the petabyte
SSD
the
3 fastest PCIe SSDs list(s)
Surviving SSD
sudden power loss
what do
enterprise SSD users want?
Where are we now
with SSD software?
how fast can your SSD
run backwards?
The big market impact of
SSD dark matter
flash SSD
capacity - the iceberg syndrome
Adaptive R/W
flash care & DSP ECC for SSDs
Why size matters in
SSD controller architecture
Efficiency as internecine
SSD competitive advantage
7 SSD types are all you
need in the solid state datacenter |
| . |
 |
| . |
|
| |
.... |
|
|
| .... |
| in memory
database is even better with FIO's flash SSDs |
Editor:- November 19, 2012 - McObject today
announced that it has run
benchmarks of its (intrinsically
designed for) in-memory database systems software - with transaction logging
enabled - on a number of different devices - and in particular Fusion-io's ioDrive
SSDs.
Editor's comments:- In a paper published 3 years ago
- In-Memory Database Systems:
Myths & Facts - McObject said that fast flash SSDs used as the
storage hot spot for traditional database software could never get performance
as good as their own in-memory solution running in DRAM with legacy hard drive
array bulk storage - and various remarks in that paper sent out a strong
anti-SSD message which the company is in effect correcting today.
What
McObject is now saying - is that by using a fast low latency SSD for the "performance
draining" transaction log - you can get even greater speedups. There
are other benefits too - which arise from the efficiency of their small
footprint database - which means that a software product - which was originally
designed for the DRAM-HDD world - is a good fit in the flash SSD world too - if
you have the right scale of data and the right SSD.
...Later:-
McObject's Marketing Director Ted
Kenney emailed me to clarify a couple of points about their product
and my interpretation of their business thinking. Here's some of what he said.
I
would point out one thing about your blog post, just to clarify from McObjects
point of view.
You mention the Myths & Facts white paper, specifically where we
argue (Myth 3, I believe) that an IMDS will always be faster than an on-disk
DBMS that uses an SSD to store records.
Keep in mind that that
papers comparison does not touch on transaction logging. At least, transaction
logging is not mentioned; the assumption (our assumption, in writing it) is that
the comparison is between a pure IMDS (all data kept in main memory and nothing
stored to persistent media), and an on-disk DBMS that stores records on a SSD.
Our conclusion was that while the DBMS storing to SSD is likely faster than a
DBMS storing to HDD, it still cant touch the performance of a pure IMDS.
In contrast, our recent comparison (the subject of the press release I sent
you) is focused differently: it presumes that the user wants data durability and
recoverability. That rules out use of the pure IMDS (because RAM storage is
volatile), so we instead look at solutions that deliver
recoverability/durability, specifically an on-disk DBMS storing records to
persistent media vs. an IMDS with transaction logging (lets call that IMDS+TL).
Then for the IMDS+TL we measure performance using different storage devices:
HDD, SSD and ioDrive.
The result: an IMDS+TL storing its log on HDD beats the performance
of a DBMS storing records to HDD (by about 3x). If you then upgrade the
device on which the IMDS+TL stores its transaction log, the performance
difference (compared to DBMS+HDD) is even greater (as much as 15x when
using the ioDrive). But the recent round of testing did not look at the
pure IMDS performance. If it had, the pure IMDS would have beat the IMDS+TL
using any of the devices to store its transaction log.
We hadn't considered that our message in the earlier white paper was
anti-SSD or that we we're now correcting that message. Instead, wed say that the
earlier paper looked at a scenario in whichperformance is the highest goal
(the only goal mentioned, anyway) whereas the new tests focused on
performance, with durability/recoverability as an additional requirement.
Re your comment - It seems that a software product which was
originally designed for the DRAM-HDD world is a good fit in the flash SSD
world, too if you have the right scale of data and the right SSD. - Actually
eXtremeDB was designed for the DRAM world initially (in-memory only). When we
later added support for persistent storage (first with transaction logging,
later with optional persistent storage for selected record types) we were (and
still are) agnostic: eXtremeDB does not recognize or care about the type of
persistent media used.
Again thanks for taking the time to look
at our news and at our various statements vis-à-vis flash, storage and
performance. It sounds like you understand our technology and the issues
involved. I just wanted to point out that the white papers discussion, and this
recent press release, take slight different perspectives on what the
developer/end-user is trying to accomplish. | | |
| .. |
| .. |
| |
