• Call us: 1(704) - 858 - 0065
  • Email us: dmngaya@dmnbigdata.com
  • Working Hours: 8am - 6pm

Performance MongoDB

Performance MongoDB Nous parlons de performance. Les performances des systèmes informatiques dépendent de divers facteurs, notamment les performances du matériel sous-jacent, à savoir le processeur, le disque et la mémoire. Une fois que nous avons choisi une configuration matérielle, ce sont nos algorithmes qui déterminent les performances. Et pour une application reposant sur une base de données, ce sont les algorithmes utilisés pour satisfaire nos requêtes. Vous pouvez affecter la latence et le débit des requêtes de base de données de deux manières. La première consiste à ajouter des index aux collections. Cela nous permet de trouver le document plus rapidement. Et le second consiste à répartir la charge sur plusieurs serveurs à l’aide du sharding. Dans MongoDB 3.0, il existe un nouveau stockage enfichable appelé Wired Tiger. Le moteur de stockage est le logiciel qui contrôle la manière dont les données sont stockées sur le disque. Et cela affecte par exemple la forme du système de fichiers ou l’aspect du modèle de données en mémoire. Nous allons parler de l’impact du choix du moteur de stockage sur les performances.

QUELS SONT LES MOTEURS DE STOCKAGE DANS LA BASE DE DONNÉES?

C’est l’interface entre la base de données et le matériel utilisé par la base de données. Fondamentalement, le moteur de stockage est ce que la base de données utilise pour implémenter, créer, lire, mettre à jour et supprimer des opérations. Les moteurs de stockage ne: – Modifiez la manière dont vous effectuez les requêtes non dans le shell, ni dans le pilote. – Ils ne changent pas de comportement au niveau du cluster. Le moteur de stockage affecte la manière dont les données sont écrites sur le disque. Et cela s’applique qu’il s’agisse d’insertion ou de mise à jour. Cela affecte la manière dont les données sont supprimées ou supprimées du disque. Et cela affecte la façon dont les données sont lues sur le disque. Enfin, cela affecte la structure de données utilisée pour stocker les données. BSON est représenté sur le disque. Depuis la version 3.0, nous pouvons choisir le moteur de stockage que nous utilisons, ce qui nous permet d’optimiser notre cas d’utilisation, notre matériel, etc. Deux choix (depuis mars 2015):
  • MMAP V1
  • Tigre filaire

MMAP V1:

Version classique du moteur de stockage MongoDB, elle mappe les fichiers de données directement dans la mémoire virtuelle, ce qui permet au système d’exploiter la plus grande partie du travail du moteur de stockage. Il utilise l’appel système mmap sur disque directement dans l’espace mémoire virtuelle. ne sont pas déjà en mémoire, une erreur de page les extraira dans la RAM et s’ils sont en mémoire et MongoDB les met à jour, fsync propage les modifications sur le disque.

COMMENT UTILISER MMAP V1?

C’est un moteur de stockage par défaut dans MongoDB 3.0, mais nous pouvons également utiliser:
mongodb   --storageEngine mmapvv1

nous pouvons trouver le moteur de stockage en consultant le journal (par défaut sur Centos sous / var / log / mongodb ou en vous connectant sur le shell:

repset:PRIMARY> db.serverStatus()
{

	"repl" : {
		"setName" : "repset",
		"setVersion" : 14,
		"ismaster" : true,
		"secondary" : false,
		"hosts" : [
			"base.deb.com:27017",
			"dn1.deb.com:27017",
			"dn2.deb.com:27017",
			"dn3.deb.com:27017"
		],
		"primary" : "base.deb.com:27017",
		"me" : "base.deb.com:27017",
		"electionId" : ObjectId("56a03d997d543ae69374a151"),
		"rbid" : 2048639483
	},
	"storageEngine" : {
		"name" : "mmapv1"
}
MMVAP V1 comes with collection-level document locking with MongoDB 3.0, prior that it was database-level with 2.2 to 2.6. The granularity with locking may or may not affect performance, it depends of our setup. The first thing, locking shared resources, the most is Data. If two process attempting to write the same region on disk at the same time, corruption can occur.For this reason, MongoDB has a multiple readers single writer, that means , we can have many readers and they will lock out any writers. As soon as one writer comes in, however, it locks out not only all readers, but all others writers, as well.If data were the only issue, we might have document level locking . But the reality is there’s other information. specifically metadata, where conflicts can occur. For example, two documents located in different places on disk might share a single index, so an update to one document will also involve an update to the other document might involve an update to that same index.Causing a conflict even if the documents are widely separated on disk. Another example of something that might cause a conflict is the journal, which we’ll talk about shortly. We’ll note the prior to MongoDB 3.0, we had database level locking.So if we want to distribute the load on the server among multiple databases,we can have simultaneous writes without any conflicts. But with MongoDB 3.0, we have collection level locking, which allows for more flexibility even if we have multiple collections in the same database, we can still write to them simultaneously until such time as we’re fully utilizing our resources. The next thing is the journal which is a write-ahead log. Why do we have this ? To ensure consistency in the event of a disk failure during an fsync without some bits might get updated, others not. With the journal, our write down what we’re about to then we do it. So if a disk failure occurs while we’re writing to the journal, that’s fine, we simply don’t perform the update ,when the disk comes back up, it notes the state of the database , notes that there was a partial update logged in the journal, but not complete, it ignores that log. And our database comes up in a consistent state. If a disk failure occurs later while we’re syncing our data to the disk, that’s fine too.We’ve got it complete in the journal and when our system comes back,we know that there was an incomplete update on the document , we look at the journal, complete the update and the database is back in a consistent state. So journaling is what ensures consistency of the data on disk in the event of failure and MongoDB strongly recommend it for all production systems. Finally, in MMAPv1, the data on disk is BSON, raw BSON. So bits are mapped from disk to virtual memory directly, this has implications for data modeling.

MMAPV1: DOCUMENTS ET FICHIERS DE DONNÉES:

Les documents et les fichiers de données dans MMAPv1 vont affecter les performances. Tout d’abord, à quoi ressemblent les fichiers de données? En commençant par mongodb, une fois encore, mmapv1 est par défaut. Si nous nous connectons à mongodb par shell et par défaut, nous nous connectons sur la base de données appelée test. show dbs, nous voyons la base de données locale.Il est généralement utilisé par réplication et contient également le journal de démarrage. Ainsi, il y aura une entrée pour chaque démarrage de MongoDB.Il n’est pas un très gros document. On peut voir ici
[hduser@dn1 mongo]$ ls -alh
total 1.2G
drwxr-xr-x   4 mongod mongod 4.0K Jan 22 23:30 .
drwxr-xr-x. 68 root   root   4.0K Jan 21 03:24 ..
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.ns
drwxr-xr-x   2 mongod mongod 4.0K Jan 22 23:30 journal
-rw-------   1 mongod mongod  16M Jan 22 23:30 local.0
-rw-------   1 mongod mongod 512M Jan 22 23:30 local.1
-rw-------   1 mongod mongod 512M Jan 22 23:30 local.2
-rw-------   1 mongod mongod  16M Jan 22 23:30 local.ns
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.ns
-rw-r--r--   1 mongod mongod    5 Jan 22 23:30 mongod.lock
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.ns
-rw-r--r--   1 mongod mongod   69 Jan 22 23:30 storage.bson
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.ns
-rw-------   1 mongod mongod  16M Jan 22 23:30 test.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 test.ns

i’ve got a little log file (mongod.lock). Let’s other mongod processes know not to come in , we also have local namespace file like local.ns which contains metadata, and the first data file is local.0 with 16M on this replicat set
var imax = 32;
var jmax = 32;
var kmax = 1000;
function setValues(doc, i, j, k) {
    doc._id = jmax * kmax * i + kmax * j + k;
    doc.a = i;
    doc.b = j;
    doc.c = k;
}
var emptyString = 'asdf';
emptyString = emptyString.pad(1000);  // make it bigger.
// make one thousand copies of our document in an array.
listOfDocs = []
for (i=0; i<kmax; i++) {
    listOfDocs.push({ _id: 0, a: 0, b : 0, c : 0, d : emptyString });
};
// one_thousand_docs is now built.
db.dropDatabase();  // start with a clean slate.
// db.createCollection("foo", {noPadding: true})
for (i=0; i<imax; i++) {
    for(j=0; j<jmax; j++) {
        for (k=0; k<1000; k++) {
            setValues(listOfDocs[k], i, j, k)
        };
        db.foo.insert(listOfDocs)  // breaks up if larger than 1000.
    }
}
Voir la source
Ce petit programme nous montrera comment MongoDB crée un fichier de données avec MMAPv1, démarrons-le et voyons le répertoire des fichiers de données:
[hduser@dn1 ~]$ mongo --host 192.168.56.72 --quiet loadDatabase.623a5313a2dc.js
MongoDB shell version: 3.0.6
connecting to: base:27017/test

Ce programme va ajouter 32 fois 32 fois 1 000 documents. Il a supprimé la base de données, puis il a explicitement créé la collection en définissant noPadding avec l'option true. Tous les documents seront rembourrés. Qu'est-il arrivé avec cette affaire?
Voir ci-dessous les fichiers de la base de données de test:
[hduser@dn1 mongo]$ ls -alh
total 3.7G
drwxr-xr-x   4 mongod mongod 4.0K Jan 23 07:36 .
drwxr-xr-x. 66 root   root   4.0K Jan 23 01:23 ..
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.ns
drwxr-xr-x   2 mongod mongod 4.0K Jan 23 07:34 journal
-rw-------   1 mongod mongod  16M Jan 23 00:47 local.0
-rw-------   1 mongod mongod 512M Jan 23 07:38 local.1
-rw-------   1 mongod mongod 512M Jan 23 07:38 local.2
-rw-------   1 mongod mongod  16M Jan 23 07:38 local.ns
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.ns
-rw-r--r--   1 mongod mongod    6 Jan 23 00:47 mongod.lock
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.ns
-rw-r--r--   1 mongod mongod   69 Jan 22 23:30 storage.bson
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.ns
-rw-------   1 mongod mongod  16M Jan 23 07:30 test.0
-rw-------   1 mongod mongod  32M Jan 23 07:29 test.1
-rw-------   1 mongod mongod  64M Jan 23 07:38 test.2
-rw-------   1 mongod mongod 128M Jan 23 07:30 test.3
-rw-------   1 mongod mongod 256M Jan 23 07:32 test.4
-rw-------   1 mongod mongod 512M Jan 23 07:37 test.5
-rw-------   1 mongod mongod 512M Jan 23 07:33 test.6
-rw-------   1 mongod mongod 512M Jan 23 07:38 test.7
-rw-------   1 mongod mongod 512M Jan 23 07:38 test.8
-rw-------   1 mongod mongod  16M Jan 23 07:38 test.ns

My first was 32 MB, then i’ve got 64MB, and 128MB and 256 — this is going to keep going until the insertion is done, doubling every time once it gets to two gigabytes, it’s going to stop and continue to allocates to two gigabytes but we’re not going to get there today because in mon configuration i choose smallfiles option (see this link https://docs.mongodb.org/manual/reference/configuration-options/#storage.smallFiles).
We can see my test database has maxed out 512MB .
Now, look at the statistics:

[hduser@dn1 ~]$ mongo --host 192.168.56.72 --quiet
repset:PRIMARY> db.foo.stats();
{
	"ns" : "test.foo",
	"count" : 1024000,
	"size" : 1085440000,
	"avgObjSize" : 1060,
	"numExtents" : 18,
	"storageSize" : 1164976128,
	"lastExtentSize" : 307535872,
	"paddingFactor" : 1,
	"paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. 
         It remains hard coded to 1.0 for compatibility only.",
	"userFlags" : 2,
	"capped" : false,
	"nindexes" : 1,
	"totalIndexSize" : 28583296,
	"indexSizes" : {
		"_id_" : 28583296
	},
	"ok" : 1
}

We have one million documents ,we’ve got an average size of 1060 bytes. Padding factor is actually deprecated .
What we want to look at is the number of extents. Here , we have 18 extents. So , what’s an extent ?
Within the data file, several extents are going to be defined, and these extents are going to be address spaces where we can put documents. Now as it happens. We’ve set it up so that these documents are going to be right next to each other.So, it’ll put document number one on D1, document number two on D2 and so on. Now, my documents are all the same size . We can imagine a scenario where document three is really small and document four is really big, and so on.Now as we’re aware MongoDB is schemaless . Maybe we want to add a field to document number two, may be something else.Maybe we want to push some objects to the array.
So what ends up happening to document number two ? It wants to grow, but of course it’s nex the document three (small document), it’s got no room to grow.So what ends up happening is it ends up moving.Now, the movie itself isn’t going to be free, but actually there’s another issue — indexes. The issue is the indexes need to point to the document and in the case of MMAPv1, they point to the address space that the document starts at.
Now, when that document moves not only do we have to delete it from D2 where it was and recreate it after D4 in our example but more than that we need to update every index that points to that document so that it goes from pointing after D4, So in a typical MongoDB deployment,we’re going to end up with several indexes and this can get quite expensive, especially if we’re moving a lot of documents.
Now, let’s suppose that another document needs to get inserted, if it’s a big document, it would have to go over after the new place of D2 after D4. If it’s a small document, it might fit in D3 because in this extent we have a small document and there is a free place. So, suppose we need to update document six, that’s fine.We just take some of that extra space, grow it, and all’s well.
Suppose we want to give everything some space to grow,after all, most things are going to grow sooner or later.
Question: How much space do we want to give it ?
Let’s find out what the default is for MongoDB 3.0. Let’s go back to our load database program and this time we removed the noPadding:true option then execute it in our primary replication:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
var imax = 32;
var jmax = 32;
var kmax = 1000;
function setValues(doc, i, j, k) {
    doc._id = jmax * kmax * i + kmax * j + k;
    doc.a = i;
    doc.b = j;
    doc.c = k;
}
var emptyString = 'asdf';
emptyString = emptyString.pad(1000);  // make it bigger.
// make one thousand copies of our document in an array.
listOfDocs = []
for (i=0; i<kmax; i++) {
    listOfDocs.push({ _id: 0, a: 0, b : 0, c : 0, d : emptyString });
};
// one_thousand_docs is now built.
db.dropDatabase();  // start with a clean slate.
// db.createCollection("foo", {noPadding: true})
for (i=0; i<imax; i++) {
    for(j=0; j<jmax; j++) {
        for (k=0; k<1000; k++) {
            setValues(listOfDocs[k], i, j, k)
        };
        db.foo.insert(listOfDocs)  // breaks up if larger than 1000.
    }
}
Nous pouvons voir une fois de plus que nous obtenons le même résultat, comme avec padding: option true où la plus grande taille est 512Mo
[hduser@dn1 mongo]$ ls -alh
total 3.7G
drwxr-xr-x   4 mongod mongod 4.0K Jan 23 08:46 .
drwxr-xr-x. 66 root   root   4.0K Jan 23 01:23 ..
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 blog.ns
drwxr-xr-x   2 mongod mongod 4.0K Jan 23 08:44 journal
-rw-------   1 mongod mongod  16M Jan 23 00:47 local.0
-rw-------   1 mongod mongod 512M Jan 23 08:48 local.1
-rw-------   1 mongod mongod 512M Jan 23 08:48 local.2
-rw-------   1 mongod mongod  16M Jan 23 08:48 local.ns
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 m101.ns
-rw-r--r--   1 mongod mongod    6 Jan 23 00:47 mongod.lock
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 pcat.ns
-rw-r--r--   1 mongod mongod   69 Jan 22 23:30 storage.bson
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.0
-rw-------   1 mongod mongod  16M Jan 22 23:30 students.ns
-rw-------   1 mongod mongod  16M Jan 23 08:39 test.0
-rw-------   1 mongod mongod  32M Jan 23 08:38 test.1
-rw-------   1 mongod mongod  64M Jan 23 08:48 test.2
-rw-------   1 mongod mongod 128M Jan 23 08:39 test.3
-rw-------   1 mongod mongod 256M Jan 23 08:42 test.4
-rw-------   1 mongod mongod 512M Jan 23 08:47 test.5
-rw-------   1 mongod mongod 512M Jan 23 08:44 test.6
-rw-------   1 mongod mongod 512M Jan 23 08:48 test.7
-rw-------   1 mongod mongod 512M Jan 23 08:48 test.8
-rw-------   1 mongod mongod  16M Jan 23 08:48 test.ns

So even though our documents have padding this time ,it wasn’t enough to make another data file. These were our stats from the old database where we had 18 extents and the object size 1060 bytes , so let’s start over.

[hduser@dn1 ~]$ mongo --host 192.168.56.72 --quiet 
repset:PRIMARY> db.foo.stats()
{
	"ns" : "test.foo",
	"count" : 1024000,
	"size" : 2080768000,
	"avgObjSize" : 2032,
	"numExtents" : 20,
	"storageSize" : 2116751344,
	"lastExtentSize" : 536600560,
	"paddingFactor" : 1,
	"paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. 
         It remains hard coded to 1.0 for compatibility only.",
	"userFlags" : 1,
	"capped" : false,
	"nindexes" : 1,
	"totalIndexSize" : 28583296,
	"indexSizes" : {
		"_id_" : 28583296
	},
	"ok" : 1
}

Désormais, chaque objet a une taille de 2032 octets, donc il faut tenir compte de son facteur de remplissage et, en fait, j’ai des raisons de croire qu’il correspond exactement à 1024 octets, car MongoDB 3.0 utilise une puissance d’allocations de deux tailles. Qu'est-ce que cela signifie? Supposons que nous insérons un très petit document, il va allouer 32 octets, nous remarquerons donc une puissance de deux. Si ce document dépasse 32 octets, il en donnera 64 ou peut-être que le document initial était de 64 octets, puis 128 si c'est plus gros encore, et ainsi de suite jusqu'à deux mégaoctets ou 512 Mo si nous avons l'option de petits fichiers, après cela, il ne restera plus qu'à ajouter deux mégaoctets à la fois, mais dans notre cas, 512 Mo. Nous nous approchons de la limite de 16 mégaoctets de documents et nous pourrions penser à modifier un schéma. Cela présente donc quelques avantages: 1. Il y a de la place pour grandir pour chaque document. 2. S'ils grandissent suffisamment pour dépasser leur espace d'enregistrement - l'espace d'enregistrement est un document et un remplissage - ils laissent un trou normalisé dans lequel autre chose peut entrer et s'intégrer. Et puisque la taille de ces espaces d'enregistrement est assez standardisée, il est très peu probable que nous allons avoir un trou qui ne sera plus jamais utilisé. Si les documents grandissent sans cesse, ils ne disposeront généralement pas de la totalité de ce remplissage.Now,for MongoDB 3.0 this and no padding are the only options that we have.
Avant cela, c’était aussi la valeur par défaut dans MongoDB 2.6 et dans MongoDB 2.4, c’était même pas la valeur par défaut. Dans MongoDB 2.4, ils ont essentiellement essayé de faire en sorte que la base de données devine de combien d'espace nous devions avoir besoin. - peut-être 10% au début, peut-être plusieurs fois la taille du document que l'on essaie de deviner. Cela laisserait des trous dans nos fichiers de données, des espaces que nous ne finirions jamais par combler. Cela a également créé une situation dans laquelle nous aurions initialement beaucoup de déplacements de documents. Deux tailles d'allocation permettent en réalité de faire beaucoup mieux dans des situations où nous ne savons pas exactement à quel point nos documents vont grossir, si nous veillons à ce que les affectations soient effectuées de manière efficace. C’est la grande chose à ce sujet. Nous n’avons pas besoin d’en savoir beaucoup sur l’ampleur des choses. Cependant, si nous savons quelle taille vont avoir nos documents, nous pouvons initialement avoir un document relativement volumineux - peut-être avec un champ de chaîne qui nous donne l'espace supplémentaire dont nous avons besoin - et nous pouvons alors immédiatement désinstaller ce champ et réduire le document. . En fin de compte, notre document ne bouge pas et cet espace supplémentaire devient un facteur de remplissage. Puisque notre document n'a pas bougé, nous n'avons pas à nous soucier de la mise à jour de nos index. Et puisque moi, l'être humain, sommes en train de concevoir notre schéma, nous savons exactement ce qui va se passer à l'avenir. Une autre option serait de: rendez-le plus grand que d'habitude mais laissez un espace réservé pour certains champs que nous pourrons utiliser plus tard.

TIGRE FILAIRE:

C’est une nouvelle option depuis 2015, ce n’est pas simplement un moteur de stockage pour MongoDB, il est également utilisé dans d’autres bases de données. Comme MongoDB, Wired Tiger est entièrement open source. Pour en savoir plus, nous pouvons voir la page Web: http://www.wiredtiger.com/ En conclusion, le moteur de stockage détermine directement le format du fichier de données car différents moteurs de stockage peuvent implémenter différents types de compression et différentes méthodes de stockage du BSON pour mongoDB. Et le format des index car ils sont contrôlés par le moteur de stockage. Par exemple, MongoDB utilise Btrees. Avec MongoDB 3.0, WiredTiger utilisera des arbres B +, d’autres formats étant prévus dans les prochaines versions. Il est livré avec un certain nombre de fonctionnalités intéressantes: 1. Verrouillage au niveau du document 2. Compression 3. Manque quelques pièges de MMAPv1 4. Cela donne de gros gains de performance. Wire Tiger est: 1. Construit séparément de MongoDB 2. Il est effectivement utilisé par d’autres bases de données 3. C’est un projet open source Comment ça marche ? Nous avons ici différentes options pour le moteur de stockage dans MongoDB 3.0 et ultérieur:
[hduser@dn1 ~]$ mongod --help
Storage options:
  --storageEngine arg (=mmapv1) what storage engine to use
  --dbpath arg                  directory for datafiles - defaults to /data/db
  --directoryperdb              each database will be stored in a separate directory                               
  --noprealloc                  disable data file preallocation - will often hurt performance                                
  --nssize arg (=16)            .ns file size (in MB) for new databases
  --quota                       limits each database to a certain number of files (8 default)                               
  --quotaFiles arg              number of files allowed per db, implies --quota
  --smallfiles                  use a smaller default file size
  --syncdelay arg (=60)         seconds between disk syncs (0=never, but not recommended)                              
  --upgrade                     upgrade db if needed
  --repair                      run repair on all dbs
  --repairpath arg              root directory for repair files - defaults to 
                                dbpath
  --journal                     enable journaling
  --nojournal                   disable journaling (journaling is on by default for 64 bit)                             
  --journalOptions arg          journal diagnostic options
  --journalCommitInterval arg   how often to group/batch commit (ms)
WiredTiger options:
  --wiredTigerCacheSizeGB arg           maximum amount of memory to allocate for cache; defaults to 1/2 of 
                                        physical   RAM
  --wiredTigerStatisticsLogDelaySecs arg (=0)
                                        seconds to wait between each write to a statistics file in the dbpath; 
                                        0 means  do not log statistics
  --wiredTigerJournalCompressor arg (=snappy)
                                        use a compressor for log records [none|snappy|zlib]
  --wiredTigerDirectoryForIndexes       Put indexes and data in different directories
  --wiredTigerCollectionBlockCompressor arg (=snappy)
                                        block compression algorithm for collection data [none|snappy|zlib]
  --wiredTigerIndexPrefixCompression arg (=1)
                                        use prefix compression on row-store leaf pages

Nous allons maintenant essayer de courir avec le moteur de stockage Wired tiger:La première chose que nous avons faite est d’arrêter le processus mongod:
sudo service mongod stop
supprimer tous les fichiers de données appartiennent à MMAPv1 sinon nous aurons une erreur:

cd /var/lib/mongod  
      sudo rm -Rf *
## Ajoutez cette entrée dans votre fichier de configuration mongodb (#ajoutez un nouveau moteur de stockage wiredtiger) storageEngine = wiredTiger ou utilisez la ligne de commande ci-dessous: mongod --storageEngine wiredTiger --logpath /var/log/mongodb/mongod.log --fork sudo service mongod start

Nous avons ci-dessous des fichiers de données pour wiredTiger:
[hduser@base mongo]$ ls -ltr
total 149936
-rw-r--r-- 1 mongod mongod        21 Jan 23 12:08 WiredTiger.lock
-rw-r--r-- 1 mongod mongod        46 Jan 23 12:08 WiredTiger
-rw-r--r-- 1 mongod mongod       533 Jan 23 12:08 WiredTiger.basecfg
-rw-r--r-- 1 mongod mongod        95 Jan 23 12:08 storage.bson
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-10--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-12--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-14--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-16--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-18--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-20--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 23 12:08 index-22--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     20480 Jan 23 12:08 index-24--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod  12066816 Jan 24 17:07 index-26--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 17:07 index-8--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 17:07 index-5--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     32768 Jan 24 18:38 index-1--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     36864 Jan 24 19:33 _mdb_catalog.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-9--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     32768 Jan 24 19:33 collection-0--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-6--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     32768 Jan 24 19:33 collection-7--2152637442347840544.wt
drwxr-xr-x 2 mongod mongod      4096 Jan 24 19:33 journal
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-4--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-11--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-13--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-15--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-17--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-19--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     16384 Jan 24 19:33 collection-21--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     32768 Jan 24 19:33 collection-23--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod 140713984 Jan 24 19:33 collection-25--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod         5 Jan 24 19:33 mongod.lock
-rw-r--r-- 1 mongod mongod     36864 Jan 24 19:34 index-3--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     36864 Jan 24 19:34 collection-2--2152637442347840544.wt
-rw-r--r-- 1 mongod mongod     36864 Jan 24 19:35 sizeStorer.wt
-rw-r--r-- 1 mongod mongod    102400 Jan 24 19:35 WiredTiger.wt
-rw-r--r-- 1 mongod mongod       882 Jan 24 19:35 WiredTiger.turtle
nous voyons déjà la collection et un index. Allons à la base de données puis regardons le startup_log sur la base de données locale, nous verrons le moteur de stockage:
	"_id" : "dn2.deb.com-1451924833869",
	"hostname" : "dn2.deb.com",
	"startTime" : ISODate("2016-01-04T16:27:13Z"),
	"startTimeLocal" : "Mon Jan  4 11:27:13.869",
	"cmdLine" : {
		"config" : "/etc/mongod.conf",
		"net" : {
			"bindIp" : "192.168.56.73"
		},
		"processManagement" : {
			"fork" : true,
			"pidFilePath" : "/var/run/mongodb/mongod.pid"
		},
		"replication" : {
			"replSet" : "repset"
		},
		"storage" : {
			"dbPath" : "/var/lib/mongo",
			"engine" : "wiredTiger",
			"mmapv1" : {
				"smallFiles" : true
			}
		},
Créons un nouveau document sur la base de test: cela créera une autre collection avec un index. WiredTiger fonctionne au niveau de la collection et les index sont les index d’ID de soulignement. Internals de WiredTiger: Premièrement, il stocke les données sur le disque dans des arborescences B, similaires aux arborescences B utilisées par Index pour les index, mais pas pour ses données. Lors de la mise à jour, il écrit une nouvelle version des documents plutôt que d’écraser les données existantes de la même façon que MMAPv1. Cela peut sembler beaucoup de travail, mais wiredTiger le gère très bien. Ainsi, avec WireTiger, nous n’avons pas à nous préoccuper du mouvement des documents, pas plus que du facteur de remplissage. En fait, WiredTiger ne fournit même pas de rembourrage. Ensuite, il a deux caches de mémoire, le premier est le cache WireTiger, qui représente la moitié de notre RAM par défaut, mais nous pouvons l’accorder, et le suivant est le cache du système de fichiers. Comment nos données sont extraites du cache WiredTiger vers le cache du système de fichiers, puis sur le lecteur. Cela se produit périodiquement à ce qu’on appelle un point de contrôle. Au cours d’un point de contrôle, nos données sont transférées du cache WiredTiger dans le cache du système de fichiers, puis transférées sur disque. Chaque point de contrôle est un instantané cohérent de nos données. Il initie un nouveau point de contrôle 60 secondes après la fin du dernier point de contrôle. Donc, à peu près toutes les minutes, peut-être un peu plus. Si, pour une raison quelconque, nous exécutons notre MongoDB avec WireTiger sans journalisation ni réplication, nous devrions revenir au dernier instantané pour obtenir une vue cohérente de nos données – donc environ une minute.Parce que c’est un instantané cohérent, si nous utilisons la journalisation, le journal sera tronqué à ce stade. Si trop de notre cache WireTiger est sale, il commencera à vider les données dans le cache du système de fichiers, puis de là sur le disque. Une chose à noter ici est qu’étant donné qu’un point de contrôle est un instantané cohérent valide de nos données, nous n’avons techniquement pas besoin d’exécuter WiredTiger lorsque la journalisation est activée. Nous avons la garantie d’avoir un état cohérent de nos données depuis le dernier point de contrôle et l’avant-dernier point de contrôle ne sera pas supprimé tant que le prochain point de contrôle n’aura pas été entièrement écrit. Bien sûr, la journalisation conserve nos données sur disque beaucoup plus rapidement. Il est écrit sur le disque beaucoup plus rapidement, c’est-à-dire.

WIREDTIGER – VERROUILLAGE DE NIVEAU DE DOCUMENT:

Techniquement, WiredTiger n’a pas de verrous, mais de bons protocoles de concurrence. L’effet est l’équivalent du verrouillage au niveau du document. Avec WiredTiger, nos écritures doivent évoluer en fonction du nombre de threads. Quelques mises en garde: Ne pas essayer d’utiliser beaucoup plus de threads que de cœurs. Évidemment, notre matériel est toujours une limitation potentielle. Ensuite, puisque WiredTiger dispose de son propre cache et que les données contenues dans l’argent WiredTiger ne doivent pas nécessairement être identiques à celles du cache du système de fichiers, ou telles qu’elles sont représentées sur le lecteur, elles sont en réalité très différentes – WiredTiger est capable d’introduire la compression.

WIREDTIGER – COMPRESSION:

3 options de compression – techniquement deux options de compression, ou nous pouvons exécuter sans compression. La valeur par défaut est Snappy: il est rapide, il donne la priorité à la vitesse, mais essaie également d’obtenir autant de compression que possible. Zlib: privilégie un peu plus la compression, éventuellement au détriment de la vitesse. Comparez cela avec MMAPv1 où le BSON doit être écrit sur le disque, tout comme il est en mémoire, de sorte qu’aucune compression n’est possible. Certaines options que nous pouvons utiliser: La compression du préfixe d’index, par exemple, permet d’économiser de l’espace, mais c’est un coût d’utilisation du processeur. Nous pouvons également sélectionner l’option permettant de placer les index dans un répertoire séparé, nous pouvons également ajuster la taille de notre cache afin d’optimiser nos performances et, enfin, nous pouvons également disposer d’un enregistrement de statistiques.

INDEX:

C’est un moyen de trouver nos documents très rapidement, voici la commande:
repset:PRIMARY> use test
switched to db test
repset:PRIMARY> db.foo.createIndex({a:1});

{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
Cette commande est très similaire à celle-ci:
db.foo.find().sort({a:1});
or i can sort by descending order:
db.foo.find().sort({a:-1});
Nous pouvons spécifier plusieurs champs lorsque nous créons un index:
repset:PRIMARY> db.foo.createIndex({a:1,b:1})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"numIndexesAfter" : 3,
	"ok" : 1
}
et un peu comme avec une sorte l’ordre est important, c’est un index a1, b1 et n’est pas du tout identique à un index b1, a1. Je peux utiliser mon index pour trier sur a1, b1 comme ceci:
db.foo.find().sort({a:1,b:1}); 
or to sort on a negative 1:
db.foo.find().sort({a:-1,b:-1}); 
Les deux sont acceptables en passant, quand nous avons un index sur deux champs ou plus, cela s’appelle un index composé. Et je devrais noter que les index ont seulement deux directions (positif 1, positif 1) ou (négatif 1, négatif 1) mais je ne peux pas travailler avec négatif 1, positif 1 ou positif 1, négatif 1, qui n’utiliserait pas d’indice .

COMMENT SAVOIR QUEL INDEX EST DANS MA COLLECTION?

repset:PRIMARY> db.foo.getIndexes();
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "test.foo"
},
{
"v" : 1,
"key" : {
"a" : 1
},
"name" : "a_1",
"ns" : "test.foo"
},
{
"v" : 1,
"key" : {
"a" : 1,
"b" : 1
},
"name" : "a_1_b_1",
"ns" : "test.foo"
}
]

COMMENT BAISSER UN INDEX DANS MA COLLECTION?

repset:PRIMARY>db.foo.dropIndex({a:1});
{ "nIndexesWas" : 3, "ok" : 1 }

SCANS DE COLLECTION:

Pourquoi créons-nous ces index? Si nous avons une collection contenant par exemple un milliard, voire un million ou un millier de documents, et que nous voulons trouver un document spécifique très rapidement, si nous n’avons pas d’index, la base de données effectuera une analyse de la collection de manière séquentielle. tout au long de la recherche de correspondances à ceci et cela sera lent si la collection est grande.Cependant, si nous avons un index, et nous aurons un index dans “ID” en général, comme l’index d’ID est automatiquement créé pour une collection . Si nous voulons rechercher cette valeur «ID», nous pouvons simplement descendre jusqu’à ce que nous trouvions «ID» et qu’il y ait un pointeur sur l’enregistrement de droite, ou que les enregistrements et les «clés dupliquées» soient autorisés dans les index MongoDB. ID index, en raison d’une contrainte de clé unique.

INDEX NOTES: INDEXES UNIQUES: INDEX ÉPARGNÉS: INDEX TTL: INDEX GEOSPATIAUX: INDEX DE TEXTE: CRÉATION D’INDICE DE FOND: EXPLIQUEZ LES PLANS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
repset:PRIMARY> use pcat
switched to db pcat
repset:PRIMARY> show collections
products
repset:PRIMARY> db.products.find().pretty();
{
    "_id" : "ac3",
    "available" : true,
    "brand" : "ACME",
    "name" : "AC3 Phone",
    "price" : 200,
    "type" : "phone",
    "warranty_years" : 1
}
{
    "_id" : "ac7",
    "available" : false,
    "brand" : "ACME",
    "name" : "AC7 Phone",
    "price" : 320,
    "type" : "phone",
    "warranty_years" : 1
}
{
    "_id" : "ac9",
    "available" : true,
    "brand" : "ACME",
    "name" : "AC9 Phone",
    "price" : 333,
    "type" : "phone",
    "warranty_years" : 0.25
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bf9"),
    "for" : [
        "ac3",
        "ac7",
        "ac9"
    ],
    "name" : "AC3 Series Charger",
    "price" : 19,
    "type" : [
        "accessory",
        "charger"
    ],
    "warranty_years" : 0.25
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bfa"),
    "color" : "green",
    "name" : "AC3 Case Green",
    "price" : 12,
    "type" : [
        "accessory",
        "case"
    ],
    "warranty_years" : 0
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bfb"),
    "for" : [
        "ac3",
        "ac7",
        "ac9",
        "qp7",
        "qp8",
        "qp9"
    ],
    "name" : "Phone Extended Warranty",
    "price" : 38,
    "type" : "warranty",
    "warranty_years" : 2
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bfc"),
    "available" : false,
    "color" : "black",
    "for" : "ac3",
    "name" : "AC3 Case Black",
    "price" : 12.5,
    "type" : [
        "accessory",
        "case"
    ],
    "warranty_years" : 0.25
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bfd"),
    "available" : true,
    "color" : "red",
    "for" : "ac3",
    "name" : "AC3 Case Red",
    "price" : 12,
    "type" : [
        "accessory",
        "case"
    ],
    "warranty_years" : 0.25
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bfe"),
    "limits" : {
        "data" : {
            "n" : 20,
            "over_rate" : 1,
            "units" : "gigabytes"
        },
        "sms" : {
            "n" : 100,
            "over_rate" : 0.001,
            "units" : "texts sent"
        },
        "voice" : {
            "n" : 400,
            "over_rate" : 0.05,
            "units" : "minutes"
        }
    },
    "monthly_price" : 40,
    "name" : "Phone Service Basic Plan",
    "term_years" : 2,
    "type" : "service"
}
{
    "_id" : ObjectId("507d95d5719dbef170f15bff"),
    "limits" : {
        "data" : {
            "n" : "unlimited",
            "over_rate" : 0
        },
        "sms" : {
            "n" : "unlimited",
            "over_rate" : 0
        },
        "voice" : {
            "n" : 1000,
            "over_rate" : 0.05,
            "units" : "minutes"
        }
    },
    "monthly_price" : 60,
    "name" : "Phone Service Core Plan",
    "term_years" : 1,
    "type" : "service"
}
{
    "_id" : ObjectId("507d95d5719dbef170f15c00"),
    "limits" : {
        "data" : {
            "n" : "unlimited",
            "over_rate" : 0
        },
        "sms" : {
            "n" : "unlimited",
            "over_rate" : 0.01
        },
        "voice" : {
            "n" : 1200,
            "over_rate" : 0.05,
            "units" : "minutes"
        }
    },
    "monthly_price" : 90,
    "name" : "Phone Service Family Plan",
    "sales_tax" : true,
    "term_years" : 3,
    "type" : "service"
}
{
    "_id" : ObjectId("507d95d5719dbef170f15c01"),
    "additional_tarriffs" : [
        {
            "amount" : {
                "percent_of_service" : 0.06
            },
            "kind" : "federal tarriff"
        },
        {
            "amount" : 2.25,
            "kind" : "misc tarriff"
        }
    ],
    "cancel_penalty" : 25,
    "monthly_price" : 50,
    "name" : "Cable TV Basic Service Package",
    "sales_tax" : true,
    "term_years" : 2,
    "type" : "tv"
}
repset:PRIMARY> db.products.getIndexes();
[
    {
        "v" : 1,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "pcat.products"
    },
    {
        "v" : 1,
        "key" : {
            "for" : 1
        },
        "name" : "for_1",
        "ns" : "pcat.products"
    }
]
repset:PRIMARY> db.products.find({"for":"ac3"}).explain("executionStats");
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "pcat.products",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "for" : {
                "$eq" : "ac3"
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "for" : 1
                },
                "indexName" : "for_1",
                "isMultiKey" : true,
                "direction" : "forward",
                "indexBounds" : {
                    "for" : [
                        "["ac3", "ac3"]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 4,
        "executionTimeMillis" : 0,
        "totalKeysExamined" : 4,
        "totalDocsExamined" : 4,
        "executionStages" : {
            "stage" : "FETCH",
            "nReturned" : 4,
            "executionTimeMillisEstimate" : 0,
            "works" : 5,
            "advanced" : 4,
            "needTime" : 0,
            "needFetch" : 0,
            "saveState" : 0,
            "restoreState" : 0,
            "isEOF" : 1,
            "invalidates" : 0,
            "docsExamined" : 4,
            "alreadyHasObj" : 0,
            "inputStage" : {
                "stage" : "IXSCAN",
                "nReturned" : 4,
                "executionTimeMillisEstimate" : 0,
                "works" : 5,
                "advanced" : 4,
                "needTime" : 0,
                "needFetch" : 0,
                "saveState" : 0,
                "restoreState" : 0,
                "isEOF" : 1,
                "invalidates" : 0,
                "keyPattern" : {
                    "for" : 1
                },
                "indexName" : "for_1",
                "isMultiKey" : true,
                "direction" : "forward",
                "indexBounds" : {
                    "for" : [
                        "["ac3", "ac3"]"
                    ]
                },
                "keysExamined" : 4,
                "dupsTested" : 4,
                "dupsDropped" : 0,
                "seenInvalidated" : 0,
                "matchTested" : 0
            }
        }
    },
    "serverInfo" : {
        "host" : "base.deb.com",
        "port" : 27017,
        "version" : "3.0.8",
        "gitVersion" : "83d8cc25e00e42856924d84e220fbe4a839e605d"
    },
    "ok" : 1
}

QUESTIONS COUVERTES: LIRE ET ÉCRIRE LE RAPPEL: DB.CURRENTOP () & DB.KILLOP () REVISITED:

Si nous recherchons des problèmes de performances de base de données, il est conseillé de se connecter à db.currentOp () pour obtenir la valeur suivante: “secs_running”: (chercher longtemps), il est alors possible de tuer le processus à l’aide de la commande db .killOp (). Essayons-le en créant une activité sur notre serveur, nous avons le résultat ci-dessous: Nous avons donc un champ inprog – en cours – indiquant un tableau de toutes les opérations en cours. Il serait donc très courant de voir une liste assez longue si nous avons beaucoup de clients connectés à la base de données. Peut-être avons-nous 1000 connexions à la base de données, et il y a 40 opérations en cours, nous n’en avons qu’une.
repset:PRIMARY> db.currentOp();
{
	"inprog" : [
		{
			"desc" : "conn369",
			"threadId" : "0x6e9cd80",
			"connectionId" : 369,
			"opid" : 799732,
			"active" : true,
			"secs_running" : 3,
			"microsecs_running" : NumberLong(3303195),
			"op" : "getmore",
			"ns" : "local.oplog.rs",
			"query" : {
				"ts" : {
					"$gte" : Timestamp(1453703749, 34)
				}
			},
			"client" : "192.168.56.72:45089",
			"numYields" : 0,
			"locks" : {
				
			},
			"waitingForLock" : false,
			"lockStats" : {
				"Global" : {
					"acquireCount" : {
						"r" : NumberLong(8)
					}
				},
				"Database" : {
					"acquireCount" : {
						"r" : NumberLong(4)
					}
				},
				"oplog" : {
					"acquireCount" : {
						"r" : NumberLong(4)
					}
				}
			}
		},
		{
			"desc" : "conn3046",
			"threadId" : "0x36eb5a0",
			"connectionId" : 3046,
			"opid" : 798240,
			"active" : true,
			"secs_running" : 800,
			"microsecs_running" : NumberLong(800320312),
			"op" : "update",
			"ns" : "performance.sensor_readings",
			"query" : {
				"$where" : "function(){sleep(500);return false;}"
			},
			"client" : "192.168.56.71:40703",
			"numYields" : 1597,
			"locks" : {
				"Global" : "w",
				"Database" : "w",
				"Collection" : "w"
			},
			"waitingForLock" : false,
			"lockStats" : {
				"Global" : {
					"acquireCount" : {
						"r" : NumberLong(1600),
						"w" : NumberLong(1598)
					}
				},
				"Database" : {
					"acquireCount" : {
						"r" : NumberLong(1),
						"w" : NumberLong(1598)
					}
				},
				"Collection" : {
					"acquireCount" : {
						"r" : NumberLong(1),
						"w" : NumberLong(1598)
					}
				}
			}
		}
	]
}
repset:PRIMARY> db.setProfilingLevel(2);
{ "was" : 0, "slowms" : 100, "ok" : 1 }
2016-01-25T18:18:28.882-0500 I WRITE    [conn3212] update performance.sensor_readings query: 
{ $where: "function(){sleep(500);return false;}" } 
update: { $set: { name: "fran" } } keyUpdates:0 writeConflicts:0 exception: JavaScript execution terminated code:16712 
numYields:294 locks:{ Global: { acquireCount: { r: 297, w: 295 } }, Database: { acquireCount: { r: 1, w: 295 } }, 
Collection: { acquireCount: { r: 1, w: 295 } } } 147791ms
2016-01-25T18:18:28.883-0500 I COMMAND  [conn3212] command performance.$cmd command: update 
{ update: "sensor_readings", 
updates: [ { q: { $where: "function(){sleep(500);return false;}" }, u: { $set: { name: "fran" } }, 
multi: true, upsert: false } ], 
ordered: true } keyUpdates:0 writeConflicts:0 numYields:0 reslen:186 locks:{ Global: { acquireCount: 
{ r: 298, w: 296 } }, 
Database: { acquireCount: { r: 1, w: 296 } }, Collection: { acquireCount: { r: 1, w: 296 } }, Metadata: 
{ acquireCount: { W: 1 } } } 147792ms
repset:PRIMARY> db.killOp(798240)
{ "info" : "attempting to kill op" }
below source code for the script create_score,  pers.js:
use students;
db.grades.drop();
for (i = 0; i < 10000000; i++) {
    for (j = 0; j < 4; j++) {
	assess = ['exam', 'quiz', 'homework', 'homework'];
	record = {'student_id':i, 'type':assess[j], 'score':Math.random()*100};
	db.grades.insert(record);
    }
}
sous le code source du script stress_students.js:
import pymongo

# établir une connexion à la connexion à la base de 
données = pymongo.MongoClient("mongodb://localhost")

#obtenir une poignée à la base de données de test
db=connection.school
foo = db.students


for j in range(1,10):
    for i in range(400000,500000):
        doc = foo.find_one({'student_id':i})
        # print "first score for student ",doc['student_id'],"is ",doc['scores'][0]['score']
        if (i % 1000 == 0):
	    print "Did 1000 Searches"

LE PROFILER:

MONGOSTAT ET MONGOTOP:

Laisser un commentaire

Fermer le menu
×
×

Panier