Bangdb - part of app process
The embedded version of the BangDB becomes part of client's process. It comes as library (~450k bytes) linked dynamically (or statically) with the client's program. The db can be used as persistent store or as simple cache
The embedded version of the db is released and available freely under BSD license for download
Bangdb - client server model
The db runs as network service and clients access it over the network. The db as service is implemented using the event driven model which supports many thousands of concurrent connections from clients resulting in very high throughputs for both reads and writes
The db can be configured to run completely in-memory or backed with the perstistent data store on non volatile disk
The client server version of the db is released and available freely under BSD license for download
Bangdb - Elastic BigData Space
This provides the single machine view of the entire data cluster where each node runs an instance of BangDB. The data is partitioned in nothing shared manner with each node running the data services for the appropriate data. The data is replicated for high availability and fault masking.
This model scales lilearly with the number of machine in the grid. The high network churning rate can be tolerated using the model where many machines can leave,join or fail at any given time
The in-memory data grid/Elastic data space will be available for review in Nov 2014
Elastify Once Scale Always
Elasticity on 3D. Data, Transactions and Services
Distributed Computing Platform
Unlock real economic benefits of cloud
Moving to cloud is happening today and it will be norm in coming days. Applications are either moving to public cloud, to privately hosted one or a hybrid one. All virtualized environment provides elasticity in term of infrastructure provisioning resulting in saving in capex and opex in some way. But it's up to the application to exploit the benefits extended to it by the cloud infrastructure. If application inherently is not capable of growing and shrinking elastically depending upon the load then despite the amount of infrastructure that it can get from the virtualized resource pool, it will budge to scale beyond a threshold point.
Here the application elasticity is required in order to achieve continuous and uninterrupted business in the most cost effective manner and the application elasticity remains mostly in realm of the software developer and not with the cloud provider
The Application architecture is the critical element in order to realize the optimum economic and technical benfits of cloud. The various interesting quotes in this regard are as following;
Traditionally, applications have been built for fixed, rigid and per-provisioned infrastructure. It is critical to build a scalable architecture order to take advantages of a scalable infrastructure - AWS Amazon
Applications architectures are not designed to take advantage of cloud's elastic infrastructure resources to maximize ROI, high availability, performance and scale - Forrester, Apr 2011
Architectural issues are a big reason why relatively few business applications have made the jump to cloud - Forrester, Apr 2011
Performance has been the key to the success for many applications. However, few years back when applications used to run in in-premise non virtualized infrastructure, it rarely mattered if the the performance of the application was 10 percent higher or lower, at least not always visible from the cost angle.
With the virtualized environment in place, one can map from performance to cost saving, especially if the application runs on commodity hardware. 10 percent higher performance could result in around 10 percent saving in cost. Hence more than any time before, performance of the key components and the infrastructure becomes one of the key points for the business and it's applications
The use of commodity hardware with SSD is the key going forward for optimizing the cost benefits. To exploit the fact that the cost of RAM, SSD and Hard Disk are placed in decreasing order, it requires more than to just treat SSD as replacement of Hard Disk. A careful design can configure the use of these three in order to optimize the incurred cost for a given elastic requirements of an application. Treating SSD as RAM+ would help us achieve this, and allowing an application to seamlessly use more or less of any of these entity through a knob would be greatly desired. Thus instead of always looking for a extra machine or RAM, we may look for extra SSD