Introduction to MongoDb with .NET part 44: a summary

Introduction

In the previous post we saw how to set the read and write preferences for our MongoDb operations in code. We can set these options at various levels: at the client, at the database or at the collection level. We can also specify our preferences directly in the connection string.

The previous post was also the last in this series dedicated to MongoDb in .NET. We’ve come a long way and it’s time to summarise what we have learnt.

Read more of this post

Introduction to MongoDb with .NET part 43: the read and write preference in the .NET driver

Introduction

In the previous post we discussed the ideas of read preference and read concern in MongoDb. Both play a role in multi-server scenarios where we can give hints to MongoDb where we want to read the data from: the primary server, one of the secondaries, the one with the shortest response time etc.

In this post we’ll see how to set the read and write concern options in the MongoDb .NET driver.

Read more of this post

Introduction to MongoDb with .NET part 42: the read preference

Introduction

In the previous post we first discussed briefly what a replica set in MongoDb is. A replica set is a group of MongoDb servers that behave as a single unit in order to provide increased data availability. There is one primary node and 2 or more secondary nodes. The “w” part of write concern in a replica set can be set to the number of nodes which should all send an acknowledgement of the write/update operation. It can also be set to “majority” where we want an acknowledgement from the majority of the replica set nodes. We can also specify a tag value for “w” so that we wait for the servers with a specific tag to acknowledge the operation.

We eventually want to read from our database as well. An interesting question is where we want to read the data from in a replica set. This is where the read preference enters the picture. There’s also a related term called read concern which we’ll also go through in some details.

Read more of this post

Introduction to MongoDb with .NET part 41: the write concern in a replica set

Introduction

In the previous post we introduced the topic of write concern in MongoDb. The write concern consists of two parts. The ingredient “w” stands for “write” and we can set the level of acknowledgement with it. The default is 1 and it means that we wait for an acknowledgement that the write operation was persisted to memory. 0 means fire-and-forget, i.e. we send the write operation to MongoDb and we don’t want to wait for any type of acknowledgement. The other ingredient of the write concern is “j” which stands for journal. The journal is a log where MongoDb registers all changes to the collection and its documents. We can either wait for the journal to be persisted to disk or not worry about it.

In this post we’ll talk a little bit about replica sets and what the write concern means in that scenario.

Read more of this post

Introduction to MongoDb with .NET part 40: the write concern

Introduction

In the previous post we saw how indexes were handled in the in the MongoDb .NET driver. Normally MongoDb indexes are created through the mongo shell, but the driver also offers a couple of options just in case you need that.

In this post we’ll start the finishing phase in this series on MongoDb and .NET: write and read concerns. These terms are related to durability and consistency of the data in the database.

Read more of this post

Introduction to MongoDb with .NET part 39: working with indexes in the MongoDb .NET driver

Introduction

In the previous post we went through a couple of diagnostics tools available in MongoDb. We mentioned the default logging tool which automatically logs all queries that took more than 100ms to complete. Then we looked at 3 tools that provide more details about what is going on in MongoDb: the profiler, mongotop and mongostat. They are great tools especially when we’re trying to optimise our queries. They also help debug our application by looking at the actual queries executed in the database.

This is the final post dedicated to indexing and performance in MongoDb. We’ll look at how to work with indexes in the MongoDb .NET driver.

Read more of this post

Introduction to MongoDb with .NET part 38: diagnostics

Introduction

In the previous post we learnt about building indexes for text fields in MongoDb documents. Index fields are very useful if you want to search for certain bits of text within a larger text. The text search does a very good job at finding the best matches. We can even ask MongoDb to rank the matching documents for us.

We’re actually done with the discussion regarding indexes in MongoDb. This post will give a brief overview over the diagnostics tools available in MongoDb. They help us extract a lot of useful information about what is going on within MongoDb.

Read more of this post

Introduction to MongoDb with .NET part 37: indexing text fields

Introduction

In the previous post we looked at various aspects of the query plan produced by the explain function. There are three query plan modes that correspond to an increasing level of details: query plan mode, execution stats mode and all plans execution mode. With the query plan mode we can quickly verify which strategy MongoDb will use to execute a query. Execution stats also tells the number of documents and index keys scanned and produced in each step. Finally the all plans execution mode shows how MongoDb selected a certain execution path by producing the details of any rejected plan as well.

In this post we’ll look at how to index text fields.

Read more of this post

Introduction to MongoDb with .NET part 36: other bits and pieces about the query plan

Introduction

In the previous post we looked at a couple of options we can provide when creating an index. With a unique index we can ensure that only unique values can be inserted on a property. A sparse index is often used in conjunction with a unique index. It enables us to index fields that not every document has, i.e. where the field is null. In that case those documents won’t be indexed. Finally we looked at foreground vs. background index creation. If an index is created on a foreground thread then it is relatively fast but it also blocks all readers and writers in the database. Background index creation on the other hand is slower but doesn’t block other threads that want to read and write.

In this post we’ll look at a couple of things related to the explain function.

Read more of this post

Introduction to MongoDb with .NET part 35: index options

Introduction

In the previous post we investigated how to create indexes within sub-documents. The dot notation which we saw when querying sub-documents also provides the syntax for deep indexing. We also quickly saw how to retrieve all indexes of a collection. In addition we learnt that array indexes are called multi-key indexes in MongoDb. The query plan returned by the explain function shows whether a certain index used for the query execution is multi-key or not.

In this post we’ll look at a couple of options available when creating indexes.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.