Solución:
@ andreas-jung tiene razón en eso ensure_index() es un envoltorio sobre create_index(), Creo que la confusión surge con la frase:
Cuando PyMongo crea (o asegura) un índice, se “recuerda” durante ttl segundos.
No es que el índice sea temporal o “transitorio”, lo que sucede es que durante la cantidad de segundos especificada, una llamada a ensure_index() intentar crear el mismo índice de nuevo no tendrá algún efecto y será no llama create_index() debajo, pero después de que caduca el “caché”, una llamada a ensure_index() voluntad llamar de nuevo create_index() debajo.
Entiendo perfectamente su confusión porque, francamente, los documentos de PyMongo no hacen un buen trabajo al explicar cómo funciona esto, pero si se dirige a los documentos de Ruby, la explicación es un poco más clara:
- (Cadena) índice_aseguro (especificación, opts = {})
Llama a create_index y establece una bandera para no volver a hacerlo durante otros X minutos. este tiempo se puede especificar como una opción al inicializar un objeto Mongo :: DB como opciones[:cache_time] Cualquier cambio en un índice se propagará independientemente del tiempo de caché (por ejemplo, un cambio de dirección del índice)
Los parámetros y opciones de estos métodos son los mismos que los de Collection # create_index.
Ejemplos:
Call sequence:
Time t: @posts.ensure_index([['subject', Mongo::ASCENDING]) -- calls create_index and sets the 5 minute cache
Time t+2min : @posts.ensure_index([['subject', Mongo::ASCENDING]) -- doesn't do anything
Time t+3min : @posts.ensure_index([['something_else', Mongo::ASCENDING]) -- calls create_index and sets 5 minute cache
Time t+10min : @posts.ensure_index([['subject', Mongo::ASCENDING]) -- calls create_index and resets the 5 minute counter
No estoy diciendo que los controladores funcionen exactamente igual, es solo que, con fines ilustrativos, su explicación es un poco mejor en mi humilde opinión.
Tenga en cuenta que en Mongo 3.x ,uranceIndex está obsoleto y debe desalentarse.
En desuso desde la versión 3.0.0: db.collection.ensureIndex () ahora es un alias para db.collection.createIndex ().
Lo mismo está en pymongo:
DEPRECATED: garantiza que exista un índice en esta colección.
Lo que significa que siempre debes usar create_index.
los ensureIndex método en el Interactive Shell y ensure_index en el controlador de Python hay cosas diferentes, aunque se usa la misma palabra. Ambos create_index y ensure_index El método del controlador de Python crea un índice de forma permanente.
Quizás uno usaría ensure_index con un TTL razonable en tal situación, porque no estoy seguro de si create_index volvería a crear el índice cada vez que lo llame. La recreación normalmente no es deseada y podría ser una operación pesada. Pero incluso ensure_index (del controlador python o también ruby) posiblemente podría volver a crear el índice cada vez que el TTL expire o cuando lo llame desde una instancia de cliente diferente o después de un reinicio. No estoy seguro de esto.
Quizás una posibilidad aún mejor es verificar primero, usando el método index_information(), si el índice ya existe. Si ya existe, no lo volverás a crear.
Ahora estoy demostrando cómo el término ensure_index (o ensureIndex) se usa con 2 significados diferentes:
1) Crea un índice si aún no existe en la base de datos
Esto es lo que Shell interactivo método ensureIndex() lo hace:
http://www.mongodb.org/display/DOCS/Indexes#Indexes-Basics
También el Node.JS MongoDB Driver se comporta de esta manera:
https://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/collection.js
(Buscar function ensureIndex en el archivo collection.js.)
2) Crea un índice si no está en la ‘caché del controlador’
El mismo identificador se usa aquí con un significado diferente, lo que me resulta confuso.
Python y el controlador ruby almacenan información en la memoria sobre índices que se crearon recientemente, y llaman a este comportamiento “almacenamiento en caché”.
No informan a la base de datos sobre este almacenamiento en caché.
El resultado de este mecanismo es, si llamas create_index o ensure_index por primera vez con un valor TTL (tiempo de vida), el controlador insertará el índice en la base de datos y recordará esta inserción y también almacenará la información TTL en la memoria. Lo que se almacena en caché aquí es la hora y el índice en el que se encontraba.
La próxima vez que llames ensure_index con el mismo índice de la misma colección en la misma instancia de controlador, el ensure_index El comando solo insertará el índice nuevamente, si TTL segundos aún no han pasado desde la primera llamada.
Si llamas create_index, el índice siempre se insertará, no importa cuánto tiempo haya pasado desde la primera llamada, y por supuesto también si esta es la primera llamada.
Este es el controlador de Python, busque def ensure_index en el archivo collection.py:
https://github.com/mongodb/mongo-python-driver/blob/master/pymongo/collection.py
Y el conductor rubí, busca def ensure_index en el archivo collection.rb:
https://github.com/mongodb/mongo-ruby-driver/blob/master/lib/mongo/collection.rb
(Tenga en cuenta que las distintas instancias de cliente no conocen el almacenamiento en caché de las demás, esta información se mantiene solo en la memoria y es por instancia. Si reinicia la aplicación cliente, la nueva instancia no conoce las inserciones de índice “en caché” antiguas. Además, otros clientes no lo saben, no se cuentan entre sí).
Todavía no pude entender completamente lo que sucede en la base de datos, cuando el controlador de python o el controlador de ruby insertan un índice que ya está allí. Sospecho que no hacen nada en este caso, lo que tiene más sentido y también coincidiría con el comportamiento del Interactive Shell y el controlador JS.