2012-08-31 25 views
24

Estoy creando un servicio para el que usaré MongoDB como un back-end de almacenamiento. El servicio producirá un hash de la entrada del usuario y luego verá si ese mismo hash (+ entrada) ya existe en nuestro conjunto de datos.Creación de ID de objeto personalizado en MongoDB

El hash será único aún aleatorio (= no incremental/secuencial), por lo que mi pregunta es:

  1. personal ¿Se -legitimate- utilizar un valor aleatorio para un ID de objeto? Ejemplo:

$object_id = new MongoId(HEX-OF-96BIT-HASH);

O será MongoDB tratar el ID de objeto diferente al resto de los producidos por el servidor, ya que un "real" de objeto también contiene marcas de tiempo, machine_id, etc?

¿Cuáles son los pros y los contras de utilizar un valor 'aleatorio'? Supongo que sería estadísticamente más lento para el motor actualizar el índice en las inserciones cuando los nuevos _id no son de ninguna manera incrementales. ¿Estoy en lo cierto?

Respuesta

28

Sí, está perfectamente bien utilizar un valor aleatorio para una identificación de objeto, si algún valor está presente en el campo _id de un documento que se está almacenando, se trata como objectId.

Dado que el campo _id siempre está indexado, y la clave principal, debe asegurarse de que se genere un objectid diferente para cada objeto. Existen algunas pautas para optimizar los identificadores de objeto definidos por el usuario:

http://www.mongodb.org/display/DOCS/Optimizing+Object+IDs#OptimizingObjectIDs-Usethecollections%27naturalprimarykey%27intheidfield.

+0

Identificación única + aleatoria es el camino a seguir. – Sim

+0

@Sim ¿Es por eso que votaste? Tal vez puedas explicarnos un poco tu razonamiento, básicamente estás hablando el mismo razonamiento que tanto yo como este respondedor. Básicamente, ObjectId es una identificación única y aleatoria. – Sammaye

+0

@Sammaye lo siento, debe haber sido un clic mal dirigido. :/Quería votar por su respuesta y por esta porque son más relevantes que la mía. Si editas tu respuesta, puedo votarla. Sin la edición, el sistema no me lo permitirá. – Sim

6

Si es bueno o malo depende de su singularidad. Por supuesto, el ObjectID proporcionado por MongoDB es bastante único, así que esto es algo bueno. Mientras puedas replicar esa singularidad, entonces deberías estar bien.

No hay riesgos inherentes ni pérdidas de rendimiento al usar su propia ID. Supongo que usarlo en forma de cadena podría consumir más índice/almacenamiento/poder de consulta, pero ahí lo estás usando en forma de MongoID (Id. De Objeto), que debería preservar las fortalezas de no almacenarlo en una cadena simple.

4

solo he encontrado una respuesta a una de mis preguntas, respecto al rendimiento de indexación:

Si no necesita _ID'S están en un orden algo bien definido, en inserciones todo el b-árbol por el índice _id ser cargado. BSON ObjectIds tienen esta propiedad.

Fuente: http://www.mongodb.org/display/DOCS/Optimizing+Object+IDs

+0

Ah sí, solo noté que en realidad había dos preguntas en ese pregunta, vaya, lo siento :) – Sammaye

+0

Se llevó mi primer comentario porque he cambiado de opinión, cargar todo el árbol b sería una mala idea, también reitero el problema de omisión de consultas anteriores basadas en rango. – Sammaye

7

Mientras que todos los valores, incluyendo los hashes, se pueden utilizar para el campo _id, recomendaría contra el uso de valores aleatorios por dos razones:

  1. Es posible que necesite desarrolle una estrategia de gestión de colisiones en caso de que produzca valores aleatorios idénticos para dos objetos diferentes. En la pregunta, implica que generará ID usando algún tipo de algoritmo hash. No consideraría estos valores como "aleatorios", ya que se basan en el contenido que está digiriendo con el hash. La probabilidad de una colisión es una función de la diversidad de contenido y el algoritmo hash. Si está utilizando algo como MD5 o SHA-1, no me preocuparía el algoritmo, solo el contenido que está procesando.Si necesita desarrollar una estrategia de gestión de colisiones, definitivamente no debería utilizar ID aleatorias o basadas en hash ya que la gestión de colisiones en un entorno agrupado es complicada y requiere consultas adicionales.

  2. Los valores aleatorios, así como también los valores hash, están deliberadamente destinados a dispersarse en la recta numérica. Eso (a) requerirá que más del índice del árbol B se conserve en la memoria en todo momento y (b) puede causar un rendimiento de inserción variable debido al reequilibrio del árbol B. MongoDB está optimizado para manejar ObjectIDs, que vienen en orden ascendente (con granularidad de un segundo tiempo). Es mejor que te quedes con ellos.

Cuestiones relacionadas