Open yuqi1129 opened 9 months ago
@xunliu cc @jerryshao I conducted a primary survey on the ORM framework for key-value storage, and it seems that it's not recommended to use ORM in key-value storage and there's no mature resolution available. I also agree with this point. Here are my thoughts on how to solve this problem.
As long as the number of dimensions of user information is not too large, I believe it is possible to encode them into key-value pairs with an encoder and decode them when loading. For instance, we would only retrieve user information by username and ID, then we can encode the username and ID into the key of the key-value pair. Please be aware that it's not appropriate to use this solution if the count of query dimensions exceeds 4.
For queries with more than 4 dimensions and complex queries, such as those with functions. It's really challenging to use key-value storage, maybe we should considering introduce relational database to copy these scenarios.
So, we can handle user account information similarly to graviton entities and choose appropriate encode/decode methods if possible, for complex scenarios, we may need to copy them one by one. What's your opinion?
I think the ORM framework is very important, we can create a database access layer so that we can also support a variety of heterogeneous databases. snowflake has also implemented an EntityLayer in the FDB on FDB.
otherwise, I'm very curious how Arangodb implements search on Rocksdb, can you research that? Can you share your research documents or web page?
Describe the feature
As we plan to store user-related information such as user accounts and audit information in key-value storage, we need to save Java objects in the form of key-value pairs to RocksDB, then a generic ORM framework is required to convert object to key-value pair.
Motivation
No response
Describe the solution
No response
Additional context
No response