Content deleted Content added
Gilad.maayan (talk | contribs) No edit summary |
→Misleading first paragraph: new section |
||
Line 28:
I suggest adding [[Xeround]] to the list of in-memory databases. I believe it is sufficiently notable, see the entry for more details. [[User:Gilad.maayan|Gilad.maayan]] ([[User talk:Gilad.maayan|talk]]) 12:51, 9 October 2011 (UTC)
: Since there were no objections, I'm adding Xeround [[User:Gilad.maayan|Gilad.maayan]] ([[User talk:Gilad.maayan|talk]]) 10:40, 31 October 2011 (UTC)
== Misleading first paragraph ==
At present, says "Accessing data in memory reduces the I/O reading activity when querying the data which provides faster and more predictable performance than disk".
This is misleading because it describes any normal disk-oriented database system. It does not describe a particular feature of in-memory database systems.
Having this misleading statement in the opening paragraph leads me to suspect the reliability of the product table: how many of those products are just normal disk-oriented database systems which cache or pin data in memory?
Any normal disk-oriented database system caches data in memory, thus reducing I/O reading activity, providing faster and more predictable performance. Also, lots of normal disk-oriented database systems (such as MS SQL Server), provide for pinning particular tables in memory, providing faster & more predictable etc etc.
Most high transaction, low latency normal database systems will be run on hardware with sufficient memory to keep the whole database in memory.
In-memory database systems (unless it's just a misleading marketing term), are marked by the abscence of disk-oriented optimisations, disk-oriented OS calls, and disk-oriented durability. On some reports, this can give significant speed up of write actions in particular, when compared to a normal disk-oriented database operating completely in ram, backed by a database on RAM disk.
Data in memory is not a particular feature of IMMDB: it is misleading to suggest that it is.
| |||