Skip to content
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.

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

[Enhancement]: Support Log Service in Milvus #33285

Open
3 of 14 tasks
chyezh opened this issue May 22, 2024 · 1 comment
Open
3 of 14 tasks

[Enhancement]: Support Log Service in Milvus #33285

chyezh opened this issue May 22, 2024 · 1 comment
Labels
kind/enhancement Issues or changes related to enhancement

Comments

@chyezh
Copy link
Contributor

chyezh commented May 22, 2024

Is there an existing issue for this?

  • I have searched the existing issues

What would you like to be added?

Milvus is now using proxy (maybe multi node) to interactive with message queue producer.
There's no any roles in Milvus cluster to achieve �consistency consensus at write path.
All things is done by outside message queue.
So any optimization feature at write path is a distributed problem, and hard to apply on current architecture.

We can introduce a log-based role to solve those problem. There's two new role in our new milvus architecture.

  • LogCoord, like other coord node such as querycoord, it hold the global assignment relation of underlying lognode and pchannel.
  • LogNode, a role that to do producing and consuming, any pchannel can be and only be assign to unique lognode at same time. All write and read operation need to done by it.

RoadMap or goals:

  • new message interface, provide fast filtering by using properties of message. Avoid too much unserialized operation applied to milvus lognode.
    • Properties for filtering and sorted: timetick, vchannel name, message type.
  • timestamp assignment is moved into lognode.
    • Continuous timetick message (no message between two time tick message) can be optimized as no-persistent message.
    • Timestamp sync up can be more shorter (200ms by default now), we can optimize it into 10ms level without two much overhead.
  • VChannel level consuming and producing api.
    • Consuming operation support filtering at lognode server side.
  • Remove mqwrapper,we need a wal but not a message queue in new architecture. we didn't rely on message queue's consuming api, so there's no stateful message queue side consumer on new architecture. Like pulsar, we use reader api but not consumer api.
    • Pulsar
    • Rocksmq
    • Natsmq
    • Kafka
  • Write ahead cache at lognode server side. We can no longer always consuming every message from underlying message queue, many message can be consumed from local storage of lognode by cached writing log entry.

Why is this needed?

No response

Anything else?

No response

@chyezh chyezh added the kind/enhancement Issues or changes related to enhancement label May 22, 2024
sre-ci-robot pushed a commit that referenced this issue Jun 11, 2024
issue: #33285

---------

Signed-off-by: chyezh <chyezh@outlook.com>
@xiaofan-luan
Copy link
Contributor

what about name it as streaming service?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Issues or changes related to enhancement
Projects
None yet
Development

No branches or pull requests

2 participants