jd_mongodb

Import to realise that the DocumentDB (Amazon's MongoDB emulation) is not based on the MongoDB code base.

No typing is great whether its BSON types in MongoDB or column types in RDBMS. Anything past that generally gets in the way of flexibility to respond to new business requirements. Business changes rarely originate at the schema level so its a bad place to encode business semantics.

Technology selection is a black art in many companies. Sounds like people were open to listening to the opinion of a developer in your case. Often-times the selection heuristic is habit or history. The right companies will pay more attention to reasoned arguments of their own developers.

Making JSON the coin of the realm and putting it at the core of your database design and query language is a little bit more than extra ergonomics :-)

Most JSON field databases treat the JSON field as text and index it as free text. with MongoDB you can index at any level into the document. Since 4.2 you can use wildcard indexes to index a document and any new fields that are subsequently added automatically.

https://docs.mongodb.com/manual/core/index-wildcard/

Asya Kamsky, veteran engineer at MongoDB and previously the world of SQL, talks about why developers want to use Document Databases.

Coinbase uses MongoDB, Barclays uses MongoDB, BBVA uses MongoDB, Capital One uses MongoDB. Charles Schwab uses MongoDB. FICO uses MongoDB. Goldman Sachs uses MongoDB. HSBC uses MongoDB. Intuit uses MongoDB. Uk Inland Revenue uses MongoDB. UK Dept of Work and Pensions uses MongoDB.

This is the tip of the iceberg when it comes to MongoDB's use cases in Financial services. These organisations REALLY use MongoDB for financial data and they are all public references. Relational databases are great for financial data and so is MongoDB.

In seven years working at MongoDB the one thing I have learned is technology is never "forced down the throat of the engineers". Developers have choices and would not stay in an organisation that made decisions that way. The reason developer relations exists is the acknowledgement that developers ARE the decision makers in most technology selection.

you can use JSON schema to lockdown you schemas like SQL but few developers choose do that as they prefer the flexibility that MongoDB offers. Changes in the schema are almost always due to upstream changes so the schema is a follower rather than a leader.

Encoding your business logic in the database schema is rarely a good idea.

A pretty solid history. Kinda skipped over the launch of MongoDB Atlas, but this is the only miss in a pretty accurate account.

If you have ever lost data running MongoDB (whether you are a paying customer or not) we want to hear about that and fix it. We treat any instance of data loss as a high priority bug.

You don't pick a database like MongoDB purely for its key/value query performance. SQL will do really well until it does really badly, for example in cases where you exceed the limitations of the box/VM it is running on.

I'm sure ArangoDB is wonderful technology but your characterisation of MongoDB is misplaced. The people who build the WiredTiger storage engine that MongoDB depends on have been building database engines for over 20 years. They created the original BerkeleyDB, built Oracle's NoSQL engine then left Oracle to create the Wired Tiger engine. They were acquired by MongoDB to completely revamp our storage engine technology in 2014. Don't let 7 year old memes cloud your judgement.

(I work for MongoDB).

MongoDB has killOp which will allow a user to kill any operation they have an operation ID for:

https://docs.mongodb.com/manual/reference/method/db.killOp/

The common misconception is that MongoDB stores JSON blobs. The JSON you see is converted seamlessly to BSON and is type encoded. This allows use to apply indexes at any level in the object and use complex query expressions at any level in the object.

We built our BI connector a few years ago for all the reasons you outline. Definitely worth a spin if you have this challenge again. Basically makes MongoDB look like MySQL (if that floats your boat :-)).

Of course MongoDB does integrate with BI these days via its BI connector :-)

You may be thinking of MongoRocks. MongoDB with a RocksDB storage engine https://github.com/mongodb-partners/mongo-rocks/wiki

How does BSON compromise MongoDB security?

It does take a long time to start and that is apparently Electron :-(

Are you seeing issues somewhere else?

4.4 is still a release candidate not a production release.

MongoDB is not a closed source product. It is licensed under the SSPL and the source code is available to all.

You can apply a Schema to your collection and have MongoDB enforce it . This has been in MongoDB since version 3.6. We support the JSON schema standard. https://docs.mongodb.com/manual/core/schema-validation/

Untrue. MongoDB arose from the frustrations the founders had with scaling SQL databases while building DoubleClick.

'Hatred and fear" ? This is a database we are talking about?

Companies all over the globe are betting their businesses on MongoDB and succeeding.

e.g. most recently Ticketek

http://www.theaustralian.com.au/business/technology/mongo-mi...