|WikiProject Computing||(Rated C-class)|
|WikiProject Databases / Computer science||(Rated C-class, High-importance)|
"Main memory" or "in memory"
I think the title of this article is mistaken. The expression "in-memory database" is much more popular than "main memory database". As evidence, I cite Google News and Yahoo News. Both of them return 5 or 6 hits for "in-memory", but none for "main memory". Moreover, the popular Computer Desktop Encyclopedia (www.computerlanguage.com) titles its article "in-memory database". Any objections to changing the title of this article? Westwind273 23:34, 24 August 2007 (UTC)
|This section or list is incomplete. Please help to improve it, or discuss the issue on the talk page.|
The article does not describe how the database system collect its user data from startup. And I think that is one of the main questions regarding this technology. Could some one write a few words on sentences about that? — Preceding unsigned comment added by Linbenming (talk • contribs) 06:51, 28 April 2011 (UTC)
Nokia-Siemens Networks “One-NDS”
Deleted from the list of in-memory database systems because this is a vertical solution (Home Location Register/Home Subscriber Server) rather than a database system. We should stick to database systems in order to preserve the integrity of the page. —Preceding unsigned comment added by Jatujak (talk • contribs) 04:19, 15 February 2010 (UTC)
So that this section does not become crowded, add only notable products that appear in reliable secondary sources (see Wikipedia guidelines for notability). The removed items are below - please reply here to discuss adding these back:
- Ancelus (commercial product)
- ERDB Entity Related Database (commercial product)
- EffiProz (commercial and open source)
- eXtremeDB (including hybrid eXtremeDB Fusion)
- FastDB (open source)
- ITTIA DB (including hybrid)
- DayDaLaboo (API based in-memory database from TurboData Laboratories, Japan )
Suggest Adding Xeround
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.
Couchbase and hybrid on-disk/in-memory databases
- Couchbase is well suited for applications that want most of its active dataset in memory. This data that is actively used at any given point in time is called the Working Set. It is very important that you allocate enough memory for the entire Working Set to live in memory. When there is not enough memory left for the new data that is written, some values are ejected from memory and will only exist on disk. Accessing values from disk is much slower than accessing data in memory
Which describes the sort of write buffering/read caching behavior that also happens in every other modern database. It all boils down to how "In-memory database" is defined. Some examples:
- PostgreSQL has the "synchronous_commit" option; when turned off, then database writes/commits are acknowledged to the client while they still exist only in memory, before writing to disk -- just like Couchbase. Does this make PostgreSQL an in-memory database?
- If I run PostgreSQL on a Linux tmpfs in-memory file system, is it correct to call it an in-memory database?
- If my application only uses the MySQL "memory" storage engine, should I call MySQL an in-memory database?
I would say the only reasonable answer to these questions is "no" -- otherwise we will need to include every modern database engine under the sun, which defeats the purpose of the "in-memory database" distinction. -- intgr [talk] 10:26, 18 February 2013 (UTC)
Suggested sources for expansion
We need to put the info from these into the main article and format as cites
- H-store Project
- Martin Fowler wiki: InMemoryTestDatabase
- Sprint Project
- Article "Main Memory Database Systems: An Overview" by Hector Garcia-Molina and Kenneth Salem
Hi, I am rather new to Wikipedia. I hope I am not doing that wrong.
I think the following sentence is pure advertisement: "With the introduction of NVDIMM technology, in-memory databases will now be able to run at full speed and maintain data in the event of power failure."
First, there are several competitors for NVM, but one calls it NVDIMM, which is by accident also referenced (i.e.g, Viking). Second, the sentence is not correct. Large vendors as Oracle, MS, and SAP are currently looking into NVM, but no one expects results the next two years since "real NVM" (not RAM with a battery) is not expected in mass production before 2014/15. If you need more information just ask Prof. Pavlo of Carnegie-Mellon, he's working on NVM techniques for in-memory databases. — Preceding unsigned comment added by 126.96.36.199 (talk) 09:33, 14 October 2013 (UTC)
- Agreed. I have removed the link to Viking. In the future, please be bold and just edit.
- The whole article is plastered with stuff about non-volatile memory and gives the wrong idea as if NVRAM solutions were commonplace. It appears that most of this bias was added by user Computermemorynerd, who also wrote the biased article on NVDIMM (which I already partially cleaned up).
- I lack sufficient knowledge on this subject, but it does sound like vaporware. Should we just delete everything added?
- Is NVDIMM a vendor-specific term? In that case, should NVDIMM simply redirect to NVRAM (which is presumably vendor-neutral)? -- intgr [talk] 20:28, 14 October 2013 (UTC)