Hi Sergio, 2015-12-14 14:53 GMT+01:00 Sergio Fernández <[email protected]>:
> > > > * Is there any way to get gRPC latest snapshots from any repo? Since it > > > looks that the latest release is not compatible, how long do you think > > > Google could take to release version 0.10.0? > > > > The Java side is available in the Sonatype snapshot repositories. I am > not > > working on gRPC, so I don't know their release cycle. But I am guessing > it > > will be frequent. > > > Ok, so let's wait. In the meantime I temporally added the repo for being > able to build the backend: > https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=abb1f00 > > > Thanks :) > > * I have some concerns about the build: is it possible to integrate the > > > cmake tasks in the Maven build? > > > > I wouldn't do this, because building C++ is much more system dependent > than > > building Java. Even though the code in theory should compile on other > > platforms than Linux, I didn't try. And cmake does not provide any > > dependency resolution (just checking) for the packages the code depends > on. > > I would rather build a Debian package (but we can only do this once gRPC > > 0.10.0 is released as Debian package as well, currently the latest > version > > is 0.9.0 which contains a performance bug that causes problems for > > Marmotta). > > > Yes, that's one of the negative aspects of C++. So, yes, Debian package or > Docker container could options to make this easier to deploy. > I'll try to provide a Debian package configuration if I find some time. It would also more nicely specify the dependencies. > > > * It definitely increases the deployment complexity, from the typical > two > > > layers (db-backend) to three (db-server-backend). > > > > I think there's a misunderstanding here. :) > > > > LevelDB is an embedded C++ database, compiled into Ostrich as a library, > > not a separate database server (see http://leveldb.org/). Ostrich uses > it > > internally to create 4 key-value databases, allowing fast lookups and > range > > queries over SPOC, CSPO, OPSC, and PCOS keys. It stores all database > files > > into a configurable directory on the local disk. > > > > marmotta_persistence is therefore a self-contained database server itself > > without any further dependencies. You startup marmotta_persistence, and > you > > startup the Marmotta Java backend, and you are done. So the deployment > > complexity is the same as with Postgres, just you use > marmotta_persistence > > instead of Postgres. ;-) > > > Oh, sorry, I got it wrong. I though the server required a LeveDB daemon, > but if it embeds the database as library then the deployment architecture > is something similar. > > 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? > 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. > > > * I fear maintaining another triple store would be just oo much for our > > > small community. We already spent quite some effort in the SPARQL-SQL. > > > > > > Well, at least it's worth to explore new paths and some scenarios may > > > benefit from this contribution. > > > > I'll maintain it for the time being to see if there are actually good use > > cases. The reasoning behind this is that it would require a radical step > to > > go beyond the current performance of the SQL backend (hence LevelDB and > > hence C++). There are simply certain limits to relational databases and > we > > have tuned the KiWi backend almost to that limit. I can see that there > are > > use cases where users can live with limited transaction support and > > features and trade it for performance of most common operations. Wouldn't > > it be nice to run a SPARQL server over DBPedia on a Raspberry? ;-) > > > Well, the relational db limits and features set were well known when we > worked on improving KiWi. Personally I'm thinking more about the project > maintenance given the small size of our community, but probably I'm > too cautious. > Let's be a bit risky - there's nothing to really loose. In the worst case we just remove it again. Sebastian
