Talk:In-memory database

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated C-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
WikiProject Databases / Computer science  (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Databases, a collaborative effort to improve the coverage of database related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as High-importance).

"Main memory" or "in memory"[edit]

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 ( titles its article "in-memory database". Any objections to changing the title of this article? Westwind273 23:34, 24 August 2007 (UTC)

Ok, I'll do the move; let's see if anyone complains. -- intgr #%@! 23:29, 25 August 2007 (UTC)

Key questions[edit]

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 (talkcontribs) 06:51, 28 April 2011 (UTC)

Nokia-Siemens Networks “One-NDS”[edit]

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 (talkcontribs) 04:19, 15 February 2010 (UTC)

Products List[edit]

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:

Crysb (talk) 18:23, 13 October 2010 (UTC)

Suggest Adding Xeround[edit]

I suggest adding Xeround to the list of in-memory databases. I believe it is sufficiently notable, see the entry for more details. Gilad.maayan (talk) 12:51, 9 October 2011 (UTC)

Since there were no objections, I'm adding Xeround Gilad.maayan (talk) 10:40, 31 October 2011 (UTC)

Misleading first paragraph[edit]

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. — Preceding unsigned comment added by (talk) 02:34, 15 January 2012 (UTC)

Couchbase and hybrid on-disk/in-memory databases[edit]

I have removed the paragraph about Couchbase from this article. The editor describes it as a "hybrid In-Memory and File-based database system". All I found from the Couchbase documentation is this:

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[edit]

I found the below commented-out in the "External links" section. -- Beland (talk) 04:14, 18 March 2013 (UTC)

We need to put the info from these into the main article and format as cites


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,[6] 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 (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)