Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Engineers and Our Mistakes with MongoDB

nemil.com

Post reply on HN
Print view View original

91–100 of 118 posts

Re: Startup Engineers and Our Mistakes with MongoDB

#91

Post by cmenge »

scarface74 wrote: post #67
cmenge wrote: post #61

Earlier quoted context omitted.

Well 1.) It's always a text-based interface. The ORM merely hides the fact. Type safety is weak, as is with JSON, but both aren't un-typed. 2) Yes, they are, and there are a lot of good use cases for relational databases. But if you have a number of services that share nothing (especially not the database), what is the foreign key good for? 3) You can do any style with any database. Overly aggressive normalization in…

* Type safety is weak, as is with JSON, but both aren't un-typed." How is type safety "weak" with an ORM? You are using strongly typed objects.

Yes, but they don't match the data types your SQL database supports, do they? You're talking to a remote service here., i.e. varchar, decimal, datetime, etc. in SQL aren't the same as in whatever language you're using.

That's true for JSON as well, but you probably need JSON on the other side (the API) as well...

Re: Startup Engineers and Our Mistakes with MongoDB

#92

Post by pritambaral »

ZephyrP wrote: post #35
STRML wrote: post #22

Earlier quoted context omitted.

That's a matter of opinion and implementation. Not everyone uses JWTs. What if you want to invalidate all logged-in tokens for a user? You either need to store a blacklist (that's a relation) or set extremely short expiry times.

i think he is discussing standard cookie session ids here, not access tokens. in many web applications, all the information you need is stored within that token and signed by a server-side secret.

Same thing. How do you invalidate a signed cookie?

Re: Startup Engineers and Our Mistakes with MongoDB

#93

Post by cmenge »

bdcravens wrote: post #72
scarface74 wrote: post #66

Earlier quoted context omitted.

Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore. I use ORMs to do just what the name implies -- to map relational models to objects. If I'm working with objects anyway, either I'm going to end up…

> "It's a poor carpenter that blames his tools" I think the point of the article is that Mongo is being used mostly by "poor carpenters", and provides worse defaults than SQL does. It's obvious you're operating at an advanced level that young and hungry startups aren't.

...which brings us back to the original point: if you use tools you don't understand, chances are things go wrong.

Re: Startup Engineers and Our Mistakes with MongoDB

#94

Post by cmenge »

topspin wrote: post #24
cmenge wrote: post #3

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginn…

"some text-based SQL statements" What do you have in mind there? Systems that process SQL statements interpret these statements, validate them for correctness against a schema and then provide an auditable plan. Just because SQL bears some resemblance to spoken/written English (a property that vanishes pretty quick when you get past simple use cases) doesn't mean it isn't rigorously analyzed by database systems; SELE…

Being condescending isn't helping your argument here. No, I didn't think of SQL injection and I do have a vague understanding of the SQL grammar. The NoSQL injections seem a bit constructed and pretty much can't happen with a strongly typed language in the application layer.

Re: Startup Engineers and Our Mistakes with MongoDB

#95

Post by cmenge »

flavio81 wrote: post #19
cmenge wrote: post #3

I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginn…

> Choosing a system that only offers very few guarantees forces you to think about them more explicitly. Yes, of course. And it also forces you to implement, on your own: relational (key) constraints, real transactions, etc. And thus, you, on your own, compete against more or less 44 years of research, developing, and releases by brilliant computer scientists and engineers (Ingres DB, 1973- PostgreSQL latest version,…

I'm sorry, you're so right. I'm just one of the idiots on the Internet who haven't used a system for 10+ years (or the bulk of their existence at least) and makes condescending comments...

Re: Startup Engineers and Our Mistakes with MongoDB

#96

Post by kazen44 »

mbreese wrote: post #52
eberkund wrote: post #41

What about for IoT devices? I could see NoSQL still having a place there, although I could also see it working just as well with a SQL database.

What is special about IoT devices that make them more suited towards a NoSQL solution? Scale? Is that really an issue for the majority of IoT deployments?

most IoT devices do not really need to be scalable themselves. The backend/processing side of IOT needs to be scalable. And it already mostly is doing that on both network side (ipv6) and datastore side (TSDB?).

Re: Startup Engineers and Our Mistakes with MongoDB

#97

Post by kentosi »

nevi-me wrote: post #74
kentosi wrote: post #56

Earlier quoted context omitted.

"You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?

The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties. Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me. I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in…

Interesting. I haven't used JSON-stores because in my mind it always boils down to the question of how you would link entities together. I can't seem to get a good answer... so let me put this to you:

In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS):

  create custom type LatLon(...)
  create table Person(id as int, name as string, location as LatLon)
  create table Shop(id as int, name as string, location as LatLon)

  Find everyone 10k around Macy's:
  select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km)
How would a JSON-store be better at managing this, given that with RDBMS systems you have indexes to help speed such cross-table looks?

Re: Startup Engineers and Our Mistakes with MongoDB

#98

Post by tinix »

winter_blue wrote: post #85
tinix wrote: post #64

Earlier quoted context omitted.

Most of your points are ripe with folly. 1. ORMs are slow, but generally they are worth it, and it's trivial to dive into raw queries when needed for performance reasons. 2. Mongo supports relationships, not sure what you're trying to get at. Reverse delete rules are TRIVIAL to implement in your models. This is NOT the fault of the database engine, but fault of the developer, 100%. 3/4. Lack of normalization and sche…

You should try to not start a comment with an attack. It just makes you look bad. See: http://www.paulgraham.com/disagree.html Regarding your points: > 1. ORMs are slow Maybe you haven't used any recent ORM. Where did you get this idea from? In the JVM world, Hibernate is nearly dead for new projects. EBean[1] and JOOQ[2] are both great choice server-side Java/Kotlin/Scala projects. On Android / for SQLite, there's D…

None of your points are derogatory to MongoDB in particular, any more-so than any other database.

Your points are wholly reflective of bad implementors and their implementations, not to the underlying technologies.

If one misuses a tool, that's on them, not on the tool. Further, I think it's pretty fair to say: if it's as easy to mis-use something as it is to use it, then you have a very powerful tool that should be used carefully. If it's hard to mis-use something, then it's probably not a powerful tool.

Basically, to use an analogy, don't use a jack-hammer to re-grout delicate tiles. A chisel and hammer work better, and you definitely wouldn't want to use a hammer and chisel to break up a concrete slab. Similarly, you wouldn't use a handheld rotary tool to cut a concrete slab, but using it to remove grout is perfect. Misuse of a tool leading to damage doesn't mean the tool is flawed, bad, or broken, it means it is being used incorrectly. Can you use it that way? Sure! Should you? Probably not.

ORMS are indeed slower than straight SQL, period, always, 100% of the time. This is not opinion, but hard fact of simple logic. Generally speaking, it is rather silly to expect a complex abstraction to be faster, leaner, and more efficient than a lower level one. Adding more code and complexity will never make things execute faster. (Caching does not count, obviously, that's not the point here)

That F500's total lack of effective systems architecture is the problem, not the database they used.

This is like building a treehouse with nails driven at 90 degree angle, and then blaming the hammer when it falls apart. Totally, man, you definitely shouldn't have used screws, or driven your nails at an angle converse to the lines of force. Keep blaming your tools...

Re: Startup Engineers and Our Mistakes with MongoDB

#99

Post by scarface74 »

cmenge wrote: post #91
scarface74 wrote: post #67

Earlier quoted context omitted.

* Type safety is weak, as is with JSON, but both aren't un-typed." How is type safety "weak" with an ORM? You are using strongly typed objects.

Yes, but they don't match the data types your SQL database supports, do they? You're talking to a remote service here., i.e. varchar, decimal, datetime, etc. in SQL aren't the same as in whatever language you're using. That's true for JSON as well, but you probably need JSON on the other side (the API) as well...

Yes. When you use Entity Franework's generator to map from a database table to a class, it not only maps the types from the database to your class, it also maps constraints like charactr length, nullable fields vs. non nullable fields, etc.

The same for Mongo if you are using the C# driver. If you get a Mongo collection using the standard C# syntax --

var collection = database.GetCollection("Users");

You will work with a strongly typed "schema". As long as you are working with the "collection" object, you will be working with strongly typed objects and doing type safe Linq queries.

Re: Startup Engineers and Our Mistakes with MongoDB

#100

Post by scarface74 »

nulagrithom wrote: post #82
scarface74 wrote: post #63

Earlier quoted context omitted.

But all you are doing is pushing all the joins to the web server (which in Node land is single threaded and compounds the mistake of choosing NoSQL). Why is pushing the joins "to the web" inherently bad? It's a lot easier to scale web servers than database servers.

Simplified, a JOIN on an SQL server will take advantage of its indexes to grab the data from the disk that matches the specified criteria. SQL databases are built for this sort of thing, and they're really freaking good at it. Sending that same JOIN to the web server means, at the least, shipping everything from both tables matching the criteria and matching up those two potentially huge blobs of data with each other…

If you are doing a lot of joins in Mongo - you're doing it wrong. The whole purpose of a document DB is storing your model with the related data as one document.
Post reply on HN