MongoDB vs. MariaDB vs. ClustrixDB

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.

Base de données

수 백만개가 넘는 태그 키워드의 자동완성을 위해서 별도의 데이터베이스를 구축하였습니다. MariaDB 는 MySQL 을 포크한 프로젝트입니다. MySQL 과의 강력한 호환성을 지니며, 큰 튜닝 없이 강력한 성능을 보장합니다.

Replacement for MySQL

Legacy systems

Holds our user account and results data.

OTLP

Faster than MySQL

DB

We have query-builder for SQL, and mostly using it for MariaDB.

Database

mysql보다 mariaDB가 join면에서 우수하다는 문서를 읽었습니다. 이 부분은 저의 블로그에서도 다뤘고 저의 word press 블로그는 mysql 대신 mariaDB 를 사용합니다.

특히 limit 기능이 pagenation 처리를 할 때 너무 직관적이고 편해서 mariaDB, mysql을 사랑합니다.

Used MariaDB as drop-in replacement on AWS server to act as RESTful API database in web application.

Aside from Redis, we use MariaDB to store long-term information like user-data and big-data like regeneration-information for our open-world servers. We extensively use the relational aspects of MariaDB in joins, nested queries and unions.

MariaDB is our database service.

MariaDB is used the same way as MySQL, except that MariaDB is used on our arch-based servers.

Back-end storage

Data persistence

Used in Docker local development

MariaDB has allowed us to easily scale out our DB cluster. Also has better replication tools than MySQL

We use MariaDB because it is fast, free and integrates well with the frameworks we are using.

On our servers, we use MariaDB as alternative to MySQL.

MariaDB Galera Cluster is the primary data store

A much better solution for an efficient database (compared to standard mySQL).

Introduced in computer science course.

Free and Open Source

Database used on the server

We hate Oracle.