Cloudant Local runs on a cluster of inexpensive servers. If you need to increase database traffic, you just add servers to the cluster, or take them away if database traffic is shrinking. These changes are made without downtime and with Cloudant DevOps tools that make re-partitioning your database easy as the cluster resizes.
If your app manages data that does not fit into tabular rows and columns in a relational database – data like JSON, full-text, media files, etc. – or if you expect a lot of changes to your data model, then Cloudant Local is a better fit than RDBMS. Cloudant Local is not limited by rigid schemas like RDBMSs have; each Cloudant Local database stores a collection of self-describing, variably structured JSON documents.
Multi-data center and data mobility
Many projects replicate data across data centers or between mobile devices in order to push data closer to users so they can access it faster. Cloudant Local automates the difficult problem of distributing and synchronizing changes across replicas of data stored at all locations. In Cloudant Local, all copies of your data are available for reads and writes. On the other hand, most other relational and NoSQL databases can replicate read-only copies of data to multiple locations or devices.
Adaptable deployment options
To handle the influx of massive amounts of data in modern applications, your data layer needs to be in lockstep with your development roadmap. Cloudant Local helps enable flexible deployment options to efficiently manage today’s ever-changing data.
Customer case study
Connio developed an IoT platform managing millions of endpoints without skipping a beat.Connio
Cloudant Local requires a minimum of five (5) machines to create a fully functional Cloudant cluster that ensures 24 x 7 availability. The five machines will consist of a primary load balance, and a recommended failover load balancer. The database itself will run on a minimum of three servers in a cluster, with additional database nodes added as needed for scale.
Cloudant Local runs on the following 64-bit operating systems: Debian, Ubuntu, RHEL, and CentOS. It is a best practice is for all server nodes to run the same OS. See the documentation link for specific supported OS versions.
Database (DB) nodes Minimum requirements: Four (4) cores and eight (8) threads, such as Xeon E3-1270 V2, eight (8) GB of RAM and one (1) gigabit network. Reference specifications: For larger implementations, the minimum requirements are 12 cores and 24 threads, such as dual Xeon E5 2620, 64 GB of RAM, local SSD drives to meet data volume requirements of your usage, and a one (1) gigabit network
Load Balancer (LB) nodes Minimum requirements: Dual core processor and 4 GB RAM, 500 GB local hard drive, and a one (1) gigabit network. Reference specifications: For larger implementations, the minimum requirements are a quad core processors and 8 GB RAM, 1 TB local hard drive, and a one (1) gigabit network
Flexible data storage • Store data as self-describing JSON documents • Excellent for variably- or un-structured data, and for apps with fast-changing data models • Add, change or remove fields without having to redesign the database • Attach any file type to JSON docs
Easy-to-use API and integration • GET, PUT, index and query data via a RESTful JSON API • Define indexes & complex analytics via MapReduce • Access directly from browser or via an app server • Libraries available for dozens of languages • Works with 3rd party read caches and write queues • Integrate with other tools or data sources via REST API, replication, or export/import of JSON and CSV files
Scalable, durable database transactions • Built for mixed read/write, operational workloads • Automatic data partitioning • Multiple copies of data saved on different nodes, data centers or even cloud providers for fault-tolerance • IOQ technology enables custom prioritization of transaction types