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

101–110 of 118 posts

Re: Announcing MoSQL

#101

Post by gbog »

taligent wrote: post #74
wheaties wrote: post #63

Earlier quoted context omitted.

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.

I'm under the impression that Mongo is merely hiding away some complexities, instead of truly resolving them.

Re: Announcing MoSQL

#102

Post by gbog »

raylu wrote: post #84
PommeDeTerre wrote: post #81

Earlier quoted context omitted.

I've had to deal with a lot of NoSQL advocates whose experience with SQL or relational databases doesn't extend beyond MySQL. Of course, it's understandable why they have a bad impression of SQL; they've only ever used one of the most inept implementations around. Those who are willing to try one of the more mature and sensible relational database systems usually see quite quickly the value that such systems provide.

What do you suggest?

Not the OP but I'd say giving Postgres a try is a suggestion.

Re: Announcing MoSQL

#103

Post by vog »

gfodor wrote: post #34

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

There are also JSON and XML types in PostgreSQL. It also supports an easy transition from PostgreSQL native, record and array types to JSON, and it supports a wide range of the SQL XML standard.

However, there's still something missing. PostgreSQL lacks support for XQuery. It lacks support for querying parts of JSON structure, although there's an external extension for that. And it lacks decoding JSON into native/record/array types.

So for a pure document store, PostgreSQL would require you to add lots of userdefined functions for handling your JSON structures.

However, PostgreSQL is great for hybrid approaches, when you separate your documents into content and metadata, i.e. free-structured JSON and hard-structured native types.

Re: Announcing MoSQL

#104

Post by vog »

mrkurt wrote: post #46
gfodor wrote: post #34

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

Wow, hstore really isn't a great alternative to an actual document DB. The "better" Postgres option would be a JSON type and functional indexes.

> JSON type and functional indexes

Those "Indexes on Expressions" are really a great feature that can also be combined with XML (not just JSON) and any other types. I recommend everyone to have a look at those:

http://www.postgresql.org/docs/9.2/static/indexes-expression...

Re: Announcing MoSQL

#105

Post by gbog »

taligent wrote: post #93
j-kidd wrote: post #87

Earlier quoted context omitted.

> People are scaling OUT not UP. Especially startups. Startups need to scale out because many of them like to deploy on mediocre EC2 instances with the slowest SAN storage ever. People that keep recommending PostgreSQL are rightfully ignoring this industry.

> Startups need to scale out because many of them like to deploy on mediocre EC2 instances. No. They need to scale out because providers like AWS have outages. And so startups et al need to deploy in multiple AZ/regions in order to have as close to 100% uptime as possible. You can't do that with a well considered multi master style replication strategy which PostgreSQL frankly doesn't have. >People that keep recommen…

"The trends don't lie"

Wah. And you do not even seem to be ironic. Trends always lie, there is always a next thing that will take the opposite direction, in philosophy, in science, and particularly so in computing stuff.

Re: Announcing MoSQL

#106

Post by lucian1900 »

jcase wrote: post #22
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.

Automatic failover is a pretty big feature though. I wish Postgres had a built-in solution. Sure, I could use Pacemaker but it's no where near as painless.

You should be aware however that Mongo's failover incurs downtime.

A Postgres bouncer + WAL replication achieves a similar result: There is no downtime on failover, but there is a single slave.

Re: Announcing MoSQL

#107

Post by bermanoid »

PommeDeTerre wrote: post #81
knightni wrote: post #65

Earlier quoted context omitted.

...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.

I've had to deal with a lot of NoSQL advocates whose experience with SQL or relational databases doesn't extend beyond MySQL. Of course, it's understandable why they have a bad impression of SQL; they've only ever used one of the most inept implementations around. Those who are willing to try one of the more mature and sensible relational database systems usually see quite quickly the value that such systems provide.

Beyond a few terabytes of data, Postgres is just as worthless as MySQL, and every other non-experimental SQL option comes with a "call us" price tag.

If there are production-ready options for biggish data other than NoSQL or high priced commercial analytics dbs, please share...

Re: Announcing MoSQL

#108

Post by arethuza »

vog wrote: post #104
mrkurt wrote: post #46

Earlier quoted context omitted.

Wow, hstore really isn't a great alternative to an actual document DB. The "better" Postgres option would be a JSON type and functional indexes.

> JSON type and functional indexes Those "Indexes on Expressions" are really a great feature that can also be combined with XML (not just JSON) and any other types. I recommend everyone to have a look at those: http://www.postgresql.org/docs/9.2/static/indexes-expression...

Is there any way in those expressions to parse JSON and perform arbitrary calculations - i.e. like CouchDB views?

Re: Announcing MoSQL

#109

Post by kokey »

nelhage wrote: post #16
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 wrote MoSQL) PostgreSQL scales surprisingly well for this purpose, and is much nicer for interactive queries than Hadoop/Hive. We use Impala[1] for some larger datasets, but Impala is comparatively new, and it's nice to have something as battle-tested as postgres here. As for the "why do we need realtime?": In my mind the benefit of a near-realtime replica is not that you actually often need it, but that it means…

Nice work. I spent much time last year building a system that imported MongoDB data into Oracle, having to do everything to speed up bulk loading new data into Oracle (and archiving old data). Something like this would have worked much better, and I suspect it might not be that hard to make this tool work with Oracle.

Re: Announcing MoSQL

#110

Post by zurn »

arethuza wrote: post #108
vog wrote: post #104

Earlier quoted context omitted.

> JSON type and functional indexes Those "Indexes on Expressions" are really a great feature that can also be combined with XML (not just JSON) and any other types. I recommend everyone to have a look at those: http://www.postgresql.org/docs/9.2/static/indexes-expression...

Is there any way in those expressions to parse JSON and perform arbitrary calculations - i.e. like CouchDB views?

Sure, you can write server side procedures in f.ex. javascript that do arbitrary things with the json.
Post reply on HN