Frequently Asked Questions:

Here are the list of general questions submitted by our customers with short answers:

   1) What are minimum hardware requirements to run Clusterpoint DBMS software?

   2) Can I start with a single-server database and then grow it into a cluster database for big data?

   3) What are networking requirements for Clusterpoint servers operating in a cluster?

   4) Can I use Clusterpoint DBMS on Windows Server operating systems platforms?

   5) How much data can be processed by a single Clusterpoint Server cluster node?

   6) Why does Clusterpoint uses a term 'storage' to refer to the database?

   7) What is the difference from a single storage and a cluster storage?

   8) Is it possible to run multiple Clusterpoint Server databases on the same hardware?

   9) How much time do I need to start using Clusterpoint software? 

   10) How Clusterpoint supports ACID transaction model? 

   11) How Clusterpoint differs from other NoSQL database platforms? 

   12) How does Clusterpoint differs from Amazon SimpleDB/DynamoDB cloud databases? 

Answers:

1) What are minimum hardware requirements to run Clusterpoint DBMS software?
There are no specific limitation for hardware choice.  Any off-the-shelf commodity hardware built around Intel / AMD processor architecture can run Clusterpoint DBMS.

For example, a typical hardware configuration:

• A single or a multi-core Intel/AMD 86x architecture processor;
• 32bit- or 64-bit processor architecture;
• at least 1GB RAM, more is better (Clusterpoint effectively uses all available RAM;
• HDD, SDD or a disk array (for HDD it is recommended from 7200 rpm and up as there may be faster indexing with faster disk speed and larger HDD buffers);
• Ethernet 100/1000 Mbps networking port (two ports per server recommended, one can be securely used for remote diagnostics if necessary);
• compatible motherboard;
• a computer case enclosure, a power supply for all equipment parts;
• Uninterruptible power supply (important - if not used, power failures may require longer re-indexing).

Disks may be duplicated in a mirror configuration or arranged into RAID to increase resilience against disk failures.  For a data center use, server hardware in 19" rack systems and external disk arrays can be used as well.

Hardware must be compatible with the underlying operating system providing all necessary drivers for disk and networking subsystems.

The Clusterpoint platform is developed in C/C++ and for each operating system there may be some libraries and dependencies to certain system calls for file and memory management.  We provide customized installations upon customer request. 

2) Can I start with a single-server database and then grow it into a cluster database for big data?
A single hardware server can be used to start the project and then database can incrementally be expanded by adding new servers to create a cluster.  In a clustered setup database is actually stored in distributed way, where its 1/Nth part is stored on its own hardware server (cluster node).  Clusterpoint DBMS software uses total capacity of all servers, their RAM memory and their disk subsystems to store all database data, processes all database transactions, and merges results in a seamless and transparent way.   Clusterpoint Server works as transparent cluster software, and distributes all updates automatically among less frequently used nodes or having less data stored.  

There is no single point of failure, if distributed database is run in multiple cluster nodes environment, any cluster node can serve as a master node for a specific transaction. 

Clusterpoint Manager allows to create and manage clustered databases in this environment centrally, using Web-interface, exactly in the same way as for a single database.  There is no need to partition data at the application software level.  Yet, it is possible using API to address specific cluster nodes for certain update or search operations, which can be convenient if you still require your own application logic partitioning of your databases.

Please note, that Clusterpoint provides tight control over where your data resides, and does not do automatic data volume re-balancing after each new cluster node is being added.  Although the software is using the latest added node for storing more new data than on existing possibly already filled-in nodes, it does not change location of data previously stored.  This is key difference from many key-value stores with automatic re-balancing of data location and all complexity problems arising when it is never known where particular data resides.  High availability is addressed in Clusterpoint architecture through full mirroring of each of cluster nodes, i.e., you can set up clustering in such a way, that every 1/Nth of cluster node will be mirrored to as many mirror cluster nodes as necessary, all mirrors for that particular 1/Nth node equal and automatically synchronized by Clusterpoint Server.   This architecture enables to provide necessary level of control over database configuration and location of data in clustered setup typical for enterprise environments, instead of relying for some automatic mechanism for database hidden replication that customers can not fully control (or sometimes even understand). 

Controlled clustering and database mirroring enables precise performance tuning for Web applications, professionally planning and managing the optimal underlying hardware and network infrastructure against specific application workload requirements.

3) What are networking requirements for Clusterpoint servers operating in a cluster?
If there is a need for more than one server in Clusterpoint DBMS configuration, then high-speed Ethernet switching equipment must be used for connecting all Clusterpoint hardware servers into a cluster setup.  

Please note that it is possible to use Clusterpoint software in a single server configuration, enabling excellent vertical scalability just by using more powerful hardware, multi-core CPUs, faster disks and more GB of RAM. On really cutting-edge hardware you can easily scale up some 5-10 times, but it will cost you top money.  Big-iron hardware and accompanying software is not cheap.

For scaling beyond a single-box hardware and taking advantage of cloud-like inexpensive multiple-server hardware infrastructure, it is recommended to install and run Clusterpoint software in a cluster of networked server nodes each representing relatively modest server hardware and working as a cluster nodes.  For massive clustering you would probably also need touse non-blocking network switching infrastructure, if the system is going to be run as a very fast grid-type database.   

Based on our experience, up to 30-50 or so nodes you can still use commodity network switching equipment and linear Clusterpoint database server networking topology without significant effects on performance.   Any good high through output Gigabit speed network switch or two can accommodate this number of servers in a single switching fabric and still provide efficient performance.

However, if the number of cluster nodes goes beyond 30-50 servers, and database size is so big that it requires to store it into hundreds or even thousands of servers, it is recommended for Clusterpoint software to establish a separate IP address spaces and hierarchical network topology of hardware cluster servers and network switches, connecting all hardware elements in a tree-like 4- or 5-level network, where each level is designed and hard-wired to perform in non-blocking way for machine-to-machine traffic with respect of other levels and directing local traffic only towards top-down network of tree-branches.

Clusterpoint Server software is designed to be architecturally neutral against network topologies.  However, the Clusterpoint Server software which can be downloaded from the Download section, by default is fitting linear network topology model.  

You need to understand that for effective processing of really big data it is simply necessary to eliminate objective cumulative effects of networking delays between large number of cluster nodes, if network topology is linear and every transaction needs to be span across the same level network nodes. Too many linearly networked servers start to produce network delays for interprocess communications within a cluster, while all server data is being transferred from/to the master node, which processes the incoming transaction and reply to the application.  A good rule-of-thumb is that any network caused delays longer than 0,5 seconds is an indicator that linear networking configuration of all cluster hardware servers is approaching its physical signaling limits, and therefore it is recommended to replace linear clustering topology with a tree-like hard-wired hierarchy of cluster nodes for optimal use of Clusterpoint database software.  

To solve this cumulative networking-caused delay problem for machine-to-machine communications, a tree-like network structure currently seems the only practical software engineering solution, providing required sub-second short response times for thousands of machines, where all system works in a concerted way performing search is huge databases.   

In Clusterpoint architecture for each tree-like hierarchy model of interconnected networked servers it is necessary to configure so called 'neighborhood' filters for Clusterpoint database, in such as way that any top-level Clusterpoint Servers forms a 'pool' of required number of servers each connected to a sub-tree of next level servers only, avoiding the need to do any networking with absolute majority of servers (other sub-trees).  

This flexibility of Clusterpoint software with respect of network topology, enables to store and effectively search truly gigantic databases, which span thousands of computers.  In addition, through smart application logic partitioning and using Clusterpoint Information Ranking, it is possible to achieve sub-second and always relevant data retrieval from databases containing billions of objects (such as Web search indexes, large databases in life-sciences etc.) 

For example, in this tree-model with just a 4-level networked hardware hierarchy, where top level can be, for example, 16 servers, and each of those servers would "command" sub-tree of next level 16 servers, total number of effectively working cluster nodes for highly-resilient, 16 times mirrored Clusterpoint database data storage can be easily scaled out up to 65536 servers (!!!), and still deliver  efficient operations.  The reason for this efficiency is eliminated networking delays in a tree-like topology compared to linear one.  In tree-like topology any particular machine-to-machine transaction will have only 3 short network hops among different levels of cluster servers, cumulatively still providing satisfactory short response times for search queries, under 0,2 seconds with disk access at the lowest 4th level.  Even if 1st or top level 16 servers are used for pure application level load balancing, and middle tier 2-,3-level servers only for map-reduce type clustering functionality, with real disk storage database access only at the last 4th level, there is efficiently working overall system capable of delivering lightning fast searches in huge databases in Clusterpoint architecture.  For example, if we model a large scale Internet search service, we can safely assume that each relatively modest server (16GB RAM, 1TB disk) can effectively process search within some 5 million web pages stored per hardware machine.  Since our top-down network design enables to efficiently run a cluster database with 4096 servers at the lowest 4th level, mirrored 16 times for search application load balancing, then the total capacity of the system would allow efficiently, with predictable sub-second response times, search more than 20 billion Web pages!  Taking advantages of latest SSD technologies at the lowest data storage level, query response times for Clusterpoint databases (Internet-style free format queries with results snippets) can be reduced to low sub-seconds (0,1-0,2 seconds per output web page).

When top-level parts of a above illustrated clustered database are separated geographically in different locations, effectively implementing database mirroring into multiple datacenter locations, high-availability, highly-resilient, high-performance database system is created, which can be efficiently operated with a bit of DNS and application load balancing, so that an Internet service is never lost completely and even is not experiencing any noticeable downtime by customers.

4) Can I use Clusterpoint Server DBMS on Windows Server operating systems platforms?
You can do it using virtualization software and Clusterpoint Server DBMS system.  It is a complete software package, which can be run on any Windows Server or Windows 2000/XP/Vista/Windows7 computer if VMware server virtualization software if installed. 

If there is no virtualization software installed, the Clusterpoint DBMS can be run into a VMware Player environment from VMware acting as a virtual database appliance.  

Custom configuration for Clusterpoint DBMS is created for each solution, depending on business needs (memory, disk space, clustering setup) and delivered to customer as necessary.

Please contact us on Clusterpoint Support and we will deliver a virtual appliance of your configuration under any license which we offer.

Please note, that under Windows virtual appliance software performance of Clusterpoint Server database platform will be slightly slower, about 20%-30% slower than run natively on Linux/MacOS/FreeBSD.

For customers, who, after test drive and evaluation of our software, may be seriously interested to use native port of Clusterpoint Software to Windows platform under Enterprise License, we are ready to make such as software source code native porting to Windows OS in very short time.  As the software is developed in C/C++, it can be quickly compiled for Windows, upon customer requests.  Please let us know about your interest by sending us an email message to Clusterpoint Support. 

5) How much data can be processed by a single Clusterpoint Server cluster node?
To calculate number of servers needed to run a large scale clustered database, one must determine how many data can be cost-effectively processed by a single hardware server.  This is usually an issue of finding the compromise among the budget, available hardware and total cost of system operations (administration and hosting costs).

For a typical inexpensive entry-level commodity off-the-shelf hardware configurations based on Intel processor architecture, 4GB RAM, 160GB SATA disk, it is possible to effectively store, access and search about 4-5 million XML web/office size documents per single Clusterpoint Server  data storage, where average size of a document which is relevant for indexing is about 20-50 Kilobytes.  This is typical size for an office document or Web page, taking its all content text size and meta data.  To be on safe side, recommended amount of hardware servers may be calculated with an assumption of storing about 2 million Web page or office documents per single cluster node.  Number of cluster nodes usually gives you number of hardware servers needed.

When the size of a database record is smaller, the number of database objects per single Clusterpoint storage can be many times larger.  For example, for banking account payments database, from 20 up to 50 million records can be efficiently stored, maintained and searched per single server.

When using 64bit architecture version of operating system and more powerful hardware amount of data per single node can be further scaled up. 

The same rule applies when 64bit hardware servers are used to run multiple instances of 32-bit Clusterpoint DBMS software per same hardware cluster node.

So you can see, that in order to tell you the best Clusterpoint DBMS cluster configuration, there are many factors to consider. 

With appropriate hardware you can easily scale up the same database from 4-5 millions objects per entry level hardware to some 50-100 million objects per powerful server box with multiple processors and disk-array per cluster node.

You are welcome to inform us about your business need or problem for big data solutions, and we will kindly provide you with our free professional consulting and advice how to best apply Clusterpoint DBMS technology to solve your problems. Please describe shortly your application needs, size of your database, and key problems you would like to address using Clusterpoint Software, and we would suggest the best hardware setup and Clusterpoint software configuration.  

Please do not hesitate to use our Clusterpoint Support. 

6) Why does Clusterpoint uses a term 'storage' to refer to the database?
To avoid confusion with relational database architecture concepts and make things very simple we decided to use a term  'storage' for a database storage. 

Clusterpoint Server is a unique key-based data store platform.  Data objects (XML or JSON formatted) are being written (stored) to the Clusterpoint DBMS, or read from it, or searched for using just those unique strings identifying data objects in a storage (keys). Clusterpoint DBMS software essentially operates as a storage and search platform software for any custom XML / JSON data objects, whatever their internal structure is.

So a single uniquely named 'storage' actually is the 'database' in Clusterpoint terminology.  It is just a collection of XML / JSON data objects, stored, managed and searched under the same name database, each uniquely identified by a key (a key must be unique even if cluster database is running on multiple servers, e.g., a key can be a web link, social security number, bank account, email etc.)

We use the term 'storage' instead of a term 'database' also for emphasizing the fact that Clusterpoint Server works on actual undivided data store objects automatically indexing entire data content.  There is no need to manage multiple database tables, columns, indexes and relations in the Clusterpoint DBMS.   Both terms - a 'database and a 'storage' - have the same usage and meaning in our architecture.

A single Clusterpoint storage can effectively manage multiple different structure objects in XML or JSON, so in essence the name 'storage' fits this our architecture as well as the traditional term 'database'. 

In each storage data objects can be any custom schema-less XML / JSON objects, same type of structure or multiple different types of structures.  For example, if you wish to build an entire application server with few simple data structures: you can store 4 different types of data objects: user accounts, organization profiles, application rights roles and groups of roles under the single storage 'accounts' and use that storage to effectively and securely manage your own application server functionality for registered users of your Internet service. With only 4 types of different XML objects in storage 'accounts', you can take advantage of building and running your own application server functionality, in your own preferred programming environment, without costly integration efforts with some 3rd party application server tools.  Add some application server middle ware that writes into extra storages 'sessions', 'log' and 'reporting', each with easily understandable, flexible XML data structure andvoila !  You have an industry standard, massively scalable in clusters, small and lean application server framework in your own preferred programming language, ready to run the most demanding transactional applications: all with only a Clusterpoint Server database as the data storage.  Please note that this our sample use case application would also be totally cross-platform solution, with open user-authorization and session-ticketing data storage, where user accounts, access rights and user sessions information can be freely accessed and re-used by variety of other your applications, developed in totally different platforms. This illustrates how simplified all-XML database structure application can increase productivity of your business.

Each Clusterpoint storage represents all data content (all documents stored),  all index files automatically created by Clusterpoint Software, particular storage configuration files and transaction and error log files.  To make things even more simple, all those files are located in a single directory at the physical file system level - under the same directory name of the 'storage' which is used in API to access, modify or search a particular storage.  This simplified database file system organization reduces confusion and make database administration tasks on system level very easy and understandable even for novice system administrators.  It is also absolutely easy to backup / restore the database in case of problems, using just any operating system tools for file management.

Each named storage is serviced by its own instance of Clusterpoint Server DBMS software per each cluster node, loaded into a computer RAM.  Clusterpoint software is used to manage storages, handle multiple storages configured to run as a cluster database, perform cluster-wide database operations, perform indexing and search, and do many other functionalities, that a particular storage (database) requires.  There is no need to program clustering, key-sharding, data distribution algorithms and search sorting algorithms in customer application software.  For any application a Clusterpoint storage is working just as a single logical database, no matter if the database is actually running as a single-server storage or a clustered storage spanning multiple hardware servers.

7) What is the difference from a single storage and a cluster storage?
Clusterpoint DBMS software platform is designed to operate as a distributed or grid database when configured to run across multiple networked servers.  Clustering is configured, where any uniquely named storage (of the same name) can be configured to run in the striped (distributed) configuration or mirror configuration with other same name storage across the cluster of multiple hardware servers in Clusterpoint DBMS architecture.  For example, to create a cluster database storage, system administrator can configure it manually through system configuration files or using web-based Clusterpoint Manager application.  Clusterpoint Manager application is used to manage all storages in a distributed environment, be it run on a single server, or split across the network of multiple hardware nodes. Clusterpoint software architecture scales from a single server to as large number of cluster servers as necessary.

Initially administrator can create a single named storage on a single cluster server, then add new storages with the same name, located on other hardware servers, and configuring all created storages with the same name to work as a cluster storage throughout the entire hardware cluster.  For example, a storage 'peoplebook' can be created on Server1, Server2 and Server3 and configured to run as a cluster storage of the same name 'peoplebook'.  Whenever a customer application software will perform access to the cluster storage, Clusterpoint Server software take care about the fact that data is actually distributed on 3 servers in a cluster, i.a., all clustering issues, including cluster-wide search and updates integrity will be responsibility of Clusterpoint Server.  From the application point of view there is no differences: the application software will always 'see' a single logical named storage called 'peoplebook' and will operated on it as if a single database is accessed.

In other words, clustering is mainly a software and network configuration issue in the Clusterpoint database platform architecture.  There is no difference in physical data format between a single storage and a cluster storage database, all physical file formats are the same in Clusterpoint DBMS.   Only 1/Nth of database objects are stored on Nth cluster node, and Clusterpoint Software will do all database and search operations behind the scenes.  Moreover, in Clusterpoint architecture each 1/Nth of cluster node can be accessed and operated separately as a single storage, without involving clustering functionality, so that specific applications requiring their own key-sharding based data location algorithms can work with their datasets in deterministic manner, for example, precisely planning each update location and short response times, even if they are running large Internet services with millions of users.  All cluster nodes can still work as a single searchable database for search functionality when accessed though Clusterpoint API as a cluster storage.

This design concept simplifies a number of database administration tasks.  For example, a system administration, such as backup/restore operations for a Clusterpoint distributed database, requires only a basic file and directory copying knowledge.  Administrators can have a free choice to perform backups for all cluster hardware nodes, backing up parts of the databases, or they can create and run any number of mirrored copies of all cluster nodes, for example, by locating mirrored copies for 1/Nth of each cluster node into other datacenter.  

8) Is it possible to run multiple Clusterpoint Server databases on the same hardware?
When the computer has more RAM, i.e., 16GB or 32GB RAM, then multiple large database storages can be run in parallel on the same computer, containing as much data as RAM and disk space allow for effective and fast processing. 

If you run many different Clusterpoint storages per single hardware server, each storage will be run as completely independent Clusterpoint Server instances, protected in its own memory space, and fully protected from other server software instances and from other applications.   This is ideal setup and creates a sort of an database virtualization environment without special virtualization software.   Each Clusterpoint Server instance in the computer RAM serves only its own particular storage (database), with its own users and access rights.

It is possible to use all available RAM also in a different way, using virtualization software and external disk arrays.  When configuring the Clusterpoint DBMS to run 2 or more (i.e., 4, 8) logical cluster nodes of the same storage per single server - each by its own virtual environment, a complete large scale database data can be stored and processed effectively by a single hardware server.  This configuration is also useful for prototype testing, load sharing and many other purposes. 

9) How much time do I need to start using Clusterpoint software?

A couple of hours.  Our API is really simple, it nearly works as a simplified key-based data store for storing, accessing and searching any XML / JSON data objects of arbitrary internal data structure.   Please see Clusterpoint API.

Clusterpoint DBMS software can be downloaded for free.  We are providing Clusterpoint Evaluation License for our potential customers requiring full-featured enterprise clustering-enabled software to test drive and evaluate for 30-days at no charge.  Please fill in a Registration form and submit to us with your valid email, install the software and send us your server ID (generated by installation) and we will send to your email your license key.  With this license key you can activate the Clusterpoint DBMS software.

You are welcome to contact us over email or Skype on Clusterpoint Support to discuss your business needs and requirements prior to starting to use our software. 

10) How Clusterpoint supports ACID transaction model?
Clusterpoint DBMS does not behave like a relational database, and strongly speaking can not be directly compared to ACID model principles originated from legacy multi-table SQL world.  Yet we follow those principle where they are applicable to our document-centric database model.  

In computer science, ACID model (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably. In the context of databases, a single logical operation on the data is called a transaction.

Here is how Clusterpoint Server supports ACID model:

• Atomicity: Clusterpoint DBMS database modifications follow an "all or nothing" rule. Each transaction is atomic: there are no parts of information objects stored into separate tables.  Each data object is a complete and undivided XML / JSON document.   Database  management system maintains the atomic nature of transactions in spite of any application, DBMS (Database Management System), operating system or hardware failure: either writing transaction into storage or returning error to user application.  Any XML / JSON document transfer is not subdivided and is being processed in its entirety or not at all.  In Clusterpoint architecture users do not have to worry about the effect of incomplete transactions: database objects are not "sharded" in parts among different tables or hardware servers;  In most cases applications would not need to do even low-level locking with transaction begin/commit/rollback programming, which is routine for multi-table application software systems in SQL.  We also provide API level mechanism to control XML-document locks at low level; yet usage of lock system seems to be unnecessary for most use cases where the right Clusterpoint database design and update procedure is followed by application developers, taking advantage of XML / JSON data objects completeness and our database model simplicity;
• Consistency: programming radically simplified compared to SQL world.  The consistency property ensures that any transaction the database performs will take it from one consistent state to another. Consistency states that only valid data will be written to the database.  With undivided database objects locked for updates, application can fully control consistency of updates between any number of documents, or not write them into the database storage at all.  E.g. multiple documents can be updated per single database update transaction, returning error and previous database state of any one of them fails the atomic "packaged" transaction;
• Isolation: with application controlled locking for complete and undivided XML / JSON documents, other operations cannot access data that has been modified during a transaction that has not yet completed. All update transaction are queued and executed concurrently and remain unaware of other concurrently executing transactions, waiting for the completion of another transaction that has modified data that the waiting transaction requires;
• Durability: Clusterpoint DBMS and its index can reliably recover the committed transaction updates against any kind of system failure (hardware or software). If written on disk in the Document Repository, any XML / JSON document after customer has been notified of a transaction's success will not be lost, surviving system failure, and when servers operations are restored, will be indexed from Document Repository into Clusterpoint Index. For multiple mirrored copies of a database, Clusterpoint DBMS also provides durability resilience against equipment failure.  It is automatically performing latest updates synchronization among all cluster database nodes configured to operate as same database mirrors.  The greater number of mirror servers running the same copy of customer database, the higher level of service availability and better database integrity, reducing probability of catastrophic failure of all mirror servers at once.  Practice shows that 3 mirrored servers running 3 copies of the same Clusterpoint storage (database) in parallel are more than enough to reduce risk to acceptable low probability figures in most business cases.  It also can triple database access performance: all 3 servers can be used for workload sharing.

11) How Clusterpoint differs from other NoSQL database platforms?

Here is how Clusterpoint Server differs from other NoSQL database platforms:

• Simplicity in use, simplicity in database design and simplicity of operations
• It is a server based database platform, supporting classic multi-tier client-server transaction processing architecture
• Generic multi-master clustering, with no single point of failure architecture
• No key-sharding required for data storage clustering
• Full ACID transactional integrity option (i.e. no compromise on database consistency)
• Real-time database updates, search and retrieval of results (including real-time full text search index updates)
• Functionality is focused on search, key value for document-oriented XML databases
• Unique database Information ranking for relevancy solves database scalability and performance problems in massively distributed cloud database architecture
• There is no up-front constraints and limitations on data ingestion. You don’t need to know or decide anything about your data model before you load your XML / JSON documents it into Clusterpoint DBMS.
• Clusterpoint is data structure agnostic database platform: unlimited schema (or no schema)
• Clusterpoint is automatically indexing every piece of text and document structure upon ingestion while maintaining MBs/sec ingestion rates (typically above 5MB / sec)
• Delivers guaranteed sub-second search speed (typically < 0,2 sec.) for complex database queries, from databases of any size and structure, without performance loss characteristic to SQL or XQuery databases
• Clusterpoint is leveraging document structure for targeted search and retrieval
• Clusterpoint is delivering any level of document granularity at search, data retrieval and for updates
• Enterprise class system administration tools are packaged as standard (including SNMP agent support)
• Clustering in cloud architecture support out-of-the-box, no extra software needed
• World wide 7×24 technical support, a key requirements for production environment in enterprise database systems

12) How does Clusterpoint differs from Amazon SimpleDB/DynamoDB cloud databases? 

At first perception Clusterpoint API may look very similar to Amazon AWS database API.  Clusterpoint data model is also based on the same very simple concept: unique key based database storage of any schema-free content, similarly to that of Amazon concept.  In fact,   any database application migration from Amazon cloud database to Clusterpoint is nearly effortless, due to this concept similarity.

Yet Clusterpoint Server software is a hybrid system combining distributed data storage, clustering and enterprise search functionality, representing a full-fledged server based DBMS platform with much more data management features.  In particular, Clusterpoint API search is orders of magnitude more powerful and delivers rich enterprise search functionality that Amazon lacks.  

Clusterpoint is not a simple key-value data store like both Amazon databases either: Clusterpoint works with internal customer XML / JSON structure similarly to SQL at data retrieval, satisfying nearly all database use cases for those customers who would still like to have structured database access.  In particular, Clusterpoint is far more powerful database solution for those customers who need combined structured and unstructured data handling functionality, where Clusterpoint excels.

Clusterpoint API also provides wider end-user functionality for web applications used by database developers.  There are more than 160 developers options for database functionality in Clusterpoint, including faceted search, geo-location search, auto-complete, results snippets, stemming, multiple index tuning options etc.

Another crucial difference from Amazon SimpleDB/DynamoDB is that Clusterpoint DBMS software can be downloaded and used to operate in private clouds, whereas Amazon is providing public cloud access with shared resources among multiple customers.  As soon as number of data objects stored into Amazon cloud reach millions, Clusterpoint DBMS software licensing for private cloud use cases becomes cost-efficient and pays back in 6-9 months time.

Please note that is is possible to add Clusterpoint functionality to any Amazon database in straightforward and easy way, where Clusterpoint can take care about all database search , while data objects can be still stored in Amazon SimpleDB/DynamoDB infrastructure.   Please contact us with this extra Amazon cloud database compatibility optionsending us an email to Clusterpoint Support, and we can provide you with access to Amazon hosted Clusterpoint database instance for simple and easy no-cost test-driving of this option, along with our instructions how to configure Clusterpoint DBMS to use Amazon SimpleDB / DynamoDB as a data storage.

FREE and Premium Support Options

Basic customer support over email is free of charge, just send an email to Clusterpoint Support.  

We also provide subscription based Premium Technical Support services where you have to choose one of the pre-packaged Premium Technical Support Packages.

Please read more about our FREE and Premium Technical Support Services in Technical Support section.