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

31–40 of 118 posts

Re: Announcing MoSQL

#31

Post by Ingaz »

dennis82 wrote: post #9
danielpal wrote: post #3

Earlier quoted context omitted.

At no-point. Stripe is doing it right. They are using the right tool for each job. Mongo for storage speed etc and then postgres to analyze query etc. This kind of comment shows how little knowledge you have about NoSQL and SQL. Is not a SQL vs NoSQL, it's about using the right technology for the job.

are you kidding me? There is absolutely NO reason whatsoever to use a NoSQL database for a financial services company. Postgres is more than capable of sustaining the necessary speeds of a startup. Relational databases were created in the first place to solve these very problems around transactionality and analytics for finance. This library is a beautiful example of reinventing the wheel, and otherwise creating a pa…

Tell this FIS Global.

There is absolutely no reason to make banking system on GT.M but they did.

Although: GT.M is the only(?) NoSQL that is ACID-compliant.

Re: Announcing MoSQL

#32

Post by dugmartin »

Reading the headline I thought they were introducing a SQL like interface to their API, sort of like FQL for Facebook and I got a little excited. Something like this to get the email addresses of all your active trial subscribers:

SELECT c.email FROM customers c, subscriptions s WHERE c.subscription_id = s.id AND s.status = "active" and s.trial_start IS NOT NULL;

(where of course the customer and subscription tables would be a virtual view on your customers and subscriptions)

Re: Announcing MoSQL

#33

Post by pc »

dugmartin wrote: post #32

Reading the headline I thought they were introducing a SQL like interface to their API, sort of like FQL for Facebook and I got a little excited. Something like this to get the email addresses of all your active trial subscribers: SELECT c.email FROM customers c, subscriptions s WHERE c.subscription_id = s.id AND s.status = "active" and s.trial_start IS NOT NULL; (where of course the customer and subscription tables…

Hm, that could be pretty cool actually. Especially if we also added a REPL for interactive queries at manage.stripe.com.

Re: Announcing MoSQL

#34

Post by gfodor »

FYI you can store unstructured data in PostgreSQL (and query it) with the introduction of hstore. So knock one more reason to use MongoDB instead of PostgreSQL off your list. (Disclaimer: the length of my list to use MongoDB has always been a constant that is less than one.)

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

Re: Announcing MoSQL

#35

Post by djb_hackernews »

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.

How does MoSQL handle schema changes and new fields in mongo?

I'm imagining with this tool you start to need to be a bit more careful with the flexibility which initially drew you to mongo.

Re: Announcing MoSQL

#36

Post by ozgune »

nelhage wrote: post #25
ozgune wrote: post #23

Earlier quoted context omitted.

Out of curiosity, did you guys consider running SQL on MongoDB using Postgres foreign tables? What were the pros and cons of that approach for your use-cases? (In full disclosure, I wrote mongo_fdw for PostgreSQL.)

I actually prototyped our PostgreSQL solution using mongo_fdw (Incidentally, I throw together Debian packaging here, if you're interested: https://github.com/nelhage/mongo_fdw ). Our experience was that mongo_fdw doesn't (yet?) give postgres enough information and knobs to plan JOINs efficiently, which is one of the things we wanted. I got a decent amount of leverage out of using mongo_fdw and then cloning to native…

That's neat. :) For mongo_fdw, we're expecting better join performance once we upgrade to PostgreSQL 9.2 FDW APIs and start collecting table statistics.

I'm sure there are other factors involved for MoSQL, but they are probably outside the scope of this post. I'd love chat about them offline.

Re: Announcing MoSQL

#37

Post by nelhage »

zopticity wrote: post #29
physcab wrote: post #7

This is pretty cool but I'm struggling to see what the use cases are, atleast for analysis. There might be quite a bit of benefits for running application code that I'm not aware of. With regards to analysis though, their own example question is "what happened last night?" but then they go on to say that it is a near real-time data store. Does it matter that it is a real-time mirror then? I've always liked the paradi…

I totally agree with this. I don't understand why you would want to translate MongoDB to MySQL for? What are the advantages to doing a full data dump? There's an overhead converting from MySQL to MongoDB as the two formats are completely different. What about the edge cases when one format doesn't support the other.

They each have different advantages and strengths.

MongoDB is great for failover and for rapid development or prototyping. SQL is great for reporting or analytics, since you can do all kinds of aggregates and JOINs right in the database.

The edge cases where you can't represent the data perfectly aren't a huge deal for this use case -- because it's a one-way export, you don't have to be able to round-trip the data, and as long as you can export the data you want to run analysis on, it doesn't matter if there's some you can't get.

Re: Announcing MoSQL

#38

Post by dennis82 »

gdb wrote: post #20
dennis82 wrote: post #9

Earlier quoted context omitted.

are you kidding me? There is absolutely NO reason whatsoever to use a NoSQL database for a financial services company. Postgres is more than capable of sustaining the necessary speeds of a startup. Relational databases were created in the first place to solve these very problems around transactionality and analytics for finance. This library is a beautiful example of reinventing the wheel, and otherwise creating a pa…

(I work at Stripe.) Where we use MongoDB, it's not because of speed. PostgreSQL is certainly capable of fast performance. MongoDB is useful for its ability to log freeform data as well as for its replication model. (We use sharded MongoDB in a few places, but mostly use straight replica sets.) We use MySQL, MongoDB, PostgreSQL, and Impala. They're all useful in different places.

> "We use MySQL, MongoDB, PostgreSQL, and Impala."

Thanks for the clarification, but this makes it even more obvious your engineering team is introducing needless complexity into your organization.

Postgres can store unstructured data just fine, so you have a 'solution' that uses 3 OLTP stores instead of one.

Re: Announcing MoSQL

#39

Post by Ingaz »

I thought that "young" NoSQLs sometime in will got SQL interface.

Look at old NoSQLs: Intersystems Cache got SQL interface, GT.M (in PIP-framework) also got SQL.

My impression that MongoDB looks a lot like MUMPS storage with globals in JSON.

Re: Announcing MoSQL

#40

Post by nelhage »

djb_hackernews wrote: post #35
nelhage wrote: post #21

Earlier quoted context omitted.

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.

How does MoSQL handle schema changes and new fields in mongo? I'm imagining with this tool you start to need to be a bit more careful with the flexibility which initially drew you to mongo.

MoSQL will just throw any fields it doesn't recognize into a JSON "extra_props" field (if you ask it to). So everything will work fine, and existing SQL code (which doesn't know about those fields) will continue to be fine.

If you need the data in SQL, you can either parse the JSON somehow, or rebuild the SQL table with a MoSQL schema that knows about the new fields.

Post reply on HN