Hi Thorsten, > 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 simple pipes). "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 object ID). 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 buffer cache). 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 Right. > 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. Cheers, - Alex -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
