Hi Amirouche, On Mon, Jul 20, 2020 at 2:01 AM Amirouche Boubekki < [email protected]> wrote:
> Le lun. 20 juil. 2020 à 03:57, Lansana Camara <[email protected]> a écrit > : > > > > Can you provide a diagram of the architecture? > > A DHT backend could be used to spread the on-disk load over many > peers, but only as _cold storage_ not as a primary source of truth. > Um, no, I am unclear on why you are making a distinction between hot and cold storage. The current three prototypes all provide hot storage, and have no provisions at all for cold storage. > > I'm having a hard time visualizing high-performance servers being wired > up by a database. > > I am not sure I understand that. Every system requires some kind of > database. The atomspace is a database. It is an in-RAM database. > What could be done is to have a Single Source of Truth There is no single source or truth. Fundamentally, there cannot be. Some people will say "eventually consistent", but I am not aware of any reason why that is desirable. Yes, I understand that certain kinds of datasets might need to be consistent, but this should NOT be a built-in property of the database! This is a VERY IMPORTANT point that results in a huge amount of friction and confusion because it leads people into making utterly terrible design decisions that have no rational basis. I have worked very long and very hard to completely eliminate all concepts of "eventual consistency" and "single source of truth" from the atomspace. These are two of its important selling-points! Don't erase or subvert them! where > everything is persisted forever No, not forever. Deletion IS a very important quality! and secondary sources of truth where > expert systems (high-performance services) store the data in their > favorite schema. You've lost me. That atomspace is a database. It has a certain built-in schema that is (supposed to be) general enough to layer other schemas on top. The idea is that any "favorite schema" can be easily/trivially layered on top of the atomspace. This is "mostly true" today, but there remain some ugly bits that I would like to see fixed. This is usually the case of Event Sourcing systems. > The whole system is eventually consistent. Again, No. This is NOT a desirable property of the system! It's an anti-pattern. That means that a given > expert system will have to wait sometime before they become aware of > new knowledge. The advantage is that you keep around all the data in > the log, the event source, That is what the demo at https://github.com/opencog/atomspace-cog/ is. It is the "event source" > and aggregate the useful knowledge for a > given system in a fine-tuned highly performant database for specific > uses. That is what the atomspace is. It is a fine-tuned, high-performant database. It's got the highest performance possible, that I have been able to squeeze out of it, and if someone thinks they know how to make it faster, ... well, that would be a very interesting direction to go in. But, to get faster, it would need some truly new, radically different approach, and I cannot really imagine what that would be. This is not my favorite approach but it is workable. > :-/ --linas -- Verbogeny is one of the pleasurettes of a creatific thinkerizer. --Peter da Silva -- 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/CAHrUA358UNzZxG9%2B7GrBFN9oa%3DjcsZVEzBuHHcAmi_GBSXoX0Q%40mail.gmail.com.
