3

Let's imagine very simple task to be done on server. There are many users chatting on our site and we would like to know, if each of them is online or not.

There are two obvious approaches to do that — use MySQL database or apply memcached NoSQL solution.

But why should memcached perform faster? If I understand it correct, MySQL will also read data from memory, not from the disk (if set up and tuned correctly). Few resources for persistence, but also not too much — just few memory pages to flush on disk.

The main question. Is there a strong reason to go NoSQL for such a task or MySQL will also perform ok?

Denis Kulagin
  • 8,472
  • 17
  • 60
  • 129

2 Answers2

4

For such a trivial task, you're right, it won't significantly change the performance, as the data will remain in memory and I/O won't be an issue.

Your question seems to imply memcached is a typical NoSQL engine; let me emphasize that memcached is an entity on its own and usually not conceptualized as a NoSQL database, but more as a fast and volatile key-value store, more often than not backed by a disk-bound database.

SQL and NoSQL each have strong points and weaknesses out of scope with your question, and more info about that is available in another thread.

Community
  • 1
  • 1
Patrice Levesque
  • 2,079
  • 17
  • 16
0

NoSQL in general is for analysis of Big Data. Memcached is for making a fast caching system.

A chat doesn't need analysis of Big Data, nor a cache system, because you only need to show a few data, and data are often updated. So, a relational DBMS is the best choice.

Imagine you have a complex site which rarely changes. Imagine that your pages are complex, and several complicated queries must be executed to compose each page. In that case, using memcached makes sense, because you can compose the pages, and store them in-memory.

Imagine you have enormous business intelligence data. You need to get some aggregating operations, like avg, standard deviation, sums... well, a Big Data solution may perform better than MySQL. Thought, there is a great number of caveats.

Conclusion: NoSQL is not for chats :)

Federico Razzoli
  • 4,901
  • 1
  • 19
  • 21
  • Categorizing NoSQL as data analysis solution is simplistic. This is probably true for column oriented stores, but not necessarily for graph, document or even KV oriented databases. Just saying ;) – LMeyer May 23 '13 at 09:37
  • I don't think that they should be used for other purposes. Many of them are schemaless, error-prone, or write data too rarely to get good performance (MongoDB, for example) and those I know don't grant data integrity or any form of builtin security. So, I wouldn't use them for anything else than datawarehousing (and only in case of ENORMOUS databases). But of course it's just my opinion. I had to use them sometimes, but that happened because the DBA wasn't able to do his job and optimize a relational DB. But again, that's just my experience. – Federico Razzoli May 23 '13 at 09:47
  • Fair enough, but you should look into it deeper. For example, Redis can be used as a cache system, or Neo4J can be interesting performance wise in a chaotic data structure. These all are specific use cases usually involving Big Data of course, but still. – LMeyer May 23 '13 at 10:00
  • Well yeah, I don't know Neo4 but I agree about Redis. NoSQL is a marketing term, and it is used for software projects which are very different each other. – Federico Razzoli May 23 '13 at 10:04