MongoDB vs. Hadoop vs. RocksDB

MongoDB fills our more traditional database needs. We knew we wanted Trello to be blisteringly fast. One of the coolest and most performance-obsessed teams we know is our next-door neighbor and sister company StackExchange. Talking to their dev lead David at lunch one day, I learned that even though they use SQL Server for data storage, they actually primarily store a lot of their data in a denormalized format for performance, and normalize only when they need to.

The everything store.

Mongo powers our data

Used to be MySQL, but once moved to MongoDB, everything just speed up dramatically, data became pretty and easy to work with. Sophisticated aggregations allow us to run complicated analytics anytime as easy as possible.

Store image metadata.

Nearly all of our backend storage is on MongoDB. This has also worked out pretty well. It's enabled us to scale up faster/easier than if we had rolled our own solution on top of PostgreSQL (which we were using previously). There have been a few roadbumps along the way, but the team at 10gen has been a big help with thing.

Our NoSql data storage. Provided to us through Modulus.

Main storage

We use MongoDB as the database server for all infra configuration/settings.

Used MongoDB as primary database. It holds trip data of NYC taxis for the year 2013. It is a huge dataset and it's primary feature is geo coordinates with pickup and drop off locations. Also used MongoDB's map reduce to process this large dataset for aggregation. This aggregated result was then used to show visualizations.

MongoDB is only used as session storage since storing session in Firebase is not feasible.

로그성 데이터는 mongodb 에 기록됩니다. 뛰어난 성능이 강점입니다만 NOSQL 의 특성을 이해하지 못하고 사용할 경우에는 오히려 독이 될 수 있습니다.

Big datasets not likely to need joins with another dataset go in Mongo to offload Postgresql

As primary database

in conjunction with Meteor, database alternative

This is our DB.

So much more flexible than SQL …

Primary product data store

Primary app data store.

We use Mongo for persistent storage and retrieval. We also use a nifty Mongo ODM, Mongoose (available from NPM), to model our schemas and connect to Mongo on our private VLAN.

We support Mongo databases so that developers can interact with their data.

Main database

Our main datastore

Our data storage, for the most part is handled by a set of MongoDB storage clusters handling all the persistent information needed for our apps.

Hosts the unstructured data for each event that comes into the system. Also maps the event to each individual job or pipeline that gets spun off. All relevant persistent data is currently stored here.

Data layer

Backend account data storage.

In conjunction with Mongoose.js as a Node.js interface for MongoDB, I utilize this service to store user/feedback information.

Data storage of ITFrame

Notifications and analytics.

Great data store for JSON objects, which is mostly what I need.

Document oriented distriubted storage

Because you don't know what data you will be querying for. Perfectly suited for rapid prototyping. Altering tables in traditional, relational DBMS is painfully expensive and slow.

Performance is not great though. Ah who cares!

MongoDB is used as a datastore for accounts and users and underlying storage engine for databases.

Models in Agile Toolkit support NoSQL databases including MongoDB.

Main data storage, Has a secondary cache and stores our time series reports.

MongoDB is our prefered document store for pretty much all non-relational-heavy development. MongoDB scales beautifully and provides us with very polished api's and drivers. Easy to use, flexible and scalable.

some logger with it's own isolated collection

backend data store container

Replicated high-availability and high-performance database.

Backend of the app

Used Mongodb for web application development.

Saving Application data

Yes, we use Mongo

Backend server

MySQL was yesterday... MongoDB rocks. Check out s for smartdata on npm for MongoDB with TypeScript support.

Primary document store backend for the API

Unstructured No-SQL DB was important as deal with several different devices.

The backend for Parse Server.

System's main database

While the huge majority of BI data comes from 3rd-party sources, some pieces require ad-hoc sources - this is largely where Mongo comes into play. Views such as "Activity Log" need on-the-fly recordkeeping that's best manually entered; considering that fetching from a task manager API will paint an overwhelming or inaccurate picture of the month's activity.

Auxiliary storage for service data and settings. GridFS as storage for binary data

We are testing out MongoDB at the moment. Currently we are only using a small EC2 setup for a delayed job queue backed by agenda. If it works out well we might look to see where it could become a primary document storage engine for us.

Schema-less, JS in the console, flexible, fast, and pairs well with node/Mongoose.

타임라인 반응 데이터 및 로그 데이터 저장

OpenStack 내부의 메터링 서비스 데이터 기록을 위한 DB로 잠깐 사용했었다.

다이어리 앱의 사용자 및 다이어리 데이터는 MongoDB로 관리합니다.

Data storage.

The Geospatial features are the easiest to get up and running and easiest to scale beyond single servers. On top of that NoSQL allows us to iterate features at the speed of light.

We use Mongo for storage

Backend and analytics database.

Easy to develop with, can make changes to schemas easily.

Persistence database to store any data

Native integration with meteor

We used MongoDB to implement a filesystem abstraction for the application (i.e. each user has his/her own home directory and can share them, etc.)

Primary DB

For document (attachments) storage and associated metadata

Easy to use for small projects

Persistence Database

NoSQL of choice

MongoDB is used to store most of our data, both user-related (e.g. documents, contacts etc.) and global.

Leading document (JSON) database

We use MongoDB as our main NoSQL repository for data.

Out main storage.

Stores database items in document format. Doesn't require a schema declaration.

Mandatory database in meteor.js, stores user profiles

If we encounter multi-level or complex objects, we usually go with mongo/document/cosmos DBs. Getting better in detecting such objects and moving them here.

The massive volume of discovery data that powers Pinterest and enables people to save Pins, create boards and follow other users, is generated through daily Hadoop jobs...

The MapReduce workflow starts to process experiment data nightly when data of the previous day is copied over from Kafka. At this time, all the raw log requests are transformed into meaningful experiment results and in-depth analysis. To populate experiment data for the dashboard, we have around 50 jobs running to do all the calculations and transforms of data.

in 2009 we open sourced mrjob, which allows any engineer to write a MapReduce job without contending for resources. We’re only limited by the amount of machines in an Amazon data center (which is an issue we’ve rarely encountered).

YARN for cluster management

Product recommendations

• Raw storage engine
• Replication
• Fault-tolerance

Our data lake

Datalake and bigdata analytics

TBD. Good to have I think. Analytics on loads of data, recommendations?

Importing/Exporting data, interpreting results. Possible integration with SAS

大大大大大