El sistema de archivos es nuestra forma de almacenamiento común, que se compone principalmente de dos partes: datos y metadatos. Entre ellos, los datos son el contenido específico del archivo, que generalmente se muestra directamente al usuario; y los metadatos son los datos que describen los datos, que se utilizan para registrar los atributos del archivo, la estructura del directorio, la ubicación del almacenamiento de datos, etc. En términos generales, los metadatos tienen características muy distintivas, es decir, ocupan menos espacio pero se accede a ellos con mucha frecuencia.
En los sistemas de archivos distribuidos actuales, algunos (como S3FS) administran metadatos y datos de manera unificada para simplificar el diseño del sistema, pero la desventaja es que algunas operaciones de metadatos harán que los usuarios experimenten un retraso evidente, como directorios lsgrandes etc. Más sistemas de archivos optarán por administrar los dos por separado y realizar una optimización específica de acuerdo con las características de los metadatos. JuiceFS adopta este diseño y su diagrama de arquitectura es el siguiente:
Entre ellos, el motor de metadatos debe ser una base de datos que pueda admitir operaciones de transacción, y el motor de datos generalmente usa almacenamiento de objetos . Hasta ahora, JuiceFS ha admitido más de 10 motores de metadatos y más de 30 motores de datos.
Al usar JuiceFS, los usuarios pueden elegir libremente componentes maduros para que actúen como estos dos motores para hacer frente a entornos empresariales ricos y cambiantes y requisitos de almacenamiento de datos. Sin embargo, para los nuevos usuarios, cuando se enfrentan a más opciones, también surge una pregunta: ¿Qué base de datos es más apropiada para elegir como motor de metadatos en mi escenario? Este artículo presentará los tipos de motores de metadatos que puede usar JuiceFS, así como sus ventajas y desventajas desde la perspectiva del diseño del producto.
01-Tipo de motor de metadatos de JuiceFS
Actualmente, JuiceFS admite tres categorías de motores de metadatos.
El primero es Redis . Redis es el primer motor de metadatos compatible con JuiceFS después de que fuera de código abierto. En primer lugar, Redis es lo suficientemente rápido, que es una de las capacidades importantes que deben tener los motores de metadatos; en segundo lugar, Redis tiene una amplia audiencia y la mayoría de los usuarios tienen experiencia práctica en Redis. JuiceFS también admite bases de datos compatibles con el protocolo Redis, como KeyDB y Amazon MemoryDB.
Sin embargo, la confiabilidad y la escalabilidad de Redis se limitan fácilmente, y su rendimiento es mediocre en algunos escenarios con altos requisitos de seguridad de datos o a gran escala. Por lo tanto, hemos desarrollado y respaldado otros dos tipos de motores.
La segunda es la clase SQL . Como MySQL, MariaDB, PostgreSQL, etc., se caracterizan por su gran popularidad y suelen tener una buena fiabilidad y escalabilidad. Además, también se admite la base de datos integrada SQLite.
La última es la clase TKV (Transactional Key-Value Database) . Sus interfaces nativas son relativamente simples, por lo que son más personalizables en JuiceFS y, en general, tienen un mayor rendimiento que las clases SQL. En la actualidad, este tipo de soporte incluye TiKV, etcd y BadgerDB incorporado, etc. El soporte para FoundationDB también está bajo un desarrollo intensivo.
Lo anterior es una clasificación basada en la interfaz de protocolo de JuiceFS cuando se conecta a la base de datos. Hay varias bases de datos en cada categoría, y cada base de datos tiene sus propias características, a continuación se comparan varias opciones comúnmente utilizadas por los usuarios en función de estas características.
Comparación de motores de metadatos
| redis | MySQL/PostgreSQL | TiKV | etc. | SQLite/Badger DB | |
|---|---|---|---|---|---|
| actuación | alto | Bajo | medio | Bajo | medio |
| Escalabilidad | Bajo | medio | alto | Bajo | Bajo |
| fiabilidad | Bajo | alto | alto | alto | medio |
| disponibilidad | medio | alto | alto | alto | Bajo |
| Popularidad | alto | alto | medio | alto | medio |
Como se mencionó anteriormente, la mayor ventaja de Redis es su alto rendimiento, ya que es una base de datos de memoria completa. En otros aspectos es mediocre.
En términos de escalabilidad, por lo general, un solo Redis puede admitir alrededor de 100 millones de archivos. Cuando supera los 100 millones, el uso de memoria de un solo proceso de Redis será relativamente grande y el rendimiento de la administración también disminuirá. La versión de código abierto de Redis admite el modo de clúster para expandir la cantidad total de datos que puede administrar. Sin embargo, dado que Redis no admite transacciones distribuidas en modo de clúster, como el motor de metadatos de JuiceFS, solo hay un proceso de Redis disponible para cada JuiceFS. volumen. , la escalabilidad de un solo volumen no mejora mucho en comparación con un solo Redis.
Desde la perspectiva de la confiabilidad, Redis vacía los datos cada segundo de forma predeterminada, lo que puede provocar una pequeña pérdida de datos en caso de una excepción. Al cambiar la configuración de appendfsync a siempre, Redis se puede vaciar después de cada solicitud de escritura, de modo que el rendimiento de la confiabilidad de los datos mejora, pero el rendimiento disminuirá.
En términos de disponibilidad, la implementación de nodos de monitoreo centinela y nodos en espera de Redis puede seleccionar un nodo de respaldo para brindar servicios nuevamente después de que el nodo principal de Redis se cuelga, lo que mejora la disponibilidad hasta cierto punto. Sin embargo, Redis en sí no admite un protocolo de consenso distribuido, y sus nodos de respaldo usan respaldo asíncrono, por lo que, aunque el nuevo nodo esté activo, puede haber brechas de datos en el medio, lo que resulta en datos incompletos.
El rendimiento general de MySQL y PostgreSQL es similar. Todos son productos de base de datos que han sido verificados por una gran cantidad de usuarios durante muchos años, con buena confiabilidad y disponibilidad, y alta popularidad. Es solo que su rendimiento es promedio en comparación con otros motores de metadatos.
TiKV fue originalmente el almacenamiento subyacente de PingCAP TiDB, pero ahora se ha separado y se ha convertido en un componente de base de datos KV independiente. Según los resultados de nuestras pruebas, es una excelente opción para el motor de metadatos de JuiceFS. Tiene confiabilidad de datos y disponibilidad de servicio no más débil que MySQL, y funciona mejor en rendimiento y escalabilidad. Solo en términos de popularidad, todavía hay una brecha entre él y MySQL. De nuestra comunicación con los usuarios, si ya son usuarios de TiKV o TiDB, generalmente prefieren usar TiKV como el motor de metadatos de JuiceFS al final. Pero si no están familiarizados con TiKV antes, serán mucho más cautelosos al aceptar un componente tan nuevo.
etcd es otra base de datos similar a TKV. La razón para admitir etcd es que es muy popular en escenarios de contenedores.Básicamente, k8s usa etcd para administrar su configuración. Usar etcd como el motor de metadatos de JuiceFS no es un escenario particularmente adecuado. Por un lado, su rendimiento es medio, y por otro lado, tiene limitaciones de capacidad (por defecto 2G, máximo 8G), y será difícil ampliarlo más adelante. Sin embargo, su confiabilidad y disponibilidad son muy altas y es fácil de implementar en escenarios en contenedores, por lo tanto, si los usuarios solo necesitan un sistema de archivos con una escala de un millón de archivos, etcd sigue siendo una buena opción .
Finalmente, están SQLite y BadgerDB, que pertenecen a la clase SQL y la clase TKV respectivamente, pero la experiencia de usarlos es muy similar, porque son todas bases de datos incrustadas independientes. Este tipo de base de datos se caracteriza por un rendimiento medio, pero una escalabilidad y disponibilidad deficientes, ya que sus datos se almacenan en el sistema local. Tienen la ventaja de ser muy fáciles de usar, ya que solo requieren los propios binarios de JuiceFS y ningún componente adicional. Los usuarios pueden usar estas dos bases de datos en ciertos escenarios específicos o al realizar algunas pruebas funcionales simples.
02- Resultados de la prueba de rendimiento de un motor típico
Hemos realizado algunas pruebas típicas de rendimiento del motor y hemos registrado los resultados en este documento . Uno de los resultados más directos de la prueba de la interfaz de origen es aproximadamente: Redis > TiKV (3 copias) > MySQL (local) ~= etcd (3 copias) , de la siguiente manera:
| Redis-siempre | Redis-Everysec | TiKV | mysql | etc. | |
|---|---|---|---|---|---|
| mkdir | 600 | 471 (0,8) | 1614 (2.7) | 2121 (3.5) | 2203 (3.7) |
| es mv | 878 | 756 (0,9) | 1854 (2.1) | 3372 (3.8) | 3000 (3,4) |
| es rm | 785 | 673 (0,9) | 2097 (2.7) | 3065 (3.9) | 3634 (4.6) |
| leerdir_10 | 302 | 303 (1.0) | 1232 (4.1) | 1011 (3.3) | 2171 (7.2) |
| leerdir_1k | 1668 | 1838 (1.1) | 6682 (4.0) | 16824 (10.1) | 17470 (10.5) |
| mknod | 584 | 498 (0,9) | 1561 (2.7) | 2117 (3.6) | 2232 (3.8) |
| crear | 591 | 468 (0,8) | 1565 (2.6) | 2120 (3.6) | 2206 (3.7) |
| rebautizar | 860 | 736 (0,9) | 1799 (2.1) | 3391 (3.9) | 2941 (3.4) |
| desconectar | 709 | 580 (0,8) | 1881 (2,7) | 3052 (4.3) | 3080 (4.3) |
| buscar | 99 | 97 (1,0) | 731 (7.4) | 423 (4.3) | 1286 (13,0) |
| obtener | 91 | 89 (1,0) | 371 (4.1) | 343 (3.8) | 661 (7.3) |
| setattr | 501 | 357 (0,7) | 1358 (2.7) | 1258 (2.5) | 1480 (3,0) |
| acceso | 90 | 89 (1,0) | 370 (4.1) | 348 (3,9) | 646 (7.2) |
| setxattr | 404 | 270 (0,7) | 1116 (2.8) | 1152 (2.9) | 757 (1,9) |
| obtenerxattr | 91 | 89 (1,0) | 365 (4,0) | 298 (3.3) | 655 (7.2) |
| removexattr | 219 | 95 (0,4) | 1554 (7.1) | 882 (4.0) | 1461 (6.7) |
| listxattr_1 | 88 | 88 (1,0) | 374 (4.2) | 312 (3.5) | 658 (7.5) |
| listxattr_10 | 94 | 91 (1,0) | 390 (4.1) | 397 (4.2) | 694 (7.4) |
| enlace | 605 | 461 (0,8) | 1627 (2.7) | 2436 (4.0) | 2237 (3.7) |
| enlace simbólico | 602 | 465 (0,8) | 1633 (2.7) | 2394 (4.0) | 2244 (3.7) |
| escribir | 613 | 371 (0,6) | 1905 (3.1) | 2565 (4.2) | 2350 (3.8) |
| leer_1 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
| leer_10 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
- La tabla anterior registra el tiempo que lleva cada operación, cuanto menor sea el valor, mejor; el número entre paréntesis es el múltiplo del índice en comparación con Redis-siempre, y cuanto menor sea el valor, mejor
- Always y Everysec son valores opcionales del elemento de configuración de Redis appendfsync, que indican respectivamente que cada solicitud se vacía y cada segundo se vacía
- Se puede ver que cuando Redis usa everysec, su rendimiento es mejor, pero no es muy diferente de siempre; esto se debe a que el rendimiento de IOPS del propio disco SSD local en la máquina AWS utilizada para la prueba es relativamente alto.
- Tanto TiKV como etcd usan tres copias, mientras que MySQL se implementa en una sola máquina. Aun así, el rendimiento de TiKV sigue siendo superior al de MySQL, mientras que etcd está cerca de MySQL.
Vale la pena mencionar que las pruebas sobre todo usan configuraciones predeterminadas y no se ha realizado ningún ajuste específico para cada motor de metadatos. Los usuarios pueden configurar y ajustar según sus propias necesidades y experiencia práctica al usarlo, y puede haber diferentes resultados .
Se realizó otra prueba a través de la herramienta de banco que viene con JuiceFS, que ejecuta la interfaz del sistema operativo para leer y escribir archivos, los resultados específicos son los siguientes:
| Redis-siempre | Redis-Everysec | TiKV | mysql | etc. | |
|---|---|---|---|---|---|
| Escribir archivo grande | 565,07 MB/s | 556,92 MB/s | 553,58 MB/s | 557,93 MB/s | 542,93 MB/s |
| Leer archivo grande | 664,82 MB/s | 652,18 MB/s | 679,07 MB/s | 673,55 MB/s | 672,91 MB/s |
| Escribir archivo pequeño | 102,30 archivos/s | 105,80 archivos/s | 95,00 archivos/s | 87,20 archivos/s | 95,75 archivos/s |
| Leer archivo pequeño | 2200,30 archivos/s | 1894,45 archivos/s | 1394,90 archivos/s | 1360,85 archivos/s | 1017,30 archivos/s |
| archivo de estadísticas | 11607.40 archivos/s | 15032,90 archivos/s | 3283.20 files/s | 5470.05 files/s | 2827.80 files/s |
| FUSE operation | 0.41 ms/op | 0.42 ms/op | 0.45 ms/op | 0.46 ms/op | 0.42 ms/op |
| Update meta | 3.63 ms/op | 3.19 ms/op | 7.04 ms/op | 8.91 ms/op | 4.46 ms/op |
从上表可以看到，读写大文件时使用不同的元数据引擎最后性能是差不多的。这是因为此时性能瓶颈主要在对象存储的数据读写上，元数据引擎之间虽然时延有点差异，但是放到整个业务读写的消耗上，这点差异几乎可以忽略不计。当然，如果对象存储变得非常快（比如都用本地全闪部署），那么元数据引擎的性能差异可能又会体现出来。另外，对于一些纯元数据操作（比如 ls，创建空文件等），不同元数据引擎的性能差别也会表现的比较明显。
03-引擎选型的考虑要素
根据上文介绍的各引擎特点，用户可以根据自己的情况去选择合适的引擎。以下简单分享下我们在做推荐时会建议用户考虑的几个要素。
评估需求：比如想使用 Redis，需要先评估能否接受少量的数据丢失，短期的服务中断等。如果是存储一些临时数据或者中间数据的场景，那么用 Redis 确实是不错的选择，因为它性能够好，即使有少量的数据丢失，也不会造成很大的影响。但如果是要存储一些关键数据， Redis 就不适用了。另外还得评估预期数据的规模，如果在 1 亿文件左右， Redis 可以承受；如果预期会有 10 亿文件，那么显然单机 Redis 是难以承载的。
评估硬件：比如能否连通外网，是使用托管的云服务，还是在自己机房内私有部署。如果是私有部署，需要评估是否有足够的硬件资源去部署一些相关的组件。无论是用哪一种元数据引擎，基本上都要求有高速的 SSD 盘去运行，不然会对其性能有比较大的影响。
评估运维能力，这是很多人会忽视的，但是在我们来看这应该是最关键的因素之一。对于存储系统来说，稳定性往往才是其上生产后的第一重点。用户在选择元数据引擎的时候，应该先想想自己对它是不是熟悉，在出现问题时，能否快速定位解决；团队内是否有足够的经验或精力去把控好这个组件。通常来说，我们会建议用户在开始时选择一个自己熟悉的数据库是比较合适的。如果运维人员不足，那么选择 JuiceFS 公有云服务也确实是个省心的选项。
最后，分享下社区在使用元数据引擎方面的一些统计数据。
- 目前为止， Redis 的使用者依然占了一半以上，其次是 TiKV 和 MySQL，这两类的使用者的数量占比在逐步增长。
- 在运行的 Redis 集群的最大文件数大概是在 1.5 亿，而且运行情况是比较稳定的，上文提到的推荐的 1 亿文件是建议值，并不是说无法超过 1 亿。
- 整体数量规模 Top3，都是使用的 TiKV 而且都超过了 10 亿文件数量。现在最大的文件系统的文件数量是超了 70 亿文件，总容量超过了 15 PiB，这也从侧面证明了 TiKV 在作为元数据引擎时的扩展能力。我们自己内部测过使用 TiKV 作为元数据引擎存储 100 亿文件，系统仍能稳定地运行。所以如果你的整个集群预期的规模会非常大，那么TiKV 确实是一个很好的选择。
04- 元数引擎迁移
文章的最后，为大家介绍元数据引擎迁移。 随着用户业务的发展，企业对元数据引擎的需求会发生变化，当用户发现现有的元数据引擎不合适了，可以考虑将元数据迁移到另一个引擎中。 我们为用户提供了完整的迁移方法，具体可以参考这个文档。
这个迁移方法有一定的限制，首先只能迁移到空数据库，暂时无法将两个文件系统直接合在一起；其次，需要停写，因为数据量会比较大的情况下，很难在线将元数据完整的迁移过来。要做到这点需要加许多限制，从实测来看速度会非常慢。因此，把整个文件系统停掉再去做迁移是最稳妥的。如果说实在需要有一定的服务提供，可以保留只读挂载，用户读数据并不会影响整个元数据引擎迁移的动作。
虽然社区提供了全套的迁移方法，但是还是需要提醒用户，尽量提前对数据量的增长做好规划，尽量不做迁移或尽早迁移。当要迁移的数据规模很大时，耗时也会变长，期间出问题的概率也会变大。
如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0ᴗ0✿)