Requirements And Possibilities Of LeoBase Indices

• The means of repeating values groups detecting: transit to group beginning/ending, to the next/previous group and so on;
• Fast search of value by index and return of the first record number satisfying the condition of search;
• Means for record numbers from two linked databases transformation. The database links can be presented as a directed graph:



The arrows show the LeoBase link direction, but indices allow to carry out tranformation both to the right and to the left, from one record set to another.

• The possibility to introduce new elements, to remove old ones and to replace the existing ones not only by one, but by packets;
• Index dictionary (histogram) increasing the search speed and fastens index change operations (planned).

An approximate dependence of search speed on record quantity and query complexity to search (term number) is shown on the figure below:

Requirements And Possibilities Of Virtual Bit Arrays

• Supporting up to 1200 simultaneously used arrays;
• Quite optimal memory data storing structure. While working the VBA manager can use all available RAM, but the special query can free this memory. In Windows version of VBA such a query is not necessary -- the memory will be freed automatically;
• The basic functions — as bit set/reset, check for set bit, are widened with such functions as bit setting within specific number range, returning of N-th bit among the set ones, returning bit number by number among the set ones, by sequent iteration on single bits in ascending or descending order of bit numbers and many others;
• The functionally complete operation set between bit arrays -- logical AND, OR, SUB, NOT;
• Methods of loading and storing bit arrays from files;
• Fast information transfer from LeoBase index to bit array, for example, transferring of all the current group of repeating values and loading all index values within a certain range of index element numbers. Thanks to this posibility the LeoBase search query result is the all records satisfying the query, but not only the first one; the result is returned very quick.

LSF Possibilities And Requirements

• Read and write operations buffering. All computer's memory can be used for buffer;
• Flexible work with buffer. With free memory present, LSF can take it all, but if necessary, but the special query can free this memory. In Windows version of LSF such a query is not necessary -- the memory will be freed automatically;
• Write-behind supporting while writing to disk files;
• Files operations set is substantially widened compared to standard ones. This set allows to use LSF as file manager of full value. Besides standard file writing and reading, filling a file in with specific byte value is supported, cutting and pasting of file contents in any file position are supported, moving a file fragment to any place of the same file and many functions are available;
• The independence of file number, registered under LSF, on maximal operating system file descriptors;
• The possibility to appoint various privilege levels of buffering to various files and to various parts of one file. Thus, more important files and their parts will be in LSF buffer for a longer time than the others. It's possible to appoint various impotance degrees of file parts depending on concrete situation;
• The powerful trigger system. thanks to it there is a possibility to overload practically all of LSF standard actions, for example, to carry out executed actions statistics, to code infromation recorded to disk and so on. The triggers being overloaded one can adapt LSF to work on other plattforms and organize access to an abstact device (for example, to remote carrier by dedicated line);
• The transparent placing of one or more files on several physical carriers. In overwhelming majority it removes the problem of space lack for files. In case of insufficient disk space there is a possibility of saving information on separate carriers, even on diskettes. In another working period information from these carriers can be moved to main carriers, where the space is freed;
• LSF requires about 10 K of RAM and minimum 20 file handles for successful work. For one file registration about 60 bytes of memory are required.

Working With LSJ

To start work with snapshots mechanism, one should create a system journal. The filling in of system journal is organized cyclically while working with database complex. The journal consists of seversl sections of equal size. The recording into sections is done sequentially. When there are no free sections, the data of first section are annulated, then the same is done with the second one and so on. The number of sections and the size of each one are important features. Let's regard such an analogy. There's a picture album with photos from various countries.The number of photos which can be placed there is restricted by its volume. When the album is overfilled, the oldest pictures are taken away and they are replaced by new ones. If the travels takes place quite often, the album is filled and renewed pretty fast. Thus, maximal photo age is defined by album thickness and travels frequency to other countries.

The same situation takes place in system journal. The oldest database state which can be viewed (by activating corresponding snapshot) depends on journal size, database change frequency and on sections count (because, if necessary, the section is annulled completely).

There are no other special ways to define the system journal size -- it's just an empirical process depending on database size, the dynamics of its changing and so on. Let's mark up the following: the active snapshot fixing occurs at rather long operations as report generating or very complex search. That's why if there's an overfilling of journal (the section current in work is annuled), journal renewal will not be carried out before the end of operation. Consequently, the server will block all the modifying operations for this time.

We'll explain the system journal work. There's a system journal consisting of four sections.

On step 1 the system journal is empty. On step 2 is has three sections filled and in the end of first section a snapshot is set; the large report is generated with using this snapshot. On the third step the system journal is overfilled. At this moment the data of first section must be annuled.

However, the report is generated using the snapshot which is fixed with LeoBase kernel. That's why server stops filling the system journal, blocks all system transactions until snapshot removal (end of report generation).

There are two ways out off the situation: either to increase the system journal overall volume, or to split it into larger number of sections with the same volume.

If the number of sections equals 5, there will be a chance the set snapshot is not in the first but in the second section. In this case blocking will take place only at the next filling of first section in and at jump to the second one. This gives additional time during which report generation may be completed. However, switching between sections takes some time. The main designer's task is to find a balance between number of sections and working speed.

UPGRADE Possibilities And Requirements

Let's explain the purpose of this system by the following example.

Company N created the large volume information search system. The changing and filling the database in takes place continuously, and users who bought this product must get new version base in proper time. There are two ways of solving the problem. THe first is to send full copy of new base to all users. If the total volume compared to changes is rather large, it may cause substantial expenses. The second way is to send just new and changed information. No doubt, it's much more efficient. The realization of the second variant is the purpose of UPGRADE system in LeoBase.

UPGRADE execution is splitted in two phases. Phase 1 is realized on a host computer where the latest variant of database is kept. As the result of this phase, there is UPGRADE file containing all changes and editions which took place since the given time. Phase is carried out on user's computer which performs the database contents actualization using the information from UPGRADE file.

The necessary condition of successful phase 1 work is providing a changes journal on host. The UPGRADE file can be of two formats: Fast and Compact. In the first case the file is formed relatively faster but its size is larger than in the second case. Compact format requires necessary presence of system journal, and the size of acquired UPGRADE file is minimal. The main difference between two formats is that in Fast format the whole modified records are placed into UPGRADE file, and in Compact only really changed fields are present. It has nothing to do with MEMO fields which in both cases are put into UPGRADE file only if there's such a necessity (i.e. it doesn't refer to record contents itself).

The concept of system and UPGRADE time in LeoBase have great meaning for renewal and coordinational operations. The UPGRADE time is used to synchronizing the database contents on host and user. The system time serves as start countdown for phase 1 execution on host.

!!! - go to the RUSSIAN VERSION

 

Click Here to Return Back

Webmasters, contact Belarus.net support
Click Here to visit Belarus.net