Live data from Hacker News

Building a MongoDB Clone in Postgres

legitimatesounding.com

91–99 of 99 posts

Re: Building a MongoDB Clone in Postgres

#91

Earlier quoted context omitted.

Since the relational model is very set-oriented, it has always had a particularly hard time dealing with ordered lists. But that's really a minor thing, and is actually something an ORM can do well to abstract. My real headache with ORM has always been to get it to perform efficiently. For example, say I want to iterate through the GPA's of all the students. To do so, the ORM usually pulls in the full object model fo…

I've used ORM tools such as the one in Django, Active::Record and DBIx::Class. I do not have the issues you mentioned ... I always remember the API calls I need to make and performance has not been an issue (granted, I'm fairly familiar with all issues that can come up, so I know when or where to optimize in general). the ORM usually pulls in the full object model for each student Here's how to do it in Django (and n…

> http://www.postgresql.org/docs/9.1/static/hstore.html

A clearer version would probably be:

    for student in Student.objects.only('gpa'):
        print student.gpa

Re: Building a MongoDB Clone in Postgres

#92
post #84
post #74

Earlier quoted context omitted.

[1] looks like an example where the data didn't fit in RAM. Mongo works best when data fits in RAM or if you use SSD's. Yes, it's sub-optimal. [2] is from a year and a half ago. It doesn't belong in a sentence that includes the word "still." I work at foursquare, btw. Those outages happened on my first and second days at the company. I wasn't so keen on mongo then either. We've gotten much better at administering it.…

[2] When you look at [1] you'll notice that these exact problems are still prevalent. I'd in fact be curious how exactly did you work around the sharding issues at 4square? Remember I replied to someone who claimed it takes "no engineering effort" to scale MongoDB. That's not only obviously false, but last time I tried the sharding was so brittle that recommending it as a scaling path would border on malice. I ran a…

I don't think what I said was bullshit. So you wrote tests to make mongo fail, and you've seen cases where people run into problems with it. That still doesn't disprove my point. With postgres, you roll your own sharding. With mongo, you don't have to.

Re: Building a MongoDB Clone in Postgres

#94
post #84

Earlier quoted context omitted.

[2] When you look at [1] you'll notice that these exact problems are still prevalent. I'd in fact be curious how exactly did you work around the sharding issues at 4square? Remember I replied to someone who claimed it takes "no engineering effort" to scale MongoDB. That's not only obviously false, but last time I tried the sharding was so brittle that recommending it as a scaling path would border on malice. I ran a…

I don't think what I said was bullshit. So you wrote tests to make mongo fail, and you've seen cases where people run into problems with it. That still doesn't disprove my point. With postgres, you roll your own sharding. With mongo, you don't have to.

Sure, makes sense. If you're happy with your deployment randomly failing.

Re: Building a MongoDB Clone in Postgres

#95
post #94

Earlier quoted context omitted.

I don't think what I said was bullshit. So you wrote tests to make mongo fail, and you've seen cases where people run into problems with it. That still doesn't disprove my point. With postgres, you roll your own sharding. With mongo, you don't have to.

Sure, makes sense. If you're happy with your deployment randomly failing.

/troll.

Re: Building a MongoDB Clone in Postgres

#96
post #94

Earlier quoted context omitted.

Sure, makes sense. If you're happy with your deployment randomly failing.

/troll.

It seems you fall squarely into the bucket of 'people who haven't even tried' (and some other unfavorable buckets, but I'll leave that to your older self to judge).

Re: Building a MongoDB Clone in Postgres

#97
post #84
post #74

Earlier quoted context omitted.

[1] looks like an example where the data didn't fit in RAM. Mongo works best when data fits in RAM or if you use SSD's. Yes, it's sub-optimal. [2] is from a year and a half ago. It doesn't belong in a sentence that includes the word "still." I work at foursquare, btw. Those outages happened on my first and second days at the company. I wasn't so keen on mongo then either. We've gotten much better at administering it.…

[2] When you look at [1] you'll notice that these exact problems are still prevalent. I'd in fact be curious how exactly did you work around the sharding issues at 4square? Remember I replied to someone who claimed it takes "no engineering effort" to scale MongoDB. That's not only obviously false, but last time I tried the sharding was so brittle that recommending it as a scaling path would border on malice. I ran a…

"I ran a few rather simple tests for common scenarios; high write-load, flapping mongod, kill -9/rejoin, temporary network partition, deliberate memory starvation. MongoDB failed terribly in every single one of them. "

What other databases did you go to the same lengths to make fail which handled them gracefully?

Re: Building a MongoDB Clone in Postgres

#98
post #96

Earlier quoted context omitted.

/troll.

It seems you fall squarely into the bucket of 'people who haven't even tried' (and some other unfavorable buckets, but I'll leave that to your older self to judge).

Wow, I just saw your awesome response! FWIW, I too work at foursquare and sit next to Neil (nsanch). Feel free to verify by asking him!

I reiterate: /troll

Re: Building a MongoDB Clone in Postgres

#99

Earlier quoted context omitted.

> SQL still has a place and MongoDB is no replacement Let's flip this: NoSQL is finding it's place in the database ecosystem. SQL is the name of a database query language, NoSQL is a term that identifies a set of new, ostensibly non-relational, data storage engines that so implement an SQL parser despite SQL being the Standard Query Language, with twenty years of history behind it. My opinion - They decided to call i…

"I'd much rather access data from Mongo, Riak, Redis, and Couch using the SELECT, INSERT, UPDATE and DELETE statements that I have known since 1988, instead of having to learn four new database APIs." Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database.

I'm going to disagree. A partial implementation of SQL would go a long way to clearing the stigma of "You old RDBMS users don't know what you're doing" that NoSQL engenders.

They are database operations, originally implemented against database management systems that attempt to map relational algebra (set operations) onto data stores. There is nothing in the SQL grammar that prevents its implementation outside RDBMS.

> "Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database."

I don't want to do set operations, I want to retrieve data.

SELECT * FROM user_collection WHERE city = 'Bronx' expresses a desire for data, not a desire to perform a bunch of set operations, and should be functionality that is provided but the database vendor since we've had SQL since the 1980s and "everybody" knows SQL.

Take a look at this page form MongoDB's web site: http://www.mongodb.org/display/DOCS/Mongo+Query+Language

It is telling that they explain API examples in terms of SQL SELECT statements. I infer that if they wanted to do the work they could provide a SQL processor, and extrapolate to every other API-only datastore.

Post reply on HN