The Case For ZAppDB

ZAppDB was written from the ground up to allow the developer to create server-side (Cloud) RDMS applications that would be easily scalable, much more powerful, and flexible to use. When coupled with ZAppSvr (ZeroPoint Application Server) it is possible to create highly complex projects easily and with far fewer database constraints and related issues.

Our purpose here is to outline the advantages of this system and why it is a break-through product that can be of great worth in creating data driven high performance network services.

Here are a few obvious differences between ZAppDB and SQL databases:

  • Super-scalable, so projects can systematically grow without hitting a hard 'limit'. ZAppDB is a great solution for small or very large projects
    • Avoid the pain of project redesign, if demand exceeds design expectations!
  • Write and Read performance remains the same as table sizes grow
  • No CPU or core limitations or extra charges
    • Inexpensive licenses are 'per instance'
    • Why depend on critical path tools that might soon be orphaned and unsupported?
    • Upgrade your server without having to pay for an expensive license upgrade!
  • Runs completely in memory for high performance
  • Generates dynamic, internally cached views of data, as the data is actually requested by the application
    • Data ordered by the index specification
    • No index tweaking required for maximum performance
    • LRU algorithms are used to remove the least used data if memory needs to be freed up to make way for new data requests
  • Designed for hundreds of concurrent (parallel) requests on a single table or multiple tables at the same time
  • Write through cache management
    • All cached views of data are updated on insert, delete or update operations, so that cache does not need to be reloaded
  • Queries and data write request cycle times are both typically < 1ms. (Read/Write performance depends on the network, memory speed and the size of the data block being returned)
    • Single record write times of <1ms on tables > 250k records. Large numbers of concurrent writes can average much less. From our testing we see gains over SQL of about 40x.
    • Avg read times of ~20us is possible and even less in the case of large numbers of concurrent requests
  • All column data is in string form
  • Hot and Convenient java connector makes life easier
    • Relational navigation within a request data set
      • GetFirst(), GetLast(), GetFirst(num), Get Last(num), GetNext(), GetNext(num), GetPrev(), GetPrev(num), etc.
      • This feature makes it possible to create navigational 'viewport tables' eliminating the downloading tens of thousands of records, and keeps what is displayed as current as possible!
    • Data returns as a String[][] for easy use
  • High efficiency pays
    • In the case of a large service the number of servers required to meet requirements can be reduced dramatically reducing fixed expenses
    • Low demand on system resources allows high performance when running on the same system as the application server. Do it all with one box!
    • Higher service reliabiity due to fewer servers and increased MTBF
  • Built fresh from the ground up for this project, ZAppDB is not just an extension of legacy code, but a fresh approach to improve database development to meet current developer's needs

The last thing a developer wants to do is to design a data driven application only to discover that there is a performance issue forcing an application rewrite. Especially if the rewrite involves circumventing limitations that are built in to the tool set used to develop the original project. This can be a time-consuming and painful process.

An application or web service that works very well in a demo or for a single user may not be suitable when the system is under serious load.


Copyright © 2023, ZeroPoint, LLC.      Questions? Comments? Email Us.