Should I use graphd-client or storaged-client?

[GG2002]

General Question

I wanna add Nebula support for Opendal, so I need to treat Nebula as a KV-like database. I plan to do like this:

// create test space, its vid type should be str
CREATE SPACE test_kv(PARTITION_NUM = 20, VID_TYPE = FIXED_STRING(21));

// create kv tag
CREATE TAG kv(value string);

// insert key-value pair
INSERT VERTEX kv VALUES "test":("23");

// get value by key
FETCH PROP ON kv "test" YIELD kv.id as key, kv.value as value;
+-------+
| value |
+-------+
| "23"  |
+-------+

// delete key-value pair
DELETE VERTEX "test";

I found that there are three clients here.

I am curious whether using graphd-client or storaged-client is better. In terms of feeling, my requirement is very simple, may the latency of connecting to storaged server directly be smaller?

[GG2002]

I have tried to test the benchmark of these two methods, but I encountered the same problem #18 while the graphd-client worked correctly.

[wey-gu]

Normally the storage client is for analytical query that scans all data per tag or edge type. While graphd client is the normal one takes graph queries.

So it really depends on what we'd like to achieve.

One pitfall for storage client is that, it requires to get list of storage host from metad and access storage host from the addresses maintained in metad(service discovery), thus those addresses may not always accessible from the client side(many clusters were deployed in a way treating meta and storage not exposed services).

Implementing graphd may be the goto path that will always work. While it won't be a scalable approach when OpenDAL towards NebulaGraph as ETL purposes (scanning whole graph data)

[GG2002]

One pitfall for storage client is that, it requires to get list of storage host from metad and access storage host from the addresses maintained in metad(service discovery), thus those addresses may not always accessible from the client side(many clusters were deployed in a way treating meta and storage not exposed services).

Implementing graphd may be the goto path that will always work. While it won't be a scalable approach when OpenDAL towards NebulaGraph as ETL purposes (scanning whole graph data)

Thanks for your reply. I'll think about these things carefully.