Slashdot Mirror


MongoDB CEO Claims They're Luring Customers From Oracle (diginomica.com)

"MongoDB is increasingly encroaching on Oracle's database lead -- with enterprises becoming more and more confident with the maturing NoSQL technology," according to Diginomica, citing this new interview with CEO Dev Ittycheria: 30% of our business is migration off existing workloads to us. Two years ago it was 5%. Ditching Oracle and others, but mainly Oracle... one of the nice benefits of being in this market is that Oracle has done a great job of alienating its customer base... if there are performance reasons, regulatory reasons, developer demand -- [people] will change... We have grown business by 2.5X over last two years. And our employee base has pretty much doubled.
One reason he cites is Oracle's higher prices on their top-line products, saying MongoDB's new customers include "a large bank, whose logo you would recognize instantly [with] a very sophisticated equities trading platform." Ittycheria says MongoDB is now a nine-figure business, and after they launched their new database-as-a-service product Atlas last June, "the growth in that business has been off the charts."

153 comments

  1. alienating its customer base by Anonymous Coward · · Score: 0

    Oracle is the 'democrats' of databases...

    1. Re:alienating its customer base by eric_harris_76 · · Score: 1

      Or "Republicans". Turnout for the statutory duopoly parties was down this presidential election.

      Turnout for opposition party candidates was way, way up.

      --
      There's no time like the present. Well, the past used to be.
  2. Mongo is now a nine figure business by fustakrakich · · Score: 1

    Sounds about right for a buyout, no?

    --
    “He’s not deformed, he’s just drunk!”
    1. Re: Mongo is now a nine figure business by Anonymous Coward · · Score: 0

      He's basically asking to be bought out by Oracle.

  3. ACID doesn't matter... by tlambert · · Score: 2

    "ACID doesn't matter... your first install is free!"

    1. Re:ACID doesn't matter... by Anonymous Coward · · Score: 0

      Last time I used MongoDB wide-scale it was as a cache infront of the ACID database; effectively replacing memcached not the more reliable database.

      PostgreSQL (the ACID DB) had an FDW for MongoDB which allowed a trigger to directly and immediately mark the cached items stale.

      Document stores are great for data that never lives longer than the front-end program using the document store.

  4. NoSQL is stuff for morons by Master5000 · · Score: 0

    NoSQL is stuff for morons who can't do SQL and think they have invented something better. Most of these schemaless stuff is just morons too stupid to realize that there actually is a schema if you use your brain for 5 minutes. But can't let the javascript kiddies have a stroke by thinking now, can we?

    1. Re:NoSQL is stuff for morons by mwvdlee · · Score: 0

      No; morons are people who think that RDBMS's using SQL are the only database solution you will ever need for any problem you might ever encounter.
      NoSQL databases have their uses. I personally wouldn't choose MongoDB, but there are definitely situations where some form of NoSQL is better than SQL.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    2. Re:NoSQL is stuff for morons by Joviex · · Score: 1

      No; morons are people who think that RDBMS's using SQL are the only database solution you will ever need for any problem you might ever encounter. NoSQL databases have their uses. I personally wouldn't choose MongoDB, but there are definitely situations where some form of NoSQL is better than SQL.

      If I had points, but I spent them modding that retard down.

    3. Re:NoSQL is stuff for morons by angel'o'sphere · · Score: 1

      Yeah, and if I had points I would delete you from the /. data base.

      Facepalm.

      Your parent is right and you are to uneducated to grasp it.

      But feel free to show us how bright you are and give us a few examples where a SQL based DB (actually they are called "relational", but I guess you know that ...) is superior to a NoSQL DB.

      We are waiting ...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    4. Re:NoSQL is stuff for morons by Joviex · · Score: 1

      But feel free to show us how bright you are and give us a few examples where a SQL based DB (actually they are called "relational", but I guess you know that ...) is superior to a NoSQL DB.

      Hey, jackass, you misread the entire conversation if you think we are saying what you just posted.

      I agreed with the guy who pointed out that there are proper tools for proper solutions i.e. NOT EVERYTHING IS A NAIL IF YOU ARE A HAMMER.

      Apparently, you have a reading comprehension problem.

      Cheers.

    5. Re:NoSQL is stuff for morons by angel'o'sphere · · Score: 1

      If I had points, but I spent them modding that retard down.
      So you meant a moron who was several posts up ... and you needed such a complicated answer to point that out.

      Perhaps you have a comprehension problem how /. works.

      I most likely don't read it in the "treading" way you read it, get a clue. But thanks for your attempted insults ;D

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:NoSQL is stuff for morons by Anonymous Coward · · Score: 0

      He expressed the wish to have the post he was replying to moderated, but he did not say which way. Based on the tone of his post, I would expect upwards.

      It seems you somehow expected a downmod.

    7. Re:NoSQL is stuff for morons by Anonymous Coward · · Score: 0

      A comeback post with improper grammar is generally a fail.

    8. Re:NoSQL is stuff for morons by Anonymous Coward · · Score: 0

      If I had points, but I spent them modding that retard down.

      And now that you’ve posted in this thread, your moderation has magically vanished.

  5. could just be the beginning by sribe · · Score: 3, Informative

    From my experience, I'd guess that about 90% of Oracle installations do not need Oracle. They're all ripe for migration to PostgreSQL or MongoDB. (Granted the 10% of installations that are big enough to need Oracle will be way more than 10% of Oracle's database revenue, but it's still a nice market segment, ripe for the taking.)

    1. Re:could just be the beginning by fustakrakich · · Score: 2

      If Mango can produce enough revenue, Oracle will make them an offer they can't refuse. In the meantime, they can let them (Mango) do all the dirty work of gathering clients.

      --
      “He’s not deformed, he’s just drunk!”
    2. Re:could just be the beginning by haruchai · · Score: 1

      Mongo, not Mango

      --
      Pain is merely failure leaving the body
    3. Re:could just be the beginning by Anonymous Coward · · Score: 2, Funny

      Mongo just pawn in game of life.

    4. Re:could just be the beginning by sribe · · Score: 1

      If Mango can produce enough revenue, Oracle will make them an offer they can't refuse. In the meantime, they can let them (Mango) do all the dirty work of gathering clients.

      While that's true, I would hope that they might also get an offer from Amazon or IBM, or even Microsoft...

    5. Re:could just be the beginning by Anonymous Coward · · Score: 0

      There is tic toc in atomic
      Leaders make a deal
      The cosmic is largely comic
      A con they couldn't conceal

    6. Re:could just be the beginning by Anonymous Coward · · Score: 0

      Why would you want Amazon or IBM to buy them? Neither company has a very good reputation for pushing open source software. Incase you are unaware, Mongo is an open source database with an enterprise selling model.

      In fact, Amazon has shown a propensity to take open source software and push a SaaS model around them without giving back to the community that they're taking from. I cannot think of a single open source project from Amazon that is not working with an AWS service.

      IBM is known for providing quality, enterprise software, but they are not known for pushing quality, open source software. But, importantly, everything they do comes with a huge premium.

      Weirdly, Microsoft is the best to buy them right now. But Microsoft is also all-too-willing to kill their projects right now, which is obviously a double-edged sword. It makes them more agile, but they're also killing projects similar to how Google does it: too soon.

      I like Mongo as a stand-alone company. I see no benefit to the community at large for them to be acquired by a large company.

    7. Re:could just be the beginning by Tablizer · · Score: 2

      But orgs don't want the extra expense of staffing and training between multiple brands, and migrating back and forth between them as needs change, such as a small database growing large and vice versa. One-stop-shopping simplifies all this.

      I'd suggest picking no more than two brands for an org: one high-end and one low-end. You'd probably want the option of ACID for both, which makes no-sql solutions a problem.

    8. Re:could just be the beginning by Kjella · · Score: 2

      From my experience, I'd guess that about 90% of Oracle installations do not need Oracle.

      True, but many Oracle customers turn into all-Oracle shops because the DBAs claim it's the "enterprise quality" solution that they can get for a pittance more on top of the already expensive contract - not to mention a vested self interest - and the executives see the costs of managing an Oracle database environment and fear that they'll be hit with another huge bill. And that drives a lot of software to support installation on Oracle and so the circle is complete.

      I've worked with Oracle and when it works "right" it's a beast. But I often found that in complex SQL it's a system that wants it "the Oracle way" or need handholding with indexes and execution hints even though there's several ways to achieve the same results. MS SQL and PostgreSQL would usually do something roughly right performance-wise as long as it was logically right. It's okay if you would have to make those kinds of optimizations anyway, but a giant pain in the ass when that's not a priority.

      --
      Live today, because you never know what tomorrow brings
    9. Re: could just be the beginning by Anonymous Coward · · Score: 0

      Is being enterprise quality better or worse than being web scale?

    10. Re:could just be the beginning by Anonymous Coward · · Score: 0

      For the sake of the product and the customers, none of the above. Red Hat would have my vote

    11. Re:could just be the beginning by angel'o'sphere · · Score: 1

      Care to point out which NoSQL DBs are not ACID, that would be helpful.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    12. Re:could just be the beginning by lrichardson · · Score: 2

      From my experience, I'd guess that about 90% of Oracle installations do not need Oracle.

      I'll go one step beyond that: in my experience, 99% of Oracle installations could be replaced with SQLite, MySQL, Firebird, even Derby. (Possibly Excel, in some cases)

      Virtually every Oracle DB I have encountered has used the POWER of Oracle (TM) as an excuse to skip putting together a decent schema. Massive duplication of data. Joining dozens of tables to get commonly needed data. Tables with far too many fields.

      I'm currently dealing with one that works ... just. Minor issues, like virtually every table can be dropped by at least two orders of magnitude in size, the actual Oracle DB supporting the application uses ~140 tables, when it needs ten, and there is a ton of data stored that is inaccessible using keys.

      If management would spend a fraction of the amount they spend on hardware on a decent DBA, then they wouldn't need to spend millions on monstrosities (in terms of overkill) like Oracle ... and the hardware needed to run it on. Have similar feelings towards Hadoop ... yay, it's great, sooo scalable! Whadya mean I can't get the data out in a usable form?

      I do have a grudging respect for OLAP, in one regard: put together a decent schema, and new elements can generally be added by inserting one row in the description table, not by changing the schema itself. That really lends itself to ease of maintenance. But, again, it does require *some* up-front design work.

    13. Re:could just be the beginning by MichaelSmith · · Score: 1

      99% of Oracle installations could be replaced with SQLite

      Ah no. sqlite can't even handle my little embedded applications because it falls over when accessed from more than one process at a time. I have seen a webapp with an openoffice back end. Works surprisingly well.

    14. Re:could just be the beginning by lrichardson · · Score: 1

      Yeah, I kinda threw that in as a complaint, but you're absolutely right: it doesn't support concurrent processing very well at all. Then again, I've seen one installation where it was used only to pull info during the day, and updated (batch) at night. They simply created a couple dozen copies of the database itself. Which isn't all that different than one of the Oracle options. Although, in this case, the developer put a tricky little bit in, so each DB had one user at a time. Insane, and not particularly scalable, but it worked just fine for this instance.

    15. Re:could just be the beginning by udachny · · Score: 0

      I agree that many data models out there are outrageous and do not warrant using Otacle, etc., but just a number of tables doesn't mean anything. My smallest projects have tens of tables, large ones start from about 150, a large project I am running has about 380 but by themselves these numbers don't say much.

    16. Re: could just be the beginning by Anonymous Coward · · Score: 0

      Here, have some candy.

    17. Re:could just be the beginning by Anonymous Coward · · Score: 0

      When is Microsoft going to buy Red Hat?

    18. Re:could just be the beginning by EmperorOfCanada · · Score: 1

      I would bump that up to 100%. The only times I have used Oracle in my career (which would be about 50 times) was when a client said something stupid like, "We are an Oracle House, do you use Oracle?" Then after I would swallow my vomit, I would show them a list of all the clients where I used Oracle.

      Not once in my entire life have I even thought, "Oracle would be best for this." It would be like looking at my flowers in the garden and thinking, "They would grow better if I threw butter at them."

      If you look at leading companies at every level of the spectrum with various data needs, none of the leaders use Oracle. Visa, Facebook, Google, etc. I don't know of any of the profitable airlines. I don't know of any of the leading banks. I have never seen Oracle in a viable finance company.

      The pattern of Oracle buyers seems to be companies that want to pretend they are big. So small chains of financial advisers, franchises that are desperate to grow, small time phone companies, stupid governments. It like those fools who think that by having the fanciest Visa card that they are somebodies. No you are just a fool who paid too much for what everyone else gets for far far far less.

    19. Re:could just be the beginning by Tablizer · · Score: 1

      Maybe I haven't been keeping up, but they lose lots of their original advantages by doing such.

    20. Re:could just be the beginning by angel'o'sphere · · Score: 1

      Why would they?
      What has the question if a DB is relational and uses SQL or is non/Relational aka non/SQL aka NoSQL to do with any of the four letters in ACID?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    21. Re: could just be the beginning by Anonymous Coward · · Score: 0

      That depends which highly paid contractor You ask.

    22. Re:could just be the beginning by Tablizer · · Score: 1

      Is this a terminology question or an existing product question? I didn't name the products.

    23. Re:could just be the beginning by Anonymous Coward · · Score: 0

      For the product I am currently working on, we only support Oracle at the customer sites even though it is complete and utter overkill, and inflicts stupid costs for them. If we recommended Postgress, our company would not look serious. The customers rather pay through their noses than meddle with those open source hippies.

    24. Re:could just be the beginning by Yenya · · Score: 1

      I agree with your post. Just a minor nitpick:

      > Massive duplication of data. Joining dozens of tables to get commonly needed data

      You are contradicting yourself, aren't you? Keeping the schema in the normal forms means adding more joins to the queries.

      --
      -Yenya
      --
      While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
    25. Re:could just be the beginning by Anonymous Coward · · Score: 0

      Is this with WAL mode on? It still may not help much if you have consecutive writers, but it did produce a marked improvement when used for MediaWiki, which has a mix of readers and writers.

    26. Re:could just be the beginning by Anonymous Coward · · Score: 0

      I have never seen Oracle in a viable finance company.

      Then you haven't looked hard enough. Or at all. I've done backup and recovery work at a few of Australia's big four banks (not naming which ones, specifically, but that narrows it down to a subset of ANZ, Westpac, CBA, and NAB.) Every one of those that I've worked at uses Oracle in some capacity. Every. Single. One.

      I don't know exactly what those databases were used for - I only managed backups, and made sure that the systems underlying the backup technology were reliable. But the fact remains: they were there, they were being used, and they were important to the companies.

      Now, whether or not they actually needed to use Oracle is another question entirely, and one I can't answer - I simply don't have that depth of knowledge about the systems in question. But to assert that "I have never seen Oracle in a viable finance company" strongly suggests to me that you're just making up BS to sound like you know more than you actually do.

    27. Re:could just be the beginning by angel'o'sphere · · Score: 1

      You are the one who started by "claiming" NoSQL would be non ACID ... so up to you if it is a terminology question.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    28. Re:could just be the beginning by hattig · · Score: 1

      Exactly. If your company can afford a DBA team, then Oracle is an option. This will likely keep the money rolling in to Oracle for the foreseeable future.

      If your company can't afford a DBA team, then you really need to look elsewhere, where-ever that may be (IMO PostgreSQL and Cassandra, maybe MongoDB, maybe ElasticSearch stack) and do a short period of trialing / proof-of-concepting to see what works best. However in this case one suggested recommendation is that you choose ONE company-wide SQL solution and ONE company-wide NoSQL solution, and only allow exotics on a case-by-case basis when the need is demonstrated.

  6. Inappropriate customers by Anonymous Coward · · Score: 1

    I'm guessing that the Oracle customers that are most easily convered are those who shouldn't have been using oracle in the first place.

  7. Oracle != Mongo by Anonymous Coward · · Score: 4, Informative

    Mongo is NoSQL, it can't steal business from Oracle at a large scale as processes would have to be completely rewritten to use NoSQL....and while the new setup would be faster, it would lose transactions and the ability to roll them back, among other things.

    1. Re:Oracle != Mongo by WaterDamage · · Score: 1

      BINGO! This is what the original poster doesn't get by making such a ridiculous claim. Now, I'm all for Mongo and use it myself but NoSQL has it's place but anyone that knows anything about enterprise scale apps, security and transactions knows that SQL and NoSQL are worlds apart.

      Soon well be seeing headlines with "This is the Year of NoSQL" which remind me of the flavor of the month "This the year of the Linux desktop" or "This is the Year of Ruby on Rails with Gems" failed attempts to detrone the kings like Sun's Java or Microsoft Windows as they've been running those failed mottos since 1999 and to this day Java is the king and Microsoft owns the desktop market despite it's many horrendous OS offerings over many decades. hahahahaha

    2. Re:Oracle != Mongo by fluffernutter · · Score: 1

      NoSQL just seems loosey-goosey to me. Usually structure is there for a reason. How can a hundred people in an organization work on a database that can change on a whim by any one of them?

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    3. Re: Oracle != Mongo by Anonymous Coward · · Score: 0

      Each record could have a different structure. Add a flag to one record.. now you have a default default field.

      A single customer record needs to support an array of new types.. include it on your next insert..

      Its very flexible.

    4. Re: Oracle != Mongo by _merlin · · Score: 2

      You've completely sidestepped the question. How do you use MongoDB and its ilk in situations where you need transactional consistency or fine-grained permissions?

    5. Re:Oracle != Mongo by Anonymous Coward · · Score: 0

      nosql had its year some years ago.
      Now its just withering away, as people found out, that its not better than in-memory-hashmaps if used for caching and not better than sql solutions if data integrity matters.
      nosql has no longer any legitimate usecases. (never had in the first place and only lived on hipsters and hypes and WEBSCALE!)

    6. Re: Oracle != Mongo by Anonymous Coward · · Score: 0

      nothing that is impossible with relational DBs.

      Also: will your random changes break all other users (Websites, Report-generation tools, ...) of your unstable shitass database?

    7. Re: Oracle != Mongo by Anonymous Coward · · Score: 0

      You don't at the database level. Mongo is not suited to that model. Fine grained control like that should be handled in the application layer, if you are using something like mongo

    8. Re:Oracle != Mongo by angel'o'sphere · · Score: 1

      NoSQL DBs don't lose transactions and while they are in the process of doing one, they can roll back as any other DB can. Otherwise it would not be a DB ... get a clue.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    9. Re: Oracle != Mongo by angel'o'sphere · · Score: 1

      That is a pretty dumb question ... sorry to say that as I'm usually a protagonist who says: "there are no dumb questions, but only dumb answers".

      To answer your dumb question: you don't use MongoDB in scenarios where you need transactional consistency or fine-grained permissions

      Facepalm

      Use the right tool for the job, and stop pretending that other tools have no right job where they are useful or more useful than the tool you use for your job.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    10. Re: Oracle != Mongo by Anonymous Coward · · Score: 0

      Explain. As I've experienced, you cannot mark a connection as transactional, make three separate calls, have the third fail, and then have it auto rollback all three calls.

    11. Re: Oracle != Mongo by Anonymous Coward · · Score: 0

      Uh, if the poster didn't understand that transactional consistency is not a great fit for MongoDB then it's not a dumb question.

      Obviously, the poster isn't as familiar with MongoDB as you. The poster's lack of understanding makes that a pretty crucial question actually.

      What's your excuse for your lack of understanding of what constitutes a dumb question? You don't come off as exactly brilliant.

    12. Re: Oracle != Mongo by buchanmilne · · Score: 1

      Maybe it was a rhetorical question.

    13. Re:Oracle != Mongo by Anonymous Coward · · Score: 0

      In RDS, a transaction cant be started and there could be three successful calls, then a failed call, and the previous 3 calls would be rolled back. That can not be done with Mongo.

    14. Re:Oracle != Mongo by hattig · · Score: 1

      Why are hundreds of people working on the same objects directly? That's screaming for a microservice interface on top for the 95% who are doing the same operations. And then suddenly the underlying system doesn't matter.

      Most NoSQL solutions have a structure to the documents (because in the end they're serialised forms of Java/C#/etc objects), it's just that it isn't columnar. There can be arrays, inlined sub-objects, etc. And you can set indexes on these deeper aspects, and so on. The DB is optimised for tweaking at the object level of course, and locks at the object level (but doesn't provide multi-object transactions out of principle).

      Some NoSQL solutions add some very cunning features to how you can define the structure of the data, you can do some funky things with Cassandra's slices, for examples (although it's been some time).

    15. Re: Oracle != Mongo by hattig · · Score: 1

      What sort of transactional consistency do you require?

      Do you care if it takes a short period to replicate across the cluster before it can be read again? NoSQL solutions include options, if you need that (e.g., i don't care, i want a quorum agreement on the read, all must agree (read from master, enforce writes through master), etc). Indeed these options are often what distinguish one NoSQL solution from another.

      Are you only modifying a single document? Then you can do that atomically. Remember that document may represent a lot of tables in a RDBMS.

      And maybe this use case is simply not suitable for a document database. RDBMS is great at these things - it just isn't great at some things NoSQL is great at.

    16. Re: Oracle != Mongo by hattig · · Score: 1

      But those three calls in an SQL DB might map to the same single document in a NoSQL DB! Indeed that's one of the reasons for transactions in an SQL database - the tabular structure with fixed columnar schemas pretty much requires transactions for safety.

      Maybe you only care about eventual consistency too?

  8. If all you have is a hammer... by snookiex · · Score: 3, Interesting

    I won't waste my time explaining you why NoSQL databases are suitable for many use cases, as your post is a flamebait, however I will tell you a bit about my first-hand experience: I'm one of the developers of an open source network inventory application (see signature). We started out by using an RDBMS, but one of the requirements was to provide a dynamic data model and using a schema-based database brought a lot of problems to the table. Besides, we quickly realized that the best way to represent a network was not a bunch of linked tables but a graph, because that's what telecommunications networks are.

    --
    Open Source Network Inventory for the masses! Kuwaiba
    1. Re:If all you have is a hammer... by haruchai · · Score: 2

      I think I'll give your Kuwaiba a try. I've started to evaluate some network inventory applications for when we ditch our managed services provider in the next couple years

      --
      Pain is merely failure leaving the body
    2. Re:If all you have is a hammer... by snookiex · · Score: 1

      Cool :) Any feedback is greatly welcome.

      --
      Open Source Network Inventory for the masses! Kuwaiba
    3. Re:If all you have is a hammer... by fluffernutter · · Score: 2

      NoSQL to me seems both uninteresting and interesting at the same time. I big part of the justification of it seems to be 'I don't want to work with a set schema'. Well there are reasons for schemas and just because it seems inconvenient, usually that isn't a reason for doing anything and you're just going to shoot yourself in the foot in the end. The more interesting aspect of nosql is its ability to easily scale across multiple small servers, as opposed to an SQL database which is a big monolithic thing that is difficult to separate.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    4. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      Not all NoSQL databases are equal; Cassandra has schema's.
      Obviously, all NoSQL databases lack features that an SQL databases has, otherwise it'd just be an SQL database.
      And vice versa, all SQL databases lack features that NoSQL databases have.

      If they didn't call it "NoSQL" but "Document stores", people wouldn't be so against it; it's just be an alternative database that is not to be a relational database and therefore happens not to use SQL, like so many other databases before and after SQL.

    5. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      Many NoSQL products do require you to establish a schema for productive / production use cases. For the most part, the NoSQL data stores that do not allow a schema will result in slower search time execution because they're inevitably doing it on the fly, which is both an advantage, but also a disadvantage.

    6. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      but one of the requirements was to provide a dynamic data model

      In my experience demands for a dynamic data model usually come down from above because management and the "designer" consultants they hired are too lazy or stupid to think about what their data needs actually are or will be. They get sold on the ideas of a flexible and schema-less data model without appreciating any of the downsides. A well tailored schema on an RDBMS can kick the pants off a schema-less pile of mud and transactions totally suck until you really need them and don't have them. An RDBMS forces you to think about your data and the problems you want to solve ahead of time and frankly, for most projects, that's a good thing.

    7. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      The more interesting aspect of nosql is its ability to easily scale across multiple small servers, as opposed to an SQL database which is a big monolithic thing that is difficult to separate.

      Scaling as a problem is overrated. Every startup imagines that they're going to grow at a rate of 100% per year once everyone realizes how awesome their widgets are, so they focus on scaling before they even have that problem, neglecting their real problems, and end up going bust long before they bump up against the limits of an RDBMS. First question to ask before writing code, "Do we actually have the problem that we think we have?"

    8. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      So, they're filesystems?

    9. Re:If all you have is a hammer... by war4peace · · Score: 1

      Arguably off-topic, but I would really be interested which solution you think is better for a real time grand strategy multiplayer game involving a LOT of data. A database is a must, but which, i'm still struggling to figure out.
      The DB would include a few million solar systems with celestials attached to them, also ships, colonies, planetary bases, celestial bases, a full economy and so on.

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
    10. Re:If all you have is a hammer... by angel'o'sphere · · Score: 1

      Actually you would not use a DB for that.
      The prime mistake of plenty of such endeavors is that they use a DB ...

      If you want to call it a DB, then yo use a "main memory DB". Obviously you have to shard it by solar system or clusters of some systems. But you would keep all state in memory. Only write stuff to disk to be able to recover from a crash.

      E.g. http://www.prevayler.org/

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    11. Re:If all you have is a hammer... by fluffernutter · · Score: 1

      Then I think I get NoSQL even less, since that seems to be listed as one of the main benefits to NoSQL on any 'Why use NoSQL' page that I read.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    12. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      Not all NoSQL databases are equal; Cassandra has schema's.

      False. Cassandra has *keyspaces*. Each row can contain whatever "columns" it likes. Trying to use Cassandra for anything else but hash key or hash key + range key is an exercise in aggravation.

    13. Re:If all you have is a hammer... by Hylandr · · Score: 1

      It's great for developers but Mongo doesn't scale well to big data-sets. Sure you can increase the size of the instances running the replica set, but you can't get around the latency copying large data sets introduces.

      There's a reason relational databases have been around since the 70s.

      https://en.wikipedia.org/wiki/...

      --
      ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
    14. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      Thank you for posting an example that is something other than social networking.

    15. Re:If all you have is a hammer... by Squash · · Score: 1

      Not quite. Filesystems have mature tools for backup/restore/versioning that are efficient for individual records (files)! But you generally don't access them with json queries.

      --
      Squash
    16. Re:If all you have is a hammer... by snookiex · · Score: 1

      Yes, it's always about the scenario you have to face. For example, the idea of the project is to provide (in the future) a complete open source OSS (Operations Support Systems) suite. The next application in the pipeline is a Trouble Ticketing system integrated with the inventory. We have chosen an RDBMS as backend which will coexist with the inventory's graph database. Some of the reasons that led us to take that decision is that this kind of application is better modeled as a set of tables (in the end is just forms, tables and reports), the data model won't change [that much] once it's deployed and text indexing to serve searches is already proved to be efficient and reliable in major relational databases.

      --
      Open Source Network Inventory for the masses! Kuwaiba
    17. Re:If all you have is a hammer... by ADRA · · Score: 1

      Know your requirements first, and figure out solutions secondly.

      Considering a solar system is very well partitioned already with almost no outside bleed, you could probably get by with something like Cassandra. If you're in love with 'documents' representing your sytems, you could use MongoDB.

      If you want to support features that involve extra-solar system queries, you may want to stick closer to traditional RDBMS. I'd chime in more, but I have to go!

      --
      Bye!
    18. Re:If all you have is a hammer... by snookiex · · Score: 1

      I second angel'o'sphere. Without knowing details about the requirements, it seems that an in-memory database serves your purpose, periodically saving the most relevant states and user settings. You can handle the load and availability/resilience scaling horizontally. Just a random thought.

      --
      Open Source Network Inventory for the masses! Kuwaiba
    19. Re: If all you have is a hammer... by Anonymous Coward · · Score: 0

      Doesn't scale? But...it's webscale!

    20. Re:If all you have is a hammer... by Parker+Lewis · · Score: 2

      using a schema-based database brought a lot of problems to the table

      Pun intended?

    21. Re:If all you have is a hammer... by lkcl · · Score: 1

      I won't waste my time explaining you why NoSQL databases are suitable for many use cases

      at the request of a client i did an evaluation of a range of databases, mongodb, postgresql, mysql, and after none of them matched up to the required performance tried leveldb and lmdb (which ended up the winner by a long, long margin). mongodb's performance was the worst of the worst. it wasn't so much that it was below the performance of the other databases, it was the *MASSIVE* pauses which began after about 90 seconds of continuous INSERTs, and continued to increase to over THIRTY SECONDS, that really put the nail in its coffin.

      so after only ten minutes of INSERTs i gave up on the testing because it was clear that mongodb had some form of internal cacheing and administrative overhead that took absolute precedence over data entry. as the use-case was for the storage of real-time data, having massive pauses that effectively took the entire database offline was completely unacceptable, and i will not be using mongodb, ever.

    22. Re:If all you have is a hammer... by snookiex · · Score: 1

      Yeah, I've heard horror stories about MongoDB. My rule of thumb is, if whatever you are going to do can be done with an RDBMS without much hassle, you just go for it, it's proven and support is widely available. If your requirements demand something more exotic, try other options. Just out of curiosity, did you evaluate CassandraDB? I worked for a company that switched from MySQL to CDB. Their main product was having performance issues, but I think it was caused by database modeling mistakes rather than a db engine thing. I was a bit skeptic about the migration, but I left before I could see the results.

      --
      Open Source Network Inventory for the masses! Kuwaiba
    23. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      I guess you're excited about the graph features in MongoDB 3.4 then... even though it boils down to a recursive 'join' in the end.

      OP is an idiot though, there is a need for document databases, and he shows a clear lack of understanding of 'schemaless', thinking it means 'might as well be random'.

      Still, RDBMS are nice and comfortable for many developers. No need to wrap head around something else, even if the data being stored isn't a good match for columnar multi-table storage.

    24. Re:If all you have is a hammer... by hattig · · Score: 1

      A lot of the NoSQL stuff out there is trite tosh.

      MongoDB (and others) is best thought of as being a document database, rather than a columnar database. Think of what makes up, say, an Order - in Mongo, that's one document. In RDBMS it is several data tables and join tables, even though the data is only indexed from the primary 'orders' table.

      A NoSQL DB will still index on specific fields that you specify. It still has a query language, even if it isn't SQL, it might have relations between fields in documents, and so on. You might still deserialise from the DB into a strictly defined object at the code level (there's your schema), and so on.

      There are pros and cons, of course. You may decide that using PostgreSQL with its JSON types is a middle ground you can accept. You may be perfectly happy with multi-table columnar storage for documents. You might be wary of MongoDB in particular because it had a load of teething problems and data resiliency issues.

      I think what many people can accept is paying for fewer new Oracle installs within their company.

    25. Re:If all you have is a hammer... by fluffernutter · · Score: 1

      What I don't understand is how something like MongoDB optimizes searching. In a relational database the focus is on the field, so if you want to search by last name and date or by order number you make an index that has last name and date fields, and another that has order number. If the whole order is just one glob, how do you signify that certain fields should be made more efficient than others?

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    26. Re:If all you have is a hammer... by Anonymous Coward · · Score: 0

      Yay, two databases for a single dataset - the RDBMS and the Graph DB... in no way will you have issues with that down the line :D

      The issue here is that the application has been modelled as tables up front. Why? A Ticket (with comments, etc) is a single document. An Inventory Item is a document. An Order is a document. A Report is a document. A Form is a document. MongoDB can do graph based recursive searches (from 3.4) so you can hunt 'related popular items' and so on, in a single query to the DB.

      God I used to think tabular too, don't get me wrong. Many many times I have lovingly crafted a schema with dozens of tables for what is actually just a single document... and the application would just recursively build the document from those tables, and vice versa, but only care about very specific indexes...

    27. Re:If all you have is a hammer... by hattig · · Score: 1

      You could have a massive relational schema, or you could model those items you talked about as documents in a NoSQL solution. I'm guessing that the ratio of reads to writes is skewed massively to the reads, so this indicates a nicely scaled sharded DB to handle the load.

      Solar System: Name, Location, Attached (permanently) Celestials and Constructs. Lookup geo-spatially (3D) would be nice in the DB, to get systems close to you. Seems to map well to a document based storage.

      Obviously you would cache it all in memory at run-time (write through for performance), but most DBs can provide that natively these days. What does a typical application store in memory - complex objects. Maybe that could determine what the backing permanent-storage DB should be.

    28. Re:If all you have is a hammer... by hattig · · Score: 1

      TBH MongoDB 3.4 has graph queries. So assuming Solar Systems are linked by 'trade routes' or 'warp jumps' or even just linked to all systems within X light years, you should be able to use that effectively for route planning, getting all near systems, and so on, without a complex 3D geo-spatial lookup.

      But it is application specific, without knowing the requirements, who knows what the use cases are.

      But yeah, "Get System Trading 'Gold' Ordered By Distance From Me" is your typical space trading game query. I suspect MongoDB can do that in a single call to the DB. RDBMS might require you to do multiple steps to collate that data (or the most horrible of multi-table joins).

    29. Re:If all you have is a hammer... by war4peace · · Score: 1

      There are massive reads and writes too, with it being a multiplayer game pretty much every action you take needs to be written and made available to others instantaneously.
      For example: player A selects a fleet from his colony X and sends it to colony Y. Player B could scan the solar system the very next second and detect that fleet leaving. Or player B could scan planet X repeatedly to determine the moment the fleet belonging to player A left planet X.

      Typical empty (not player-altered) solar system contains the following:

      - System-wide attributes (galactic zone, regional effects, ownership breakdown data to name a few)
      - Star(s) with all their attributes: size, type, subtype, temperature, default name, star catalog code, location both on spherical and Cartesian coordinates and so on.
      - Planets with all their attributes: size, type, subtype, default name, coordinates, resource types, gravity, density, etc.
      - Other celestials (both permanent and temporary) with all their attributes. Celestial types are many: Asteroid fields, comets, moons, sites (a subtype including AIs, pirates, Archives, Cosmic Anomalies, Battle remnants, beacons, Ancient Ships, Wormholes, Artifacts, Gates, etc) each with their own attributes and subtypes.

      Populated / discovered systems contain all of the above and in addition you have player-related items, ranging from colony development to fleets and space-based deployed or mobile structures.

      Some parent attributes (e.g. system-wide ones) affect child object attributes, so there is complex relationship data between objects.

      I confess I am a newbie in relation to database architecting, and as such I won't design it (will let experts handle that). But when choice of a data storage solution comes, I would very much prefer to be knowledgeable at least about the basics, otherwise wrong choices could prove disastrous.

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
  9. I just "bought into" Oracle yesterday by Trax3001BBS · · Score: 1, Funny

    No troll, just the facts relating to me.

    It time for me to run Win7 as a VM OS (I can fresh install my Win7 as often as I want -on this computer, and my numbers don't go over ( those added for each upgrade). This with Linux Mint (cinnamon).

    Did the research and Virtualbox was the software I went with as it met my every need https://www.virtualbox.org/. While it cost nothing up front, I'm into Oracle now.

    1. Re:I just "bought into" Oracle yesterday by drinkypoo · · Score: 1

      Did the research and Virtualbox was the software I went with as it met my every need

      I take it you're not expecting a video driver that works worth a damn.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:I just "bought into" Oracle yesterday by Dutch+Gun · · Score: 1

      If you didn't have to consult a lawyer and sign a few contracts, then you didn't "buy into" Oracle.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    3. Re:I just "bought into" Oracle yesterday by WaterDamage · · Score: 0

      Offtopic, but to answer your stupid trolling and hopefully shut you up, video drivers are handled at the host OS level, VM Hypervisors have no bearing on finding a video driver to the guest OS. You must be stuck in 1993 and still be using MS-DOS where this was an actual issue.

    4. Re:I just "bought into" Oracle yesterday by drinkypoo · · Score: 1

      Offtopic, but to answer your stupid trolling and hopefully shut you up, video drivers are handled at the host OS level, VM Hypervisors have no bearing on finding a video driver to the guest OS.

      Well, yes, yes they do. First, there is an emulated video card. The emulation is carried out with varying levels of success. Second, there is sometimes a video driver supplied with the emulation solution. This is the case for both Virtualbox and VMware, which come with video drivers. If it's QEMU/KVM (etc.) then it's the QXL driver for SPICE that's most desirable (unless you are using one of the emulated video cards, none of which seem to be emulated particularly well) and if it's DOSEMU then it's again emulated, only one of which works particularly well.

      Virtualbox's video driver system is garbage compared to vmware's, and it always has been.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    5. Re:I just "bought into" Oracle yesterday by Anne+Thwacks · · Score: 1
      If you did not have to give your soul AND your firstborn, then you did not "buy into" Oracle

      FTFY

      --
      Sent from my ASR33 using ASCII
    6. Re:I just "bought into" Oracle yesterday by 0100010001010011 · · Score: 1

      If you don't currently owe Oracle anything you didn't buy into them.

      I'll take the practices of crack dealers over Oracle.

    7. Re:I just "bought into" Oracle yesterday by Sesostris+III · · Score: 1

      For an individual, or even a small organisation, you can even get a fully functional copy of Oracle's database - Oracle Database 11g Express Edition - for free.

      Of course, its when you want to scale, or if you need enterprise support, that the costs start piling up.

      --
      You never know what is enough unless you know what is more than enough. - Blake
    8. Re:I just "bought into" Oracle yesterday by Anonymous Coward · · Score: 0

      Video drivers are shit everywhere, if you want to use them for gaming.

    9. Re:I just "bought into" Oracle yesterday by Anonymous Coward · · Score: 0

      Oracle and crack dealers (and the government) are distinguished by their product, not their practices, or their ethics.

    10. Re:I just "bought into" Oracle yesterday by Anonymous Coward · · Score: 0

      Usually, when people are talking about Oracle, they're talking about the DB server and rarely about their other products, like Oracle SOA, Weblogic or Tuxedo

      There is a large number of products of various quality, that were in the mix of the companies, Oracle, the company, bought.

      When buying Sun, they were after the Hardware-IP and Java. They also got Virtualbox from the deal, which they didn't manage to fuck up yet. They got OpenOffice, which they screwed up massively, along with Glassfish (screwed), Netbeans (still nice), Solaris (screwed)

      Privately, I am a happy Virtualbox user myself, but be on the lookout, in case Oracle salesmen want to change the licensing and cash in on Virtualbox. Working professionally with a lot of the tools and servers mentioned above, i know the company quite well (through their sales reps), i can assure you, it's going to happen within the next 5-10 years, depending on it's installbase.

    11. Re:I just "bought into" Oracle yesterday by 0100010001010011 · · Score: 1

      or their ethics.

      Don't speak that way about crack dealers please.

    12. Re:I just "bought into" Oracle yesterday by EmperorOfCanada · · Score: 1

      Piling up is not the half of dealing with Oracle. I would have my local used car dealership blindly handle my personal finances before I would deal with an Oracle sales person again.

    13. Re:I just "bought into" Oracle yesterday by EmperorOfCanada · · Score: 1

      I say fu Oracle, every time I use Virtualbox. I has bugs but it does what I want. I find that VMWare molests my machine in ways that make me unhappy.

    14. Re:I just "bought into" Oracle yesterday by Trax3001BBS · · Score: 1

      Did the research and Virtualbox was the software I went with as it met my every need

      I take it you're not expecting a video driver that works worth a damn.

      Two thing here I have an old hauppauge video capture card I plan on ripping CD's with - it uses RCA jacks, this from FreeDos who has a driver for it.

      I have VT-d for VM, it lets the VM'd OS have directed I/O access to the Video card, hard drives, and network

    15. Re:I just "bought into" Oracle yesterday by Trax3001BBS · · Score: 1

      Offtopic, but to answer your stupid trolling and hopefully shut you up, video drivers are handled at the host OS level, VM Hypervisors have no bearing on finding a video driver to the guest OS. You must be stuck in 1993 and still be using MS-DOS where this was an actual issue.

      Take it as a troll if you wish, it would be my first time, so different, video's fairly covered.

      I did use it once before many years ago using VMware, and Apples snow leopard, video wasn't a problem. Playing my games was and I only had it installed a day.

    16. Re:I just "bought into" Oracle yesterday by Trax3001BBS · · Score: 1

      Offtopic, but to answer your stupid trolling and hopefully shut you up, video drivers are handled at the host OS level, VM Hypervisors have no bearing on finding a video driver to the guest OS.

      Virtualbox's video driver system is garbage compared to vmware's, and it always has been.

      I sure didn't want to hear that, I spent a bit of time with wikipedia.org comparing charts of different comparisons, Virtualbox sure seemed to work for me.
      I don't use windows anymore so my gaming days are over, steams ok but all I have are bad titles.

    17. Re:I just "bought into" Oracle yesterday by Trax3001BBS · · Score: 1

      I say fu Oracle, every time I use Virtualbox. I has bugs but it does what I want. I find that VMWare molests my machine in ways that make me unhappy.

      Well it would appear I was the only one who didn't know, I dropped windows, win7 are for those times windows has to be used, yet Wine seems to do just fine, Agent Ransack is the only must have program of mine that just won't even try to install,

      But I'm enjoying playing around with Linux Mint (cinnamon), that's my game now, getting those applications running that just don't want to, Auth2DB at the moment.

  10. SQL/NoSQL: false dichotomy by jlowery · · Score: 1

    There's going to be a knife's-edge of difference between SQL and NoSQL databases in 5-10 years. Queries are being added to NoSQL databases, and JSON navigation/indexing is being added to SQL databases. Evaluating them in terms of performance, ease-of-use, and standards is going to be time-consuming.

    --
    If you post it, they will read.
    1. Re:SQL/NoSQL: false dichotomy by Anonymous Coward · · Score: 0

      I disagree. There's a big difference between having transactions and not having transactions. Yes, when you stick XML in Oracle or JSON in PostgreSQL, as are both very common, yes the line gets fuzzier, but lack of transactions will always be a shows-stopper for many use cases.

    2. Re:SQL/NoSQL: false dichotomy by Anonymous Coward · · Score: 0

      Exactly. There's also a difference between Consistent vs. Eventually Consistent. These NoSQL products trade off a lot of features in order to get the ability to scale horizontally. And, really, calling it "NoSQL" at all is really a misnomer. There is a query language. It is structured. Compared to typical SQL databases, it's also extremely limited, but that doesn't make it any less query-y or structure-y.

      There's really not much of a different between these "NoSQL" databases and some other database product with a two column table (key, data blob) and a lazy replication strategy.

    3. Re:SQL/NoSQL: false dichotomy by ADRA · · Score: 1

      Both exist. Well, XML navigation into SQL, but same-ish difference. There are a laundry list of SQL drivers pasted over NOSQL equivalents.

      The only problem is there's no universal ODBC / SQL that can just work accross all architectures. SQL has warts and is effective at a specific philosophy of data architecture, but it was a universal standard for decades, making the problem domain relatively simple to embrace. There's no standard that 99% of the dev's out there can use and embrace out of box, which will just help propagate the vast trove of incompatible solutions that exist presently.

      --
      Bye!
  11. Hur hur by Anonymous Coward · · Score: 0

    "Mongo(loi)DB" hahahaha hahaha hahahahaha hahahahaha hahahah RETARDS!

  12. If all SQL you know... by Anonymous Coward · · Score: 0

    If all SQL you know is MySQL, it's clear that you long for NoSQL.

    There are, you know, decent SQL databases out there.

    1. Re:If all SQL you know... by Anonymous Coward · · Score: 0

      Because MYSQL is the slowest as fuck ever.

      THIS CURRENT query has literally been running 89945 (24 hours) WITH NO END IN SIGHT

      There must be a new way.

  13. Similar high level stategy. by HornWumpus · · Score: 1

    One consultancies business model could have been cynically described as "Feast on E?S divisions' former clients in the energy industry." Feast we did.

    It was a good business model for the same reason noSQL strategy is good. Nobody likes repeated financial sodomy by smug suits who don't deliver, we're looking at you Oracle marketing.

    On the other hand, the JavaScript everywhere model is just silly. Storing _everything_ as JavaScript JSON objects makes at much sense as storing _everything_ as XML objects did. People who don't know history...but if the object is to sell out before failing then bravo.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  14. Guess that means they really are Web Scale!! by haruchai · · Score: 2
    --
    Pain is merely failure leaving the body
  15. Why not postgres? by shoor · · Score: 1

    OK, I'm not a DBA (IANADBA? Hmm, I like the sound of that, 'yanadba', which syllable to put the accent on though.)

    But, really, why do corporations not use postgres? Is it some inherit deficiency in the product? A general antipathy to Open Source? Lack of publicity and marketing on the part of Postgres? Nobody from the company to hold the customer's hand when they first get it? (In that case, maybe there needs to be a Red Hat Postgres) Or something else?

    --
    In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
    1. Re:Why not postgres? by Voyager529 · · Score: 2

      OK, I'm not a DBA (IANADBA? Hmm, I like the sound of that, 'yanadba', which syllable to put the accent on though.)

      But, really, why do corporations not use postgres? Is it some inherit deficiency in the product? A general antipathy to Open Source? Lack of publicity and marketing on the part of Postgres? Nobody from the company to hold the customer's hand when they first get it? (In that case, maybe there needs to be a Red Hat Postgres) Or something else?

      Honestly, it may be a bit of everything, but I'll share my own personal anecdote...

      I used to provide desktop and network support to a relatively small insurance company (about a hundred employees). Their line-of-business application that handled everything from claims to brokers to billing was coded and maintained by a firm who built the product on an Oracle backend. It's a relatively small Oracle installation - $90,000/year was the number I remember hearing, which is obviously peanuts for an Oracle install.

      The coding company was mortified of change. Virtualizing the old Solaris boxes was months of meetings and performance metrics ("virtualized servers will be slower" - we were migrating from servers old enough to still have "Sun Microsystems" logos on them to a high end Poweredge blade chassis...). The people coding for it knew Oracle and Java, and genuinely believed that "write once, run everywhere" was a promise that Java delivered - it took over a year to convince them that "running in IE compatibility mode was not a long-term solution"; the product was indeed written for IE6, though to be fair they did indeed update it to run properly in Webkit and newer iterations of Trident.

      Checkbox Compliance is a very, very powerful thing. No matter how much PostrgeSQL and EnterpriseDB promises to be a drop-in replacement, and no matter how true that actually is, the fact that it isn't "Oracle" scared the crap out of the developers and the people who supported them. MariaDB was able to overcome this to an extent because it was literally the exact same code at the beginning, and answered to the same SQL commands (still using 'mysql' where appropriate). The first time something goes wrong, no matter whose fault it is, it's blamed on the recent change. It very well could be - and probably is - someone else's fault...but when you're dealing with management - even remotely competent management - and saying that something they asked for isn't going to work right because Postgres != Oracle, or the upstream vendor keeps saying "we don't support PostgreSQL" no matter what the issue is (...the website isn't compatible with Edge...), migrating to Postgres becomes a headache for 100% PEBKAC reasons.

    2. Re:Why not postgres? by Anonymous Coward · · Score: 0

      maybe there needs to be a Red Hat Postgres

      Yeap. In most serious organisations there has to be a reliable vendor behind each software application used in production. In some less serious organisations, any open source solution is an issue "because the bad guys can put spyware and stuff in there."

    3. Re:Why not postgres? by 0100010001010011 · · Score: 1

      s/Oracle/Matlab

      s/PostreSQL/Python

      Welcome to engineering.

    4. Re:Why not postgres? by Kjella · · Score: 1

      s/Oracle/Matlab

      s/PostreSQL/Python

      Welcome to engineering.

      Well I understand why you have a hard time replacing Matlab with PostgreSQL :)

      --
      Live today, because you never know what tomorrow brings
  16. MongoDB vs. Oracle by backslashdot · · Score: 1

    Why did he have to comment and get on Oracle's radar?

    1. Re:MongoDB vs. Oracle by Anonymous Coward · · Score: 0

      So Oracle would see they are a big business and competitor and try to buy them out.

  17. Transactions and Eventual Consistency by bigbang137 · · Score: 1

    At minimum, transactions and eventual consistency are two reasons why you'd want SQL over NoSQL. Personally I also think that a good SQL schema would allow for faster queries on a single host than schemaless NoSQL would on multiple hosts.

  18. Mongo like candy by Anonymous Coward · · Score: 0

    KABOOM!

  19. Oracle Sucks, but.. by Anonymous Coward · · Score: 0

    There is more to oracle than their database engine..

    1. Re:Oracle Sucks, but.. by HornWumpus · · Score: 1

      Their database is the only thing they make that doesn't suck. Oracle apps...run AWAY.

      They've bought some things with mixed suckage levels (Java) and some more pure suck (MySQL).

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  20. But... by Anonymous Coward · · Score: 0

    ... Is it web scale?

  21. Nice Mongo advertisement by Anonymous Coward · · Score: 0

    Shouldn't this be properly labeled as sponsored content?

    Mongo must be desperate.

  22. That shit is still alive? by Anonymous Coward · · Score: 0

    Wasnt it proven that postgres json and key-value-store are *faster* than mongo plus you get ACID compilant?

    Using noSQL nowadays is like using mysql/MariaDB/... Only shitty startups do, because they either lack the skill or are too hipster for "that ancient stuff" (that would kick their asses in 90% of the usecases, plus: data integrity)

    Because WEBSCALE is all you need!

  23. What's the point of MongoDB? by Anonymous Coward · · Score: 0

    In my experience, MongoDB is worthless. Hell, PostgresSQL does a better job with what MongoDB is aimed for than MongoDB.

    Way too many times I've seen memory leaks causing MongoDB balloon not just to take all RAM as intended, but go into swap, hanging the machines. Even for a database in the megabytes, MongoDB was forcing a machine with 384 GB of RAM to hit swap, and this wasn't due to cache either.

    If you want a real solution, go with something that has stood the test of time.

    1. Re:What's the point of MongoDB? by MichaelSmith · · Score: 1

      Yeah for the servers running mongo I have administered I have put in daily or weekly reboots. Its a crude way to fix the problem bit it seems to work.

  24. Memory leaks by MichaelSmith · · Score: 1

    I have never seen mongo run happily on its own for more than a week at a time. It has to be coddled and administered by hand. Automatic restarts are a necessity,

    So no, its not challenging Oracle right now,

    1. Re:Memory leaks by EmperorOfCanada · · Score: 1

      MongoDB isn't challenging my team of monkeys writing the data into sand on a beach.

    2. Re:Memory leaks by Tablizer · · Score: 1

      So an org has to choose between memory leaks (Mongo) or wallet leaks (Oracle).

  25. No problems with vbox video drivers... by Anonymous Coward · · Score: 0

    as long as I've been using it. Now I'm not trying to play videos in a vm that would be kind of silly.

    I have had problems with running win 10 in a qemu-kvm vm under Centos 7 though.

    1. Re: No problems with vbox video drivers... by Anonymous Coward · · Score: 0

      "not trying to play videos in a vm that would be kind of silly"

      Doesn't that work in any VM? Bit sad if it doesn't and about time it did.

  26. MongoDB is Web Scale by Anonymous Coward · · Score: 0
  27. Some comments completely ignore the use cases by molarmass192 · · Score: 1

    When what's in the database is directly related to $$$, like account balances, financial transactions, hard asset tracking, billing, SSNs, payroll, and legal compliance, you use a serious tool like Oracle. Would you trust your paycheck being deposited into your bank account correctly to MongoDB? MySQL? Postgres? Not to say you can't try to do it with those tools, but with Oracle, you can be pretty much guaranteed that even if all your data centers simultaneously sink into the ocean, you can recover your financial data to a consistent state at a known point in time, even if it's from multiple snippets of backups. Oracle's consistency and recovery tools are still second to none in the industry.

    If you're tracking tweets, dating profiles, blog posts, or network traffic ... then your data isn't business critical and you could even use flat files if you were a sadist and really wanted to.

    Look, I use PostgreSQL, Sqlite, and even BigTable for various repositories, they're all very good tools given a use case, but that's not data that would sink the business if it wasn't 100% completely accurate. Those data in those tools can suffer some data loss and, even though it would make for a particularly unpleasant period of work and meetings, the continuity of the business would not at stake.

    --

    Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
    1. Re:Some comments completely ignore the use cases by EmperorOfCanada · · Score: 1

      This is like the old BS about "Nobody was ever fired for using IBM" well Oracle is about the same as all the rest. The only time any of the major DBs lose data is during some crazy edge case. Server A was on fire, Server B had a HD failure on the raid and a bug in the raid slowed the whole system to a crawl, and C it was superbowl night and this was a NFL score keeping site.

      When I do mission critical data storage, I don't just kind of throw it into any DB and hope for the best. There are logs, logs, and more logs that can be used to rebuild the datastore. There are checksums, hashes, etc. that verify that things have remained as they should be, and as truly mission critical gets reached, there are whole other systems, using whole other architectures that do the same thing and then verify the results of the primary system.

      I have literally seen no realiablity difference between Oracle, Sybase, Postgres, MySQL, MariaDB, and even SQLite. Data goes in, and data comes out. If you work near the edges of any of them, then prepare to get burned. If you stay in the happy zone then things just work. To use your example of a bank, it isn't a problem to use hardware and specifications that are multiples of what is needed, keeping everything boring and safe.

      If I were trying to run my banking DB from a beaglebone storing on an SD card, then I would recommend everyone switch banks regardless of DB.

    2. Re:Some comments completely ignore the use cases by MichaelSmith · · Score: 1

      use flat files

      ...or redis but then I repeat myself.

    3. Re:Some comments completely ignore the use cases by Anonymous Coward · · Score: 0

      When what's in the database is directly related to $$$, like account balances, financial transactions, hard asset tracking, billing, SSNs, payroll, and legal compliance, you use a serious tool like Oracle. Would you trust your paycheck being deposited into your bank account correctly to MongoDB? MySQL? Postgres? Not to say you can't try to do it with those tools, but with Oracle, you can be pretty much guaranteed that even if all your data centers simultaneously sink into the ocean, you can recover your financial data to a consistent state at a known point in time, even if it's from multiple snippets of backups. Oracle's consistency and recovery tools are still second to none in the industry.

      If you're tracking tweets, dating profiles, blog posts, or network traffic ... then your data isn't business critical and you could even use flat files if you were a sadist and really wanted to.

      Look, I use PostgreSQL, Sqlite, and even BigTable for various repositories, they're all very good tools given a use case, but that's not data that would sink the business if it wasn't 100% completely accurate. Those data in those tools can suffer some data loss and, even though it would make for a particularly unpleasant period of work and meetings, the continuity of the business would not at stake.

      Unless you work for Oracle, you are a jackass. First, MongoDB, MySQL, and PostgreSQL are different classes of databases. Second, YES, "business critical" data can be and is stored safely in databases besides Oracle.

    4. Re:Some comments completely ignore the use cases by Anonymous Coward · · Score: 0

      Would you trust your paycheck being deposited into your bank account correctly to MongoDB?

      No.

      MySQL?

      Probably not.

      Postgres?

      Yes.

  28. Sounds like a last ditch effort to get bought by O by EmperorOfCanada · · Score: 1

    I can't say just how much I hate MongoDB. I love NoSQL but MongoDB is made up of the most arrogant assholes to have walked the internet. Maybe Twitter was more Arrogant but I dealt with twitter less. Oracle will rip you wallet out through your asshole but at least the DB is all about just shoving data in, and taking data out. Not telling you that you should alphabetize your fields or some OCD shit that is all about telling me how to do my job.

    MongoDB makes all this noise about how it is about freedom. It is like some kind of North Korean version of Freedom. Freedom to do things exactly as they have specified, and if you stray from the holy path then you are wrong and will be told you are wrong by everyone from MongoDB on every forum ever combined with the DB saying that you are wrong wrong wrong.

    My dream is that MongoDB is on the ropes and that is why they are pulling this MBA shit. With any luck two things will happen. First is that the organization behind MongoDB goes completely under. But that some of the actual developers fork it, fix it, and make what was fundamentally a good idea, actually become a product that I or any developer with a modicum of talent would use.

  29. Isn't it web scale by goombah99 · · Score: 2

    I heard MongoDB is webscale.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  30. MongoDB - try it, and then nove on by Anonymous Coward · · Score: 0

    I am not a fan of MongoDB.

    I found it resource intensive (ti is a small data system, not a big data system) and too variable in its performance and behaviour. I saw individual writes in the write stream being delayed for up to a minute (while all the others around them were fine). MongoDB has no guarantees about ordering of execution of tasks, either. The schemaless design basically faciliaties poor software engineering practises and some of the default behaviours were (to me) highly unexpected and not useful - returning NULL for records rather than an error, other stuff which now after a year or so has passed I can't remember.

    It's a product I would not use again.

  31. Can confirm by pestilence669 · · Score: 1

    I spent months trying to give them millions in license fees. Our millions weren't enough to deal with corporate, so we were directed to third parties. After months of being shit on, we transitioned our entire backend architecture. They could have had their name on some major big-ass product launch, but no. We weren't giving them at least $250m per year. Dealing with Oracle is a bullshit experience. If any Oracle customer could move onto Excel or even text files, they would in an instant. The levels of shit one can endure have no limit when it comes to them. The company is shit. Their customer service is shit, unless you have enough money. It's sad, actually. Oracle, the database, is pretty f'ing awesome. The company... worse than a pyramid scheme run by Hitler.