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

Announcing MoSQL

stripe.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Announcing MoSQL

#71

Post by odellk »

gdb wrote: post #55
monstrado wrote: post #42

Earlier quoted context omitted.

(Clouderan here) How are you liking Impala? We just dropped 0.5 release yesterday which includes the JDBC driver :D! Edit: Awesome job on the Ruby client, it's great!

It's been great -- setup was a bit of work (we're on Ubuntu, so had to build from source), but once up and running it's allowed us to do lots of ad-hoc analysis that would have been too hard otherwise. I've been meaning to write a MoSQL equivalent for our Impala data, but at the moment we're doing a more traditional ETL.

gdb - If you have Impala, Hadoop, and Hive right now. Why use MongoDB instead of HBase and make it all work in a happy harmony?

Re: Announcing MoSQL

#72

Post by meaty »

Also useful when MongoDB blows chunks because it was a crap architectural decision and you quickly port your app to raw SQL...

Re: Announcing MoSQL

#73

Post by colinmarc »

monstrado wrote: post #64
nelhage wrote: post #56

Earlier quoted context omitted.

We've been pretty happy so far. There have been a few rough edges getting it up and keeping it running, but we've been very impressed with the performance so far. I've passed your comment on to Colin, who wrote the Ruby client -- I'm sure he'll appreciate it!

I got myself a little Impala Herd server setup, pointed it at my Impala cluster and it's working great ;).

heh, I didn't think anyone would actually use that - I originally wrote it meaning to use it as a tutorial for the blog post, then scrapped that idea.

Thanks for the kind words!

Re: Announcing MoSQL

#74

Post by taligent »

wheaties wrote: post #63
taligent wrote: post #53

Earlier quoted context omitted.

> So knock one more reason to use MongoDB instead of PostgreSQL off your list. One of the reasons MongoDB is so popular is because it is an fantastic database for developers. As a Java developer I can deal in my code with sets, hashmaps, embedded structures and have it effectively map 1-1 in the database. It's akin to an object database meaning you can focus higher up in the stack. With the SQL ORMs you can't avoid h…

Please don't confuse problems with SQL ORMs with SQL itself. SQL stores are powerful, flexible, and quite easily queryable. MongoDB is only a good database for developers if it solves the problems that you need to solve in a way that causes no impedance mismatch. And for the record, we use both a SQL store, Redis and MongoDB where the use case suits it where I work.

I am under no confusion. SQL ORMs all suffer from the same problems (which is forced by the underlying SQL model) that MongoDB does not.

And your whole "use the right tool for the right job" goes without saying. It's others who seem to be obsessed with this "SQL is perfect for everything" delusion.

Re: Announcing MoSQL

#75

Post by lucian1900 »

nelhage wrote: post #21
lucian1900 wrote: post #12

Earlier quoted context omitted.

The only advantage MongoDB has over Postgres is built-in sharding, and even that is of dubious value.

To pick one, we like the fact that MongoDB lets you change your schema and add new fields to your documents without having to worry about migrations or keeping track of schema versions, or any of that. You could build something like that on top of SQL, but it's nice to have a tool where you don't have.

I've found a good SQL library (like Alchemy), a good migration library (like Alembic) and a DB with non-blocking migrations is much nicer to use, since it makes data migrations very easy.

Re: Announcing MoSQL

#76

Post by gfodor »

burntsushi wrote: post #70
gfodor wrote: post #57

Earlier quoted context omitted.

Of course, the problem with that approach is you don't have anything enforcing any sort of data integrity below the application. In my experience most of the time you actually can put down on paper a schema and a set of rules the data should obey without too much fear of it changing dramatically. The nice thing about hstore is it allows you the flexibility to introduce unstructured data in just the places where a sch…

> MongoDB et all basically are built around the assumption that a schema is never worth the complexity. It's a bold claim that contradicts many decades worth of database research. Unless MongoDB et al are saying "always use MongoDB et al and never an RDBMS", then I'm not sure how you arrived at the conclusion that "the schema is never worth the complexity." If anything, the appropriate assumption is, "schemas aren't…

The "right tool for the job" mantra often cited whereby you run N different data stores for different use cases heavily discounts the true implication of running multiple data stores: you have to run multiple data stores. You have more ways to get burned by your lack of expertise. You need more eyeballs for the same amount of confidence in your system since those will probably need to be different types of experts. You need to know how to monitor them and tune them. Discussion about which data store to use for a given use case becomes a constant drag on discussions. There is less consistency in modeling since you have to work with multiple paradigms. Your software needs to be built to be able to deal with multiple data stores. All your export/import/backup/etc software efforts that are 1-to-1 with each data store need to be multiplied.

The bottom line is if you drop in a second data store because you have a few fields in your database that are a pain to model with a schema, you are doing yourself a disservice compared to just doing ALTER COLUMN foo hstore.

My colleague mcfunley wrote an article about this blind spot when people talk about these issues:

http://mcfunley.com/why-mongodb-never-worked-out-at-etsy

Re: Announcing MoSQL

#79

Post by shawn-butler »

mrkurt wrote: post #66
shawn-butler wrote: post #49

Earlier quoted context omitted.

There is a JSON type but it just validates content. HSTORE can be fully indexed (gIST and GIN). Just have to roll your own object graphs for nesting if that's what you need to do. I swear I have typed this exact same comment previously. Deja vu, maybe

JSON type gives you some typed values within the doc, multi-level nesting, etc. You can add functional indexes ( http://www.postgresql.org/docs/9.1/static/indexes-expression... ) to index specific attributes within the JSON, do legit sorts over values, reasonable array queries, etc. It seems much, much closer to what Mongo does than anything you can do with hstore.

I think you just restated my comment. Do you believe expression indexes do not apply to HSTORE?

I consider both HSTORE (key/value) and the current JSON type and record functions are just intermediate steps to a fuller API [0].

[0]: http://www.postgresql.org/message-id/50EC971C.3040003@dunsla...

Re: Announcing MoSQL

#80

Post by burntsushi »

gfodor wrote: post #76
burntsushi wrote: post #70

Earlier quoted context omitted.

> MongoDB et all basically are built around the assumption that a schema is never worth the complexity. It's a bold claim that contradicts many decades worth of database research. Unless MongoDB et al are saying "always use MongoDB et al and never an RDBMS", then I'm not sure how you arrived at the conclusion that "the schema is never worth the complexity." If anything, the appropriate assumption is, "schemas aren't…

The "right tool for the job" mantra often cited whereby you run N different data stores for different use cases heavily discounts the true implication of running multiple data stores: you have to run multiple data stores. You have more ways to get burned by your lack of expertise. You need more eyeballs for the same amount of confidence in your system since those will probably need to be different types of experts. Y…

While I agree that is often a blind spot, it is a red herring to this statement made by you:

> MongoDB et all basically are built around the assumption that a schema is never worth the complexity. It's a bold claim that contradicts many decades worth of database research.

You may well argue that if you have N-1 applications using PostgreSQL, and the Nth application could---on its own---justifiably use MongoDB, then it is still appropriate to use PostgreSQL in favor of not adding Yet Another DB Engine.

But that is nothing more than a specific case that is often ignored in the "best tool for the job mantra". It does not mean that schemas are never worth the complexity of an RDBMS.

All I'm saying is that you can't claim that a recommendation of MongoDB assumes schemas are never worth the complexity; you can only claim that the assumption is that they are sometimes not worth the complexity.

More generally, MongoDB makes no assumption that contradicts "years of DB research."

Post reply on HN