What is primary application area of the DB?

What is the primary application area of the DB? Is it supposed to do a generic DB work or it is rather an OLAP? I mean, OLAPs tend to have a large latency and high thoroughput and this is rather unacceptable for the generic usage, where the thoroughput is nice but the latency is a critical. How authors are positioning their product?

BTW I really like your query language, it feels really smooth, great catch!

great to hear your voice. In my opinion, and first of all, this is a ‘Graph’ DB. Which means it’s not a generic DB. For example, there is no ‘join’ in our DB. This DB is focus on those problem which can be described in graph structure, social network, for example.

joins are useless anyway for big volumes, so I don’t really care. I rather meant is it a good idea to have large tag records. And not even a record.

Imagine the following situation: we have a document DB with a collection which although doesn’t have a formal scheme fits into some defintion. Each document can be represented as a t tree, with 5-6 leafs at max.

So, is it a good idea to represent each tree as a graph? In this case, instead of getting the single item, we should ask for a given vertex and all its children vertices. Would it work or latencies would a bit on higher side?

Tree can be considered as a graph. I think you may construct your graph like

  1. each document as a vertex
  2. docs connected use edges, described as ‘have’
  3. use our ‘Go 1 step’ statement , and to search children of a single document

or, if I didn’t get your point, please let me know.

Well, nothing you can help better than I can help myself. I wanted to know if this would be fast enoguh for my data set – obviously, it is up to my data set and I can only check this myself :slight_smile:

Thank you.

BTW, Nebula is mainly for OLTP instead of OLAP. If your property is a document, perhaps the latency would be high.