Atlas Device Sync utiliza espacio en el clúster Atlas sincronizado de tu aplicación para almacenar metadatos para la sincronización. Esto incluye un historial de cambios en cada base de datos sincronizada. Atlas App Services minimiza este uso de espacio en tu clúster Atlas. Minimizar los metadatos es necesario para reducir el tiempo y los datos necesarios para la sincronización.
Historia
El backend de App Services mantiene un historial de cambios en los datos subyacentes para cada ámbito, similar al Registro de operaciones de MongoDB. App Services utiliza este historial para sincronizar datos entre el backend y los clientes. App Services almacena el historial en el clúster Atlas sincronizado.
Guarnición
Cuando se establece un tiempo máximo sin conexión del cliente en una aplicación, elrecorte elimina los cambios anteriores a ese tiempo máximo sin conexión del cliente.
Tiempo máximo sin conexión del cliente
Utilizado en el recorte, el tiempo máximo sin conexión del cliente controla el límite de antigüedad del historial. Esto modifica indirectamente el tiempo que un cliente puede permanecer sin conexión entre sesiones de sincronización con el backend. Los clientes que no se sincronizan durante más de la cantidad de días especificada podrían experimentar un reinicio la próxima vez que se conecten al backend.
Si se establece un valor menor para el tiempo máximo sin conexión del cliente, se reducirá la cantidad de historial requerido para la sincronización. La optimización resultante reduce el uso de almacenamiento en el clúster Atlas sincronizado.
Las aplicaciones nuevas habilitan automáticamente el tiempo máximo sin conexión del cliente con un valor por defecto de 30 días.
Advertencia
El tiempo máximo sin conexión del cliente provoca cambios permanentes en el historial
El tiempo máximo sin conexión del cliente permite recortar el historial anterior. Esto modifica permanentemente el historial afectado y puede provocar reinicios del cliente en el futuro.
Conceptos clave
La sincronización siempre debe converger en el mismo estado final en todos los clientes. Para converger durante una sincronización, los clientes necesitan el historial completo de cambios desde su última sincronización. Cuando un cliente no sincroniza durante un período prolongado, el recorte puede alterar el historial de forma que impida la convergencia. Dado que la sincronización depende de que todos los clientes converjan en un resultado común, un cliente así no puede sincronizar.
Como resultado, el cliente debe reiniciarse para poder reanudar la sincronización. En este caso, el cliente elimina la copia local de un dominio y descarga su estado actual desde el backend. La sincronización se reanuda con la nueva copia del dominio.
El tiempo máximo sin conexión del cliente controla el tiempo que el backend espera antes de aplicar el recorte. Tras el número especificado de días sin sincronización, los clientes podrían experimentar un reinicio la próxima vez que se conecten al backend.
Las aplicaciones que no especifican el tiempo máximo de desconexión del cliente nunca aplican el recorte. Esto significa que los clientes pueden conectarse después de cualquier periodo de desconexión (semanas, meses o incluso años) y sincronizar los cambios. Con el tiempo, los dominios que se editan con frecuencia acumulan muchos cambios. Con un conjunto de cambios grande, la sincronización requiere más tiempo y uso de datos.
El tiempo máximo sin conexión del cliente no influye inmediatamente en los reinicios del cliente
El recorte provoca cambios permanentes e irreversibles en el historial. Por lo tanto, aumentar el tiempo máximo de desconexión del cliente no modifica inmediatamente el tiempo que tarda el cliente en reiniciarse. El recorte ya modificó el historial existente, lo que requiere reiniciar el cliente. El nuevo historial necesita tiempo para acumularse hasta alcanzar el nuevo tiempo máximo de desconexión del cliente.
Reducir el tiempo máximo sin conexión de un cliente no modifica inmediatamente el tiempo que tarda en reiniciarse. Los reinicios comienzan a ocurrir antes una vez que el trabajo de recorte programado regularmente aplica el recorte al historial recién habilitado.
Establecer el tiempo máximo sin conexión del cliente
Desde la interfaz de usuario de App Services, haga clic en Device Sync Menú en la barra lateral. La pestaña Dashboard se muestra por defecto.
Haz clic en la pestaña Configuration.
Desplácese hacia abajo hasta la sección Advanced Configuration (optional) y haga clic en el menú desplegable para expandir la sección.
![Sección de configuración avanzada en la interfaz de usuario de App Services]()
En la sección Client Max Offline Time, especifique el número de días que el cliente de su aplicación puede permanecer sin conexión. El valor predeterminado es 30 días. El valor mínimo es 1.
Haz clic en el botón Save Changes en la parte inferior de la pantalla una vez que estés listo para guardar.
En la ventana de confirmación, haga clic en el botón Save Changes nuevamente para confirmar los cambios.
Extraiga una copia local de la última versión de su aplicación con el siguiente comando pull:
Halarappservices pull --remote="<Your App ID>" Puede configurar el número de días que el cliente de su aplicación permanecerá fuera de línea como máximo con el
client_max_offline_dayspropiedad en el archivosync/config.jsonde su aplicación:``sync/config.json``{ "client_max_offline_days": 42, } Implemente la configuración actualizada de la aplicación con el siguiente comando push:
Empujarappservices push --remote="<Your App ID>"
Optimización del rendimiento y el almacenamiento al utilizar la sincronización flexible
Para la configuración de Sincronización Flexible, la cantidad de espacio de almacenamiento de Atlas utilizado es directamente proporcional al número de campos consultables configurados. Estos campos utilizan el almacenamiento del clúster de Atlas de respaldo. Cuantos más campos consultables configure, más almacenamiento utilizará en el clúster de respaldo.
Si tiene una gran cantidad de colecciones en una aplicación, es posible que necesite usar el mismo nombre de campo consultable en varias colecciones. Combine esto con los permisos para obtener un control más preciso sobre quién puede acceder a cada colección.
Ejemplo
Tu aplicación puede contener 20 o 30 colecciones, pero quieres minimizar el número de campos consultables. Puedes reutilizar los campos consultables globales en todas las colecciones para sincronizar objetos de cada una. Por ejemplo, owner_id podría ser un campo que quieras consultar en varias colecciones.
Como alternativa, puede tener owner_id en varias colecciones, pero solo necesita consultarlo en una. En este caso, puede convertir en owner_id un campo consultable. Esto significa que Sync solo tiene que mantener los metadatos de este campo para una colección, en lugar de almacenar metadatos de todas las colecciones donde no se consulta.
Finalmente, para las aplicaciones donde los dispositivos desean consultar una faceta específica de los datos,owner_id == user.id como, se recomienda designar el campo como un campo consultable indexado. Los campos consultables indexados ofrecen un rendimiento más eficiente para las aplicaciones donde el cliente solo necesita sincronizar un pequeño subconjunto de sus datos (por ejemplo, un grupo de tiendas o un solo usuario).
Se puede tener un campo indexado consultable por aplicación. Un campo indexado consultable es un campo global consultable que debe estar presente y usar el mismo tipo de datos elegible en cada colección que se sincronice.
Para obtener más información, consulte Ámbitos de campos consultables y Campos consultables indexados.
Para obtener el mejor rendimiento, abra un dominio sincronizado con una consulta amplia. A continuación, agregue consultas más refinadas para exponer conjuntos de datos específicos en la aplicación cliente. Separar conjuntos de trabajo de una consulta amplia ofrece un mejor rendimiento que abrir varios dominios sincronizados con consultas más granulares.
Al configurar campos consultables, tenga en cuenta las consultas amplias que utiliza para la sincronización y seleccione menos campos que admitan esas consultas amplias.
Ejemplo
En una aplicación de listas de tareas, priorice consultas generales como assignee == currentUser o projectName == selectedProject para una consulta de sincronización. Esto le proporciona un par de campos generales para sincronizar documentos. En el cliente, puede refinar aún más su consulta para tareas con cierta prioridad o estado de finalización, para desglosar un conjunto de trabajo.
Resumen
Device Sync utiliza espacio en su clúster Atlas sincronizado para almacenar el historial de cambios.
El recorte reduce el uso de espacio para las aplicaciones de sincronización flexible, pero puede provocar reinicios de clientes que no se han conectado al backend durante más tiempo que el tiempo máximo sin conexión del cliente (en días).
Añadir campos consultables adicionales a una configuración de sincronización flexible aumentará el consumo de almacenamiento en un clúster Atlas. Usar consultas amplias y seleccionar menos campos compatibles con ellas reduce el consumo de almacenamiento.