mongodb-user
[Arriba] [Todas las Listas]

[mongodb-Usuario] documento Más eficaz estrategia de traslado?

To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Subject: [mongodb-Usuario] documento Más eficaz estrategia de traslado?
From: Seth Kelly <kelly.sethp@xxxxxxxxx>
Date: Mon, 1 Feb 2016 07:12:28 -0800 (PST)
Delivery-date: Mon, 01 Feb 2016 15:06:13 -0500
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=FGiLskgL+TkmA64ngT1HXasoJPDGmGTcnAX2SQqAXtI=; b=rH66CnD6NJVeV2WHMR5WrEPxEWCMdo2gEh05J9HUSWzwx89ouJlw57+sdBWKwhKK3e lijeWttqIuWwNx6kCI78z3S9nVnSPaHTZ00bKMfHu9vEuedIfVdmFPNaZvaQC/FvZ/AJ uNpUh98qAAxpG0KolBEHiuANQW3qJfGRJibAx4yhfCwOtITTMa5/2K3xe73qVZGuORNT wyI2pHZa4inEZtU45EU1OF1rpzzbENrH3XrTCJFl156793Abd3lP4AS0RfNNXv7QBPP4 QLk/uYln510XhpONqzmi7AzSsi3vvfxCqK+YutyMvbxe///6CAxspfFGqyYkngkcQl1s H3tw==
Envelope-to: traductor@xxxxxxxxxxx
List-archive: <https://groups.google.com/group/mongodb-use>
List-help: <https://groups.google.com/support/>, <mailto:mongodb-user+help@googlegroups.com>
List-id: <mongodb-user.googlegroups.com>
List-post: <https://groups.google.com/group/mongodb-user/post>, <mailto:mongodb-user@googlegroups.com>
List-subscribe: <https://groups.google.com/group/mongodb-user/subscribe>, <mailto:mongodb-user+subscribe@googlegroups.com>
List-unsubscribe: <mailto:googlegroups-manage+1044811755470+unsubscribe@googlegroups.com>, <https://groups.google.com/group/mongodb-user/subscribe>
Mailing-list: list mongodb-user@xxxxxxxxxxxxxxxx; contact mongodb-user+owners@xxxxxxxxxxxxxxxx
Reply-to: mongodb-user@xxxxxxxxxxxxxxxx
Sender: mongodb-user@xxxxxxxxxxxxxxxx
*Hey *folks,

tengo una cuestión relacionada a *mongoDB Escribir/Sacar rendimiento. 
 Específicamente, qué la mayoría de manera eficaz de hacerlo?

Estoy utilizando *MongoDB a como el respaldando tienda para un distribuido *cache que construí.  El *cache los apoyos Encuentran, Insertar y Sacar operaciones (*cache 
las entradas nunca son actualizadas).  Encuentra el rendimiento es la mayoría de importante, 
seguido por Insertar, entonces Saca.  La mayoría de el tiempo consigo 
grande Encontrar rendimiento <50*ms con mi 40GB *dataset.  Aun así, ocasionalmente 
veo rendimiento *spikes arriba de en el 100*ms-300*ms gama.  Estos *spikes resultado en 
consultas lentas *logged al *profiler, y aparecer para ser *correlated con tiempo 
de alto Sacar volumen.  *Basado en el *timeAcquiring *metrics para el escribir 
cerradura, aparece que el Encontrar las operaciones ocasionalmente están consiguiendo *queued 
para una cantidad excesiva de tiempo detrás de Sacar operaciones.  Mi objetivo es a *minimize 
cronometra gastado escribir-cerrado de modo que **Encuentra** no es obstruido por 
Saca, porque **Encuentra** es la prioridad más alta de #mío aplicación operación.*

Cada documento contiene un *indexed la variedad de llaves llamó "*invalidationKeys". 
 Un Sacar implica un $en consulta con algún conjunto de *invalidationKeys. Un dado 
clave típicamente empareja 0-25 documentos.  Dejado decir tengo 5 *invalidationKeys 
= un, *b, *c, *d, y *e, y quiero sacar todos los  documentos que referencia ninguno 
de ellos.  hay 3 maneras puedo pensar del cual podría ser eficaz.

1: *Moar aproximación de Hilos - *Spin arriba de 5 hilos y marca 5 consultas paralelas a *mongoDB: 
 
*db.*cache.Saca("#unknown{^*invalidationKeys":$#adv: [un]}}),
*db.*cache.Saca("#unknown{^*invalidationKeys":$#adv: [*b]}}),
...

2: *Batched aproximación - Marca un grande $en consulta con todo 5 llaves:
*db.*cache.Saca("#unknown{^*invalidationKeys":$#adv: [un, *b, *c, *d, *e]}}),

3: DB-nativo *batched aproximación - Utilizar el *Bulk API para hacer un solo *bulk 
operación fuera de 5 consulta independiente operaciones (puedo utilizar *unordered 
porque estos Sacan las operaciones son independientes):
*var *bulk = *db.*cache.*initializeUnorderedBulkOp();
*bulk.Encuentra("#unknown{^*invalidationKeys":$#adv: [un]}}).Saca();
*bulk.Encuentra("#unknown{^*invalidationKeys":$#adv: [*b]}}).Saca();
...
*bulk.Ejecuta();

Mi opción de usos de implementación actual 1 (tengo una piscina de 20 hilos que 
individuo de servicio Saca operaciones).  Estoy preguntándome si yendo a opción 2 
o 3 reducirá el tiempo gastado escribir cerrado o no.

-- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo"
de usuario.

Para otro *MongoDB opciones de apoyo técnico, ve: *http://www.mongodb.org/sobre/apoyo/.
--- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo" de usuario.
A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
Visita este grupo en *https://grupos.*google.*com/Grupo/*mongodb-usuario.
Para ver esta discusión en la visita de web *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/3389*c594-601un-4#uno2*e-8025-*d2763747070*b%40*googlegroups.*com.
Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
Hey folks,

I have a question related to mongoDB Write/Remove performance. 
 Specifically, what's the most efficient way to do it?

I am using MongoDB to as the backing store for a distributed cache that I 
built.  The cache supports Find, Insert and Remove operations (cache 
entries are never updated).  Find performance is the most important, 
followed by Insert, then Remove.  Most of the time I get 
great Find performance <50ms with my 40GB dataset.  However, I occasionally 
see performance spikes up in the 100ms-300ms range.  These spikes result in 
slow queries logged to the profiler, and appear to be correlated with times 
of high Remove volume.  *Based on the timeAcquiring metrics for the write 
lock, it appears that the Find operations are occasionally getting queued 
for an excessive amount of time behind Remove operations.  My goal is to 
minimize time spent write-locked so that **Finds** aren't obstructed by 
Removes, because **Find** is my application's highest priority operation.*

Each document contains an indexed array of keys called "invalidationKeys". 
 A Remove involves an $in query with some set of invalidationKeys. A given 
key typically matches 0-25 documents.  Let's say I have 5 invalidationKeys 
= a, b, c, d, and e, and I want to remove all documents which reference any 
of them.  There's 3 ways I can think of which might be efficient.

1: Moar Threads approach - Spin up 5 threads and make 5 parallel queries to 
mongoDB: 
db.cache.remove({"invalidationKeys": {$in: [a]}}),
db.cache.remove({"invalidationKeys": {$in: [b]}}),
...

2: Batched approach - Make one big $in query with all 5 keys:
db.cache.remove({"invalidationKeys": {$in: [a, b, c, d, e]}}),

3: DB-native batched approach - Use the Bulk API to make a single bulk 
operation out of 5 independent query operations (I can use unordered 
because these Remove operations are independent):
var bulk = db.cache.initializeUnorderedBulkOp();
bulk.find({"invalidationKeys": {$in: [a]}}).remove();
bulk.find({"invalidationKeys": {$in: [b]}}).remove();
...
bulk.execute();

My current implementation uses option 1 (I have a pool of 20 threads which 
service individual Remove operations).  I'm wondering if going to option 2 
or 3 will reduce time spent write locked or not.

-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/3389c594-601a-4a2e-8025-d2763747070b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Anterior por Tema] Tema Actual [Siguiente por Tema>