ios - son - trucos para buscar en google como un experto

Cómo insertar y buscar eficientemente UUID en Core Data

Question

Estoy buscando una forma eficiente de almacenar y buscar UUID en Core Data. Esos UUID son generados por muchos dispositivos iOS en un sistema distribuido. Cada uno de esos dispositivos puede almacenar aproximadamente 20-50k UUID.

Es obvio que almacenar el UUID como cadena en los datos centrales perjudicará la eficacia de la indexación. Pero después de una serie de investigaciones descubrí que almacenar el UUID como Datos Binarios en Datos Básicos (e indexarlo) puede ser menos eficiente que almacenarlo como Cadena .

Como no se admite el tipo de datos BINARY-like o VARBINARY-like en SQLit. Supongo que cualquier tipo de datos de datos binarios en Core Data se almacena como BLOB en SQLit. Como BLOB podría ser el tipo de datos más lento para indexar, tendrá una influencia negativa en el rendimiento.

Entonces, ¿alguien puede ayudar a responder, existe una forma más eficiente de almacenar UUID en Core Data?

Answer 1

Guárdelos como una cadena ASCII y convierta el campo en un índice.

EDITAR

Egads, estaba dando vueltas y descubrí esto. Qué vergonzosa respuesta. Debo haber estado un poco de humor ese día. Si pudiera, simplemente lo eliminaría y seguiría. Sin embargo, eso no es posible, así que proporcionaré un recorte de una actualización.

Primero, la única manera de saber qué es "eficiente" es medir, teniendo en cuenta el tiempo y el espacio del programa, así como la complejidad del código fuente y el esfuerzo del programador.

Afortunadamente, este es bastante fácil.

Escribí una aplicación OSX muy simple. El modelo consiste en un solo atributo: identifier .

Nada de esto importa, si no marca su atributo como un índice. Tomará mucho más tiempo al crear la tienda, pero hará que las consultas sean mucho más rápidas.

Además, tenga en cuenta que crear un predicado para un atributo binario es exactamente lo mismo que crear uno para una cadena:

fetchRequest.predicate =
    [NSPredicate predicateWithFormat:@"identifier == %@", identifier];

La aplicación es muy simple. Primero, crea N objetos y asigna un UUID al atributo identificador. Guarda el MOC cada 500 objetos. Luego almacenamos todos los identificadores en una matriz y los mezcla aleatoriamente. Toda la pila de CD se derriba por completo para eliminarlo todo de la memoria.

A continuación, construimos la pila de nuevo, y luego iteramos sobre los identificadores, y hacemos una búsqueda simple. El objeto fetch se construye con un predicado simple para obtener ese objeto. Todo esto se realiza dentro de un autoreleasepool para mantener cada búsqueda lo más prístina posible (reconozco que habrá cierta interacción con las memorias caché de CD). Eso no es tan importante, ya que solo estamos comparando las diferentes técnicas.

El identificador binario es el de 16 bytes para el UUID.

UUID String es una cadena de 36 bytes, el resultado de llamar a [uuid UUIDString], y se ve así (B85E91F3-4A0A-4ABB-A049-83B2A8E6085E).

Base64 String es una cadena de 24 bytes, el resultado de la base 64 que codifica los datos binarios del UUID de 16 bytes, y se ve así (uF6R80oKSrugSYOyqOYIXg ==) para el mismo UUID.

Count es la cantidad de objetos para esa ejecución.

El tamaño de SQLite es el tamaño del archivo sqlite real.

El tamaño de WAL es lo grande que se obtiene el archivo WAL (write-ahead-logging), solo FYI ...

Crear es la cantidad de segundos para crear la base de datos, incluido el guardado.

La consulta es el número de segundos para consultar cada objeto.

Data Type     | Count (N) | SQLite Size | WAL Size  | Create  | Query
--------------+-----------+-------------+-----------+---------+---------
Binary        |   100,000 |   5,758,976 | 5,055,272 |  2.6013 |  9.2669
Binary        | 1,000,000 |  58,003,456 | 4,783,352 | 59.0179 | 96.1862
UUID String   |   100,000 |  10,481,664 | 4,148,872 |  3.6233 |  9.9160
UUID String   | 1,000,000 | 104,947,712 | 5,792,752 | 68.5746 | 93.7264
Base64 String |   100,000 |   7,741,440 | 5,603,232 |  3.0207 |  9.2446
Base64 String | 1,000,000 |  77,848,576 | 4,931,672 | 63.4510 | 94.5147

Lo primero que hay que señalar aquí es que el tamaño real de la base de datos es mucho mayor que los bytes almacenados (1,600,000 y 16,000,000), lo cual es de esperar para una base de datos. La cantidad de almacenamiento adicional será relativamente relativa al tamaño de sus objetos reales ... este solo almacena el identificador por lo que el porcentaje de sobrecarga será mayor).

En segundo lugar, en los problemas de velocidad, como referencia, hacer la misma consulta de 1.000.000 de objetos, pero usar el ID de objeto en la recuperación tomó aproximadamente 82 segundos (obsérvese la marcada diferencia entre eso y llamar a existingObjectWithID:error: que demoró 0.3065 segundos) .

Debe perfilar su propia base de datos, incluido un uso juicioso de los instrumentos en el código de ejecución. Imagino que los números serían algo diferentes si hiciera varias ejecuciones, pero están tan cerca que no es necesario para este análisis.

Sin embargo, en función de estos números, veamos las medidas de eficiencia para la ejecución del código.

• Como era de esperar, el almacenamiento de los datos binarios del UUID en bruto es más eficiente en términos de espacio.
• El tiempo de creación es bastante cercano (la diferencia parece estar basada en el tiempo para crear las cadenas y el espacio de almacenamiento adicional requerido).
• Los tiempos de consulta parecen casi idénticos, y la cadena binaria parece ser un poco más lenta. Creo que esta fue la preocupación original: hacer una consulta sobre un atributo binario.

El binario gana mucho espacio, y se puede considerar un acercamiento cercano tanto al tiempo de creación como al tiempo de consulta. Si solo consideramos eso, almacenar los datos binarios es el claro ganador.

¿Qué hay de la complejidad del código fuente y el tiempo del programador?

Bueno, si está utilizando una versión moderna de iOS y OSX, prácticamente no hay diferencia, especialmente con una categoría simple en NSUUID.

Sin embargo, hay una consideración para usted, y esa es la facilidad de uso de los datos en la base de datos. Cuando almacena datos binarios, es difícil obtener una buena visualización de los datos.

Entonces, si, por algún motivo, desea que los datos en la base de datos se almacenen de una manera más eficiente para los humanos, entonces almacenarlos como una cadena es una mejor opción. Por lo tanto, es posible que desee considerar una codificación base64 (o alguna otra codificación, aunque recuerde que ya está codificada en base-256).

FWIW, aquí hay una categoría de ejemplo para proporcionar un acceso más fácil al UUID como NSData y cadena base64:

- (NSData*)data
{
    uuid_t rawuuid;
    [self getUUIDBytes:rawuuid];
    return [NSData dataWithBytes:rawuuid length:sizeof(rawuuid)];
}

- (NSString*)base64String
{
    uuid_t rawuuid;
    [self getUUIDBytes:rawuuid];
    NSData *data = [NSData dataWithBytesNoCopy:rawuuid length:sizeof(rawuuid) freeWhenDone:NO];
    return [data base64EncodedStringWithOptions:0];
}

- (instancetype)initWithBase64String:(NSString*)string
{
    NSData *data = [[NSData alloc] initWithBase64EncodedString:string options:0];
    if (data.length == sizeof(uuid_t)) {
        return [self initWithUUIDBytes:data.bytes];
    }
    return self = nil;
}

- (instancetype)initWithString:(NSString *)string
{
    if ((self = [self initWithUUIDString:string]) == nil) {
        self = [self initWithBase64String:string];
    }
    return self;
}