Existe-t-il un modèle établi pour la recherche de personnes dans les collections fiables de Service Fabric ?

Question

Dans les collections fiables (en particulier IReliableDictionary), une approche permettant de mettre en œuvre des requêtes "courantes" consiste à mettre à jour un dictionnaire secondaire qui structure les clés de manière à ce qu'elles soient ordonnées d'une manière spécifique dans une énumération. Pour les grands ensembles de données, J'aimerais éviter de faire circuler un grand nombre de données. .

Pour ce faire, j'aimerais mettre en œuvre une sorte de jeton de continuation que l'appelant peut me fournir lorsqu'il demande les données. J'applique actuellement cette méthode en générant d'abord une énumération ordonnée et en renvoyant les n premiers éléments, où n = la taille MAX_PAGE. La suite est essentiellement la dernière clé de cette liste de n éléments. . La prochaine fois que l'appelant transmet le jeton de continuation, Je génère l'énumérable ordonné avec la fonction de filtrage spécifiant que la clé doit être supérieure à la suite. .

Cela pose deux problèmes (à ma connaissance) :

1. En pourrait changer entre le moment où l'appelant demande une page pour la première fois et celui où il la demande à nouveau. . Je ne suis pas certain de pouvoir éviter cela, car les mises à jour de la collection doivent pouvoir être effectuées à tout moment, quelle que soit la personne qui tente de consulter les données.
2. Je ne suis pas certain de la manière dont la fonction de filtrage est utilisée. Je suppose que, puisqu'un développeur peut filtrer sur n'importe quoi, la fonction La méthode GetEnumerableAsync() doit fournir toutes les clés du dictionnaire avant de renvoyer l'énumérable . Pour un ensemble de données suffisamment important, cela semble lent.

Existe-t-il des méthodes prescrites pour la pagination de données de ce type ? Je commence à avoir l'impression de faire fausse route avec Reliable Collections pour certains de mes cas d'utilisation.

Answer 1

Une façon de construire des indices secondaires est d'utiliser Notifications . En utilisant les notifications avec un type de référence TKey & TValue, vous pouvez gérer un index secondaire sans créer de copies de votre TKey ou TValue.

Si l'index secondaire doit fournir une isolation des instantanés, la structure de données choisie pour l'index secondaire doit implémenter le contrôle de la concurence multi-version.

Si vous ne disposez pas d'une telle structure de données pour héberger l'index secondaire, une autre option consiste à maintenir la transaction et l'énumération en direct à travers les appels du client paginé. De cette façon, vous pouvez utiliser le support intégré des instantanés du Dictionnaire Fiable pour fournir un balayage cohérent des données sans bloquer les écritures. Dans ce cas, le jeton serait le TransactionId permettant à votre service de trouver l'énumération pertinente pour MoveNextAsync sur. L'inconvénient de cette option est que le dictionnaire fiable ne sera pas en mesure d'éliminer les anciennes versions des valeurs qui sont maintenues visibles par les transactions instantanées qui peuvent durer longtemps.

Pour atténuer l'inconvénient ci-dessus, vous voudrez probablement limiter le nombre de transactions snapshot en vol et le temps dont dispose un client pour terminer l'énumération paginée avant que votre service ne se débarrasse de l'énumération et de la transaction de lecture correspondante.

Quand CreateEnumerableAsync si un filtre de clé est utilisé, Reliable Dictionary invoquera le filtre pour chaque clé afin de voir si elle satisfait le filtre personnalisé. Étant donné que les TKeys sont toujours conservées en mémoire aujourd'hui, nous n'avons pas rencontré de problèmes avec la plupart des filtres de clés. La partie la plus coûteuse d'une énumération est généralement la récupération des valeurs paginées sur le disque.

Answer 2

J'ai un problème similaire, qui concerne également le filtrage et le tri de données provenant de plusieurs partitions.

Mon plan est de construire une vue indexée dans un service à état non partitionné en utilisant des notifications. Ici, j'aurai plusieurs dictionnaires, avec des clés différentes, où chaque clé est une ou plusieurs propriétés qui peuvent être filtrées ou triées, et la valeur est une liste triée d'ID.

Fondamentalement, je prévois de rechercher, trier et paginer sur ces clés, puis, à la dernière étape, j'utilise les identifiants de la page qui doit être renvoyée aux partitions d'origine et j'obtiens les données complètes pour ces identifiants à partir de là (cela peut également être fait à partir d'un autre service sans état).

Cette méthode n'assure pas la cohérence des données, puisque les données interrogées peuvent changer entre les paginations suivantes.

Il doit être plus lent que celui avec les instantanés et les jetons de continuation, mais cela vaut peut-être la peine d'essayer.