Skip to content

[doc] fix typos, formatting and consistency in architecture.md #1390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
polyzos merged 1 commit into from
Jul 23, 2025
Merged

[doc] fix typos, formatting and consistency in architecture.md #1390

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions website/docs/concepts/architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,12 +34,12 @@ Additionally, it coordinates critical operations such as:
- Managing data migration and service node switching in the event of node failures.
- Overseeing table management tasks, including creating or deleting tables and updating bucket counts.

As the **brain** of the cluster, the **Coordinator Server** ensures efficient cluster operation and seamless management of resources.
As the **brain** of the cluster, the **CoordinatorServer** ensures efficient cluster operation and seamless management of resources.

## TabletServer
The **TabletServer** is responsible for data storage, persistence, and providing I/O services directly to users. It comprises two key components: **LogStore** and **KvStore**.
- For **PrimaryKey Tables** which support updates, both **LogStore** and **KvStore** are activated. The KvStore is used to support updates and point lookup efficiently. LogStore is used to store the changelogs of the table.
- For **Log Tables** which only supports appends, only the **LogStore** is activated, optimizing performance for write-heavy workloads.
- For **Log Tables** which only support appends, only the **LogStore** is activated, optimizing performance for write-heavy workloads.

This architecture ensures the **TabletServer** delivers tailored data handling capabilities based on table types.

Expand Down Expand Up @@ -73,4 +73,4 @@ In upcoming releases, **ZooKeeper will be replaced** by **KvStore** for metadata
Additionally, **Remote Storage** allows clients to perform bulk read operations on Log and Kv data, enhancing data analysis efficiency and reduce the overhead on Fluss servers. In the future, it will also support bulk write operations, optimizing data import workflows for greater scalability and performance.

## Client
Fluss clients/sdks support streaming reads/writes, batch read/writes, DDL and point queries. Currently, the main implementation of client is Flink Connector. Users can use Flink SQL to easily operate Fluss tables and data.
Fluss clients/SDKs support streaming reads/writes, batch reads/writes, DDL and point queries. Currently, the main implementation of client is Flink Connector. Users can use Flink SQL to easily operate Fluss tables and data.