You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On newest Debian and other systems it sometimes impossible to install Java 11/8. But current compilation fails to build on Java 17 due to the dependencies.
On newest Debian and other systems it sometimes impossible to install Java 11/8. But current compilation fails to build on Java 17 due to the dependencies.
Thanks for your suggestion, we plan to support java17 in the 2.0 version (Also, we provide a in-memory graph-computer implement (written by Go) -- and it will be public soon, it will be more user friendly to use with the small and medium-sized datasets (less than 10 billion vertexes & edges) )
On newest Debian and other systems it sometimes impossible to install Java 11/8. But current compilation fails to build on Java 17 due to the dependencies.
Thanks for your suggestion, we plan to support java17 in the 2.0 version (Also, we provide a in-memory graph-computer implement (written by Go) -- and it will be public soon, it will be more user friendly to use with the small and medium-sized datasets (less than 10 billion vertexes & edges) )
Sounds cool, I've read the contest page and will be quite excited to see 2.0 in action!
As for billions, it seems that cluster setup with pd-store will be the way. At least current docs\demos for cluster mode and roles is not so handy as large-single-node setup - but for hundreds of billions edges and more it's hardware bounded.
On newest Debian and other systems it sometimes impossible to install Java 11/8. But current compilation fails to build on Java 17 due to the dependencies.
Thanks for your suggestion, we plan to support java17 in the 2.0 version (Also, we provide a in-memory graph-computer implement (written by Go) -- and it will be public soon, it will be more user friendly to use with the small and medium-sized datasets (less than 10 billion vertexes & edges) )
Sounds cool, I've read the contest page and will be quite excited to see 2.0 in action!
As for billions, it seems that cluster setup with pd-store will be the way. At least current docs\demos for cluster mode and roles is not so handy as large-single-node setup - but for hundreds of billions edges and more it's hardware bounded.
Yes, indeed the graph-computer could upgrade to support Java17/21 easily due to there isn't too much dependency burden.
U can try upgrading its compilation and runtime versions on your own. I don't think there should be many issues with the adaptation, but the community plan is to support Java17 as a whole until version 2.0, so there won't be a single component to be upgraded ahead of time (Not a technical obstacle)
In addition, the upcoming graph computing can be understood as a Go version of a new computing model (GAS model, where data is stored/computed in memory first, but also supports storing excess data to disk, similar to the combination like Redis+RocksDB. Its code is basically ready and waiting for complete documentation and other preparation to be used.
It provides simple binary boot and multiprocessing clustering (independent of k8s/yarn, easily to start), which is more suitable for the environment and needs of most ordinary users
Activity
imbajin commentedon Jul 22, 2024
Thanks for your suggestion, we plan to support java17 in the
2.0version (Also, we provide a in-memory graph-computer implement (written by Go) -- and it will be public soon, it will be more user friendly to use with the small and medium-sized datasets (less than 10 billion vertexes & edges) )moonbaseDelta commentedon Jul 22, 2024
Sounds cool, I've read the contest page and will be quite excited to see 2.0 in action!
As for billions, it seems that cluster setup with pd-store will be the way. At least current docs\demos for cluster mode and roles is not so handy as large-single-node setup - but for hundreds of billions edges and more it's hardware bounded.
imbajin commentedon Jul 22, 2024
Yes, indeed the
graph-computercould upgrade to support Java17/21 easily due to there isn't too much dependency burden.U can try upgrading its compilation and runtime versions on your own. I don't think there should be many issues with the adaptation, but the community plan is to support Java17 as a whole until version 2.0, so there won't be a single component to be upgraded ahead of time (Not a technical obstacle)
In addition, the upcoming graph computing can be understood as a
Goversion of a new computing model (GAS model, where data is stored/computed in memory first, but also supports storing excess data to disk, similar to the combination likeRedis+RocksDB. Its code is basically ready and waiting for complete documentation and other preparation to be used.It provides simple binary boot and multiprocessing clustering (independent of k8s/yarn, easily to start), which is more suitable for the environment and needs of most ordinary users
imbajin commentedon Sep 3, 2024
FWD:
The new in-memory/high-performance computer system code in #311