Today, we are happy to announce that MongoDB version 3.6 has passed our tests and is generally available on the ObjectRocket platform.
You can get the full list of what is available in the MongoDB 3.6 release notes.
In a previous blog post, we provided an introduction to massive scaling with MongoDB. Scaling tends to be reactive in nature leading to issues such as degraded application performance or, even worse, total application downtime. These issues ultimately lead to a negative customer experiences that impact your business.
In this post, we’ll explain some of the most common MongoDB use cases we come across and different characteristics that are influencing these choices.
Creating consistently good customer experiences has become a key challenge for many organizations.
Today’s users, customers, clients, and buyers are notoriously impatient. They demand new experiences that engage and inspire; and they wanted them delivered at light speed. Because of these demands and expectations, applications and data stores have evolved in order to provide these types of “I want it now” experiences.
There are lots of definitions for scaling. Scaling could be defined as removing the scales from a fish. However, with databases, scaling refers to having the ability to expand to meet additional needs around storage/disk, RAM/memory, CPUs/compute cycles, networking, or other resources.
Beginning in version 3.2, MongoDB tracks usage statistics for every index. To access these statistics, MongoDB offers the $indexStats aggregation pipeline stage. For example, the following command will provide the index statistics for the collection “test.foo”:
db.foo.aggregate( [ { $indexStats: { } } ] )
We won’t describe the $indexStats output as there is plenty of documentation and many good articles out there that cover this topic.
It’s no secret that NoSQL databases have gained tremendous ground over relational databases in the last decade. A primary driver for this is the huge amount of data generated today from sources we never would have dreamed of two decades ago.
One frequent Elasticsearch support request we receive is “Can you help with my response time?” or “My queries are taking a long time, what can I do?”
Whenever we get these types of questions, we begin by taking a deeper look at two main areas:
Operations Side – Look at the current system resources and default Elasticsearch options.
Despite all of the buzz focusing on newer NoSQL data stores, relational and SQL-based databases are still alive and well. In fact, almost every customer we work with has some MySQL, PostgreSQL or MS SQL Server in their environment alongside their MongoDB, Redis, or Elasticsearch.
It’s no secret that data is the cornerstone to any successful marketing campaign today. Your carefully collected data—shepherded by your equally carefully selected database administrator (DBA)—is a treasure trove of business intelligence that serves up all sorts of invaluable nuggets of information about your customers that you can use to your advantage and theirs.
