Open-source graph database, built for real-time streaming data, compatible with Neo4j.
cyphergraphgraph-algorithmsgraph-analysisgraph-databasekafkakafka-streamsnosqlopencypherstream-processingstreaming-data
2c50ea41d5
Summary:
This change, hopefully, simplifies the implementation of different kinds
of GraphDb. The pimpl idiom is now simplified by removing all of the
crazy inheritance. Implementations classes are just plain data stores,
without any methods. The interface classes now have a more flat
hierarchy:
```
GraphDb (pure interface)
|
+----+---------- DistributedGraphDb (pure interface)
| |
Single Node +-----+------+
| |
Master Worker
```
DistributedGraphDb is used as an intermediate interface for all the
things that should work only in distributed. Therefore, virtual calls
for distributed stuff have been removed from GraphDb. Some are exposed
via DistributedGraphDb, other's are only in concrete Master and Worker
classes. The code which relied on those virtual calls has been
refactored to either use DistributedGraphDb, take a pointer to what is
actually needed or use dynamic_cast. Obviously, dynamic_cast is a
temporary solution and should be replaced with another mechanism (e.g.
virtual call, or some other function pointer style).
The cost of the above change is some code duplication in constructors
and destructors of classes. This duplication has a lot of little tweaks
that make it hard to generalize, not to mention that virtual calls do
not work in constructor and destructor. If we really care about
generalizing this, we should think about abandoning RAII in favor of
constructor + Init method.
The next steps for splitting the dependencies that seem logical are:
1) Split GraphDbAccessor implementation, either via inheritance or
passing in an implementation pointer. GraphDbAccessor should then
only be created by a virtual call on GraphDb.
2) Split Interpreter implementation. Besides allowing single node
interpreter to exist without depending on distributed, this will
enable the planner and operators to be correctly separated.
Reviewers: msantl, mferencevic, ipaljak
Reviewed By: msantl
Subscribers: dgleich, pullbot
Differential Revision: https://phabricator.memgraph.io/D1493
|
||
|---|---|---|
| cmake | ||
| config | ||
| customers | ||
| docs | ||
| experimental | ||
| libs | ||
| poc | ||
| release | ||
| src | ||
| tests | ||
| tools | ||
| .arcconfig | ||
| .clang-format | ||
| .gdbinit | ||
| .gitignore | ||
| .ycm_extra_conf.py | ||
| apollo_archives.py | ||
| apollo_archives.yaml | ||
| apollo_build.yaml | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| Doxyfile | ||
| Doxylogo.png | ||
| init | ||
| README.md | ||
memgraph
Memgraph is an ACID compliant high performance transactional distributed in-memory graph database featuring runtime native query compiling, lock free data structures, multi-version concurrency control and asynchronous IO.
dependencies
Memgraph can be compiled using any modern c++ compiler. It mostly relies on the standard template library, however, some things do require external libraries.
Some code contains linux-specific libraries and the build is only supported on a 64 bit linux kernel.
- linux
- clang 3.8 (good c++11 support, especially lock free atomics)
- antlr (compiler frontend)
- cppitertools
- fmt format
- google benchmark
- google test
- glog
- gflags