> Distribution involves separate machines, connected via TCP. On each
> > machine, typically several PicoLisp database processes are running,
> Is my interpretation right, that the ' several PicoLisp database processes'
> running on one machine form a 'PicoLisp process family' that is considered
> as one application with one database?
Yes, but there may be also several such "families" on a single machine.
A single application, operating on a single database, consists of a
parent process with an arbitrary number of child processes. This
structure is necessary because synchronization of all processes that
access a given database must go via a common parent (family IPC uses
"A single database" means usually a single directory, containing all
files of that database. Theoretically, a database may consist of
maximally 65536 files, but this dosn't make sense in a typical Unix
environment, because of too many file descriptors and other resource
problems. A single file can contain maximally 4 Tera objects (42 bit
It makes well sense to run several applications (= databases) on a
single machine, to get a better load distribution. I have no general
rule, for opimal tuning some experimentation is required. It depends
mostly on the number of CPU cores and the amount of available RAM (file
For the program logic (how those applications communicate with each
other), it doesn't matter which application is running on which machine,
as long as all is properly configered. I had an admin application for
connecting/starting/stopping the individual apps.
> How do you split up the databases? Rather by rows or rather by columns (I
Not on that level, but on a functional level. For example, we had many
databases (about 70) collecting data from filer volumes, sending some of
their data to a second layer (also 70) which in turn sent some boiled-up
stuff to a single dedicated database containing some global data.
Another front-end application queried all the lower levels to generate
statistics and user reports, and contained a rule database (in Pilog) about
what to do on the lower levels.
> know they are not 2D tables in picolisp, what I mean is: does every DB cover
> the whole class hierarchy, but only a fraction of the objects, or does each
Yes, this was the case for the first and second layer described above.
In each layer all databases had the same model (E/R definitions, in fact
the same program code).
> DB cover a fraction of the class hierarchy, but all objects belonging to
> these classes?
So each application is a complete class hierarchy in itself, independent
from (but knowing about) the other DBs.
But what I described was for that concrete use case. I had only a single
project with such large DBs until now. Probably many other designs are
possible. As Henrik said, stress is on ease of designing such
structures, not on a given framework. The philosophy of PicoLisp was
always to go for a vertical approach, with easy access from the lowest
to the highest levels.