What is Mongo DB and why should you use it!

The word Mongo is derived from the world humongous. So in essence, it implies that its sole purpose is to store mammoth amounts of data or what is otherwise coined as ‘big data’.

MongoDB is a document oriented database unlike its traditional relational counterparts such as SQL Server, DB2, Oracle, PostgreSQL etc.  MongoDB uses a JSON like syntax which is made up of name value pairs.

The fact that MongoDB is a document database, one of the rules that govern MongoDB is that every document must be unique. Hence it should have an ID. It’s also important to remember that the size of this document is typically 16MB.

MongoDB is elastic and therefore scales horizontally unlike RDBMS that scale vertically.

One of the key concepts of MongoDB is that there should always be a copy of the primary database (although not required), it is recommended that there be at least two copies of a database. In the event of a failure of primary database, the database can be restored from one of secondary servers.

The world we live in today where businesses are constantly evolving, billions of people and ‘things’ are always communicating, changing the way organizations and customers interact with each other and the environment around them. Data comes from different geographical locations and across multiple channels. Managing this explosion of high-velocity dynamic data while maintaining customer privacy is a challenge with legacy systems to say the least. That said, data is therefore of paramount importance for any organization large or small.

The solution to support rapidly growing applications is to scale horizontally by adding servers instead of concentrating more capacity in a single server. NoSQL databases, on the other hand, usually support auto-sharding, meaning that they natively and automatically spread data across an arbitrary number of servers, without requiring the application to even be aware of the composition of the server pool. Data and query load are automatically balanced across servers, and when a server goes down, it can be quickly and transparently replaced with no application disruption. This is especially an ideal situation for web applications.

While it is true that NoSQL databases lack transaction support and semantics database element that offers guarantees about data consistency and persistence. This is a solid tradeoff based on MongoDB’s goal of being simple, fast, and scalable. Once you leave those heavyweight features at the door, it becomes much easier to scale horizontally.

Some of the big 20 companies such as Google, Facebook, LinkedIn use NoSQL databases and it fits very well with their business model. That said, MongoDB has truly become a global company with over 50,000 members, 100 User Groups all around the world. As it stands right now, MongoDB has 29 offices in 14 different countries with over 3000 customers.

What’s in MongoDB

  • Key-values stores (JSON like syntax i.e. key/value pairs)
  • Column Family Stores (hierarchical schemas)
  • Document Databases
  • Multi-nested data
  • High velocity data coming at a very high rate of speed
  • Graph Databases
  • Unstructured data and by not enforcing transactional consistency
  • Document oriented databases are schema-agnostic. This allows for agility and highly iterative development
  • Durability when used in tandem with at least three servers (minimum)
  • Profiling Queries

Types of NoSQL Databases

Is MongoDB the Right Choice?

While it’s all fine and dandy to jump to this new shiny NoSQL database, but you ought to step back and ask yourself the following questions:

  • What are some of characteristics of my data?
  • What are the business needs of my data?
  • Am I required to query across multiple tables and possibly across multiple databases?
  • Do I need my data to be transactional?

Benefits

There’s no question, when compared to relational databases, NoSQL databases are more scalable and provide superior performance. Following are some of its benefits:

  • Speed and large volumes of rapidly changing structure, semi-structure and unstructured data
  • Open source, hence mostly Free
  • Object-oriented programming that is easy to use and flexible
  • Simplicity (with virtually no complex rules i.e. tables, relationships and less OOP impedance mismatch
  • Geographically distributed scale-out architecture instead of expensive, monolithic architecture

Format

MongoDB uses an open data forma called BSON which is similar to the JSON format. The BSON data format was developed by the MongoDB team. This format is special in that it facilitates searching of documents rapidly including the ability to add types for handling binary data. MongoDB stores data in BSON documents which is self-contained.

Scaling

Relational databases are designed to scale vertically, in that a single server has to host the entire database to ensure acceptable performance for cross-table joins and transactions. This can become an expensive proposition while placing limits on scale. The solution to support rapidly growing applications is to scale horizontally, by adding servers or cloud instances instead of concentrating more capacity in a single server.

References

www.MongoDB.com

http://Dataconomy.com/sql-vs-nosql-need-know

Posted in NoSQL | Comments Off on What is Mongo DB and why should you use it!

How to handle Many-to-Many Relationship in EF Core

There are a few steps that are instrumental in handling a Many-to-Many relationship in EF Core. It must be noted that EF Core 1.1 does not support Many-to-Many relationship right off the bat. However, with a junction table in hand, you can achieve this in just a few easy steps. Here’s how:

Let’s write a couple of POCO classes first. Below are the two main classes, namely Department and Employee respectively. Let’s just assume the relationship between the two is Many-to-Many.

    class Department
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Location { get; set; }

        public List DepartmentEmployees { get; set; }
    }
    class Employee
    {
        public int ID { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }

        public List DepartmentEmployees  { get; set; }
    }

As indicated above; in order for it work, we need a join table such that it can contain foreign keys of Department and Employee Classes like so:

class DepartmentEmployee
    {
        public int DepartmentID { get; set; }
        public int EmployeeID { get; set; }

        //Navigation Properties
        public Department Department { get; set; }
        public Employee Employee { get; set; }
    }

Now, add a class which is to be derived from DbContext. For this, ensure that you have the necessary packages installed which are the following:

  1. Microsoft.EntityFrameworkCore.SqlServer
  2. Microsoft.EntityFrameworkCore.SqlServer.Design
  3. Microsoft.EntityFrameworkCore.Tools

Please note, I have installed  SqlServer.Design package only because, I am using SQL Server. If I were using DB2, I would need to install the DB2.Design package and so on.

class DepartmentContext : DbContext
    {
        public DbSet Department { get; set; }
        public DbSet Employee { get; set; }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlServer(@"server=obi-oberoi; database=demo.ManyToMany; trusted_connection=true;");
        }
    }

Now, let’s try and add our first migration using the Package Manager Console window and see what we get:
PM>add-migration initial

InitialMigrationNotice, the message that says “The entity type “DepartmentEmployee” requires a primary key to be defined”. This is because EF Core could not discover a primary key in the DeparmentEmployee model even though they are defined in the class.

One thing to keep in mind though is that in order for a Join table to work, you need composite primary key(s). However, the creation of a composite key cannot be achieved simply through Data Annotations as it only provides a scaled down version of Fluent API. For that you need a Fluent API.

In order to resolve this, let’s override the OnModelCreating() method in our context and configure the ModelBuilder API that’ll define the shape of our entity, the relationship and how it maps to the database.

Given that it’s a composite key, it’s made up of the DepartmentID and EmployeeID.

    class DepartmentContext : DbContext
    {
        public DbSet Department { get; set; }
        public DbSet Employee { get; set; }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlServer(@"server=obi-oberoi; database=demo.ManyToMany; trusted_connection=true;");
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity()
                .HasKey(d => new { d.DepartmentID, d.EmployeeID });
        }
    }

Now, let’s try adding a migration.CompositeKeyand it worked!!!

Posted in ORM | Comments Off on How to handle Many-to-Many Relationship in EF Core

How to Build Trillion $ Opportunities & Solve the Grand Challenges of Humanity!

This is pretty much eleventh hour; and with a bunch of tickets on hand, I thought of making this final pitch to entice like-minded people to come and attend this once in a life time event.

This short seminar of 60 – 75 minutes could potentially change ones life and pave the road to ultimate Success!

WadhwaBlogUse this link to register for a complimentary seat.

I look forward to seeing  you on May 15th at 5:30PM at Microsoft Canada Headquarters.

Obi

Posted in News | Comments Off on How to Build Trillion $ Opportunities & Solve the Grand Challenges of Humanity!

Why is EF Core so blazing fast than its Predesessor?

It’s worth noting that EF Core is a brand new shiny tool from Microsoft that has been built from the ground up. It is lightweight, extensible and it comes with a plethora of new features when compared with EF 6.x.

Now, when it comes to performance, in just about all possible scenarios where tests have been conducted on CRUD related operations, EF Core has invariably outperformed EF 6.x. This is despite EF 6.x code having been tweaked for maximum optimization against somewhat naïve EF Core code, and yet coming out as a winner. So this begs the question…why is EF Core so much faster?

Well, the answer lies in the following:

  • Caching
  • Batching
  • Faster Initialization to build object models (conceptual model, mappings, storage etc.)

Stay tuned for more!!

Posted in ORM | Comments Off on Why is EF Core so blazing fast than its Predesessor?

EF 6.x or EF Core? I am confused!!!

If you are an enterprise developer or you are building a Line of Business Application and targeting the full .NET Framework and who also cares about visual tooling, EF 6.x is the way to go. It also means you can do WPF, Win Forms, ASP.NET MVC, Console apps etc.

EF 6.x is a mature product that is built over a period of time starting from 2008 till now. During this period, we have seen continuous improvements by way to adding new features, bug fixing etc. It has a rich eco-system of database providers and provides at least four workflows to build a model and database. It includes the following:

  • Code First
  • Code First From Database
  • Database First (EDMX Designer)
  • Entity First (Visual EDMX Designer)

EF Core on the other hand can target a multitude of application models ranging from full .NET Framework, ASP.NET Core as well as Xamarin. So if your dominant concern is to deploy your application on devices such as iOS, Android and such, EF Core is probably the way to go!

Apart from being cross-platform, EF Core is also a lightweight version of Entity Framework and is therefore built on a more leaner and faster development stack. Its because it has been built from ground up and is built over a set of services which make up the core of .NET.

Not only new platforms and new devices, EF Core has been architected to target new data stores. These data stores can be both relational and non-relational. Some of the examples of database providers are the following:

  • Azure Table Storage
  • Reds
  • In Memory (functional testing)
  • Relational providers such as:
    • SQL Server
    • SQLite
    • SQL Compact
    • Postgres
    • Oracle (prototyped)
    • DB2

more to come…

Posted in ORM | Comments Off on EF 6.x or EF Core? I am confused!!!