On Thu, Jul 30, 2020 at 9:43 AM Ben Goertzel <[email protected]> wrote:
>
> Realizing these limitations one sees that for OpenCog purposes one
> likely better off w/ more basic key-value or column stores than with
> graphDBs ...
>
While I was writing the last message to Matt, I realized that having any DB
at all is very nearly pointless. That having a DB-backed storage is very
nearly an anti-pattern.
The only useful function that a DB seems to provide is to be able to say
"get me this particular atom X from the disk". But how often do you need
that? Far more typical is that you want to load zillions of atoms, and do
something with them. If zillions of atoms are too big to fit in RAM, then
we are back to the chunking problem that started this conversation, and the
chunking problem has nothing to do with databases.
The only other advantage of databases is incremental backup -- for
multi-day, multi-week-long calculations, you want to save partial results,
one atom at a time.
How much RAM are you willing to sacrifice to the storage subsystem? Every
byte of RAM used by the storage subsystem is one less byte available to the
AtomSpace.
For this, it seems that -- indeed, having a simple but very fast key-value
store might be best.
It took me a decade to arrive at this chain of thought. It seems
confusingly obvious, too simple to be true. But there it is...
-- 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/CAHrUA36Mh6KVGL55AmrPB65pufD8w_PcTZWyoV3yukP05fs2zA%40mail.gmail.com.
