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

cannot directly follow along with phone_calls keyspace #411

Open
classbasics opened this issue Nov 14, 2020 · 0 comments
Open

cannot directly follow along with phone_calls keyspace #411

classbasics opened this issue Nov 14, 2020 · 0 comments

Comments

@classbasics
Copy link

Please replace every line in curly brackets { like this } with appropriate answers, and remove this line.

Description

match $p isa person, has full-name $n; get;

could have been made

match $p isa person, has first-name $n; get;

first-name is a defined attribute in the phone_calls keyspace, while full-name is not.

It is all very nice to read along and visualize what the database will do, it is a much better thing to try the code out at the same time.
Some of these examples could have easily been adjusted to work with the phone_calls keyspace.
Attributes could have been defined first in the docs, rather than a note explaining why the code does not work.
The graphics on concepts should have been shown earlier in the docs, along with the associated keywords.

On a different note I expected version 2.0 to be available in September 2020 and run on a more efficient database, e.g. Scylladb instead of Cassandra.
Running off aws ebs is bad for a database and there should have been an option to run on Scylladb on nvme.
I read somewhere the network has to be loaded separately for each query. I hope that is wrong as it severely limits concurrent queries on limited hardware or makes infrastructure costs exorbitant.
I have not seen any benchmarking, and also have not seen any comparative benchmarking.
It looks like every node (concept) has to be read in a query.
I don't think Grakn could handle a billion nodes (concepts), but I would like to be proven wrong.
The docs are not the worst I have seen, but it certainly deters me from considering it as an alternative to a column graph.
Maybe I just don't need insights that much and can use ML to analyze traditional data structures.
Hoping for improvements here.

Location of Content

https://dev.grakn.ai/docs/query/match-clause

Expected Content

{ Please describe what you expected to happen. }

Actual Content

{ Please describe what actually happened. }

Additional information

{ Any additional information, including logs or screenshots if you have any. }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants