
MongoDB Is Raising Another $100M - aquark
http://techcrunch.com/2015/01/09/mongodb-funding-filing/
======
nawitus
I find it unfortunate that CouchDB is pretty much a dead project even though
it's fundamentals are for most projects better than MongoDB. Master-master
databases are the future for most scaled architectures.

~~~
otterley
What can you do in CouchDB that you can't do in ElasticSearch?

~~~
brickcap
@vvoyer already mentioned replication. But there is another thing that couchdb
is good at but most people don't use it/ know about it. It can interpret
arbitrary erlang code.

Which means that you can write an erlang module and call it with couchdb show
functions and have the benefit of a ready made http api for you.

A practical use of this would be to use mnesia as an in memory key-value
store(for similar things that you would use redis for) and then call the
functions in the module from a show function. All the benefits that you get
with erlang you get with couchdb.

One of the killer features (for me at least) is user accounts management. In 3
http calls I have login-logout facility in my app ready. I can't tell you how
impressed some of my clients are when I show them a V1 of their product in a
couple of days.

~~~
otterley
If you configure your indexes properly, you get replication in ES for free:
[http://www.elasticsearch.org/guide/en/elasticsearch/guide/cu...](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/replica-
shards.html#replica-shards)

~~~
janl
This is different from CouchDB’s peer-to-peer or master-less replication where
nodes can live all over the world, be offline for arbitrary amounts of time or
even be phones or web-browsers.

------
NDizzle
Do.... I'm trying to phrase this the right way. These are serious questions.

Do people actually consider using MongoDB for new projects? Do they want to
add it to existing infrastructure? Why, with only a cursory search on the
limitations?!

~~~
angrybits
Unless your workload is storing deeply-hierarchical-yet loosely-related-but-
otherwise-independent documents, you have a relational model. Not using a
relational engine doesn't change that.

~~~
ibejoeb
It's really hard to get this through to people nowadays. The relational model
is powerful, and the storage systems, logic engines, languages, and ancillary
toolsets that work under it--on the market, ready for production, today--are
very advanced.

When I work with people who claim that their models are not relational, I
usually have to contend that they are. The argument goes like this: you may be
able to model your problem as documents or hierarchies, but can you model all
of the questions you want to ask about that data in the same way?

The major vendors of relational systems have first-class support for
hierarchical data structures, recursive data structures, graphs, KVs, and
documents, and they can be used in conjunction with the basic relational
features. Modern SQL is more that just SELECT...FROM...WHERE...GROUP BY; it
has powerful, fast analytical functions, domain modeling, and reporting
features. The top engines can partition your data and parallelize your access
patterns to get the most value out of your commodity multi-core/SSD hardware.

The support for such systems is ubiquitous in todays software libraries. These
systems even have tailored hardware platforms to support them if your problems
really lie far out on the curve.

The downside is that none of the free/OSS systems are quite as capable. The
commercial systems often require the top-tier editions to support all of the
above.

The good news is that it's really a good financial deal if you actually need
it. A $40,000 license for Oracle or MS-SQL is 1/4 of the annual cost of an
engineer that can coerce similar functionality out of a lesser product. Their
are plenty of consultants that can help you get there on a one-and-done basis.

PostgreSQL is getting there, too. Query parallelism is, for me, the biggest
gap. There are some neat aftermarket solutions, but it's not quite there yet.

~~~
count
While I don't disagree with you, I think you're might be missing a higher
level difference: many of todays teams are pulling functionality OUT of the
storage engine entirely, and 'rolling their own' in the application code.

I'm not passing judgement on if that's a good thing or not, but many teams I
see today are looking at the storage engine as nothing but that: a temporary
place to put things that can be swapped out if there's something that does the
same job faster, where 'job' is glorified K:V and possibly sorting.

Ceding advanced functionality to the database is what is being avoided: my own
app code is usually easier to troubleshoot than an obscure Oracle error.

------
nobody_nowhere
So that brings the total to $331M? That's a metric ton of cash, what do they
do with it?

~~~
jamesblonde
Take some database courses, learn about transactions and isolation models,
maybe some do some distributed systems courses, learn about agreement
protocols, failure models, recovery models....

~~~
fiatmoney
Some may think the OP is joking.

[https://www.youtube.com/watch?v=nzjIP6O4kEo](https://www.youtube.com/watch?v=nzjIP6O4kEo)

~~~
revelation
Why do they even have a _Ruby_ driver? Isn't FFI a thing in ruby?

~~~
steveklabnik
A pure Ruby driver makes it available on JRuby, which doesn't handle the FFI
as well.

------
debacle
So if Mongo is such shit and Couch is a pain in the ass to configure with not
so great documentation, what _can_ I use as a NoSQL database? From time to
time, I find myself wanting a database that is flexible with document
definition but every tool I've tried has kind of sucked.

~~~
jxf
This sounds like heresy, but you can actually use Postgresql. It has a JSON
column type that supports indexing!

[http://www.postgresql.org/docs/9.4/static/datatype-
json.html](http://www.postgresql.org/docs/9.4/static/datatype-json.html)

~~~
ahoge
Postgres also got hstore (key-value) and arrays. So, if you only need a little
bit of flexibility on top, you can have that, too.

~~~
jxf
`hstore` is good if you know for sure you'll never have nesting (because the
values have to be primitive types). Otherwise, JSON is probably the safer,
more reliable bet, though it's slightly slower.

------
megaman821
What is the go to use case for a document database?

Things like ElasticSearch (search database), Neo4j (graph database), and Redis
(key/value store) seemed to be used along-side a traditional RDBMS, and have
specific use cases that make them superior than trying to shoe-horn the
functionality into a traditional RDBMS.

~~~
smurfpandey
Storage of JSON documents. We are using MySQL as our primary database, and
mongoDB for storing JSON documents.

~~~
zachrose
What do you do with the documents? Join them? Search them? Filter them?
Summarize/aggregate them? All of the above? Do you have schemas for them?
(Just curious!)

~~~
smurfpandey
These documents are simply sent to our client apps. All the processing happens
on MySQL. And since we are sending JSON, so instead of creating JSON on
runtime, we store as a document and retrieve that and send to the client.

We retrieve documents using the unique id generated in mysql table.

------
lovemenot
With the new CRO appointment, what changes to their business model are now
expected in order for them to try to realise these investments? I guess they
cannot do much about s/w licensing remaining at zero cost, so will they be
targeting just support revenues?

------
lquist
Maybe I'm being stupid, but a non-ACID database sounds scary to me.

~~~
mrinterweb
That kind of depends on your needs. Since the documents are hierarchical, and
can be self-contained (depending on design), you can get a write receipt from
MongoDB. I think the necessity of ACID applies more to relational databases
that are updating multiple related records. If you really need an ACID like
transaction in MongoDB, you have to do it in your software and check the write
receipts. Of course this can fail if the database server suddenly goes down,
but with MongoDB you should be using replica sets anyways.

~~~
chris_wot
How many people write receipt only databases?

------
dutchbrit
How much are they currently valued at (and how fast do they spend $100M)?

------
scorpion032
I guess we can all surely expect to get a couple more of MongoDB mugs this
year.

------
fapjacks
So I guess we can look forward to a lot more marketing selling MongoDB as some
incredible database? It would be nice if they spent that money making it less
of a pain to use and less brittle.

~~~
rdtsc
> So I guess we can look forward to a lot more marketing selling MongoDB as
> some incredible database?

I have 2 MongoDB mugs. I could use 4 more for a nice set.

~~~
fapjacks
Heh, that's true. Actually (ironically) I have a MongoDB mug too, which I
found orphaned on a desk in a back office at my old job.

------
0xFFC
I dont know so much about internal architecture of database's, but I really
loved how mongodb care about people with providing such great course on
udacity.

