CODEWITHSUNDEEP
performancemongodbrediscouchdbkey-value
AlessandroEmm
AlessandroEmm

Reputation: 698

DocumentDB vs Key-Value DB with hierarchy Performance

First things first: I know Key-Value DB are by far best the performing databases. My assumption is that this is due to their simplicity (sticking to very few primitives). (EDIT2: Obviously also due to beeing mostly held in Memory)

Anyway what about more complex datastructures like hierarchy trees and the likes. With DB like redis you have to build a structure based on "flat" hashes with links whereas with document DBs like couchdb you just build up the structure yourself like:

"menu": {
    "id": "file",
     "value": "File",
     "popup": {
        "menuitem": [
             {
              "value": "New",
              "onclick": "CreateNewDoc()"
              },
              {
              "value": "Open",
              "onclick": "OpenDoc()"
              },
              {
              "value": "Close",
              "onclick": "CloseDoc()"
              }
       ]
}

If I have structures like this, does it even make sense to use redis performance and usabilitywise?

Interestingly key-value and document Databases get compared 1:1 very often, while serving a different purpose or/and use-case IMHO.

EDIT:

What I'm looking for: generally I would like to have a JSON-like DB store, which is giving me the ease of defining and building complex structures on the fly and getting the good things from use of a Databases-System (failover, speed, ...).

Thank you!

Upvotes: 0

Views: 1296

Answers (2)

yojimbo87
yojimbo87

Reputation: 68453

If I have structures like this, does it even make sense to use redis performance and usabilitywise?

Structure you depicted consists of embedded data in a json document, however even with document databases there is still a difference between embedded and referenced/linked data. If you embedd a lot of data into single document, you can end up with performance issues and data fragmentation. Referencing is on the other hand more flexible, but requires some joining logic. To sum it up - it depends on your domain model and problem your are trying to solve. Regarding redis there are libraries like ohm which provide more OOP based higher level data abstraction.

What I'm looking for: generally I would like to have a JSON-like DB store, which is giving me the ease of defining and building complex structures on the fly and getting the good things from use of a Databases-System (failover, speed, ...).

Although mongodb is probably the most popular document database followed by couchdb, you can also try to look at other solutions like arangodb or orientdb. Each of them is built on top of some philosophy which might provide benefits in specific areas compared to other solutions, e.g. couchdb's map-reduce way of querying might not be suitable for everyone, but it's durable.

Upvotes: 2

garbados
garbados

Reputation: 885

Key-Values stores like Redis perform so well because they store data in-memory, which you can read/write many times faster than data stored on disk.

The trouble with in-memory storage is fault tolerance: if Redis turns off unexpectedly, memory clears, and all your data is lost. So, Redis is appropriate when you're reading and writing data frequently, but you don't mind if this data is lost. For example: login sessions, where losing data means users just sign in again.

CouchDB and other document stores swap speed for fault tolerance, ensuring your data is safer under more circumstances. Document stores like CouchDB also provide queries, letting you search and parse your data, which you can't do with Redis. A document store like CouchDB is appropriate when you're reading and writing data that you can't afford to lose arbitrarily.

Upvotes: 1

Related Questions