Das Dateisystem ist unsere gemeinsame Speicherform, die hauptsächlich aus zwei Teilen besteht: Daten und Metadaten. Darunter sind die Daten der spezifische Inhalt der Datei, der dem Benutzer normalerweise direkt angezeigt wird; und die Metadaten sind die Daten, die die Daten beschreiben, die verwendet werden, um Dateiattribute, Verzeichnisstruktur, Datenspeicherort usw. aufzuzeichnen. Metadaten haben im Allgemeinen sehr charakteristische Eigenschaften, dh sie nehmen weniger Platz ein, werden aber sehr häufig aufgerufen.
In den heutigen verteilten Dateisystemen verwalten einige (z. B. S3FS) Metadaten und Daten auf einheitliche Weise, um das Systemdesign zu vereinfachen. Der Nachteil besteht jedoch darin, dass einige Metadatenoperationen zu offensichtlichen Verzögerungen bei Benutzern führen, z. B. lsgroße usw. Weitere Dateisysteme werden sich dafür entscheiden, die beiden getrennt zu verwalten und eine gezielte Optimierung gemäß den Eigenschaften von Metadaten durchzuführen. JuiceFS übernimmt dieses Design und sein Architekturdiagramm sieht wie folgt aus:
Unter ihnen muss die Metadaten-Engine eine Datenbank sein, die Transaktionsvorgänge unterstützen kann, und die Daten-Engine verwendet im Allgemeinen Objektspeicher . Bisher hat JuiceFS mehr als 10 Metadaten-Engines und mehr als 30 Daten-Engines unterstützt.
Bei der Verwendung von JuiceFS können Benutzer ausgereifte Komponenten frei wählen, die als diese beiden Engines fungieren, um mit reichen und veränderlichen Unternehmensumgebungen und Datenspeicheranforderungen fertig zu werden. Für neue Benutzer stellt sich jedoch angesichts der größeren Auswahlmöglichkeiten auch die Frage: Welche Datenbank ist in meinem Szenario als Metadaten-Engine besser geeignet? Dieser Artikel stellt die Arten von Metadaten-Engines vor, die JuiceFS verwenden kann, sowie deren Vor- und Nachteile aus Sicht des Produktdesigns.
01-JuiceFS-Metadaten-Engine-Typ
Es gibt drei Kategorien von Metadaten-Engines, die derzeit von JuiceFS unterstützt werden.
Das erste ist Redis . Redis ist die früheste Metadaten-Engine, die von JuiceFS unterstützt wird, nachdem es Open Source wurde. Erstens ist Redis schnell genug, was eine der wichtigen Fähigkeiten ist, die Metadaten-Engines haben müssen; zweitens hat Redis ein breites Publikum und die meisten Benutzer haben praktische Erfahrung mit Redis. JuiceFS unterstützt auch mit dem Redis-Protokoll kompatible Datenbanken wie KeyDB und Amazon MemoryDB.
Da die Zuverlässigkeit und Skalierbarkeit von Redis jedoch leicht eingeschränkt sind und die Leistung in einigen Szenarien mit hohen Anforderungen an die Datensicherheit oder bei großen Skalierungen mangelhaft ist, haben wir zwei weitere Arten von Engines entwickelt und unterstützt.
Die zweite ist die SQL-Klasse . Wie MySQL, MariaDB, PostgreSQL usw. zeichnen sie sich durch eine hohe Popularität aus und weisen normalerweise eine gute Zuverlässigkeit und Skalierbarkeit auf. Darüber hinaus wird auch die eingebettete Datenbank SQLite unterstützt.
Die letzte ist die Klasse TKV (Transactional Key-Value Database) . Ihre nativen Schnittstellen sind relativ einfach, sodass sie in JuiceFS besser anpassbar sind und im Allgemeinen eine höhere Leistung als SQL-Klassen aufweisen. Derzeit umfasst diese Art der Unterstützung TiKV, etcd und eingebettete BadgerDB usw. Die Unterstützung für FoundationDB wird ebenfalls intensiv entwickelt.
Die obige Klassifizierung basiert auf der Protokollschnittstelle von JuiceFS beim Herstellen einer Verbindung zur Datenbank. In jeder Kategorie gibt es verschiedene Datenbanken, und jede Datenbank hat ihre eigenen Eigenschaften.Im Folgenden werden einige Optionen verglichen, die häufig von Benutzern basierend auf diesen Eigenschaften verwendet werden.
Metadaten-Engine-Vergleich
| Redis | MySQL/PostgreSQL | TiKV | usw | SQLite/BadgerDB | |
|---|---|---|---|---|---|
| Leistung | hoch | Niedrig | Mitte | Niedrig | Mitte |
| Skalierbarkeit | Niedrig | Mitte | hoch | Niedrig | Niedrig |
| Zuverlässigkeit | Niedrig | hoch | hoch | hoch | Mitte |
| Verfügbarkeit | Mitte | hoch | hoch | hoch | Niedrig |
| Popularität | hoch | hoch | Mitte | hoch | Mitte |
Wie oben erwähnt, ist der größte Vorteil von Redis seine hohe Leistung, da es sich um eine Full-Memory-Datenbank handelt. Ansonsten ist es mittelmäßig.
In Bezug auf die Skalierbarkeit kann ein einzelnes Redis normalerweise etwa 100 Millionen Dateien unterstützen.Wenn es 100 Millionen überschreitet, wird die Speichernutzung eines einzelnen Redis-Prozesses relativ groß, und die Verwaltungsleistung nimmt ebenfalls ab. Die Open-Source-Version von Redis unterstützt den Cluster-Modus, um die Gesamtmenge der Daten zu erweitern, die sie verwalten kann. Da Redis jedoch keine verteilten Transaktionen im Cluster-Modus unterstützt, steht als JuiceFS-Metadaten-Engine immer noch nur ein Redis-Prozess für jedes JuiceFS zur Verfügung volume. , ist die Skalierbarkeit eines einzelnen Volumes im Vergleich zu einem einzelnen Redis nicht wesentlich verbessert.
Aus Sicht der Zuverlässigkeit löscht Redis Daten standardmäßig jede Sekunde, was im Falle einer Ausnahme zu einem kleinen Datenverlust führen kann. Durch Ändern der Konfiguration von appendfsync auf always kann Redis nach jeder Schreibanforderung geleert werden, sodass die Leistung der Datenzuverlässigkeit verbessert wird, die Leistung jedoch abnimmt.
In Bezug auf die Verfügbarkeit kann die Bereitstellung von Redis-Wächterüberwachungsknoten und Standby-Knoten einen Backup-Knoten auswählen, um Dienste wieder bereitzustellen, nachdem der Haupt-Redis-Knoten aufgelegt hat, wodurch die Verfügbarkeit bis zu einem gewissen Grad verbessert wird. Redis selbst unterstützt jedoch kein verteiltes Konsensprotokoll, und seine Sicherungsknoten verwenden asynchrone Sicherungen. Obwohl der neue Knoten aktiv ist, kann es in der Mitte zu Datenlücken kommen, was zu unvollständigen Daten führt.
Die Gesamtleistung von MySQL und PostgreSQL ist ähnlich. Sie alle sind Datenbankprodukte, die sich seit vielen Jahren von einer großen Anzahl von Benutzern bewährt haben, mit guter Zuverlässigkeit und Verfügbarkeit und hoher Beliebtheit. Es ist nur so, dass ihre Leistung im Vergleich zu anderen Metadaten-Engines durchschnittlich ist.
TiKV war ursprünglich der zugrunde liegende Speicher von PingCAP TiDB, wurde aber jetzt getrennt und zu einer unabhängigen KV-Datenbankkomponente. Nach unseren Testergebnissen ist es eine ausgezeichnete Wahl für die JuiceFS-Metadaten-Engine. Die Datenzuverlässigkeit und Dienstverfügbarkeit sind nicht geringer als bei MySQL, und es bietet eine bessere Leistung und Skalierbarkeit. Lediglich in Sachen Popularität klafft noch eine Lücke zu MySQL. Aus unserer Kommunikation mit Benutzern geht hervor, dass diejenigen, die bereits TiKV- oder TiDB-Benutzer sind, am Ende normalerweise TiKV als Metadaten-Engine von JuiceFS bevorzugen. Aber wenn sie mit TiKV noch nicht vertraut sind, werden sie bei der Annahme einer solchen neuen Komponente viel vorsichtiger sein.
etcd ist eine weitere TKV-ähnliche Datenbank. Der Grund für die Unterstützung von etcd liegt darin, dass es in Containerisierungsszenarien sehr beliebt ist.Grundsätzlich verwendet k8s etcd, um seine Konfiguration zu verwalten. Die Verwendung von etcd als Metadaten-Engine von JuiceFS ist kein besonders geeignetes Szenario. Einerseits ist die Leistung durchschnittlich, andererseits hat es Kapazitätsbeschränkungen (Standard 2G, maximal 8G), und es wird später schwierig sein, es zu erweitern. Seine Zuverlässigkeit und Verfügbarkeit sind jedoch sehr hoch und es lässt sich problemlos in containerisierten Szenarien bereitstellen.Wenn Benutzer daher nur ein Dateisystem mit einer Größe von einer Million Dateien benötigen, ist etcd immer noch eine gute Wahl .
Schließlich gibt es noch SQLite und BadgerDB, die zur SQL-Klasse bzw. zur TKV-Klasse gehören, aber die Erfahrung mit ihrer Verwendung ist sehr ähnlich, da sie alle eigenständige eingebettete Datenbanken sind. Dieser Datenbanktyp zeichnet sich durch mittlere Performance, aber schlechte Skalierbarkeit und Verfügbarkeit aus, da seine Daten eigentlich im lokalen System gespeichert werden. Sie haben den Vorteil, dass sie sehr einfach zu verwenden sind und nur JuiceFS-eigene Binärdateien und keine zusätzlichen Komponenten benötigen. Benutzer können diese beiden Datenbanken in bestimmten spezifischen Szenarien oder bei der Durchführung einiger einfacher Funktionstests verwenden.
02- Leistungstestergebnisse eines typischen Motors
Wir haben einige typische Motorleistungstests durchgeführt und die Ergebnisse in diesem Dokument festgehalten . Eines der direktesten Ergebnisse des Quellschnittstellentests lautet ungefähr: Redis > TiKV (3 Kopien) > MySQL (lokal) ~= etcd (3 Kopien) wie folgt:
| Redis-Immer | Redis-Everysec | TiKV | MySQL | usw | |
|---|---|---|---|---|---|
| mkdir | 600 | 471 (0,8) | 1614 (2,7) | 2121 (3,5) | 2203 (3.7) |
| ist mv | 878 | 756 (0,9) | 1854 (2.1) | 3372 (3,8) | 3000 (3,4) |
| ist rm | 785 | 673 (0,9) | 2097 (2.7) | 3065 (3,9) | 3634 (4,6) |
| readdir_10 | 302 | 303 (1.0) | 1232 (4.1) | 1011 (3.3) | 2171 (7.2) |
| readdir_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) |
| erstellen | 591 | 468 (0,8) | 1565 (2,6) | 2120 (3.6) | 2206 (3,7) |
| umbenennen | 860 | 736 (0,9) | 1799 (2.1) | 3391 (3,9) | 2941 (3,4) |
| Verknüpfung aufheben | 709 | 580 (0,8) | 1881 (2,7) | 3052 (4.3) | 3080 (4.3) |
| Nachschlagen | 99 | 97 (1,0) | 731 (7,4) | 423 (4,3) | 1286 (13.0) |
| getattr | 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) |
| Zugang | 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) |
| getxattr | 91 | 89 (1,0) | 365 (4,0) | 298 (3,3) | 655 (7,2) |
| entfernenxattr | 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) |
| Verknüpfung | 605 | 461 (0,8) | 1627 (2,7) | 2436 (4,0) | 2237 (3,7) |
| Symlink | 602 | 465 (0,8) | 1633 (2,7) | 2394 (4.0) | 2244 (3,7) |
| schreiben | 613 | 371 (0,6) | 1905 (3.1) | 2565 (4,2) | 2350 (3,8) |
| lesen_1 | 0 | 0 (0,0) | 0 (0,0) | 0 (0,0) | 0 (0,0) |
| lesen_10 | 0 | 0 (0,0) | 0 (0,0) | 0 (0,0) | 0 (0,0) |
- Die obige Tabelle zeichnet den Zeitaufwand jeder Operation auf, je kleiner der Wert, desto besser; die Zahl in Klammern ist das Vielfache des Index im Vergleich zu Redis-immer, und je kleiner der Wert, desto besser
- Always und Everysec sind optionale Werte des Redis-Konfigurationselements appendfsync, die jeweils angeben, dass jede Anfrage geleert wird und jede Sekunde geleert wird
- Es ist ersichtlich, dass die Leistung von Redis bei Verwendung von everysec zwar besser ist, sich aber nicht wesentlich von „always“ unterscheidet, da die IOPS-Leistung der lokalen SSD-Festplatte selbst auf der für den Test verwendeten AWS-Maschine relativ hoch ist
- Sowohl TiKV als auch etcd verwenden drei Kopien, während MySQL auf einer einzigen Maschine bereitgestellt wird. Trotzdem ist die Leistung von TiKV immer noch höher als die von MySQL, während etcd MySQL nahe kommt.
Erwähnenswert ist, dass die Tests vor allem Standardkonfigurationen verwenden und keine spezifische Abstimmung für jede Metadaten-Engine vorgenommen wurde. Benutzer können es nach ihren eigenen Bedürfnissen und praktischen Erfahrungen bei der Verwendung konfigurieren und anpassen, und es kann zu unterschiedlichen Ergebnissen kommen .
Ein weiterer Test wurde mit dem mit JuiceFS gelieferten Bench-Tool durchgeführt, das die Schnittstelle des Betriebssystems zum Lesen und Schreiben von Dateien ausführt.Die spezifischen Ergebnisse sind wie folgt:
| Redis-Immer | Redis-Everysec | TiKV | MySQL | usw | |
|---|---|---|---|---|---|
| Große Datei schreiben | 565,07 MiB/s | 556,92 MiB/s | 553,58 MiB/s | 557,93 MiB/s | 542,93 MiB/s |
| Große Datei lesen | 664,82 MiB/s | 652,18 MiB/s | 679,07 MiB/s | 673,55 MiB/s | 672,91 MiB/s |
| Kleine Datei schreiben | 102,30 Dateien/s | 105,80 Dateien/s | 95,00 Dateien/s | 87,20 Dateien/s | 95,75 Dateien/s |
| Kleine Datei lesen | 2200.30 Dateien/s | 1894,45 Dateien/s | 1394,90 Dateien/s | 1360,85 Dateien/s | 1017.30 Dateien/s |
| Stat-Datei | 11607.40 Dateien/s | 15032.90 Dateien/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✿)