Azure Storage Table Paging

Question

Para implementar simple paginación en Azure Storage en relativamente sencillo: Paging with Windows Azure Table Storage. Esto puede implementarse con la funcionalidad de token de continuación.

Pero.

Esto es sólo el comienzo de una paginación seria. El primer problema es ordenando. No puede hacer OrderBy en Azure Table. ¿Cuál sería la mejor solución para superar esto? Las páginas deben ser ordenadas, ese es el hecho.

El segundo problema, cuando viene a la paginación es saber el número total de páginas, con la continuación de la funcionalidad del token esto no es posible. Hacer en cada página ".Count()" me parece muy ineficiente (ya que las particiones pueden estar en varios servidores, por ejemplo).

El tercer problema es, en relación con el segundo, incluso usted puede contar cuántas páginas tiene, cómo "conectar" las páginas contadas con los tokens de continuación reales. Este es el mayor misterio para mí. ¿Cómo obtener una continuación de la fila de la tabla específica?

Estaría muy feliz, si se pudiera proporcionar la solución correcta. Debo admitir que también tengo uno y lo escribiré en una de las respuestas a continuación.

Answer 1

Sé que esto no resuelve su pregunta de la manera que usted solicitó, pero aún así, no creo que la búsqueda se realice de la manera que usted sugirió. Lo que quiero decir con eso es que, dado que Azure Table Storage no es compatible con la función que necesita, puede que no sea una buena opción.

Me gustaría obtener los datos en una memoria caché local, realizar el pedido y la paginación allí y terminar con ello. Hay una solución sugerida para esta limitación con la construcción cuidadosa de rowkey/partitionkey pero recomiendo encarecidamente que no sigas eso.

Blog blog= new Blog(); 
// Note the fixed length of 19 being used since the max tick value is 19 digits long. 
string rowKeyToUse = string.Format("{0:D19}", 
     DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks); 
blog.RowKey = rowKeyToUse; 

Así que un blog de b1 fecha 10/1/2008 10:00:00 AM tendrá 2521794455999999999 como el rowKey, y b2 de fecha 10/2/2008 10:00:00 AM tendrá 2521793591999999999 como el rowKey y por lo tanto, b2 será anterior a b1.

Para recuperar todos los blogs con fecha posterior 10/1/2008 10:00:00 AM, utilizaremos la consulta siguientes aparatos:

 string rowKeyToUse = string.Format("{0:D19}", 
     DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks); 
var blogs = 
    from blog in context.CreateQuery<Blog>("Blogs") 
    where blog.PartitionKey == "Football" 
     && blog.RowKey.CompareTo(rowKeyToUse) > 0 
    select blog; 

(esto ha sido tomado de Windows Azure tabla, diciembre de 2008 Documentos provided por Microsoft)

En cuanto a contar el número de páginas, es fácil, una operación de división simple hará el truco aquí; en cuanto a los tokens de continuación, una forma sería (a petición inicial) "caminar" en cada página y obtener el token de continuación que, básicamente, le indica qué fila de las claves de partición & vienen a continuación. Pero tener todos ellos significa que eres vulnerable a los errores de coherencia (por ejemplo, si alguien publica algo en el mismo almacenamiento de la mesa).

Personalmente, me basaría en rowkeys, como describí anteriormente, o si es un requisito, me moveré a un motor de almacenamiento que lo admita.

Para elaborar un poco más, si usted sabe que tendrá una sola cláusula "OrderBy", puede seleccionar todas ellas, y por alguna implicación, adivinar cuáles serán los límites de la página.

En una nota lateral, creo que la paginación proporcionada no está permitida para paginación en el front-end, pero para aliviar el límite de 1000 resultados. Pero esto es solo mi $ 0.02.