I love this idea. I can see myself using MoSQL pretty soon. Does it handle geospatial data? Can it replicate geospatial data from Mongo to a Geometry data type in Postgres?
Announcing MoSQL
61–70 of 118 posts
Re: Announcing MoSQL
#62Earlier 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.
Awesome! Great to hear it's working out for you guys, looking forward to MoSQL for Impala :-)
Re: Announcing MoSQL
#63FYI 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
> 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.
Re: Announcing MoSQL
#64Earlier 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!
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 ;).
Re: Announcing MoSQL
#65Nice. Real businesses need a data warehouse and SQL is the right tool for that job. I thank them for releasing this.
> Real businesses need a data warehouse and SQL is the right tool for that job. Honestly. I don't think you could be more misinformed if you tried. Hint: Google "Big Data".
...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.
Re: Announcing MoSQL
#66Earlier 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.
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.
Re: Announcing MoSQL
#67Is there currently support for "unrolling" arrays or hashes into tables of their own? If not, would definitely be interested in helping to add that on (we use arrays on documents quite a bit, but have run into a number of situations where a simple SQL query for analysis could have quickly replaced a bunch of mongo scripts).
There isn't support. It's definitely something I've pondered. If you're interested in adding support, I'd be happy to hear from you at (my username) AT stripe.com.
Email sent!
Re: Announcing MoSQL
#68Is there currently support for "unrolling" arrays or hashes into tables of their own? If not, would definitely be interested in helping to add that on (we use arrays on documents quite a bit, but have run into a number of situations where a simple SQL query for analysis could have quickly replaced a bunch of mongo scripts).
I've added that capability to mongo_fdw, which I use for getmetrica.com. I'll be contributing it back soon (after that 9.2 API conversion). Would be happy to talk to you about the wrapper or Metrica. Email's in my profile.
FYI, the email field from the profile doesn't actually get displayed publicly. Mine is (username) @gmail.com
Re: Announcing MoSQL
#69Earlier quoted context omitted.
I've added that capability to mongo_fdw, which I use for getmetrica.com. I'll be contributing it back soon (after that 9.2 API conversion). Would be happy to talk to you about the wrapper or Metrica. Email's in my profile.
FYI, the email field from the profile doesn't actually get displayed publicly. Mine is (username) @gmail.com
Whoops. Okay, emailing.
Re: Announcing MoSQL
#70Earlier 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…
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 always worth the complexity." When they are, you use an RDBMS. When they aren't, you don't bother with the data integrity constraints.