Forgot your password?
typodupeerror
Data Storage

NoSQL Document Storage Benefits and Drawbacks 96

Posted by samzenpus
from the pros-and-cons dept.
Nerval's Lobster writes "NoSQL databases sometimes feature a concept called document storage, a way of storing data that differs in radical ways from the means available to traditional relational SQL databases. But what does 'document storage' actually mean, and what are its implications for developers and other IT pros? This SlashBI article focuses on MongoDB; the techniques utilized here are similar in other document-based databases."
This discussion has been archived. No new comments can be posted.

NoSQL Document Storage Benefits and Drawbacks

Comments Filter:
  • Same as the old boss (Score:5, Interesting)

    by greg1104 (461138) <gsmith@gregsmith.com> on Monday June 04, 2012 @04:27PM (#40213101) Homepage

    It's so cute how NoSQL developers have reinvented the XML database.

    • by tepples (727027)
      True, but this time it's "web scale", whatever that means. And a lot of the concerns in that video [youtube.com] appear to have been addressed, with durability provided through a journal file.
    • Re: (Score:2, Informative)

      by Anonymous Coward

      The article lied. It mentioned benefits and drawbacks in the title, but all it described was a collection of collections of key-value pairs. Is that really what this whole NoSQL thing is about?

      • by Anonymous Coward

        Yes. It's a column-based store, as opposed to a row-based store.

    • by Anonymous Coward

      XML as database has a hierarchie, NoSQL looks like a key (_id) value (hashes) flat unstructured mess. I'm not fond of XML/Xpath/Xwhatever but atleast I think it has more structure compared to NoSQL

      • by greg1104 (461138)

        JSON is relevant to NoSQL because it gives a good answer to "how do I store more complicated things than key/value lookups?", one that's even possible to decode in a web browser noadays. XML databases gave an answer to "how do I store schemaless data in a relational database?", a similar issue. Both combinations--relational + XML, NoSQL + JSON--end up providing the same basic capabilities.

        • by Nadaka (224565) on Monday June 04, 2012 @05:16PM (#40213685)

          JSON is crap for storing arbitrary structured data and collections for web applications.

          In javascript you can easily construct an object that is both an "Array" and has named attributes (an associative array). However, you can't recreate that object with valid JSON.

          JSON also introduces a fantastic new method of inserting arbitrarily executing code into a web application, demanding yet another set of defenses against insertion attacks to be developed.

          It is a problem masquerading as a solution to a problem it can't actually solve.

          • JSON also introduces a fantastic new method of inserting arbitrarily executing code into a web application

            How so, if you parse the JSON in your own code [google.com] instead of eval()ing it?

            • by Nadaka (224565)

              That was the point. Not everyone does that.

              The defacto standard for instantiating an object from json is still eval()

              • by arose (644256)
                Just like the standard is to feed forms straight into MySQL. That's the reason MySQL sucks after all.
              • All major web browsers have supported JSON.parse() for a long time; including IE8. Anyone who is still using eval() for parsing JSON should come out of their cave and get with the times. I doubt you would find any serious web developer who still uses eval(), except in "extreme" circumstances. There's just no real need for it in most applications.

    • by jd (1658) <imipak@yaCOLAhoo.com minus caffeine> on Monday June 04, 2012 @05:07PM (#40213613) Homepage Journal

      The "old old boss" would be the CDF/NetCDF/HDF family of self-describing distributed storage solutions. They predate XML by a long way and are - I believe - the first true self-describing method of storing, indexing and searching data.

      For the most part, they support network interconnections between instances, so you can have your virtual storage distributed over as many physical systems as you like. The users will never see the difference except in terms of speed. This gives you all the benefit of NoSQL's distributed model (which XML lacks) but with several decades more development in the database design.

      But wait! There's more! If you order in the next gazillion years, you get OpENDAP absolutely free! (Which it is anyway.) OpENDAP will translate between any two data formats, so if one site wants to view the data as, say, a conventional database, another wants to look at it as a collection of spreadsheets and a third is expecting XML data, you'd have OpENDAP translate between client form and central repository form.

      I have no objections to Mongo or Memcache, they're very powerful and are very useful, but we're still ultimately talking about technology everyone else has had since 1985, thanks be to NASA, and many NoSQL technologies are really just network-aware versions of the DBM/NDBM/BDB/GDBM/QDBM family which have existed since Unix began.

      NoSQL definitely has a place - I would not want to try serving cached web data from HDF5 - and it's an important place. But that's just as true for Hierarchical Databases, Star Databases (aka "Data Warehouses"), "genuine" (ie: actually complies with Codd's rules) relational databases (SQL isn't truly relational in the Codd model, merely a subset), and so on.

      It's time we got away from one-size-fits-all ideas, which violates the Unix ethos anyway, and get back to using best solutions for specific problems rather than passable solutions that fail at everything. These are all wonderful, highly specialized solutions to highly specific problem types. Treating them as such will always produce a better answer than force-fitting solutions into not-quite-failing with problems they aren't designed for.

      • It's time we got away from one-size-fits-all ideas

        What do you mean? We shouldn't use ASCII? Or Unicode? How about what we in the West know as the Arabic numbering system? Universality has its place. Standards are useful and important. PL/1 failed perhaps because programming is more complicated. Though computing is universal, we have not yet managed to come up with a good universal programming language. But data may be simpler.

        Having said that, I think HDF5, NetCDF, JSON, YAML, and SQL (and NoSQL) all fail on the universality front. You would not

        • by jd (1658)

          The thing with self-descriptive data is it doesn't matter if you personally use ASCII, EBCDIC, Unicode or wide characters. You can map whatever to whatever. There is a standard, but it is in the description and not in the described. Specialized solutions are superior - in their niche. I would take a toolbox with a thousand types of saw, hammer and blade over a single Swiss Army Knife because each tool is superior even though no single blade can do everything.

          A universal system would be an object-oriented Co

        • by vegiVamp (518171)

          > What do you mean? We shouldn't use ASCII? Or Unicode? How about what we in the West know as the Arabic numbering system?

          None of those *are* one-size-fits-all. ASCII and Unicode are very good at encoding text in human-readable forms; but I wouldn't want to encode my porn in them. The arabic numbering system is very good at expressing discrete quantities, but kindly refrain from writing a whole novel in it.

          The point is that this NoSQL stuff is being hailed as the next big thing, which shall Smite the Rel

          • by julesh (229690)

            I don't think anybody is claiming NoSQL is new. Many NoSQL products are just incremental improvements over old-style object-oriented databases, after all.

            All that is new is the concerted push to point out to people that RDBMSs and SQL shouldn't necessarily bethe automatic solution to every problem. They're extremely good at certain tasks, perhaps even for a large majority of tasks, but there are some instances where they are not the best tool for the job. The NoSQL people just want to make sure we all co

            • by vegiVamp (518171)

              Unfortunately, the NoSQL people come over as if - and many actually do - believe that RDBMSes are utterly useless now that they have found Je- err, their new toy.
              Of course what is now suddenly known as NoSQL has it's place - hell, how many of us haven't been using Memcached or something similar? Mozilla (and many others) uses RDF stores - yep, that's also NoSQL now. It's just not the ONLY solution, let alone always the BEST one - and of course you need to pick the right tool for the job.

              There's been a kente

    • It's so cute how NoSQL developers have reinvented the XML database.

      Actually, XML is a comparative latecomer.

      NoSQL uses JSON which has "name: { blah:val, blah:val }" style syntax. I needed a text database format for some [perl/awk] scripts I wrote in the 80's. I ended up creating a similar curly brace format--no big deal.

      Before relational databases even existed, there were CODASYL-compliant databases. These didn't even have SQL as we know it today.

    • by cait56 (677299) *
      Actually I think they reinvented the flat file.
    • by Anonymous Coward
      It's so cute how you exclude XML database developers from NoSQL developers. NoSQL gave the trend a name, the currently popular examples tend to not be XML based, but they are all part of the same family. The biggest difference is probably that XML developers love formal schemas whereas the current crop prefers informal ones.
    • by Pseudonym (62607)

      What I find especially cute is that nobody in this thread seems to have heard of Z39.50 or WAIS.

      • by greg1104 (461138)

        The whole "XML in databases!" trend came out of people being frustrated with not being able to stuff arbitrary data into a relational database. This "new" document storage idea is addressing the exact same problem in a similar way, only it's a different schemaless storage scheme/database pair. That's why I was amused by the similarity.

        Z39.50 and WAIS were implementing a client/server protocol that wasn't tied to any particular database storage backend. If I were searching for a historical precedent for f

        • by Pseudonym (62607)

          Z39.50 and WAIS were implementing a client/server protocol that wasn't tied to any particular database storage backend.

          That's certainly true. I only know of one Z39.50 database engine that actually speaks Z39.50 natively.

          Nonetheless, Z39.50 was designed with SGML in mind. It implements a very flexible documents-with-nested-and-repeating-fields schema, and did so in 1988.

    • by gadzook33 (740455)
      You mean lotus notes?
  • by Nadaka (224565) on Monday June 04, 2012 @04:32PM (#40213195)

    The article is barely a description of MongoDB records. It does not really detail any real drawbacks or benefits beyond "look ma, random structure in my record!"

    • by Moses48 (1849872) on Monday June 04, 2012 @04:59PM (#40213517)

      I read this article with the hope of seeing some of the benifits and drawbacks (as the title implied). No talk of scalability, indexing, speed, etc. I actually feel dumber for having read the article.

      • by nullchar (446050)

        The comments on SlashBI are great too. I also wanted to know how to query data out of your "documents" as the Wikipedia page doesn't describe that. Using the SlashBI example, show me all contact objects with state = "DC" or all records where last name ilike 'o_ama'. Does performing a search like that iterate over all records? Do you need to enable some full-text indexing of your entire document store to be able to execute queries like that?

  • by Sarten-X (1102295) on Monday June 04, 2012 @04:37PM (#40213271) Homepage

    Oh, look, it's a NoSQL article.

    Cue the hundreds of Slashdotters who proclaim "Oh, they're reinvented obsolete databases" and "Just wait until they need ACID, then they'll be fucked", the NoSQL blind-faith followers who harp about pure scalability and clustering, and at least a dozen references to an animated video of a retarded strawman saying "webscale" repeatedly.

    Somewhere in the depths of poorly-researched comments will be some guy who thinks that NoSQL is a tool that really just might be useful for particular use cases, and should be used where appropriate, and nowhere else. Sadly, his post will be missed because everyone's too busy talking about how everything can be done just as easily on a $500,000 server farm running Oracle's latest and greatest turd.

    • by Fwipp (1473271)

      +1 Preemptively made other posts Redundant

    • by busyqth (2566075)
      Oh there are definitely use cases for mongo: It's the cheap/fast selection on the "cheap/fast/good: pick 2 of 3" scale.
      Kind of like the McDonalds of data storage.
    • Welp, looks like that's it for the thread, folks. Move along.

    • by greg1104 (461138) <gsmith@gregsmith.com> on Monday June 04, 2012 @04:54PM (#40213453) Homepage

      Sadly, his post will be missed because everyone's too busy talking about how everything can be done just as easily on a $500,000 server farm running Oracle's latest and greatest turd.

      Actually, I was going to talk about how PostgreSQL 9.2 (expected in Q3 of this year) will include JSON support [postgresql.org]. The database also has non-relational key value [postgresql.org] storage, and that feature is even available in Heroku deployments [heroku.com] now.

      PostgreSQL also lets you relax ACID for performance when that makes sense, at the transaction level, using synchronous_commit parameter [postgresql.org] and unlogged tables [depesz.com].

      There are two things PostgreSQL doesn't do as well as MongoDB. It won't do simple key/value lookups quite as fast; I normally eliminate that problem by putting a memcached server in at some level. And you can't split writes among multiple nodes easily yet.

      • by dkleinsc (563838)

        Glad I'm not the first to bring up PostgreSQL, which gives you serious amounts of awesomeness at 0% of the cost of Oracle.

    • by jd (1658)

      Agreed, but that's the peril of living in a world where everything is tightly-coupled and highly-integrated. People forget that you can mix-n-match, they look no further than using one system for everything. NoSQL does indeed have a purpose, and just like an F1 car, it is in a class of its own when used for that purpose. But I'd no more use Memcache as a substitute for NetCDF or Ingres than I would use an F1 car to go off-road sight-seeing.

    • my article about porn stars using kickstarter and other donation websites to provide each other with healthcare (because there is no healthcare in the porn industry) got instantly blacklisted.

      instead, you get this.

      shrug.

    • by sco08y (615665)

      Somewhere in the depths of poorly-researched comments will be some guy who thinks that NoSQL is a tool that really just might be useful for particular use cases, and should be used where appropriate, and nowhere else.

      Yes, those "appropriate uses for NoSQL" are like unicorns... often rumored, only apparently seen in huge companies like Amazon and Google where they have dozens of PhDs working on them. They're very similar, unfortunately, to the "seemingly appropriate uses for NoSQL" but you can't really tell until you've wasted months of development effort...

      • by DavidTC (10147)

        And when people point out there appears to be no actual use, the NoSQL people feel the need to expand NoSQL to include completely random things like Memcache, which is not any sort of 'database' at all, and the Memcache people would be completely baffled to be included in this group.

        I'm frankly surprised they haven't started claiming that filesystems are NoSQL. And everyone uses those! So everyone uses NoSQL!

        And, in fact, they're correct. That's really what NoSQL is. It's a not a replacement for any sort

  • by claytongulick (725397) on Monday June 04, 2012 @04:39PM (#40213283) Homepage

    I'm not sure what the point of this "article" is. It is light on actual information or anything useful, it's basically just a few paragraphs that say "a NoSQL database called Mongo stored data in JSON format. This may or may not work for you".

    If we're going to have "BI" articles, they should be informative, containing useful information that we couldn't have gathered ourselves in 10 secs of googling.

    How about some comparisons between various NoSQL solutions? How about binary access API v/s RESTful approach ala Couch? How about clustering, replication and scalability? How about stability concerns (with Couch, for example). Real world use cases? Examples of companies using them for specific solutions? Performance comparisons with RDBMS's? Problem domains that NoSQL/schema less DB is more suited to than a RDMBS?

    I'm not trying to be pointlessly critical here, I'm trying to provide some constructive feedback on the new slashdot BI format. This article wasn't useful to me at all. I'll probably not spend time reading these articles in the future if the content is as light as this article.

  • Unstructured Data (Score:5, Interesting)

    by Bigby (659157) on Monday June 04, 2012 @04:49PM (#40213413)

    I don't know when unstructured data turned into NoSQL or Big Data, but it is a pretty simple concept with complex Enterprise level requirements. I work in this field and have for various companies. The biggest obstacle is conforming to the laws of various jurisdictions and levels of government.

    You have unstructured data, but it NEEDS some level of structure. That structure is there to restrict access to certain groups within the organization and also for retention rules, which differ by type of data being stored. Not to mention that you must store certain documents in the country of origin, so structured field-based distributed storage plays a role. Oh yea, laws/policies around encryption and whether or not an index violates those laws/policies.

    This doesn't work well with a relational database. Sure, you can jam it into a RDBMS like IBM Content Manager, but it becomes inflexible. However, there are constraints that must be followed and all documents need some kind of structure wrapped around them in a RDBMS-like fashion.

    I haven't dove into these NoSQL systems myself. They seem like a good idea, but I hesitate if they are too loose. In an Enterprise with sensitive information, you need to deny first. Also, how do they index the fields? Like when you have 100,000,000 documents with invoice numbers...

    • by Yogs (592322)

      Relatively free form key value pairs except some other stuff that matters for your domain works just fine in a relational db, you just have to query for it when you need it. If you already have a db and an ORM, which would be the common case in any enterprise environment, you'll get your getters and setters for free once you specify class/member->table/column and you can have an attribute table in the without breaking step. How this would be hard to set up or use compared to a key/value store is a myst

    • by dhasenan (758719)

      In RavenDB, you create indices by creating a query returning the field you want to index and telling RavenDB to index that. For instance, if you are going to query your User documents based on email address often, you would write an index:

      from user in Users select new { user.EmailAddress }

      And then you can query:

      from user in Users where user.EmailAddress == "bob.dobbs@example.org"

      You can do this without an index, but it will be slow. Though in the case of RavenDB, I believe the database will add indices base

  • With MongoDB and lack of hard schema requirement doesn't mean your data model can be all willy-nilly. You have to put some thought into it. Several people have mentioned they are looking for the benefits and drawbacks. I'm really enjoying it. Here's my short list draw backs. Case Sensitive: If you load data with mixed case you will have to use a regular expression to find it all. Data Type UnStrickness: If you load zip codes as a string "11223" and try to find it with an numeric 11223 you are out of luc
  • by ilsaloving (1534307) on Monday June 04, 2012 @05:33PM (#40213845)

    Where is Lotus Notes in all this bru ha ha? They were the original NoSQL system.

    • Where is Lotus Notes in all this bru ha ha?

      Still at the same place they were decades ago?

      *not* flamebait here. Truth. I had deal with this not that long ago on a daily basis... and I wonder, I really really do.

      • Having done some development work on it a long time ago, your news is dissappointing.... yet... somehow not surprising.

        • Well, the "good news" is where I work is now dumping Lotus for Outlook... and all MS software along with it.

          I am not entirely sure if this is a step forwards or backwards..

  • I was really hoping for a more in-depth description of what NOSQL has to offer over other DB options.
  • ... to describe non-relational databases. There are many different ways to store data in various database designs. They are mainly of the following: Relational (mysql, postgresql), Column based (HBase, Cassandra), Document based (Mongodb, CouchBase), Hash based (redis, memcached), and Graph based (neo4j). Databases can also be categorized as single system databases or distributed databases. Mongodb and most (all?) relational dbs are single system databases. HBase, Cassandra, CouchBase, Riak are distributed
  • What is the point of document storage in a noSQL database? If you're not going to store docs in a RDBMS, why not just store them in a filesystem? What is the point of Mongo or whatever this stuff is?
    • What is the point of document storage in a noSQL database? If you're not going to store docs in a RDBMS, why not just store them in a filesystem? What is the point of Mongo or whatever this stuff is?

      They are JavaScript Object Notation (JSON) documents and you can query into fields of the object-document without the database having to read the whole "document" in the same way you can read rows based on some set of columns in an RDBMS. Given objects like { a = { b,c } } or just d = f you could read a.b where = c or just d where = f. It's multidimensional as opposed to the flat column format of an RDBMS. Unfortunately, their are no data types, constraints, foreign keys or triggers. Data integrity has to

      • by DavidTC (10147)

        They are JavaScript Object Notation (JSON) documents and you can query into fields of the object-document without the database having to read the whole "document" in the same way you can read rows based on some set of columns in an RDBMS.

        Yes, congratulations on off-loading the 'reading the document into memory and parsing it' into an entirely different process. I'm that will make it much faster then simply keeping the document mmapped in the application that needs it, and in no way be counterproductive

  • We used MongoDB as a query/cache accelerator for semi-structured data. The key bottleneck was delegating queries outside of application (pre-filtering results according to ACLs, date transforms, etc.).

    We don't have a shockingly huge dataset, and site traffic wouldn't be considered as webscale, but the ad-hoc schema and ability to delegate complex queries to the DBs as JS was really powerful and bought us a lot of performance for very little effort.

    And it's only a cache of the authoritative data store, so we

  • I, for one, would have a much better time taking NoSQL seriously if so many of the arguments for it didn't reduce to -and to truly express this reduction properly I need to put on my best Barbie voice- "The relational model is haaaaard." Some say SQL instead (for example, whoever came up with the NoSQL moniker), but except for a couple of arguments that amount to pure syntax baw it reduces to pretty much the same thing.

    NoSQL has its place: there are some things it does really well. The problem is that the t

"When it comes to humility, I'm the greatest." -- Bullwinkle Moose

Working...