Linear Ranking Scalability in Clusters
There is another great advantage to design and apply your own customized Clusterpoint Information Ranking to your database XML structure and documents: cost-effectiveness for a database management. When Information Ranking is applied, the unique technical design of the Clusterpoint Index allows you to organize highly distributed database storage in a multi-server cluster environment using commodity hardware components. Clusterpoint DBMS handles total data volume in a scalable way where each cluster node runs its own relatively small part of the database at extremely high speed. The system works mostly on pre-sorted data which also minimizes disk access needs. In essence, your custom Information Ranking rules applied to your own database create your own custom Clusterpoint Index, organized on disk level for a sequential disk access per cluster node, and optimized for multiple CPUs and multi-core CPU architectures.
Clusterpoint Index organization requires only few disk reads per each search query term per cluster node vs multi-megabyte index file handling, what legacy SQL systems require for fast data search.
Individually taken, each cluster node performs just few disk input/output operations per each search query term, which for 1/Nth part of the database on a given hardware can be nearly instant, compared to relational SQL database search. In Clusterpoint architecture any queries are performed in parallel on all cluster nodes and search results are automatically merged by the Clusterpoint DBMS software, applying the same information ranking rules to the final result set, which are implemented at every database partial index, stored and managed on every cluster node. Technically Clusterpoint Server core database software was engineered in C/C++ and delivers maximum performance optimized for contemporary hardware and networking architecture, using this ranking-based method for extremely fast data access and filtering in this massively scalable distributed database architecture.
Below is illustrated a sample database setup in simplified 3-cluster
node way, what happens on a technical level in a cluster database when
a customer application issues a search query and Clusterpoint Server
software processes it.
The node which receives the query, copies the query to its all other
cluster nodes (about 1Kb request), and each cluster node will perform
search in their local parts of the total database storage. As all the
database information is ranked and sequentially ordered on disk access
level, then for each query term there may be only few kilobytes disk
sectors read on each cluster node. Disk I/O workload depends also on
the number of results, that application requested to show the end user
in web application environment. Usually it is up to 1000 result items
maximum, which makes sense in the web model. When all matching XML
documents are found, their IDs and other requested data fields, are
transferred back to the node, which requested the cluster-wide search.
Replies also are relatively small data packages (around 20Kb), and are
almost instantly transferred over the network back to the entry point
cluster server. The server merges the final result set, again using
the same Information Ranking principles, that customer defined with
Document Policy configuration file.
With this Clusterpoint DBMS engineered software architecture seemingly
complex data retrieval transactions in a cluster happens at lightning
fast speed, as there is no need to read and process from disks
hundreds of megabytes of index files like in legacy SQL systems, no
need to massively sort data during each search query, and no need to
transfer many megabytes of data over the network links, even if total
number of possible search hits runs into millions.As a result you have
an instantly responsive database, where you can search with an easy to
use Internet-style full text (ad hoc) queries, and get the most
relevant data sorted upfront nearly without any wait time.
Please note that above illustration is a simplification for ranked index concept explanation purposes only. Actually the Clusterpoint database core engine software mechanism has been engineered with more complex logic: with disk data memory caching, customizable pre-reads for multi-page browsing support, reading ahead some longer data sequences, and with expectation of multi-page browsing, which are cached then, and do not require any disk read at all during the following next page query transaction.
