fix spelling of splitable and theorem

source/applications/replication.txt

@@ -207,7 +207,7 @@ provides access to read preferences, which have the following names.
    produce an error.
 
    The :readmode:`primary` mode sacrifices availability for
-   consistency, in terms of the :term:`CAP Theorm`.
+   consistency, in terms of the :term:`CAP Theorem`.
 
 .. readmode:: primaryPrefered
 
@@ -224,7 +224,7 @@ provides access to read preferences, which have the following names.
    specified tags, this read operation will produce an error.
 
    The :readmode:`primaryPrefered` mode sacrifices consistency for
-   greater availability, in terms of the :term:`CAP Theorm`.
+   greater availability, in terms of the :term:`CAP Theorem`.
 
 .. readmode:: secondary
 
@@ -246,7 +246,7 @@ provides access to read preferences, which have the following names.
    set, this read operation will produce an error.
 
    The :readmode:`secondary` mode sacrifices consistency for
-   greater availability, in terms of the :term:`CAP Theorm`.
+   greater availability, in terms of the :term:`CAP Theorem`.
 
 .. readmode:: secondaryPrefered
 
@@ -264,7 +264,7 @@ provides access to read preferences, which have the following names.
    set, this read operation will produce an error.
 
    The :readmode:`secondaryPrefered` mode sacrifices consistency for
-   greater availability, in terms of the :term:`CAP Theorm`.
+   greater availability, in terms of the :term:`CAP Theorem`.
 
 .. readmode:: nearest
 

source/core/sharding-internals.txt

@@ -48,7 +48,7 @@ stores address records:
   number of fixed chunks. This may have a number of effects:
 
   - If MongoDB cannot split a chunk because all of its documents
-    have the same shard key, migrations involving these un-splittable
+    have the same shard key, migrations involving these un-splitable
     chunks will take longer than other migrations, and it will be more
     difficult for your data to stay balanced.
 
@@ -60,7 +60,7 @@ stores address records:
   While this field has a large number of possible values, and thus has
   potentially higher cardinality, it's possible that a large number of users
   could have the same value for the shard key, which would make this
-  chunk of users un-splittable.
+  chunk of users un-splitable.
 
   In these cases, cardinality depends on the data. If your address book
   stores records for a geographically distributed contact list
@@ -165,7 +165,7 @@ To select a shard key for a collection:
 
 If this field has low cardinality (i.e not sufficiently
 selective) you should add a second field to the shard key making a
-compound shard key. The data may become more splittable with a
+compound shard key. The data may become more splitable with a
 compound shard key.
 
 .. see:: ":ref:`sharding-mongos`" for more information on query

source/reference/glossary.txt

@@ -828,7 +828,7 @@ Glossary
 
       .. versionadded:: 2.2
 
-   CAP Theorm
+   CAP Theorem
       Given three properties of computing systems, consistency,
       availability, and partition tolerance, a distributed computing
       system can provide any two of these features, but never all

source/use-cases/product-catalog.txt

@@ -483,7 +483,7 @@ actual activity and distribution. Consider that:
 
 - you should include one or more fields in the ``detail`` document
   that you query frequently, and a field that has quasi-random
-  features, to prevent large unsplittable chunks.
+  features, to prevent large unsplitable chunks.
 
 In the following example, assume that the ``details.genre`` field is
 the second-most queried field after ``type``. Enable sharding using