Hi Sergio, 2015-12-14 16:01 GMT+01:00 Sergio Fernández <[email protected]>:
> Hi, > > On Mon, Dec 14, 2015 at 3:09 PM, Sebastian Schaffert < > [email protected]> wrote: > > > > > So definitely, because this and the previous point, I think it's worth > to > > > explore the container approach for Ostrich. > > > > Not very experienced with Docker containers. But if I provide a Debian > > package, you might be able to use it, or not? > > > > Probably a Debian package would be a nice way to run Ostrich. But don't > spent time for me, I can manage to build it natively or in Docker. > > I already started to create a Docker image (details in the readme) > > https://github.com/apache/marmotta/blob/900a70cfd33ceafb1513e8ecd41df9bd25fb42b9/libraries/ostrich/backend/Dockerfile#L52 > > but I get the same error than building locally: > > -- Boost version: 1.55.0 > -- Found the following Boost libraries: > -- iostreams > -- Not Found Tcmalloc > -- Enabling gzip/bzip2 support (Boost iostreams found) > CMake Error: The following variables are used in this project, but they are > set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake > files: > PROTOBUF_LIBRARY (ADVANCED) > linked by target "marmotta_model" in directory /src/model > linked by target "marmotta_sparql" in directory /src/sparql > linked by target "marmotta_service" in directory /src/service > linked by target "marmotta_persistence" in directory /src/persistence > linked by target "marmotta_sharding" in directory /src/sharding > linked by target "marmotta_client" in directory /src/client > > -- Configuring incomplete, errors occurred! > See also "/src/build/CMakeFiles/CMakeOutput.log". > See also "/src/build/CMakeFiles/CMakeError.log". > > > Did I missed any installation step? > It seems you are missing Protobuf 3.0 and tcmalloc. tcmalloc is in the Debian repositories, Protobuf 3.0 currently needs to be installed manually (or as part of gRPC 0.10.0). My suggestion is to checkout the gRPC git repository, build and install to /usr/local for the moment. I'll see if I can somehow find a way to automate this step. > > > > Just being more curious about the implementation details, if I understood > > right, the triplestore model is quite similar to the proposed by > LevelGraph > > http://nodejsconfit.levelgraph.io/#16 isn't it? > > > > It is, but their implementation is naive in the sense that they simply > store all possible permutations of S, P and O. That's not needed if done > properly and unnecessarily wastes a lot of space. I only need 4 different > permutations, and I have a context/named graph in addition to SPO. > > Yeah, I find that hexastore a bit naive too, but I was not sure about the > LevelDB query capabilities to really judge it. > LevelDB is a very fast key/value store allowing not only key lookups but also range queries based on partial keys or min and max keys. So if I have an SPOC table and I query for SP__ up to SP^^ (_ being min value, ^ being max value) I get all triples with the subject and predicate used in the query. This allows us to easily support the Sesame getStatements() style pattern queries, and very fast (because I simply load a whole batch of statements sequentially from database). With the four types of tables mentioned I can support all most common queries. Sebastian
