> > > > Rocksdb is a serverless, single-system key-value database optimized for > > > > SSD disks. It has C bindings, and it's fast. For me, simple and fast > > > > are highly desirable properties. > > > > > > So is wiredtiger https://source.wiredtiger.com/ but GPLv3 > > > > Is wiredtiger actually serverless? > > It has no network component. It has a notion of table, but that is an > > optimization. You can use it like rocksdb with a single table, with single > > key-column and a single value-column. > > The only drawback is that it is difficult to work with if the dataset does > > NOT fit in RAM.
Linas replied: > The AtomSpace wants RAM. Because the AtomSpace is an in-RAM database. So > using something else that *also* wants RAM is stupid: it just means that I > have to buy a computer with twice as much RAM. I've walked down all of these > roads before. I am not sure I understand: will the new symbol expression database work along the current AtomSpace? In any case, whether it is RocksDB, wiredtiger, SQLite, Foundationdb, or whatever. The decision must not be settled lightly, I was under the impression they were clear goals and use-cases for opencog, my recommendation is to extract from those hardware and software specifications, and quality metrics, then benchmark https://okvs.dev and dbms. Be warned that using one or more https://okvs.dev lead to more economical software framework, hence possibly more profitable (less bugs, less maintenance cost, easier on-boarding; on a related note, read [0]) Benchmarking, auditing and evaluating is difficult work, with a very slow return on investment (ROI) in the short term. The goal of those is to reduce the risk of making major buggy decisions that are difficult or impossible to workaround. Fast-time-to-market is an evil practice. Meanwhile, a good design can be implemented quickly and can work flawlessly. > Maybe something like (query ?x (foo bar ?x baz)) to find all lists with four > items, three of which as shown and the fourth unknown... would this be an OK > API? Have you seen anything like this? any suggestions? It looks like the symbolic expression database you built looks much like what I call a 'General Tuple Store' where every object of the database is a tuple of arbitrary length made of "atoms". I made up the 'General Tuple Store' three-gram, the literature used to call it "Tuple Store" or maybe "Tuple Space". I prefer the General Tuple Store, to differentiate with the nstore aka. Generic Tuple Store, where tuple length is fixed. A General Tuple Store can be built on top of a Generic Tuple Store. Forget about GraphQL [...]. I think something declarative like prolog or datalog or sparql can work for some audience. It depends on the app, the niche and what you want to market. Note: In my experience, given the current state of academic and industrial practices, most of the time: code is a liability. [0] https://scribe.rip/@enkiv2/composability-homogeneity-and-language-based-systems-fb00e2c2458 -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAL7_Mo9jSbBNseXbH7d%3DghYXfv%2BvHgxyBqvxpMeVf9%3D-Qo%2B1xg%40mail.gmail.com.
