Power by Design
|
Select A Section home public service database mgr. data access data modeler site notes |
Currently In This Section AxleBase Technical Description ( Please Scroll Down ) |
Section Pages summary description design limits notable tests shortcomings nomenclature operation |
|
This is a legally copyrighted work,
__________________________________________________
__________________________________________________
__________________________________________________
_________________________
_________________________
Not Objectives
Heavy concurrent access.
( Big name brands such as MySql, Microsoft SQL Server, Oracle, and IBM DB2 should be considered for ordinary needs. Ordinary systems and AxleBase require different engineering for performance and avoidance of catastrophic stress failure.)
_________________________ Anybody who knows standard SQL can immediately query an AxleBase database. AxleBase uses the standard ANSI-92 SQL language. He does not require a super-computer query language. Standard SQL also means that most system developers already know how to apply AxleBase. AxleBase extensions are not needed for standard queries. But if a user wants to use one of his advanced technology functions, it is added to the basic standard SQL. Using his extensions does not change or interfere with the canonical SQL syntax, lexicon, or construct. They just slide into the standard construct if needed. To insure support of standard ANSI-92 SQL without confusing users, the extensions are hidden and can be found only in the "Operation Manual". Furthermore, the documentation of each extension explicitly warns that the extension is a deviation from the ANSI-92 SQL standard. ( Note:
_________________________ Can be compiled or built into any software that needs a database manager. Includes a complete and documented programming interface ( API ). Embeddability was a design objective and is not an after-thought. He is a dynamic link library, a DLL, that runs inside host software. AxleBase is ODBC compliant so he can support any host's ODBC drivers.
_________________________ His interface allows him to be totally controlled by the host system. The interface has over a hundred commands, many of which are overloaded and configurable. It is thoroughly covered in his "Operation Manual" with hundreds of examples. The interface consists of multiple selectable interfaces to support various communication needs and programming language needs. The interface includes an extensive error protocol interface that is designed for people and for machines. Demonstration apps are available with AxleBase embedded.
_________________________ A database server is a host that provides communication between a database manager and its client computers. AxleBase is the database manager. AxleBase is designed to be embedded in any host. When the host is a server, AxleBase provides all database server features. Multi-threaded servers are supported. Every AxleBase instance handles all database functions including local and remote object locking. The server can use multiple AxleBase instances to service multiple inbound client threads because every AxleBase instance operates as though it is sharing a database. Any instance on a thread can assume the role of master database controller under the host's control. ( A database server demonstrator is available with AxleBase embedded.)
End of the Functional Overview section. Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ The AxleBase features, extensions, and advanced technologies do not alter, interfere with, or compromise either its relational database construct or its standard ANSI-92 SQL language.
_________________________ An understanding of the AxleBase technology requires advanced concept abstraction and a general understanding of computer and network infrastructure. If you are not a data professional, then discussion of this section with a master database administrator (DBA) or a computer science professor is recommended. The AxleBase technology sets him far above the enterprise class, wielding quantities that are usually found only in astrophysics because they are so vast. There was no name for his class when he was created, so it is referred to as the AxleBase-class. The average DBA can use AxleBase "out of the box" like a normal database manager. Other than that, he makes no attempt to be politically correct. His advanced features were designed without apology to provide tools for the master DBA who can visualize and work with high level abstractions to perform unbelievable operations. User Consideration:
Project State:
_________________________ Objective Met:
The number is so big that an example might help. If the books in the biggest library in the world, the Library Of Congress, were converted to electronic characters for computer storage, then a single AxleBase table could hold the entire library. Furthermore, that single table could hold millions of those libraries. And each database can hold many tables.
He is not merely a data warehouse or internet search engine. He is a fully functional transactional relational database manager providing for very large data entities all of the features that are found in enterprise-level systems.
NOT needed.
His proprietary mechanisms protect the infrastructure while enabling the return of very large datasets.
Of course. One more time: AxleBase offers the standard relational database manager features along with his advanced technologies.
He goes far beyond even those features with special abilities that are so numerous that they can be described only in his "Operation Manual".
Or perhaps you were looking for his size. He is a DLL that easily fits on an old floppy disk. That may be hard to believe in this age of undisciplined bloatware, especially after you study all of the features and advanced technologies in him, but it is fact. ( Those who were not having fun watching big money and open source hoards trying to catch up were simply unaware.)
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________
Most computers cannot hold the vast databases described in the previous section. But the AxleBase technology compensates for shortcomings in equipment and infrastructure. AxleBase defaults to using local storage. His activity is then like that of any other database manager, and his administration is as simple and simpler than some. The difference is that the DBA can give him a permission list of computers and disks that he can use for storage of a table that will grow into a large size.
None. He handles it.
He performs the extremely complex task of OLTP (online transaction processing) against massive distributed databases. Yes, even updates, deletes, table joins, and index usage.
NOT needed.
His speed on desktop computers rivals that of big name brands on million-dollar servers. See the Tests page.
His indexer accommodates massive distributed tables.
Backup, Purge, Index, DropTable, etc., etc. are designed for massive tables. Research into indexing, error handling, and many other areas has yielded sub-systems inside AxleBase that are designed especially for very large entities.
Data can be stored on the cheapest desktop computers. Benefit analysis of an AxleBase installation can sometimes show cheap desktop computers giving the best performance even for wealthy organizations. So what does all that mean in human terms? It means that the Library Of Congress can easily be stored and queried on a few cheap personal computers. ( If you understand that awesome power, then prepare yourself for a shock in the next sub-section.)
( Professionals who are accustomed to normal database managers are advised to skip this feature because it will not make sense to you.)
A systemic danger to data integrity is created by allowing widely scattered and loosely controlled data sources. AxleBase is aware of that so we can be sure that our queries are valid.
( In the development of this technology, great care was invested in preserving standard concepts, methods, procedures, and commands. The new technology is accessed through the old.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________
When extraordinary power is needed, AxleBase can be configured as a super-system to simultaneously manage many computers to deliver super-computer power. Furthermore, the AxleBase technology can deliver that super-computer power from the cheapest desktop computers. He has special abilities even when operating as a standard database manager, but this feature also allows the DBA to configure him for any amount of power for exabyte-sized tables. He delivers astronomical computing power through decoupled systemic parallelization of cheap personal computers. ( His development lab uses the cheapest and oldest computers that can be found in local stores and donated scrapped computers.) Now, back to human terms to help grasp this technology. It means that the Library Of Congress that you stored on a few cheap personal computers in the last sub-section can be queried by other cheap PCs in seconds. (See test results on the Tests page.)
The Google corporation was understandably proud of the speed of their Dremel database manager. But Google relied upon massive amounts of expensive hardware for that speed, whereas the AxleBase code was laboriously designed and engineered for power. Comparisons revealed that AxleBase was over four thousand times faster than the Google system.
The super-system object that is created by AxleBase is an axsys. An axsys is AxleBase in his super-system form. As with any computer object, the axsys creation event is referred to as an instantiation; e.g., "The DBA instantiated an axsys."
NOT needed.
NOT needed.
He can perform the extremely complex task of online transaction processing in a massive super-system with a vast distributed database.
Standard system utilities such as Backup, Purge, DropTable, Index, etc. offer standard operation and extended features to handle data distribution and the super-system. Special needs are met such as reporting the state of a super-system before a query, reporting the state of a long-running super-system job, etc.
AxleBase security goes far beyond standard client-server systems to include super-systems. See the security section on this web page.
AxleBase is designed to operate as multiple instances running against a database. Multiple instances can operate as client servers against the database. Standard instances can query normally against the distributed database while other instances drive the super-system for major queries against the same database.
An instance can be set up as a database server to provide an external entry point into the super-system.
The test page shows that AxleBase can return a query from qigarows in a split second, so why would a super-system ever be needed?
( In the development of this technology, great care was invested in preserving standard concepts, methods, procedures, and commands. The new technology is accessed through the old.
( The computer scientist reading the super-system description may sense the most feared animals in computer science: i.e., Nonlinear equations.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ When truly awesome power is needed, database distribution and super-system configuration can be used together to manage very large data stores. Neither requires the other. ( Recognizing that the AxleBase technology may be the most advanced in the world, after covering the practical "nuts and bolts", the "Operation Manual" introduces the DBA to theoretical realms that are opened by the technology. It gives him a conceptual over-view so that he can critically monitor and assess the application and performance of the technology.)
_________________________ AxleBase can be operated as a standard database manager. Even as a desktop database manager. As such, he will appear to be a "run of the mill" DBMS. Objective Met:
The DBA can select from various axsys startup methods. At the most extreme, he can design his axsys so that it instantiates, monitors, and repairs itself. The DBA designs the axsys that he wants, enters its parameters, prepares the infrastructure, and powers up. The axsys mechanism allows the DBA to specify nodes by location or he can generalize configurations so that any instance that comes on line will assume the functions of a required node. Such a volunteer node will automatically register itself with monitors and controllers in the axsys. AxleBase allows alteration of all aspects of a functioning axsys, including the architecture, without taking it down. It can continue to operate while the DBA changes it to meet changing needs, even when its power is altered greatly. Tools include the ability to command all running nodes to reconfigure. If the data is distributed, every AxleBase entity knows how to find it and manage it. If running as a super-system, each entity can become a node as it comes on line so that a large axsys configures itself as it wakes up. If the data is distributed under a super-system, each AxleBase entity knows what to do when he comes on line. Traditional computer system logic requires that the host in each node be the controller, but the objective here is to keep the host as simple as possible. Therefore, the node configuration is online in each AxleBase instance and the interface includes local host service. That allows each host to query its AxleBase instance for instructions. Therefore, if desired, a single generalized host server can be created which can follow the configuration directives of its local AxleBase instance. Although the advanced technology requires capable DBAs, database users need know little or nothing about it and may even be unaware of it because AxleBase hides it. Example:
More autonomic behavior is covered in the Fault Tolerance sub-section.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________
AxleBase does not crash. He has never crashed under years of severe test loads and abuse as long as the infrastructure did not crash. He is hardened for deployment on inferior equipment in hostile environments. When a fault arises that he cannot handle, he stops processing, tries to recover, reports the problem, and awaits instructions.
The fault-space of a standard database manager is miniscule compared to that of an AxleBase super-system with a distributed database. That expansion and distribution increases a system's exposure to faults in equipment, external software, supporting operating systems, and from acts of God. That is fundamental and basic to theory and practice.
That extended fault space has been kept at the fore in AxleBase development. Not only does he contain fault tolerance mechanisms for it, but his very architecture is engineered for it. His technology uses the problem-causing expansion and topology as tools to combat those problems. Instead of a feared theoretical exercise, the skilled DBA can turn an axsys super-system managing a vast database into a solid operational asset that actually increases system robustness. Contrary to past experience and common sense, it can actually be more reliable than a local system.
The expression of the axsys is insulated from the internal architecture of AxleBase so that the local DBA can design the axsys that he needs. It allows the DBA and management staff to actually decide on levels for fault tolerance, speed, and security and then create an axsys architecture to support them.
There are three levels of data integrity in database managers.
Although the quality of the communication system is beyond his control, AxleBase compensates in some areas.
The AxleBase super-system provides autonomic node loss recovery to tolerate loss of computers and network segments.
An AxleBase table of trillions of rows scattered across a continent can be queried with confidence.
Parts of the super-system can be lost and recovered during a query without stopping the query and with no corruption in the data return. (Impossible and interesting are engineering synonyms.)
AxleBase engineering makes updates and error-control as reliable for giant distributed databases and super-system operation as for local updates.
If you know about it, AxleBase has solved it.
AxleBase can mirror any or all data objects if needed.
AxleBase in a very large data source network, such as
The laws of communication physics make it impossible for database managers to share a database with multiple systems over relativistic distances.
( The above was published before development work on AxleBase was stopped. I recall working on relativistic disruption, but do not recall the work, and it is not noted in internal comments. I find the concurrent data updates rather shocking, but was at the top of the game back in my sixties. (See "Embedded Documentation" in the "Operation Manual"
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ The super-system object that is created by AxleBase is an axsys. An axsys object is AxleBase in his super-system form. As with any computer object, the axsys creation event is referred to as an instantiation. An organization that needs an axsys requires an axsys that uniquely handles its needs, so each will be designed by the local DBA staff and system staff to meet those needs. AxleBase has the flexibility to meet nearly any conceivable design and is prepared for any implementation "out of the box". The "Operation Manual" includes suggested and detailed descriptions of the types of node hosts that the DBA might want to deploy. The primary jobs of an axsys host are:
The host needs no database programming. It needs little knowledge of the embedded AxleBase instance. Common tcp/ip communication is the only complex need. The SysLink application-level communication protocol is provided by AxleBase as a courtesy to simplify communication for the host. His primary interface of over a hundred commands can be used by a server or any other host. Additionally, AxleBase offers a simplified interface specially designed for lightweight servers. It is an orthogonal abstraction of the entire primary interface into a single command. A command can be created on a distant controller instance and shot into the target nodes through that interface. The AxleBase self-configuration in each node allows the various types of hosts to be similar servers, perhaps with slight alterations for node types. The result is a lightweight node host and reduced programming for the local organization's axsys.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ True virtualization seems to be troublesome for many people. Part of the problem may result from the big name brands referring to copies of tables as virtualizations, which is incorrect, confusing, and misleading. But aside from that, difficulty in grasping the concept seems to disrupt people's thinking so that they become confused, not only about virtual tables, but about other aspects of database management. And this poor writer may be doing an inadequate job of presenting it. Certainly, true virtualization as AxleBase does it can present mind-bending problems of conceptualization. Part of the problem is that database managers are actually not understood by many people who think that they understand. For example, attempting to sell AxleBase revealed that many use the terms "database" and "database manager" interchangeably. As accomplished by AxleBase, a virtual table contains nothing. If you were to look directly at it on disk, an empty file would be seen and a text editor would load nothing from it. But if you query that table, the query might present billions of data rows and trillions of bytes. In actuality, that data is virtual; i.e., it does not exist locally, but is an image of real data that might be located anywhere. AxleBase can also concatenate many data sources into a single virtual table so that it is locally used as a single coherent entity.
The designer attempted to thoroughly integrate virtual tables into the relational construct. From the user's perspective, virtual tables are just more tables in the database with no special features. The ShowTableAttributes() command can be used to reveal table types and virtual sources. Queries against virtual tables use the same industry-standard ANSI-92 SQL that is used with standard tables. The complex virtualization mechanisms function entirely behind the scenes. For example, "select count(*) from t_virtual" will return a row-count from the summation of all of the sources that feed t_virtual.
Table join queries of virtual tables look like any other joins, and the returns look the same. Virtual tables can be joined with other virtual tables and with standard tables. Virtual tables use the standard AxleBase error sub-system that is used by standard tables, and it adds errors that are peculiar to virtualization.
It was theoretically possible to update a virtual table, so a feasibility study was conducted that showed that it works very well.
Any data object can be a data source if it can be internally defined with valid table attributes. Acceptable data sources for an AxleBase virtual table can include :
A virtual table has all the security features of a standard table.
The uninitiated must remember that this is a relational database manager. The DBA will design the database so that its tables can be whimsically joined within queries by researchers. That creates dangers for systems, for which AxleBase has DBA tools.
Yes, every feature in this document was being addressed and(or) used by AxleBase as tests were performed, and the recorded times are correct. For example, all 38,000 files were validated every time that the three second query was run. On scrapped desktop computers. (Even its builder frequently finds it unbelievable, so he has given up trying to understand how he did it.)
Unfortunately, research and development ceased before a mechanism was developed to allow the axsys super-system to query a virtual table. It can be queried only by the standard database manager configuration. (Unfortunate because it might have taken only a few weeks to virtualize an axsys.)
A bug was encountered in the virtual concatenation sub-system in 2013, and it was intentionally not fixed as advertised. Since research and development of AxleBase have ceased, it may never be fixed. There are more features and discussions of virtual tables in the AxleBase documentation that will not be covered here. ( This sub-section was re-inserted in November of 2017 to serve the computer science Theoretical Data Limit conjecture section.)
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ AxleBase can deliver extremely detailed and long-term persisted auditing for governments and other organizations that require extreme security and accountability. His core architecture contains a detailed audit trail that is usually not manifested and cannot be defeated because it is part of the internal system structure. The system is designed to routinely discard the information, but the organization that needs it can put it into service by turning on the audit toggle. Additional audit tools can be turned on if needed. When they are turned on, any table created in the database is created with additional non-updateable audit data columns that are added to the audit trail. If the DBA turns on the audit toggle, it cannot be turned off, even by the DBA. All AxleBase data, control and configuration files are designed to be easily accessible. However, attempts to hack the audit data or audit mechanism in those files will corrupt the database. The only way to destroy audit data after the audit toggle is turned on, is to destroy the entire AxleBase installation, including all backups. This feature is not intended to suggest that AxleBase be used for heavy-duty on line transaction processing or heavy concurrent usage. Those are not his purpose. For such purposes, please consider one of the many fine normal database managers on the market from MySql, Microsoft, Oracle, IBM, etc.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ The management of a normal AxleBase database is like that of any normal database manager. For more powerful configurations and uses, the interface has a complete set of advanced commands, utilities, and tools for the DBA, and a set of VLSI admin tools. Research into the advanced features identified special needs for support of the DBA. The Operation Manual guides the DBA with suggestions for system design and administration. Only the "Operation Manual" can adequately present the tools because the list is long and involved. The following may be indicative of the power given to the DBA.
Cognate clusters may be created by the DBA. Cognate cluster configurations are maintained within databases. The types of cognate databases are :
End of the Advanced Technologies section. Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ Not necessarily high-tech, but notable. The AxleBase features, extensions, and advanced technologies do not alter, interfere with, or compromise either its relational database construct or its standard ANSI-92 SQL language.
_________________________ In an extravagant age where value and power are defined by cost, AxleBase stands alone against the trend. He is so radically different that some thought was given to placing this cost sub-section in his Advanced Technologies section. Objective Met:
In an age when every computer user thinks that he must have a huge disk drive and every manager requires the most expensive storage, AxleBase delivers huge storage and very high speed from the cheapest and smallest disk drives that can be found. Disk drives are used for years in the AxleBase lab until they die. You will notice that the tests on the Test page were run on very cheap machines, some of which were very old. But for those who can afford it, AxleBase can also run on expensive high-end multi-processor servers. AxleBase is built upon the concept of frugal simplicity. His internal simplicity that generates great power has demonstrated that, because of our inability to build sophisticated software systems, we have hardly touched the capabilities of the existing hardware investment. The rhetoric of software engineering in this civilization has camouflaged an engineering failure. ( If a giant software company tells you that you must have million-dollar mainframes, or billion-dollar super-computers for size and performance, or a cloud-computing contract, please refer them to the published AxleBase test results.)
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________
Because his tables and databases can be distributed, AxleBase is expected to use a variety of equipment and operating systems. He is expressly engineered for high performance on low-end desktop computers. However, he and his data can be placed on million-dollar servers if desired.
The AxleBase instance runs on Microsoft Windows.
His databases can be on any operating systems that can share storage sites with the manager operating system. That includes, Linux, Unix, mainframes, AIX, Ms. Windows, etc. etc. That is possible because his tables are relocatable and distributable.
His internal architecture and code are designed with generalized communication theory in mind because he was purposed for the generic computer network. That means that he can be expected to run on any of today's networks. His architecture, error handling, and tools are expected to perform to spec even on the internet. He is kept above all network protocol layers. His error handling protocols, management tools, and internal communication protocols ride totally on top of, and are independent of, network protocols. Since he adds his own layer to the network stack, any network that reliably services his communication protocol will suffice. LAN, grid, cloud, mesh, wireless, etc. are irrelevant to him. His advanced technologies are designed to morph into the network architectures that are currently being investigated. He requires only the continued transparency and dependability of the original Unix communications. Although irritating to the users, network delay is irrelevant to AxleBase. Since he was designed with even the internet in mind, he and the DBA can compensate for unforeseen delays. AxleBase is designed with low-quality media in mind. Personal experience has shown that large networks are sometimes noisier than can be tolerated by precision database operations. The AxleBase architecture and DBA tools address that issue in his distributed operations. An AxleBase installation can be made so vast that it can actually exceed the geographical and hardware boundaries of local networks. The DBA is given documented tools to manage such an entity. ( The power of today's network arises from the fact that it was designed to provide transparent and unobtrusive communication between Unix systems. Even the noise and mayhem on the internet cannot defeat its power. But if idle hands begin interfering with applications that use networks to communicate, then all is lost.)
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ Although not a glamorous feature, this one has dictated to all other project development because the developer considers it a moral imperative for software. The AxleBase interface is based upon a few unusual ideas. 1. Data belongs to its creator; not to a giant software company. 2. Technologies, even those as profoundly advanced as AxleBase, fade away, and sometimes with them the data that they contain. 3. The foundation for database security must be:
The result of those three factors is an unusual design in AxleBase that puts all data and system configuration within reach of its owner. Data is not hidden to lock people into AxleBase. Data is stored as standard ASCI text. The DBA can access his data with any text readers or other text handlers. Yes, even notepad. (Of course, AxleBase also has export and import tools.) The decision was made for AxleBase to even store numbers and dates as plain ASCII text to meet this moral imperative. Dates conform to the CoreDate protocol. (This is not to denigrate other systems that store numbers and dates as unreadable characters, but to insure that AxleBase data is accessible.) Even definitions and system configurations are in readable text. Table definitions, for example, are identified with the data and can be opened in notepad. Data will not be lost for want of a definition. ( If a giant software or cloud-computing company tells you that complete accessibility will slow operations, please refer them to the test page on this web site. If they tell you that it will defeat security, please refer them to the security section on this page.) ( Control Codes:
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ ( Axiom: Any software-based security system can be defeated. ) This sub-section does not cover all of the AxleBase security features. AxleBase security is so sophisticated that it goes up to the VPN level. Therefore, he allows his security to be addressed in layers and discrete functions for administrative simplicity.
Security in any kind of computer system is a reptilian nightmare for administrators, developers, and users. That is sometimes especially so in an advanced AxleBase installation, so the security toggle defaults to off upon installation. The DBA can then begin turning on security as he learns and as needed in the installation. The basic AxleBase security is standard server security. But even that has some optional extensions such as the security system toggle mentioned above. AxleBase offers basic security at four levels that are controlled by the DBA.
Basic AxleBase security uses the standard crud model. Crud permissions are applicable at all three levels. After security is turned on, every permission for every object defaults to "no" for every person and every system. Every user must be given permission for every type of access and every type of use for every object. Enabling security also enables the AxleBase passthrough control, which is separate from the crud controls. Passthrough access can be controlled by name and password at the domain and at the database level. For example, if access is restricted at the domain level, then the databases in that domain can be accessed only by user name and password at the domain level before encountering the database passthrough controls. The passthrough and crud controls are local to each level.
AxleBase has his own encryption and authentication mechanisms with selectable encryption depths. Encryption depths are set by the DBA in the database attributes. Encryption may be ordered at several points.
Since AxleBase is embedded in the user's host, the user is free to use third party encryption or authentication for traffic going through it. That choice is neither recommended nor discouraged. After all, professionals who are dedicated to encryption or authentication would be expected to deliver better tools for those tasks. AxleBase will not participate in third-party solutions. Also, every remote client that wants AxleBase encryption, decryption, authentication, or verification must have an embedded AxleBase instance. His authentication is not a digital signature. It is extremely verbose and will remain so. A single authentication can be several thousand bytes. His encryption is also extremely verbose and will remain so. It adds greatly to the size of every transmission, but AxleBase will not do lightweight anything.
Logging can be turned on when needed by the DBA. There are independent logging toggles within each database and each domain. Logs capture data, structure, and management operations. Extremely low level tracking can be implemented by the DBA by enabling auditing. System auditing goes down to the row level and is persisted through every data revision of every row. ( See the Audit sub-section on this page. )
Basic security automatically extends into a super-system axsys. Its administration is identical to that of a standard configuration.
At this point, AxleBase security becomes complex, but for those who need it, it may actually simplify security. For example, the following may eliminate the complex administration of Microsoft's active directories. ( Do not be concerned if you do not understand the following. It is written for those who are paid to worry about the technical details of security and for advanced DBAs.) AxleBase can establish and manage a VPN for his personal use. The ability is included in every AxleBase instance so that, if called upon to do so, any AxleBase instance can establish his own tunnel. An AxleBase VPN is turned on by the DBA with a single toggle and requires no configuration. Other VPNs that are provided by external hardware and software add tremendously to cost and to operation complexity, and are not needed for this feature. Specifically, the AxleBase VPN needs no middleware servers and bypasses the operating system service. He also uses his embedded network protocols in his VPN to relieve users and hosts of that complex and onerous configuration task. When an AxleBase VPN comes up, all supporting infrastructure will merely continue operation as usual. He can tunnel through any network that can carry his traffic including radio (wireless, cell-phone, etc.) communication. He will tunnel to and from any operating system on which he can run. Because the VPN belongs to a database manager, AxleBase has his own internal VPN server and router. That capability is built into every AxleBase instance. (Security technology adds greatly to his size, but he remains less than a megabyte.) Caveat: It is believed that the deployment of a VPN by the DBA indicates serious intent, to which AxleBase responds in kind. An AxleBase VPN is a verbose heavy-weight and may be expected to double the AxleBase network load. The technology will not be changed to increase its speed or to lessen its weight. Old PCs may respond slowly while running a VPN. This is not intended to compete with VPN specialists. Those who specialize in such things should be expected to build better VPN technology. But whether they do or do not, AxleBase can step up when needed and can do it cheaply and with simplicity.
ODBC is recognized as beneficial for world-wide data exchange needs. Therefore, AxleBase supports the ODBC standard for hosts that use an ODBC driver. However, the security benefits of the AxleBase VPN should be considered before replacing it with ODBC. The AxleBase VPN option might be used even within local networks of large organizations for the communication of highly sensitive data in this age of diminished personal integrity. If the host programmers and developers can support this degree of system abstraction and convolution, then a selectable interface in AxleBase allows his VPN to be used for the ODBC transmissions that drive him. That transforms the host into an ODBC driver.
By intent, AxleBase provides and allows no resource discovery. Also, although he can return SOAP with the SOAP error protocol in response to SQL queries, he refuses queries in the SOAP protocol. Also, he ignores information requests at the SysLink level, which is in compliance with the SysLink protocol.
( Security sub-systems are complex. Consider that fact as you go to sleep tonight if your database manager was built by the open source hordes around the world. AxleBase was built by one God-fearing man who is accountable. )
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ Due to his advanced technologies, concurrency is a more complex topic for AxleBase than it is for standard database managers. So please bear with the unusual delivery of this topic.
When embedded within a multi-client server, the concurrency problem may be lessened tremendously to that of a standard database manager. A multi-client server must have a queuing mechanism to accept multiple client requests. Most of the concurrency issues then become handled by the server's client queuing mechanism so that the clients cannot interfere with each other. The server queues client requests as they come in and presents each sequentially to one or more AxleBase threads for servicing.
Unlike standard database managers, AxleBase and his databases are designed to allow multiple instances and multiple servers to simultaneously use a database. That creates a far more complex situation than is encountered by a single database server. All units operate independently while updating, locking, unlocking, reading, etc. at high speeds. Concurrency problems are thereby increased for all of those AxleBase instances. (Even multiple administrators are not disallowed except by security.) This facet is addressed in the design of AxleBase and in the design of his databases. You will see below that tests have not yet (Hopefully, soon.) produced a failure.
A well designed distributed AxleBase database can withstand concurrency stress as well as can a standard database. In most instances, distribution of an AxleBase database actually makes it more robust.
A super-system axsys increases concurrency stress because it hits a database simultaneously from multiple directions; i.e., the axsys generates its own concurrency. The instantiation of the axsys is done in such a way that it allows the DBA to design around much of this increased problem, but the problem remains and is addressed below.
Concurrency stress testing of AxleBase disregards the normal database server situation because that is elementary. His stress testing concentrates on the more complex simultaneous activity of multiple disconnected systems using a database because each of those systems independently handles all concurrency problems without inter-system communication. All that can be said at this time is that testing of multiple systems that are simultaneously using a database at high speed has not produced a failure. (Please see the Tests page.) But all that was thereby proven is simply that; testing has not produced a failure in the AxleBase lab. The inability to force failure should not be considered a positive result. The lack of failure may be due to the internal safeguards, but it could simply be due to the limited funds for test equipment. A failure must be produced in the AxleBase lab before the concurrency limit can be known. Until a failure is produced, only an estimate can be made. For many instances hitting the same data, it might be as few as twenty or thirty. For a single server running many instances of AxleBase, it could be hundreds or thousands.
Multi-threaded servers are supported. AxleBase handles all of the database functions including local and remote object locking. The server can use multiple AxleBase instances to service multiple inbound client threads because every AxleBase instance operates as though it is sharing a database.
Some internet companies serve millions of rows to millions of customers. That is a lot of data movement, but it would be a very tiny database for AxleBase. AxleBase is engineered to handle vast datasets far larger than those that are usually queried on the internet. Engineering to serve millions of simultaneous users and engineering to manage trillion-row tables with precision and dependability are separate problem domains.
Since a failure has not yet been produced, concurrency failures have been artificially forced under carefully controlled test-bed conditions to observe the results. In all cases, the system reacted graciously to failure, protecting the data, returning error messages to the user, and maintaining operational stability. Again, that was forced failure under rigidly controlled and stepped test-bed conditions to observe the results.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ ( No, this is not a joke. ) The many advanced features in AxleBase were not allowed to become excuses for sloppy programming and excessive interface complexity. The interface was kept as simple as possible. If AxleBase is embedded in a desktop system, then anybody who has used a desktop database manager can use AxleBase. Proof is in the Axon query tool that allows point and click queries. Axon :
If AxleBase is embedded in a database server host, then anybody who has used a standard database server can use AxleBase. Proof is in the various AxleBase demonstrators that allow point and click use of databases.
AxleBase is designed to run on old and simple computers and networks. If the organization knows how to use cheap desktop computers and connect them in a low-end peer-to-peer network, then AxleBase will be happy running on it. The comical thing about it is that AxleBase will then deliver high speed performance. Of course, if the organization wants it, the DBA can run AxleBase on million-dollar computers with fancy disk configurations, special hardware with routed optical networks, and every conceivable hardware complexity. But AxleBase does NOT require it.
Creating a distributed database is about as difficult as notepad. If the DBA wants to build a distributed database, he creates a text file for each table listing storage permissions, and drops them into the database. That is all. AxleBase will handle everything else from then on. (Of course, AxleBase provides a tool with which to do it, but most of us like the simplicity of notepad.) There is certainly complexity in the administration of distributed data objects, their computers, etc., and capable people are required by that fact, but the operation of AxleBase requires little.
Since AxleBase was designed from the ground up to be embedded in whatever an organization may need, he must be embedded. The organization must have access to programming talent. Beginning programmers cannot do it. The biggest requirement is in computer communication. The programmer must understand socket programming or its equivalent, and that can become complex, not in its volume, but in compensating for the ineptitude of the socket builders. The AxleBase interface is just a bunch of programming commands that the programmer will use. Little database knowledge is needed and can be had in consultation with the data professionals. Therefore, an advanced, or possibly intermediate, programmer with a knowledge of communications will be required for the host. However, with all that said, depending on the needs of the organization, the hosts may be small and simple.
There is an area of certain complexity. The administration of the technology in that area should not be attempted by ordinary Database Administrators. Designing, configuring, booting, and administering a super-system axsys is complex. That complexity arises within the very nature of such a system. Furthermore, many features are not covered on this document. AxleBase makes it as simple as possible, but it may require a DBA team of seasoned professionals.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ The world has many powerful software systems that are confined to their single in-house computer system. Many others can be installed on other computers, but are akin to Tinker Toys that require an installation staff of skilled technicians and programmers. Moving or installing one of those powerful software systems is very costly. A packaged software system is identifiable by its ability to be transmitted intact without disruption or degradation for installation on similar computers for immediate operation without special programming. That means that the system can be delivered on disks or across a data connection. Despite his great power, AxleBase leads the industry in packaging. Not only is he packaged, but he fits on a small part of a single CD. A small executable on the CD totally installs the system in a few seconds. AxleBase is then ready for any kind of work on the new computer. But that is not hard to do since his size is less than one megabyte.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ Science projects that are characterized as "Big Data" consumers are plagued by the multitude of incompatible formats in which the data is delivered to them. The problem is currently under study by large organizations because of its seriousness. But AxleBase may have had the answer all along for those who are paying attention. If a file can be red as a text file, then the previously described AxleBase advanced features can obviate many of the problems of file format incompatibility. If, for example, an external file can be red as a text file, then it can be virtualized by AxleBase. Virtualization places the file (virtually) in a standard data table within AxleBase, which allows the external data to be red like any standard database table. The virtualization allows a redefine of the data so that it is presented in the table as needed. Furthermore, the virtualized data can be exported as though it is actually in the table. The export allows an additional metadata redefine. Also, a SQL select query can copy the virtualized data from the virtual table into a standard data table with a redefine. If virtualization is insufficient, then the text file can be imported into a standard internal table that is defined as needed. Additionally, without getting into the details, an AxleBase table can be defined almost as needed. For example, control characters can be redefined. That means, among many other things, that very strange data can be imported or virtualized into a standard AxleBase table. And of course, handling BLOBs such as photos, charts, etc. is so simple for AxleBase that it is not even worth describing. The problem of file format translation is one of many that is already solved by the flexibility of the advanced features in AxleBase.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ AxleBase offers proprietary features that solve the following advanced data acquisition problems. Torrent Technology:
Fluidity:
Dirty Data:
Fault Tolerance:
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
_________________________ AxleBase allows the DBA to set a data return type in each database, if that is desired. Variables for the various protocols, such as text separators, line terminators, etc. can be set if desired. The following return types are available:
The HTML return is an HTML data table that can be inserted directly into an existing web page. AxleBase designs HTML for each requested data return including the generated column header names. The htmlpage setting creates a complete web page containing the data that can be displayed in a browser. Hidden tags are included in the return that the host may replace with page headers and footers. This can be useful when the requestor will insert the page directly into a web site. AxleBase generates schema-based XML for communication with autonomic systems. Each XML header is a schema appropriate to its following XML stream. Schemata are dynamic with each one matching the dataset that is created by its SQL query. Participating systems must read and understand dynamic schemata. To assist humans in interpreting the return, XML tag names use the column names that are created by each query. When SOAP is specified, the SOAP error protocol is allowed to over-ride the AxleBase error protocol to satisfy the SOAP standard. Machine-readable schemata appropriate to each data stream are dynamically created for every SOAP stream header. For security, AxleBase is not discoverable by SOAP. If the database return protocol is not set by the DBA, then the default is used, but each query can specify the protocol for its return if desired. A query can specify its protocol's variables, if desired, that will be used for that query. This can be useful for an unusual individual query, but the purpose is mainly to support the design of automated systems that can fluidly specify returns as needed. The AxleBase design allows its use as an unattended data hub serving the imagination of the organization.
End of the Notable Features section. Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ The term "Big Data" came into vogue after AxleBase was created. It seems to refer to queries that return a lot of data, but usage is rather vague. In any case and regardless, AxleBase can do it. AxleBase uses the industry-standard ANSI-92 SQL query language so your data professionals can use it and so your programmers can build it into your systems without learning a proprietary language. Deviations from the standard are explicitly noted in the "Operation Manual" . This section is primarily for those who are not familiar with mainstream database managers. AxleBase accepts queries against table(s) of any size, and has been tested against tables of up to a hundred Billion rows each, including relational joins of those tables. Query syntax :
The "where" options include equal, less than, greater than, like, in, between, not equal, sounds like, not sounds like, etc. Because the standard INTO clause is wasted on AxleBase-class datasets, the AxleBase INTO clause deviates from the ANSI-92 standard. It creates a new table or external file, and inserts the entire data return into it for further work. Considering the extreme nature of AxleBase, this seemed a better use for the command. ANSI-92 returns into variables, which is far too wimpy for AxleBase-class datasets. After creation, new objects can be queried, joined to other tables, or remain in the database. (AxleBase features are far too numerous to be shown outside the documentation.) APPENDIX is an encapsulator that permits passing non-standard commands and parameters inside a query. It is not ANSI-92 compliant, but assists with administration and usage of some of the advanced AxleBase technology. Some of its features are encrypt, namealias, node, queryid, returnprotocol, row, test, workarea, etc., etc. (AxleBase allows a query to be tested before execution, allows abortion of a running query, and can report the status of a running query.) It can also be used to control super-system operation if the DBA has not configured it as needed. The SQL select query can be extremely complex with many lines of code. The above does not show all of the select options and features, and does not include inserts, updates, etc. The "Operation Manual" for AxleBase contains over a hundred thousand words. ( Additionally, there are a quarter of a million words of programmer guidance inside the code, for a total of 350,000 words. ) Or an AxleBase query can be as simple as "select * from table". As stated elsewhere, AxleBase is designed to be embedded into other systems. The designer of such systems sometimes simplifies SQL queries, as is done in the Axon system. Offering the ultimate in query simplicity, Axon allows point-and-click queries of any AxleBase database, even with table joins. ( If you are an experienced data professional, please skip this to avoid embarrassing me. Having used many database managers, I know that this is a given in serious relational database managers, but new people coming to data management through the back door do not seem to realize it.) Mixed data types seem to be important to big data aficionados. This is a list of data types that AxleBase can manage in any table, and in related tables. The datatype is a more complex term than is obvious, but the following will give an approximate idea.
Notes :
Seasoned database administrators will notice that the list is shorter than those of the big name brands. That is because those systems have more types than are needed. Some of them are designed to increase system speed, such as 19 types of numbers, which is pointless in AxleBase. Therefore, the "Operation Manual" maps sixty-five datatypes of big name brands into the above list. As with datatypes, velocity is a buzzword in big data. AxleBase can support it. In fact, it is ludicrous to even discuss it for what has possibly been the world's fastest database manager since near the turn of the century.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ Important :
Please click this link to load the Conjecture section of the theory document.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ Security :
Three : AxHandle, Axon, and AxServer.
AxHandle :
Axon :
AxServer :
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ None:
Advanced theory, algorithms, techniques, system design, and coding in AxleBase are original work. Obviously, some of it is now pervasive and whether it was developed first in the AxleBase shop is an argument worthy only of lawyers, but it was certainly independently developed there, and seems to have been first noted on the AxleBase web site over the past decade. ( Exceptions:
( Recognition:
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ Updated 28 Mar 2013 Distributed data applications requiring speed and dependability in an unpredictable fluid topology with a heterogeneous composition are currently under study. ( As previously noted, impossible and interesting are engineering synonyms.) AxleBase arose as the result of an intense and prolonged research into the limits of database management systems. Its existence is due to the fun of that research. Relativistic Effects:
Internal Communication:
System Port:
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ 2003 : Begun.
( I make changes in the web site when an error is noticed in this massive, years-long project. AxleBase has served my personal daily needs for decades and still does so in 2021, which causes some updates and corrections to better serve my needs.)
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text.
__________________________________________________ This description page covers features in broad strokes with omission of many interesting details. Even some features are omitted. The "Operation Manual" presents a 150 thousand words of detailed feature descriptions with practical instructions and theory where appropriate. It covers each of the many commands in detail with numerous examples.
Click to return to table of contents at the top. Or press {Alt Left Arrow} to return to previous text. __________________________________________________ |
|
Web site and technology |
|
|
Web site is maintained with Notepad.
|
|