5 ms·
It looks like the NoSQL movement was just a fad and plenty of startups got burned by it and some still stuck with this tech , writing inefficient workarounds fo
by myth_drannon 9y ago
It looks like the NoSQL movement was just a fad and plenty of startups got burned by it and some still stuck with this tech , writing inefficient workarounds for something that comes OTB with the regular SQL databases.
- webscalist 9y agolol trello: https://news.ycombinator.com/item?id=3485186 https://news.ycombinator.com/item?id=3485186
- myth_drannon 9y agowell, there are so many... using mongodb for CRUD apps and realizing they can't do joins.
- paulie_a 9y agoSadly some do not come to that realization and manage to implement a join "solution" anyways.
- redwood 9y agothat comment is over 2000 days old. wow
- stuffedBelly 9y agoStartups got burnt by NoSQL because they wanted to use it for everything instead of thinking over use cases that fit. It's a good thing that this fad went away and now people would be more likely to educate themselves about relational vs. non-relational db before jumping into the fire pit.
- dsmithatx 9y agoI worked with one of the largest ad publishing companies. They wanted to track data about every client served an ad. This generated over 1.2 Terabyte per hour of data when the MySQL master started to max out. We had the largest possible multiple core system. It was going to cost my client $30k to upgrade to SSD drives to get more out of MySQL. Also note we had to store this data on an expensive SAN in order to feed the data at a reasonable rate to MySQL or PostgreSQL. I had just learned of MongoDB and went to school at 10gen for their sys admin class. I talked to the developer about storing the data in NoSQL using a small sharded cluster on a Friday. Monday morning he asked me to setup a MongoDB cluster. Tuesday we moved over from MySQL. They ended up using much smaller servers, got rid of the 3par and epsilon SAN's and saving tons of money. My point is there are certain situations where NoSQL is still the answer unless you can cluster your SQL write server. I've moved on from working with Ad publishing clients but, I'm sure there are other places where SQL databases are not adequate. NoSQL might be or, have been, a fad but, like any tool when used for the right job it works.
- qaq 9y agoA production large scale ad. system system that was doing 1.2 TB per hour in writes, was migrated over from MySQL to MongoDB in roughly 24 hour window cool story Bro.
- mcintyre1994 9y agoIf more comments were like their story then this would be a way higher value comments section.
- qaq 9y agohow can more made up stories result in higher value comments section?
- DenisM 9y agoGood point. How is it possible to move that much data from SAN to mongo cluster in such a short time window?
- qaq 9y agoand rewrite and validate all the code that was accessing MySQL to use MongoDB
- foxh0und 9y agoWas $30k a lot of money for one of the largest add publishers?
- roel_v 9y agoOTOH, if you're a consultant, and you can say 'hey guys I can save you 30k, my fee is only 15k', and you can do it in a week - I mean, there are weeks where I bill less than 15k...
- quickthrower2 9y ago
- deepGem 9y agoI have to agree that there was a lot of noise in the nosql world and a lot of people got carried away by the ease of use metric. I guess people were lured by the prospect of not having to write SQL joins. That said I found nosql databases extremely helpful for storing and querying large unstructured data. Mostly because it was really hard to build relations and to store this data in tables. Think Wikipedia for instance. Since then my way of choosing databases is to try and model data into a relational db as much as possible and if that doesn't work out choose a nosql equivalent.
- hvidgaard 9y agoWith Postgre you don't need to use a different database unless your workload is "bigdata". You can store relational data alongside unstructures json and query both.
- gaius 9y ago99% of "Big Data" workloads will run happily in Postgres. There are petabyte Postreses (Postgri?) in Production, have been for a decade now...
- frik 9y agoCan we get revived WebSQL support? We can thank it a rough Mozilla devs that long moved one, that WebSQL got stopped and is support in Webkit and Blink (100% mobile devices, 80% notebook), but not on Firefox. Instead this NoSQL IndexedDB was introduced. Let's get over NoSQL fad, and support SQL in web browser!
- fulafel 9y agoDynamoDB seems to be the flavour of the day for this, people are using it even in cases where a non-sharded SQL system would work fine.
- giancarlostoro 9y agoDepends on what you're doing. We've used it on at least one production product at work where it works fine and probably will not be replaced. (If it's not broken don't fix it TM)
- romanovcode 9y agoThere are a good reason to use NoSQL, for example to replace EAV. But definitely not a good use to do everything on NoSQL so most companies opted out for 2 database solution = SQL + NoSQL and did not get burned. The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no reason. TL;DR Use Postgres.
- RandalSchwartz 9y agoOr, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres, which outperforms mongo significantly on the same hardware. Plus, you can get read-only views on the Pg side to join with traditional relational data.
- pritambaral 9y ago> Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres Postgres alone is already the best of both worlds. With ToroDB, I am restricted to the MongoDB way of dealing with my data; with Postgres, I can mix SQL and NoSQL however I like, even in a single, simple SELECT query.
- overcast 9y agoWhich amazes me how RethinkDB never eclipsed all of the other "nosql" offerings. A relational, realtime, document store. You get the benefits from both sides.