DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today
  1. DZone
  2. Data Engineering
  3. Databases
  4. MongoDB and Scale Out? No, Says MongoHQ
Content provided by Couchbase logo

MongoDB and Scale Out? No, Says MongoHQ

Don Pinto user avatar by
Don Pinto
·
Mar. 28, 14 · Interview
Like (0)
Save
Tweet
Share
5.72K Views

This article was originally written by Shane Johnson

You may have heard that MongoDB has issues with scaling out. You may have heard that Viber is replacing MongoDB with Couchbase Server. Have you heard that MongoHQ has to scale up?

I agree with MongoHQ on one thing. It's easier to scale up. While scaling up may be the only solution for MongoDB, it is not the right solution. What happens when there is no more room to scale up? I think that MongoHQ would prefer to scale out, but they realized that MongoDB was not engineered for it.

It results in a loss of functionality...

In MongoDB, for instance, horizontal scales means losing out on unique secondary indexes (one of the few schema constraints MongoDB currently supports) for a given collection.

It requires difficult decisions...

In MongoDB, this choice is the “shard key decision” that you will hear experienced MongoDB users talk about with undertones of dread.

It is complex to configure and maintain...

But once you’ve got your sharded database into production, then there’s the underlying reality that your system has more “moving parts” in it than might be ideal because more moving parts mean more things can go wrong.

It results in a loss of performance...

In a sharded setup, the network connectivity between the Mongo router, config servers, and each shard influences overall performance.

Couchbase Server, on the other hand, was engineered to scale out. It does not result in a loss of functionality. It does not require difficult decisions. It is not complex to configure and maintain. It does not result in a loss of performance.

  • Couchbase Server does not require manual configuration of sharding. It is automatic.
  • Couchbase Server does not have a lot of moving parts. There is one node type.
  • When Couchbase Server is scaled out, the performance is increased.

I think the section on oplog tailling was rather troublesome. I think it highlights the fact that MongoDB was not engineered to scale out. It turns out that administrators and developers rely on a log file for insight and integration. The problem with scaling out MongoDB is that is requires developers to tail multiple log files. There is a log file per node.

Couchbase Server, on the other hand, does not require administrators and developers to tail a log file for insight and integration. Administrators can monitor Couchbase Server from any node. Developers can integrate with Elasticsearch or Apache Hadoop without having to interact with individual Couchbase Server nodes. The topology is transparent. That's the benefit of a distributed system with a shared nothing architecture.

It's worth pointing out that Couchbase Server supports cross data center replication. It allows the data in a cluster to be replicated to a different cluster. In fact, this is how we integrate with Elasticsearch. It is as a different cluster that Couchbase Server can replicate data to. That it is an Elasticsearch cluster is irrelevant. It is simply a different cluster to replicate data to.

Join the conversation over at reddit (link).
Join the conversation over at Hacker News (link).

Further Reading

Why We Start Scaling Vertically (Google Web Cache)

Note: MongoHQ as removed the original post and is now redirecting to a new one.

Topology: The Architecture of Distributed Systems

Note: This includes an overview of the moving parts within a MongoDB deployment that is scaled out.

Couchbase Server Elasticsearch Integration (page | doc)

Couchbase Server Apache Hadoop Integration (page | doc)


Comments

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: