Talk:In-memory processing

Merger proposal
Original nominator didn't bother to begin a discussion. As for me, I haven't any clear opinion on this merge. --4th-otaku (talk)

My particular opinion on this is that we dont merge these two because they are far too broad in of themselves to be merged, final vote, no. - Joel Wyman Junior — Preceding unsigned comment added by 67.5.252.3 (talk) 23:26, 5 June 2014 (UTC)
 * Those are two different subjects altogether Regards, Tshuva (talk) 11:34, 23 June 2014 (UTC)


 * As it stands, this article can't stay on Wikipedia anyway; it's written like an essay trying to sell you some products, not an informative encyclopedia article. I don't know if there is anything salvageable here, but merging it into another article is one way. Deleting is another way. -- intgr [talk] 14:56, 24 June 2014 (UTC)

This topic is increasingly important because most modern RDBMS support in-memory database functions and users need to understand when and how to use and tune these features. In-memory databases are distinct from in-memory processing by being transactional, by being durable (through durable transaction logs), and by supporting the usual DBMS features such as query languages. Falling DRAM prices have driven major improvements in the cost-effectiveness of in-memory database technologies, and they are now commonly mainstream. MySQL and Oracle have long supported this, and with the 2014 release Microsoft SQL Server also supports it. — Preceding unsigned comment added by 72.93.83.117 (talk) 14:48, 2 November 2014 (UTC)

———

These topics have little in common. IMDB is a large, established application domain. In-memory processing is just a grab bag of generic techniques.


 * Micron: 3D XPoint In IMDB — 30 August 2015

Credit Suisse made the assertion that around 1.3 million - 1.4 million servers were running Oracle databases last year. Pitzer suggests a 2.5% penetration with 32 TB of DRAM would be a good estimate of the demand for DRAM created by IMDB.

This article is a stock pump, so apply salt in the metric prefix of your choice, but it's clear enough that this is a big, established market segment.

This discussion hasn't really gone anywhere and the proposer is MIA, so I'm removing the merge proposal from the top of the article page. &mdash; MaxEnt 18:58, 11 September 2015 (UTC)

Rewrite
From a technical standpoint this article has numerous issues. The article implies that by keeping all data in-memory no indexing is needed; this is incorrect for larger datasets. The reason for this is that a task's time complexity remains constant even if the underlying hardware (hard disk to RAM in the article) changes. In addition, the article implies that traditional databases hit disk for all queries and do not, e.g. cache data and indices in RAM. Additionally the article states that a traditional DB can only do one task (a write, a query, a view, etc.) at a time; this is not true. There are many other issues as well along with contradictions from paragraph to paragraph. Input from a DBA would be ideal but my opinion as a software architect/engineer is that the article should either be completely rewritten (preferably by a DBA) or deleted. &mdash; Alex Hajnal (talk) 07:02, 25 November 2015 (UTC)


 * Agreed. Until the rewrite happens, I think WP:STUBIFY is appropriate. -- intgr [talk] 08:23, 25 November 2015 (UTC)
 * Agreed. &mdash; Dsimic (talk &#124; contribs) 08:26, 25 November 2015 (UTC)


 * Draftify? It appears to have been written like an advert by vendors of "in-memory" database technology(UNDECLARED WP:COI), and doesn't really explain why it's technically better (which would basically be for operations that need big matrices and clusters that will be read entirely and more than once (otherwise classic read on demand kind of databases would be adequate). I have marked it appropriately.  Should it be moved to draft space?Ethanpet113 (talk) 08:46, 18 November 2018 (UTC)


 * Honestly I think the whole article should be nuked. I don't know what the procedure for doing so is though. — Preceding unsigned comment added by AlexHajnal (talk • contribs)

As of Dec 2023, the article still has several problems. So I think it needs much tougher editing, so that the gobbledygook does not confuse the sensible parts.Rick Jelliffe (talk) 07:29, 23 December 2023 (UTC)
 * For example, it is completely false in its explanation of Moore's Law.
 * And it talks of SQL as if there are no in-memory implementations.
 * And it says that in-memory processing gets its speed because data comes into RAM not the disk, but in what world does data bypass the RAM before being allocated to a disk-based RDBMS? Is it somehow talking about DMA...I doubt it. It seems a garbled version of the decision on how soon the in-memory data is synced to the persistant database, or if it is a non-persistant database...or if the RAM is flashed...or something...


 * ✅ I have rewritten the lead. The rest of the article needs to be rewritten to cope with these two different meanings. I have split the article into two sections, one for hardware (the more interesting one) and one for software (which rather looks like it hijacked the topic.) Rick Jelliffe (talk) 10:43, 23 December 2023 (UTC)

External links modified
Hello fellow Wikipedians,

I have just added archive links to 1 one external link on In-memory processing. Please take a moment to review my edit. If necessary, add after the link to keep me from modifying it. Alternatively, you can add to keep me off the page altogether. I made the following changes:
 * Added archive https://web.archive.org/20110424013629/http://www.infosysblogs.com:80/oracle/2011/03/in-memory_computing_in_busines.html to http://www.infosysblogs.com/oracle/2011/03/in-memory_computing_in_busines.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Cheers.—cyberbot II  Talk to my owner :Online 05:15, 26 February 2016 (UTC)