Add OceanBase to the list of supported metadata databases

[wpleonardo]

This PR updates the JuiceFS website content to include OceanBase as one of the supported metadata storage databases. OceanBase is a high-performance, distributed relational database known for its strong consistency and scalability, making it an excellent choice for managing metadata in large-scale storage scenarios. By highlighting OceanBase, this update provides users with more options for optimizing JuiceFS performance in demanding environments.

This PR contains Chinese and English parts, and every part have 15 articles and 1 figure modified. We have already conducted experiments and verified how to deploy OceanBase locally as a metadata repository.

At the same time, there may be several more articles which need to be modified later:

1. jfs_vs_seaweedfs.md
   In this article, it compares JuiceFS and SeaweedFS.
   As described in this article, SeaweedFS has an advantage that supports file system data replication between multiple clusters. It offers two asynchronous data replication modes: Active-Active and Active-Passive. Theoretically, after using OceanBase, users can achieve Active-Active mode, and help JuiceFS make up for this missing mode. But this part needs to be verified by experiments. After that, we will add JuiceFS&OceanBase support the Active-Active mode into this article.

2. for_distributed.md
   In this article, JuiceFS community mentioned that “A detailed guide on database selection will be available soon”. If the community needs Oceanbase architecture or performance testing materials when writing this article, we can provide them at any time.

3. metadata_engine_benchmark.md
   This article compares the performance of different databases. Once the development of the JuiceFS & OBKV API is complete, could the JuiceFS community conduct a performance test using OceanBase and OBKV to evaluate their capabilities?

[davies]

Since OceanBase is compatible to MySQL protocol, it could be a scalable replacement for MySQL. So people can use it with JuiceFS without this PR. At most, we can mention OceanBase in the MySQL section, maybe also other rational databases.

Btw, please don't let the docs to be a fight field of databases.

[davies]

These are duplicated, we may remove those for MariaDB also.

[wpleonardo]

Yes, I agree to remove this part of OceanBase and MariaDB due to the duplicate content, and could we mention that the method for setting up OceanBase/MariaDB as a metadata database is the same as MySQL because both of them are highly compatible with MySQL in this article? Is this more user-friendly?

[wpleonardo]

Already deleted the duplicate content in the article how_to_set_up_metadata_engine.md. Please check if it is OK.

[wpleonardo]

Since OceanBase is compatible to MySQL protocol, it could be a scalable replacement for MySQL. So people can use it with JuiceFS without this PR. At most, we can mention OceanBase in the MySQL section, maybe also other rational databases.

Btw, please don't let the docs to be a fight field of databases.

Thank you for the feedback! I understand the importance of keeping the documentation neutral and concise, and I appreciate your thoughts on maintaining that balance.

Regarding the changes I made, I’d like to clarify that while the number of modified files may seem large, the actual changes in each document are minimal. Most of these modifications involve adding small, relevant mentions of OceanBase in both the English and Chinese sections, which naturally doubles the appearance of changes. I also wana clarify why mentioning OceanBase in more detail could bring additional value to JuiceFS users. While it’s true that OceanBase is compatible with the MySQL protocol, it is not just a MySQL-compatible database. OceanBase is a highly scalable and distributed relational database with advanced features like Active-Active clustering, which allows seamless cross-region high availability. This capability addresses a significant gap for JuiceFS in scenarios that require robust disaster recovery or data replication across zones—something not inherently available with MySQL.

I assure you that my intent is not to create competition among databases but to enhance the documentation’s technical depth and showcase how OceanBase can address specific use cases for JuiceFS users. If necessary, I’m happy to adjust the tone or further simplify the mentions of OceanBase to make them more aligned with the community’s expectations.

Please let me know how we can move forward. I’m open to feedback and eager to collaborate to improve the documentation.

[solracsf]

PRs like these are useless, othwerwise every compatible provider built on top of another one (or every fork) should be mentioned...

These are just "growth hacking" techniques in my opinion.

[wpleonardo]

PRs like these are useless, othwerwise every compatible provider built on top of another one (or every fork) should be mentioned...

These are just "growth hacking" techniques in my opinion.

Thank you for sharing your perspective. I’d like to clarify a few points about OceanBase and its relevance to JuiceFS:

OceanBase and MySQL are fundamentally different types of databases. OceanBase is a distributed relational database, designed to support complex scenarios like Active-Active clusters, which is a key feature that distinguishes it from MySQL. This capability can help JuiceFS fill a gap in supporting such use cases.

If the goal of the JuiceFS community is to streamline the content on the website, perhaps we could consider revisiting how databases are categorized. For instance, PostgreSQL and MariaDB are quite similar to MySQL in their functionality and use cases. One possibility could be to consolidate them under the MySQL section, while retaining MySQL as the representative for standalone databases and OceanBase as the representative for distributed relational databases. This way, the structure remains clean and future support for other distributed databases could be grouped alongside OceanBase.

I believe this approach not only aligns with the community’s goals of reducing redundancy but also highlights the distinct advantages that different types of databases bring to JuiceFS users. I hope this suggestion makes sense, and I’m happy to further discuss or refine this idea!

[davies]

From JuiceFS's perspective, MySQL and PG are two protocols, we don't care the architect behind that.