9 ms·
Think before you Mongo
- devuo 10y agoIt's absurd to use a schemaless database for the simple sake of "rapid" iteration! That is so, so incredibly inefficient. You need — NEED — to understand your domain data (its structure, volume, usage, etc.) before you even begin writing a single line of code or picking a specific DB vendor. This — and only this — will rightfully inform you of what your actual technical requirements are.
- fiatjaf 10y agoThink before you Nodejs.
- mafro 10y agoPlease elaborate. This comment provides little to the discussion.
- ionwake 10y agoHe won't, because he clearly hasn't worked in the field.
- beached_whale 10y agoNot nodejs, but I am in the process of tracking down and event loop loop (e.g. emit( event_id ) somewhere in the path of an event lisener of that name). I assume this can happen within node too. The stack trace is amazing to see.
- debacle 10y agoWhat tool are you using that allows you to see the stack trace on async events? That seems like a good debugger.
- beached_whale 10y agoThe code is based on boost asio, so the io_service is on the same thread as your code if you only start 1. Then after that I am in gdb/ldb. Asio's io_service handles the async calls portion and dispatches to my callback. From there on it is no longer necessarily async. The fun is that I have a higher level event handler sitting above this to register/unregister listeners, like one would in node. If one of those listeners happens to emit a message to what is is also listening for, boom. long store short, it's not the async code per say, but after that.
- fiatjaf 10y agoYes, it is.
- PascalW 10y agoThink before you anything.
- pbreit 10y agoI'm guessing the reference is to Mongo being coupled with Node (eg, MEAN). If you're gonna go MEAN, skip the A and swap Postgres for M.
- NDizzle 10y agoMongo only pawn in game of life.
- dccoolgai 10y agoI agree... but at this point, it's tough to see with all the ink that's been spilled on these issues for years how you could think anything else. Maybe I read HN too much, but the manifold problems with MongoDB have been widely publicized for the past 6 years... it seems pretty close to conventional wisdom that you're going to have those problems if you decide to use Mongo.
- romanovcode 10y agoBecause Mongo is wrongly marketed as "all-in-one" database. Instead it should be marketed as "good database for dynamic data that requires complex filtering, also we have very good drivers for many languages" because that's the only thing it's good at.
- deleted 10y ago[deleted]
- devishard 10y agoBut there are other databases that are good at that, too, and don't drop your data. RethinkDB? RavenDB? Depending on the type of data you're using either of those could be an option, and won't just drop your data randomly.
- romanovcode 10y agoYeah, drivers are not as good tho. That also counts, am I wrong?
- hiphipjorge 10y agoThe RethinkDB drivers are phenomenal in 4 to 5 languages.
- devishard 10y agoI've had nothing but positive experience with RethinkDB drivers. RavenDB has good drivers for some languages, but admittedly not every language is well-supported. Still, I can't see a situation where I would choose a non-working datastore over a working datastore.
- ta0967 10y agolike the yesterday's submission of "Why you should never use MongoDB (2013)" (https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id=12290739), this is all just plain sad because totally unnecessary: the failure of hierarchical databases was obvious in 1960s and was the background of Edgar F. Codd's work on the relational model. unfortunately, this industry is dominated by cocky PFYs (of any age) convinced they don't need to study history of their field and, as a result, don't even recognize they're repeating 50 years old mistakes. sure, SQL has fallen so short of the promise of the relational model it's not even funny, but don't conflate the model with the query language, folks!
- velocitypsycho 10y agoRight tool for the right job. Thinking RDBMS is a silver bullet is just as bad as thinking a document database is a silver bullet. There is room in the world for both.
- ta0967 10y agobut we're not talking about silver bullets: we're talking about models which let you derive most information from your data. mathematics says you will get the most bang for your buck from the relational model. if you like hierarchical databases (data trees), consider that relational database gives you a forest: you can treat any datum as your tree root and bloom from there. with hierarchical, you're tied to a single pre-designated root. both relational and hierarchical databases let you go from department to employee, only one lets you go from employee to their department without enumeration. what purpose does precluding the latter serve?
- electricEmu 10y agoSpeed of development and execution when I don't, and will likely never need, to query that way. I argue you ignored the silver bullet criticism and then immediately doubled down on SQL as the silver bullet.
- 10y ago
- elmigranto 10y ago> Building an MVP on a super-tight schedule (early-stage apps, school projects, hackathons, etc.) This sounds like Proof of Concept, not Minimal Viable Product.
- pbreit 10y agoStill almost always better off on SQL (Lite or Postgres).
- stonewhite 10y agoIs it that time of the year, when mongo-hating blogs start popping up like daisies?
- deleted 10y ago[deleted]
- CodeSheikh 10y agoAny thoughts on Amazon's DynamoDb while we all are fresh on Mongo discussion here? Thanks.
- buckbova 10y agoI'd like to know this too. I've just started a proof of concept s3-lambda-dynamodb project and I'd like to know what others think about it. Also I know document dbs don't aggregate well, but wouldn't it be appropriate to have your app backend in NoSQL and have etl or other duplication to an rdbms or possibly cassandra?
- abhishekash 10y agoIf we treat schemaless is to Mongo then we are sure to abuse it after sometime. There are several other factors to consider. Mongo is NoSQL db and not a greek god of data storage. So, do not curse it for your sins.
- ergo14 10y agoPostgresql 9.4/9.5 offers nice support for JSON type data structures, if someone wants to iterate fast - maybe they should start with that as a baseline.
- seagreen 10y agoAre there any key/value JSON databases that enforce JSON Schema (or some other schema language)? That seems way better to me in situations where you actually care about data integrity.
- mixedCase 10y agoThat'd just be Postgres. When you need an schema you use a normal table, when you need arbitrary JSON data you use a JSON schema.
- seagreen 10y agoI don't think so -- I'm looking for a database that will actually enforce a JSON schema for you -- I don't think Postgres has any built-in support for JSON schematization. I could always do validation before inserting data, but that opens me up to error on my side which I'd like to avoid=)
- mixedCase 10y agoYou are trying to hammer a screw in. If what you want is a facility for the database to provide you with JSON on query, Postgres has a couple of functions for that, namely array_to_json and row_to_json: https://www.postgresql.org/docs/9.2/static/functions-json.html https://www.postgresql.org/docs/9.2/static/functions-json.ht...
- rakibtg 10y ago"We’ve lived and we’ve learned, and now we’re in the process of migrating from MongoDB to PostgreSQL." Why PostgreSQL instead of MySQL?
- shandor 10y ago> Why PostgreSQL instead of MySQL? Why, is there something inherently better in MySQL that makes their second choice also suboptimal? Genuine question, I have very limited knowledge on DBs.
- larrik 10y agoI think Mongo is GREAT at one very important thing: Storing other people's data. If you need to consume other services, especially if its more than one, it's hard to beat Mongo (or other NoSQL databases). You get a lot of search power (not always the easiest to tap, but you get it), and your app won't break when they change their formats. If you need a LOT of it, even better. I would never use it as my main datastore, though. At least not for any projects I can think of offhand.
- deleted 10y ago[deleted]
- BillFinchDba 10y agoI am coming from an 18-year SQL admin/dev background, and am both an MCDBA and MongoDB certified DBA. I and my DEV team have been incorporating MongoDB into our stack for about 5 years now in multiple use-cases. I am using MongoDB in my production environment for things like consuming incoming rates from different vendors, storing and serving pay stubs and client invoices to our web customers, controlling MSMQ message queues, archiving client emails for historical audits, etc. The key here is that they are document oriented entities, not normalized relational data. What it comes down to is a willingness to be agnostic in selection of your database platform. Or more to the point, to let your use-cases drive the platform instead of the reverse. If you are going to develop a use-case that requires frequent partial updates, JOINs between multiple data structures, and traditional entity normalization, then a traditional RDBMS is appropriate. If your case allows for a denormalized mode of storage where all of the relevant information is contained within one document structure, and you can benefit from a fluid design, then MongoDB could be a good fit. If you need ephemeral key-value pair structures such as in session state caching, then something like Redis may be more in line with the requirements. They all have sweet spots that they fill well... We all tend to have our preferred DB "hammer" to drive developmental "nails". What I propose is that we need to have an entire database toolbox from which to choose the right tool for each job. Others have commented here about the need to thoughtfully plan before you write one line of code and/or choose your DB platform. I have to agree completely. You can map a typical relational use-case to MongoDB very easily to start with, but you do need to be able to enforce some level of control. MongoDB does this now with document validation. https://docs.mongodb.com/manual/core/document-validation/ https://docs.mongodb.com/manual/core/document-validation/ You also now have document level atomicity and transaction-like behavior as of MongoDB 3.2. https://docs.mongodb.com/manual/core/write-operations-atomicity/ https://docs.mongodb.com/manual/core/write-operations-atomic... MongoDB, like the rest of us, is constantly iterating and improving. If you have not looked at it lately and are basing your opinions on earlier versions, I would encourage you to take another look... Just my humble opinion...
- jlaustill 10y agoThe author freely admits they tried to do a relational schema in a non-relational database. Then proceeds to say it was the wrong choice of product, instead of design. This confuses me. I use MongoDB as my main database, and it works great for me. However, I did have to learn that it works differently, which meant writing my code differently. My question is this, if you tried to use PostGres and designed your tables super super wide and embedded everything in large object data types and then it got to complicated to manage and figure out, would you consider that a failure of PostGres, or your failure as a developer/architect? I will have to chock this up to a good laugh myself. Lastly, I've used relational databases for most of my career, and I'm very good at writing SQL. But after learning MongoDB and how to use it properly, there isn't a lot that I would want to go back to an RDBMS for. And with the future roadmap of MongoDB, I don't see that changing.