tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marko Rodriguez <okramma...@gmail.com>
Subject mm-ADT to TinkerPop3
Date Thu, 13 Jun 2019 22:25:21 GMT

Various stakeholders in Apache TinkerPop have been wondering weather mm-ADT can be leveraged
in TinkerPop3. While I originally planned for mm-ADT to form the foundation of TinkerPop4,
there are a subset of features in mm-ADT that could really help TP3 moving forward. Here is
a preliminary outline of the mm-ADT features that could push the TP3 roadmap.

	1. Type system: mm-ADT has a nominal type system for the built-in types and a structural
type system for all derived types. Bytecode instructions that CRUD on database data can by
statically typed and reasoned on at compile time.

	2. Strategies: mm-ADT has a completely different approach to query optimization than TP3.
While there are compile-time strategies for manipulating a query into a semantically equivalent,
though computationally more efficient form, the concept of “provider strategies” (indices)
goes out the window in favor of reference graphs. The primary benefit of the mm-ADT model
is that the implementation for providers will be much simpler, less error prone, doesn’t
require custom instructions, and is able to naturally capitalize on other internal provider
optimizations such as schemas, denormalizations, views, etc.

	3. Instruction Set: mm-ADT’s instruction set is less adhoc than TP3. Relational operators
are polymorphic. Math operators are polymorphic. Container (collection) operators are polymorphic.
Unlike TP3, a “vertex” is just a map like any other map. Thus, has(), value(), where(),
select(), etc. operate across all such derivations. Moreover, mm-ADT’s instruction set greatly
reduces the number of ways in which an expression can be represented, relying primarily on
reference graphs (see #2 above) as the means of optimization. This should help limit the degrees
of freedom in the Gremlin language and reduce its apparent complexity to newcomers.

	4. References: mm-ADT introduces references (pointers) as first-class citizens. References
form one of the primary data types in mm-ADT with numerous usages including:
		* Query planning. (providers exposing secondary data access paths via reference graphs --
see #2 above)
		* Modeling complex objects. (will not come into play given TP3’s central focus on the
property graph data type).
		* Bytecode arguments. (nested bytecode are dynamic references and every instruction’s
arguments can take references (even the opcode itself!)).
		* Remote proxies. (TP3 detached vertices are awkward and limiting in comparison to mm-ADT
proxy references).
		* Schemas. (will probably not come into play, but “person” vertices are possible in
mm-ADT. Thus, if TP3 wants to introduce graph schemas, mm-ADT provides the functionality).

I’ll leave it at that for now. Any questions, please ask.

Take care,

http://rredux.com <http://rredux.com/>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message