Democracy, as a system, is completely dependent on communication, to the extent that when communication breaks down, so does the democratic process. In order for a group of people to participate equally in democracy, they must necessarily share a communication platform, where they can share not just facts, but also views and opinions. Small wonder then, that free speech is prized and cherished by all democracies, and coveted by citizens of almost all countries that are yet to become  democracies.

One of the fundamental requirements of free speech and participation in democracy is the availability of a free, open medium and platform of communication that is equally accessible by all members of the democratic community. Almost every culture in the world has a concept of a central community gathering place, where people gather after a day’s work, to talk and share information.

In India, this is typically the village chaupal, in West Kalimantan (erstwhile Borneo), Indonesia, it’s called a ruai. In Afghanistan, it may be called a chaikhana. These community structures have traditionally provided the common platform and free medium for communication.

This type of platform is structured like a circle, and the free medium is air. In a circular structure, everyone has an equal say, because everyone has equal access to the medium and equal reach to every other member of the platform. No special equipment is required to use this medium; ears and a mouth will typically suffice. These structures provided a way for people to voice their opinion, share their concerns and find solutions to conflict through dialogue.

After the industrial revolution and the dawn of the corporation, mass media began to play this role in people’s lives. Newspapers, radio and television became the new media that people used. These media had a much wider reach and they seemed like the perfect democratic tool. However, these media have a structural problem that prevents them from being truly democratic. By virtue of corporate and editorial hierarchy, these media are structured like a triangle (Figure 1).

Figure 1: Media communication

News, in this model, travels downwards from an elite minority that determines what content is “newsworthy” to the community. The community typically cannot relate the incoming news to their own lives, and either becomes disenfranchised by virtue of lack of representation, or assumes the media version of facts to be true, and that they themselves are an anomaly. At the very least, this influences their participation in democracy, and at worst, they are rendered voiceless in that most fundamental democratic process — debate.

This hierarchical model of modern commercial media requires profits for the media organisation to continue to run. This means that news needs to sell. If a newspaper cannot generate advertising revenue, it will soon shut down. Obviously, with profit as the first imperative, relevance of the content to the community and their feedback must become secondary. Moreover, there is an incentive in preventing communication technology from reaching its true potential. For example, if community radio became fully deregulated, would commercial radio or, for that matter, television, stand a chance?

This skewed set of incentives, and the resulting policies and actions, has led to several communities across the world, particularly in the developing world, becoming alienated and disenfranchised with mainstream society. These communities are particularly susceptible to coercion and this might partly explain the escalating violence in the world today.

This conundrum should be quite familiar to open source enthusiasts, since the basic principles involved are much the same as the ones in the open source vs closed source software debate. To draw a parallel from The Cathedral And The Bazaar, mainstream media follows the cathedral model, while community platforms are more like bazaars. Both paradigms have their value and importance in the structure of society at large. However, in the context of media, the cathedral or top-down model appears to have reached its limits of effectiveness — and, in my opinion, has passed the point of diminishing returns.

The growth of user-generated content on the Internet over the last decade is a clear indicator that as connectivity improves, people are increasingly eager to directly voice their opinions and concerns without the need of mainstream media as an intermediary, particularly since in the real world, no intermediary is perfectly impartial.

The developing world

In the developing world, this uprising of citizen media has been stunted by the uneven distribution of resources, such as infrastructure, connectivity and literacy. While connectivity in the developed world has allowed the blogosphere to become a political force to contend with, most developing countries have an Internet penetration of less than 10 per cent, typically concentrated in urban areas.

Even where connectivity exists, the vast majority of users are only just starting to view the Internet as anything more than email and instant messaging. In many of these countries, even as economies have opened up and globalisation has settled in, entire communities are still disconnected from the rest of the world, primarily because they do not represent a market segment worthy of media representation.

Mainstream media in these countries typically focus on urban issues that relate to economic and political decision makers, rather than the vox populi.

In several of these countries, however, innovation is now taking place to bridge this gap by other means. While Internet penetration remains low, the use of mobile phones is a different story altogether. Most of the developing world has far outpaced the developed world in terms of mobile phone adoption and versatility of usage. Even in places where people earn less than a dollar a day, cell phones are ubiquitous. A medium that uses voice, the oldest mode of communication known to man, amplified by several orders of magnitude, so as to cover unimaginable distances, is as irresistible to a Gond tribal in Chhattisgarh, India, as it is to a street food vendor in Jakarta, Indonesia.

Recognising the potential of this medium, several groups are now actively engaged in developing technology to allow people to use their voice to connect themselves and their communities to the rest of the world. One of the first tools of this new age of innovation is the audio portal.

An audio portal?

An audio portal (Figure 2) is essentially a website with a lot of audio content that can be accessed both through the Web as well as by phone.

Figure 2: An audio portal

While the Web interface is usually like a blog, the phone interface is an IVR (Interactive Voice Response) system, where users press keys to navigate through menus and content. In more advanced IVR systems, voice recognition may be used, though this is still limited to the well-documented accents of the English language. The Web interface is very similar to a blog, and several audio portals do use the blog layout.

Behind the scenes, the platform will also provide an interface to manage posts. Early implementations of audio portals tended to rely on specialised moderation consoles, which have media-previewing capabilities as well as functionality for moderators to add metadata, such as a summary and title, to the content to make it friendlier to users on the Web.

Users will typically call the IVR interface to record and listen to content using their cell phones, while Web users will access the website interface to listen to the audio posts using a browser, and leave comments in text, which then may or may not be converted to audio using a text-to-speech system.

People who own the latest Android or iPhone may find the idea of an IVR interface to browse content somewhat counter-intuitive, since it makes no sense to call in and scroll through a set of menus, particularly with an irritatingly monotonic voice rattling out instructions all the time, when you can simply open the Web page on your cell phone’s browser, and read.

The graph in Figure 3 may help clarify why a purely visual interface is not adequate to reach the majority of the world.

Figure 3: Cell phone and broadband users

The percentage of Internet users, even among the mobile phone users of the world, is a fraction of the percentage of people using their phones purely for voice and SMS. While mobile Internet use is, and will continue to be, on the rise, the bulk of the world will continue to be on voice for some time to come.

This is also historically consistent, since most societies have far stronger oral traditions than written ones. Voice captures much more than simply language. Tone, quality, emotion are all interwoven in the spoken word. If a picture is worth a thousand written words, then a spoken word counts for at least a few hundred… not to mention that drawing an attractive picture takes considerably more skill than speaking!

What makes mobile phones particularly attractive as a medium, though, is the two-way nature of the medium. With radio and television, though the reach may be much wider than mobile phones, the ability to respond immediately to what you hear or see — on the same platform, at the same level as the source, which is extremely valuable in fostering dialogue — is missing.

The audio portal concept caters to every cell phone, whether mass-market or smartphone equally, which works very well to level the platform. Most importantly, audio portals use technology, skills and other resources that are available now, as opposed to those that require extensive “capacity building” exercises. This is probably the reason why audio portals, as a tool, find more favour with grassroots workers and members of the community, rather than with technology evangelists and academia.

The technology

Audio portals utilise relatively simple technology, most of which has been around in the open source world for some time. An audio portal will typically consist of a phone interface (either fixed-line or mobile), connected to a content-management system (usually a database) and a Web front-end, via an IVR running on a soft switch or software PBX system. Two examples of audio portal platforms are Swara and FreedomFone.

Swara

Swara is an open source project, originally written as a research project by students and professors at MIT to augment the outreach and activities of CGNet, a people’s discussion group working with indigenous communities in central India. CGNet was started by veteran journalist Shubhranshu Choudhary, who returned to Central India, where he grew up, to find it torn by violence. Probing to find the reason for the conflict, he quickly realised that open, accessible community media would be a key component of any solution to the conflict. Given that Internet penetration in the region is less than 1 per cent, and community radio is limited by regulation, the next best medium for a community platform was the mobile phone.

The first pilot of Swara was deployed in Bengaluru for use by indigenous communities in Chhattisgarh and neighbouring states in February 2010. Today, the pilot receives over 300 calls a day, and the team is working on building the platform out as an open source project for deployment in other locations. The first replica of the project went live in Indonesia in December 2011.

Swara uses a combination of the Asterisk PBX system in combination with the LoudBlog audio blogging platform, with the integration written in Python. The tested interfaces are GSM gateways (Topex Mobilink, etc) and fixed lines (PRI/BRI) using a Digium telephony card.

FreedomFone

FreedomFone was developed by Alberto Escudero Pascual and Louise Berthilson of IT46, a Swedish IT consultancy, for the Kubatana Trust in Zimbabwe. It was created for many of the same reasons as Swara was developed in India, i.e., lack of impartial and open commercial media, and the need for local and community-level reporting. The FreedomFone pilot, a weekly audio magazine called Inzwa, has been running in Zimbabwe since July 2009, and received over 2,500 calls between July and September 2009. FreedomFone’s team is also working on developing the platform as a user-friendly DIY IVR kit, and is keen on replicating the model in other areas.

FreedomFone uses the FreeSWITCH soft switch to interface with telephony devices such as the Mobigater and Office Router GSM gateways. The content management system is written in CakePHP, and FreedomFone additionally uses the Cepstral speech synthesis system for text-to-speech conversions. The stated objective is to create a purely phone-accessible platform.

Deployment 101

Both platforms have an almost identical design, as would most audio portal software. This is almost analogous to how traditional websites are built, with the choice of platform being similar to the choice between different Web frameworks. Just as you will find lots of different opinions and preferences for Web platforms among Web designers, you will find that the few implementers of audio portals are just as varied in their preferences for platforms. This usually depends on which platform the implementer is most familiar with — and if you are implementing your own, one is essentially as good as the other.

The key question, irrespective of which platform you use, is one of deployment strategy. At present, most implementations of audio portals as community media platforms are centralised instances deployed by a single organisation or group, with a specific agenda (such as news, healthcare or governance).

Centralised function-oriented deployment

Centralised, function-oriented deployments require content of a certain quality and, as a result, must usually be moderated. Speech-recognition technology, particularly in the area of automatic transcription, is still a far cry from being very accurate. As a result, moderating a function-specific audio portal is still a manual job, for the most part.

Typically, audio portal moderators will need to listen to each message and summarise and/or transcribe it. Beyond transcription, there may be more work to do to improve the quality of the content for the specific purpose of the deployment, like sound quality clean-ups and edits, fact verification (if journalism is the function, for example) and categorisation. All of this work is further exacerbated in a centralised deployment, since all incoming calls come to the same central hub (see Figure 4).

Figure 4: Centralised deployments

In India, and other countries where long-distance call charges are higher than local call charges, centralised platforms also suffer from an added cost element, since all callers must call the central number, regardless of their own locations.

Hyperlocal deployments

An alternative model is a hyperlocal community-oriented one. In this model, an instance of the platform is deployed at the community level and maintained by community members. Such community-level audio portals could be used as voice-based bulletin boards. By managing the size of the user base, and ensuring a manageable user adoption rate by limiting publicity to word of mouth, communities could eliminate the need for moderation by making sure everyone on the platform was known by the others and therefore accountable to the community.

Several communities can then choose to link their platforms, either by sharing content, or by simply listening to each other. This will eventually lead to an organically expanding network, where people can choose which deployments they want to subscribe to, much in the same way as Internet users subscribe to different forums and websites. This would also ease the burden on centralised deployments already in existence, since they could then simply trawl the community bulletin boards for usable content, rather than filter out unusable content on their own incoming stream. As you can see from Figure 5, the hyperlocal model offers more avenues for collaboration and the cross-fertilisation of ideas between communities than the centralised model.

Figure 5: The advantage of hyperlocal deployments

A word of caution: This approach is still experimental, and needs several more deployments before it can be considered a best practice. However, for communities interested in improving their information access and level of participation in mainstream society, this is a very worthwhile experiment to take on. Both systems described here can be installed on a mid-range notebook computer.

The software is all open source and free for non-commercial use. Mobile interfaces like GSM gateways and mobile ATAs are relatively cheap — a Matrix SETU ATA 211G would cost roughly US$ 120, and the Mobigater is priced at about US$ 50. The total cost of setting up a local IVR installation and running it through a year, including the cost of connectivity, is typically less than US$ 200 a year.

Of course, the most important thing to remember while setting up an alternative communication platform is that while technology will certainly provide the tools, the key to success is to build a strong community around your platform, and quickly demonstrate value to the community from participating. This is where most of the hard work lies.

It would be interesting to see how well the open source community in India takes to these projects and how quickly the hyperlocal model can be tested with several more installations.

References

• Swara Project on GitHub
• Swara Community
• CGNet Swasra
• FreedomFone Project

Everywhere we look in today’s data management landscape, the volume of information is soaring. According to one estimate, the data created in 2010 is about 1,200 exabytes, and will grow to nearly 8,000 exabytes by 2015, with the Internet/Web being the primary data driver and consumer.

This growth is outpacing the growth of storage capacity, leading to the emergence of information management systems where data is stored in a distributed way, but accessed and analysed as if it resides on a single machine (Figure 1).

Figure 1: Distributed data storage

Besides resolving the data size problem, these solutions also need to cater to massive performance requirements to ensure timeliness of data processing. Unfortunately, an increase in processing power does not directly translate to faster data access, triggering a rethink on existing database systems.

To understand the enormity of data volumes, let’s look at a couple of figures:  Facebook needs to store 135 billion messages a month. Twitter has the problem of storing 7 TB of data per day, with the prospect of this requirement doubling multiple times per year. Criticality of data and continuity in data availability has become more important than ever. We expect data to be available 24×7 and from everywhere.

This brings in the third dimension of high availability and durability. So we have to factor in high availability without any single point of failure, which has traditionally been a telecom forte. These challenges have created a new wave in database processing solutions, which manage data in both structured
and unstructured ways.

Legacy information management systems are characterised by monolithic relational databases, disk/tape-based stores (as memory in huge quantities is scarce or expensive), vendor lock-in and limited enterprise-level scalability. With the advent of the cloud, new data management solutions are emerging to handle distributed (relational/non-relational) content on open platforms at the speed of a mouse-click.

NoSQL

One of the key advances in resolving the “big-data” problem has been the emergence of NoSQL as an alternative database technology. NoSQL (sometimes expanded to “not only SQL”) is a broad class of DBMS that differ significantly from the classic RDBMS model. These data stores may not require fixed table schemas, usually avoid join operations and typically scale horizontally.

NoSQL solutions have carved a niche market for themselves as key-value stores, document databases, graph databases and big-tables. Use cases for these solutions in Web applications are a dime a dozen. They are used everywhere — whether it is in Web-based social interactions like online gaming/networking, or revenue maximising decisions like ad offerings, and not to mention basic operations like searching the Internet. Figure 2 shows the architecture of a famous NoSQL database (CouchDB) written in Erlang.

Figure 2: CouchDB architecture

But, is NoSQL the answer to all problems? In spite of the technological acumen provided by NoSQL solutions, the RDBMS users in enterprises are reluctant to switch to it. Why?

The greatest deployment of traditional RDBMS is primarily in enterprises, for everything the enterprise does, whether storing customer information, internal financials, employee information or anything else. Is such data growing? Yes, so big-data issues are relevant to them. So why not NoSQL?

Even though there are varieties of NoSQL offerings, they are typically characterised by lack of SQL support, and non-adherence to ACID (Atomicity, Consistency, Isolation and Durability) properties. (Here, we will not go into the technical reasons for this.)

So while NoSQL could help enterprises manage large distributed data, enterprises cannot afford to lose the ACID properties — which were the key reasons for choosing an RDBMS in the first place. Also, since NoSQL solutions don’t provide SQL support, which most current enterprise applications require, this pushes enterprises away from NoSQL.

Hence, a new set of data-management solutions are emerging to address large data OLTP concerns, without sacrificing ACID and SQL interfaces.

Why is traditional OLTP insufficient?

We have already discussed the fact that there is an explosion in the OLTP data space. For example, more widely used social network sites (like Facebook and Linkedin) lead to larger OLTP requirements. Each user of such sites requires credentials and user profile information to be stored, generally in some OLTP database, even though the actual user data is stored in a NoSQL data-store. Facebook’s 750 million users require a very large OLTP database.

While growing OLTP data is a direct contributor, business requirements also force non-OLTP data to be managed as OLTP. Let’s look at the example of how analytics (which is the quintessential OLAP application) has led to the scalability requirements of OLTP.

Case study: Real-time analytics

In the earlier days, analytics were performed on historic data with specialised data warehouse solutions, mostly using an ETL (Extract, Transform and Load) approach. Data extracted from OLTP systems was fed to data warehouse systems capable of handling voluminous data. Real-time analytics is an approach that enables business users to get up-to-the-minute data by directly accessing business operational systems or feeding real-time transactions to analytics systems.

For example, previously Google Analytics analysed past performance — but recently, Google launched Google Analytics: Real Time, which shows a set of new reports on what’s happening on their site, as it happens.

Even though traditional OLTP systems provide ACID, they are not well equipped to handle the volume of data seen because of new innovative business scenarios like real-time analytics. A combination of traditional OLTP systems and analytics systems might under-utilise the analytics systems, due to scalability limitations and the performance of traditional OLTP systems.

Welcome NewSQL

To address big-data OLTP business scenarios that neither traditional OLTP systems nor NoSQL systems address, alternative database systems have evolved, collectively named NewSQL systems. This term was coined by the 451 Group, in their now famous report, “NoSQL, NewSQL and Beyond”.

The term NewSQL was used to categorise these new alternative database systems. 451 Group’s senior analyst, Matthew Aslett, clarified the meaning of the term NewSQL (in his blog) as follows: “NewSQL is our shorthand for the various new scalable/high-performance SQL database vendors. We have previously referred to these products as “ScalableSQL” to differentiate them from the incumbent relational database products. Since this implies horizontal scalability, which is not necessarily a feature of all products, we adopted the term NewSQL in the new report. And to clarify, like NoSQL, NewSQL is not to be taken too literally: the new thing about the NewSQL vendors is the vendor, not the SQL. NewSQL is a set of various new scalable/high-performance SQL database vendors (or databases). These vendors have designed solutions to bring the benefits of the relational model to the distributed architecture, and improve the performance of relational databases to an extent that the scalability is no longer an issue.”

Figure 3 is an architectural example of one of the NewSQL solutions (dbShards).

Figure 3: dbShards

Technical characteristics of NewSQL solutions

1. SQL as the primary mechanism for application interaction.
2. ACID support for transactions.
3. A non-locking concurrency control mechanism so real-time reads will not conflict with writes, and thus cause them to stall.
4. An architecture providing much higher per-node performance than available from traditional RDBMS solutions.
5. A scale-out, shared-nothing architecture, capable of running on a large number of nodes without suffering bottlenecks.

The expectation is that NewSQL systems are about 50 times faster than traditional OLTP RDBMS.

Similar to NoSQL, there are many categories of NewSQL solutions. Now we can look at these categorisations and their characteristics.

NewSQL categorisation

Categorisation is based on the different approaches adopted by vendors to preserve the SQL interface, and address the scalability and performance concerns of traditional OLTP solutions.

1. New databases: These NewSQL systems are newly designed from scratch to achieve scalability and performance. Of course, some (hopefully minor) changes to the code will be required and data migration is still needed. One of the key considerations in improving the performance is making non-disk (memory) or new kinds of disks (flash/SSD) the primary data store. Solutions can be software-only (VoltDB, NuoDB and Drizzle) or supported as an appliance (Clustrix, Translattice). Examples of offerings are Clustrix, NuoDB and Translattice (commercial); and VoltDB, Drizzle, etc., (open source).
2. New MySQL storage engines: MySQL is part of the LAMP stack and is used extensively in OLTP. To overcome MySQL’s scalability problems, a set of storage engines are developed, which include Xeround, Akiban, MySQL NDB cluster, GenieDB, Tokutek, etc. The good part is the usage of the MySQL interface, but the downside is data migration from other databases (including old MySQL) is not supported. Examples of offerings are Xeround, GenieDB and TokuTek (commercial); and Akiban, MySQL NDB Cluster and others in open source.
3. Transparent clustering: These solutions retain the OLTP databases in their original format, but provide a pluggable feature to cluster transparently, to ensure scalability. Another approach is to provide transparent sharding to improve scalability. Schooner MySQL, Continuent Tungsten and ScalArc follow the former approach, whereas ScaleBase and dbShards follow the latter approach. Both approaches allow reuse of existing skillsets and ecosystem, and avoid the need to rewrite code or perform any data migration. Examples of offerings are  ScalArc, Schooner MySQL, dbShards and ScaleBase (commercial); and Continuent Tungsten (open source).

Summing up

Given the continuing trend of data growth in OLTP systems, a new generation of solutions is required to cater to them. DBMSs have to be rearchitected from scratch to meet this demand. However, unlike NoSQL, these DBMSs have to cater for applications already written for an earlier generation of RDBMS. Hence, drastic interface changes like throwing out SQL or extensive changes to data schema is out of the question.

A new generation of information management systems, termed NewSQL systems, caters to this trend and these constraints. NewSQL is apt for businesses that are planning to:

1. migrate existing applications to adapt to new trends of data growth,
2. develop new applications on highly scalable OLTP systems, and
3. rely on existing knowledge of OLTP usage.

We look forward to your comments on this introductory article, and we will also plan for a series of expert in-depth articles on the NewSQL database technology.

Gartner has predicted in-memory computing to be one of the top 10 strategic technologies of 2012. In-memory computing is expected to have a disruptive impact on the data warehousing domain in the coming two years. There have been a series of such products released in the last two years, one of the most famous being SAP’s HANA. Real-time analytics and sub-second response times for enterprise applications require high-performance data management systems. This, in turn, has led to a surge in the importance of IMDBs.

Network bandwidth has increased dramatically and multi-core processors are available even in mobile phones. However, disk I/O speed has not been increasing at the same rate, which has crippled traditional databases. The first step towards high-performance databases is IMDBs. With ever-growing RAM size and the ability to address more RAM (with 64-bit address spaces), IMDBs are in vogue.

What is an in-memory database?

Wikipedia defines an in-memory database as, “An in-memory database (IMDB; also, main memory database system or MMDB) is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism.”

Margaret H Eich has given a very simple definition of an IMDB/MMDB: a database whose primary data store is main memory.

IMDBs are architected and designed differently from traditional RDBMSs. They have simplified algorithms and mechanisms, which are built with the awareness that all data is going to be in RAM. Figure 1 is a simple illustration of the differences.

Figure 1: IMDB vs Disk DB

IMDBs are also different from simplified storage algorithms like hash-tables or trees, in that IMDBs are “databases” or RDBMSs. Most IMDBs are ACID-compliant relational databases offering SQL. They have all the properties of a traditional RDBMS, but are tuned for data to be in-memory.

Getting deeper into the IMDB

IMDBs are not a new phenomenon. The great DB scientist Jim Gray conceptualised this technology 30 years ago and also predicted that in the 2000s these technologies would become widely accepted. Almost from the early 1980s, IMDBs have existed in the telecom and defense domains. However, these were built and maintained as internal components. IBM built one of the first in-memory engines (IMS/VS FastPath) way back in 1978.

The first significant commercial IMDB offering was TimesTen (later acquired by Oracle). Since then, almost all top DB vendors boast an IMDB product — like IBM’s SolidDB, Sybase’s ASE, etc.

Myths about IMDBs

Consider the following assertions:

• Given the same amount of RAM, disk DBs can perform at the same speed as IMDBs (by using caching technology).
• If a RAM disk is created and a traditional disk DB is deployed on it, it delivers the same performance as an in-memory database.
• If the system crashes, all the data stored in IMDBs will be lost.
• SSDs and flash storage are getting better and better. Using these technologies along with traditional disk DBs yields the same performance as an in-memory database.
• Since RAM size is limited, sizes of IMDBs are also limited.
• Finally, IMDBs are not special; they are traditional disk DBs made to run on RAM.

Naturally, all of these are myths. It is close to impossible to create an in-memory DB from a traditional disk database by just changing the OS or hardware environment.

So, internally, how different is an IMDB from a traditional disk DB?

IMDBs are architected and designed keeping in mind the fact that all data is in memory. This actually leads to much simpler design as compared to disk DBs. There are six areas of difference:

1. Query optimisation: In disk DBs, the I/O cost factor dominates the optimisation. However, in IMDBs there is no such clear factor, which makes query optimisation very tricky. This is generally solved by taking constants and falling back on rule-based optimisation.
2. Indexing: More memory-friendly data structures and algorithms are used for indexing. While most disk DBs use B-Tree as a primary indexing data structure/algorithm, IMDBs tend to use T-Tree as a primary indexing data structure/algorithm.
3. Internal data representation: Compactness of representation dominates concerns for IMDBs. With all data being in memory, IMDBs tend to use direct memory pointers heavily. This is very typical of the IMDB memory page, index data or relation representations.
4. Durability and recovery: Contrary to popular belief, IMDBs are durable. They use algorithms similar to disk DBs for persistence. However, the buffer management, which is the biggest performance bottleneck for disk DBs, is eliminated. During database loading, IMDBs tend to take a bit more time as they have to load the complete data into memory. Hence, recovery is a bit slower.
5. Access methodology: Generally, disk DBs offer client server over sockets as a primary access method. However, with no disk I/O, if IMDBs only offer sockets for access, this will become a bottleneck. Hence, most IMDBs tend to offer shared-memory access as a primary method. In a few cases, JDBC/ODBC interfaces are also supported.
6. Concurrency control: Due to inherent speed in processing, IMDBs can take coarser locks and also do less to persist them. However, disk DBs take finer locks and take elaborate measures to persist them.

Figure 2 is a typical architecture for an in-memory database.

Figure 2: IMDB architecture

Typical applications of IMDBs

IMDBs are applicable in all domains that require real-time performance and very low latency. Four domains typically use IMDBs: telecom, financial segments, enterprises, and e-commerce and Web applications. In these spaces, IMDBs are used in a variety of applications (refer to Figure 3).

Figure 3: IMDB usecases

Key offerings in the IMDB space

The IMDB space is dominated by a lot of commercial players. Some of the most important ones are Oracle TimesTen, IBM SolidDB, Sybase ASE, ENEA Polyhedra and McObject ExtremeDB. There are also some typical open source solutions. Let us take a look at two of the FOSS IMDBs — CSQL and MonetDB.

CSQ

CSQL is an open source main-memory high-performance RDBMS developed in India. It is one of the fastest open source IMDBs. It is designed to provide high performance on simple SQL queries and DML statements that involve only one table. It supports only limited features, which are used by most real-time applications, like INSERT, UPDATE, DELETE on a single table, and SELECT with local predicates on a single table.

It provides multiple interfaces such as JDBC, ODBC and other SQL APIs. CSQL offers atomicity, consistency and isolation. It is typically recommended for use as a cache for existing disk-based commercial databases.

MonetDB

MonetDB is an open source high-performance DBMS developed at the National Research Institute for Mathematics and Computer Science in the Netherlands. It was designed to provide high performance on complex queries against large databases, e.g., combining tables with hundreds of columns and multi-million rows.

MonetDB is one of the first database systems to focus its query optimisation effort on exploiting CPU caches. Development of MonetDB started in 1979 and it became an open source project in 2003. MonetDB has been successfully applied in high-performance applications for data mining, OLAP, GIS, XML Query, and text and multimedia retrieval.

How do IMDBs change the rules of the game? While existing applications and schemas can directly benefit from IMDB due to performance improvement, if some things are not carefully handled, the full benefit of IMDB is not achieved. Areas that require significant changes at both the conceptual as well as implementation levels are application design, database schema design and data design (partitioning of data).

Application design

Taking advantage of performance benefits offered by an IMDB means redesigning applications to take advantage of the specific strengths of in-memory technology. The main way to achieve this is to push work that is currently done in the application layer down to the database.

This not only allows developers to take advantage of special operations offered by the DBMS, but also reduces the amount of data that must be transferred between application layers. This can lead to substantial performance improvements and can open up new application areas.

Database schema design

IMDB is beneficial if the data fits into a single database. This requires efforts to conserve space, so more elaborate normalisation procedures are not suitable. Also, using very precise and apt data types enhances storage space. Reduced redundancy, carefully formed columns, precise index creation and efficient data management will help IMDB yield better performance.

Data design

One of the key changes when moving from traditional disk DBs to in-memory DBs is the space available, so data partitioning and storage assumes great significance. IMDB requires as much related data as possible in a single process space. Too much distribution will introduce network I/O in the processing, thereby degrading performance.

Summing up

IMDBs, combined with various current hardware trends, have the ability to change the performance of enterprise and other applications drastically. This, in turn, will result in tremendous value generation to businesses. Such enhanced performance will also foster the evolution of innovative applications and services.

Do send in your feedback and queries, which can be addressed in our forthcoming articles in the IMDB series.

A cluster is a collection of commodity components that provide scalability and availability at a low cost to the consumer. A database cluster is a collection of database servers that store and process data using commodity hardware, satisfying the need for more data storage, higher throughput and providing high availability. Postgres-XC is such a database cluster system; it is based on PostgreSQL, and follows the same open source model.

The Postgres-XC project began in 2009, through a collaboration between NTT and EnterpriseDB. The goal was to build an open source clustering solution based on PostgreSQL with 100 per cent compatible client APIs. Having PostgreSQL-compatible APIs allows existing PostgreSQL applications to use Postgres-XC with little (or no) change. The licensing terms of this project are the same as that of PostgreSQL.

Postgres-XC architecture

Postgres-XC is a write-scalable, synchronous multi-master, transparent PostgreSQL clustering solution based on shared-nothing architecture. It is a collection of tightly coupled database components, which can be installed on one or more physical or virtual machines. The components do not share any resources such as disk, cache or memory.

• Write-scalability means that Postgres-XC can be configured with as many database servers as needed; Postgres-XC is able to handle more writes than a single PostgreSQL server.
• Multi-master implies that clients can connect to multiple database servers, and that each database server provides a single, consistent, cluster-wide view of the database.
• Synchronous means that a write from any of the masters is immediately visible to other transactions running on other masters.
• Transparent means that applications do not have to worry about how the data is stored in multiple database servers, internally.

Figure 1: Postgres-XC architecture

Figure 1 gives the architectural overview of Postgres-XC with its three main components:

1. Global Transaction Manager (GTM) gathers and manages information about transactional activities in Postgres-XC, issues global transaction identifiers to transactions (to maintain a consistent view of the database on all nodes), and  provides ACID properties. It provides support for other global data, such as sequences and timestamps. It stores no user data, except control information.
2. Coordinators (masters) provide a point of contact for the application/client. They are responsible for parsing and executing queries from the clients, and returning the results (if needed). They do not store any user data themselves, but gather the data from datanodes, with the help of SQL queries fired through a PostgreSQL-native interface. The coordinators also process the data if required and even manage the two-phase commit. Although coordinators do not store user data, they use the catalogue data to parse queries, resolve symbols, plan queries, locate data, etc.
3. Datanodes store user data and catalogues. The datanodes execute the queries received from the coordinator and return results to the coordinator.

Distribution of data and scalability

Postgres-XC allows two ways of storing the tables on the datanodes:

1. Distributed tables: A table is distributed on a given set of datanodes using strategies like hash, round-robin, or modulo partitioning. Every row of a distributed table resides on a single datanode. Multiple rows can be modified or written in parallel to various datanodes; we can also read the rows from various datanodes in parallel. Performance is greatly improved by parallel writes and reads from different datanodes.
2. Replicated tables: A table is replicated on a given set of datanodes using statement-level replication, which performs better than log-based replication, since the size of the logs that must be shipped is much greater than the size of the statement. In the case of a replicated table, a row in the table resides on each datanode on which the table is replicated. Any modifications to the row must be duplicated to each replicated copy. Since all the data in the table is available on a single datanode, the coordinator can gather all the data from a single node and in some cases, act as a proxy between the client application and the datanode. This allows multiple queries on the same table to be directed to different datanodes, thus balancing the load and increasing the read throughput.

Figures 2 and 3 depict the read and write concepts for distributed and replicated tables, respectively.

Figure 2: Distributed tables

Figure 3: Replicated tables

High availability

To achieve high availability, one needs data redundancy, component redundancy and automatic failover. In Postgres-XC, data redundancy can be achieved by using the PostgreSQL native replication with Hot Standby for datanodes. Since each coordinator is a master (capable of writing data) and is capable of reading writes performed by any other coordinator instantaneously, every coordinator is capable of replacing any other, should that coordinator fail. GTM-standby acts as a redundant component for GTM. However, third-party tools are required for automatic failover of all the three types of components.

Performance evaluation

Initial transaction throughput measurements carried out using the DBT-1 benchmark have shown significant throughput scalability, as shown in Figure 4.

Figure 4: Performance evaluation

The figure plots the Scaling Factor versus the Number of Servers in Postgres-XC. The Scaling Factor is the ratio of the number of transactions completed per unit time by Postgres-XC, to that completed by PostgreSQL. A Server comprised of a coordinator and a datanode run on single machine. This benchmark demonstrated an improvement in throughput of approximately 6 times, when using 10 servers.

Release management & development processes

The Postgres-XC project is hosted on SourceForge. The Postgres-XC team tries to release a minor version of Postgres-XC every three to four months to ensure that the latest Postgres-XC features are available to users. The team also tries to make the latest PostgreSQL features available in Postgres-XC by doing frequent merges with the latest stable release of PostgreSQL.

The last release (0.9.6) of Postgres-XC supports most of the SQL syntax and features of PostgreSQL 9.1. The team is currently working on the first major release of Postgres-XC 1.0, due in 2012, with maximum PostgreSQL compliance. Some of the other features like the dynamic addition and removal of components, global deadlock detection, global constraint support, etc, will be targeted for major release after 1.0.

The development team follows the open source development model, where the issues, features or any other development related items are discussed on the public mailing list: postgres-xc-developers@lists.sourceforge.net. The postgres-xc-general@lists.sourceforge.net mailing list is used to discuss other Postgres-XC matters and to solicit help about Postgres-XC.

Wish to contribute?

The Postgres-XC team needs help with feature development, bug fixing, creating installers and distribution packages, testing, and evaluation of Postgres-XC on real applications. To be part of the Postgres-XC community, feel free to contact the Postgres-XC team at the appropriate mailing list.

Schools and colleges often focus on theory, forgetting that practical experiments teach students much more. Members of the Inter University Accelerator Centre (IUAC), an autonomous research institute that provides research facilities to universities, realised the need for experiments in education when teachers and students from other colleges visited their centre and tried to use a particle accelerator. They were not familiar with computer-controlled experiments that use machines to collect data.

Dr Ajith Kumar, a scientist at IUAC, wished to provide teachers and students with exposure to this technology and started designing a low-cost device that measured and collected data, and displayed the results graphically on the computer screen.

Along with members of the electronics department, he developed Phoenix expEYES — a combination of hardware and a software framework for computer-interfaced science experiments that doesn’t require the user to get into the details of electronics or computer programming.

“We decided to create something on a smaller scale and introduce the idea of a low-cost computer-interfaced platform for science experiments,” comments Dr Kumar.

A platform for experiments

The equipment places emphasis on leveraging the power of personal computers for experiment control, data acquisition and processing. Phoenix expEYES enables one to carry out a variety of experiments using the same inexpensive hardware with different sensor elements and software. The design also enables the platform to be used as an electronics developers’ kit, as it can be used to develop and learn microcontroller programming. Engineering students can play with the platform or use it as a case study to design similar applications. Since the code and design are open, one can get any details required from IUAC’s website.

What sets it apart

Dr Kumar emphasises, “Our main aim was to make the equipment affordable to educational institutes. Phoenix ExpEYES is priced at around Rs 3000, and a similar product in the market would cost you over Rs 1,00,000.”

The team managed to keep the price low by using low-cost hardware components that were readily available. Another cost-cutting factor is that the project runs on free and open source software, mostly written in the Python programming language.

One of the unique features of Phoenix is its job division. The microcontroller collects real-time data from the experiment, while the software running on the PC takes care of complex processing and graphical representation of data on the computer screen.

Phoenix’ hardware consists of an Atmel ATMega32 microcontroller running a C program, a 12-bit resolution analogue-to-digital converter (ADC), a 12-bit digital-to-analogue converter, variable gain amplifiers, several oscillators and a programmable constant-current source. It is interfaced to a computer that runs Python.

“For the software, we have chosen Python, as it has a huge collection of libraries and programs for scientific computation. Several GUI programs have already been written to perform various experiments. A user can conduct several experiments using the GUI programs provided, but designing new experiments would require accessing the hardware accordingly. Hardware features can be accessed by entering codes that are well documented from the Python library,” Dr Kumar explains.

Phoenix’s clear-cut architecture is one of its USPs, enabling teachers to develop new experiments with the help of the library. Dr Kumar elaborates, “School teachers are usually not inclined to learn about electronics or micro-level C-programming, but this is usually required when communicating with the hardware. With Phoenix, all they need to do is write one line of code that is readily available in the Python Library, and they will get the required data. For example, if you want to capture the frequency from a guitar, you can type a code on the computer and send a request to the hardware unit. The computer’s monitor will display the frequency while you remain uninvolved with the programming details.”

The communication takes place between the microcontroller in the hardware unit and the computer running Python through a USB connection.

Dr Kumar adds, “The earlier units that we designed had parallel ports but this kind of interfacing lost popularity. Hence we migrated to the USB interface. It also helped that Python already had a library to communicate to the serial port.”

Overcoming challenges

Ensuring a low price point for Phoenix was one of the biggest challenges before Dr Kumar and his team while designing the platform. Getting high-resolution components at low prices was a challenge in itself and required a lot of research. For example, the IUAC team went to different markets to compare prices, easy availability and resolutions before selecting ADCs. They decided to use a product from Microchip which was available for Rs 150.

“Apart from affordability, we looked for components that could be sourced easily and repaired by the users in case of damages that are common in school and college laboratories,” reasons Dr Kumar.

The IUAC team also worked on the flexibility of the framework by writing the software in a generic manner. It is easy to get the hardware and write a simple software that makes the platform rigid. However, this would have meant only a limited number of experiments that could be done on the platform.

Dr Kumar illustrates, “We can easily design platforms that work for five experiments, but for the sixth one, the user should know all the details of hardware design and coding. This makes the architecture rigid. In Phoenix, a lot of time and effort went into making the architecture flexible. Its generic nature allows software that supports time measurement, to be used to measure acceleration due to gravity and the velocity of sound.”

What lies ahead

IUAC’s goal is to help engineering students develop their own projects rather than purchase them from professionals in the field. It has approached NCERT and CBSE to make it a part of every school’s lab activities.

“As of now, the only explanation given for AC and DC is that AC means alternating current and DC means direct current. Most of the teachers cannot answer a simple query like, ‘What is the nature of voltage on a three-point mains socket?’ We hope that Phoenix will help them improve by changing their practices, and making students and teachers more aware of what is in their books,” Dr Kumar concludes.

In the previous article we discussed that as data volumes grow towards the peta-scale and beyond, most traditional databases find it difficult to scale up to the needs of cloud computing and Big Data. While Big Data drives the need for databases to handle huge volumes of data, cloud computing requires dynamic scalability.

Dynamic scalability

Dynamic scalability, at first glance, appears simple to achieve in databases with the “Shared Nothing” architecture. This architecture splits the database into multiple partitions, with one partition per server. Therefore, it should be possible to dynamically scale by adding another server and repartitioning the database across all servers. However, database partitioning is an important factor in the performance of database access.

Database queries frequently access related sets of information. If a frequently accessed related set of data gets partitioned across multiple servers, data from multiple partitions needs to be accessed before the query results can be returned — a process known as data shipping. This can have a large adverse impact on query access times.

Data partitioning needs to take data access patterns into account in order to reduce data shipping costs. Hence, “Shared Nothing” traditional relational databases typically find it difficult to achieve dynamic scalability.

The limitation of the traditional RDBMS in being able to scale dynamically led to the NoSQL movement, and the development of special-purpose data-stores (since the term database is typically used to represent an ACID-compliant traditional database, we use the term data-store for the NoSQL databases). They proposed data persistent stores typically built as replicated data tables, which trade off strict ACID semantics for improved scalability.

These systems are characterised by eventual consistency (which we discussed in an earlier article) instead of the strict ACID consistency of RDBMSs. While NoSQL databases such as BigTable, Cassandra or SimpleDB have shown excellent performance, it is not yet clear whether they can scale to the demands of the next decade’s peta-scale computing.

Big data challenges

Over the past few decades, there have been two major camps of database technology. The first one is that of OnLine Transaction Processing (OLTP) workloads, and the second that of OnLine Analytical Processing (OLAP) workloads.

An OLTP workload typically consists of a number of concurrent transactions that perform insertions, deletions and updates of the data stored in the database. OLTP workloads are both read- and write-intensive. Popular examples that we encounter in everyday life are bank transactions (deposits and withdrawals) and credit-card transactions.

OLAP workloads, on the other hand, typically perform complicated and compute-intensive analysis on the data stored in the database. For example, the CEO of a supermarket chain wants to know what the total volume of sales over the Christmas holiday period is, from each store. This requires OLAP query processing.

OLAP queries are typically read-intensive. An OLTP transaction typically accesses one or a few records, but it accesses all fields of the accessed records. On the other hand, OLAP queries access a large number of records of the database, but only access one, or a very few, of the fields of each record.

The differences in the very nature of OLTP and OLAP workloads demand certain design differences in the databases for each of these workloads. An example of these differences is the row-oriented record layout of Row-Store Databases, versus the columnar layout of Column-Store Databases.

In row stores, all the fields of the record are stored contiguously, with one record completely laid out before another record starts. In columnar stores, the column fields are laid out contiguously.

Recall that OLTP typically operates on one or a very few number of records, and hence benefits from the row layout. On the other hand, OLAP workloads access a large number of records, accessing only one or a small number of columns in each record. Hence they benefit from the columnar layout. With a column-store architecture, a DBMS needs only to read the values of the columns required for processing a given query, and can avoid bringing into memory irrelevant fields that are not needed for the current query.

In warehouse environments where typical queries involve aggregates performed over large numbers of data items, a column store has a sizeable performance advantage over a row store. A number of popular column oriented databases have been developed, such as VoltDB and Vertica.

As mentioned earlier, OLAP is read-intensive; the database performance needs to be optimised for read operations, but at the same time, it needs to support database updates while maintaining ACID consistency. Some modern databases try to optimise for both, by providing both read- and write-optimised stores.

C-store is the academic project on which the popular database analytics product, Vertica, is based. C-store provides both a read-optimised column store and an update/insert-oriented writeable store, connected by a tuple mover.

C-store

C-Store supports a small Writeable Store (WS) component, which provides extremely fast insert and update operations. It also supports a large Read-optimised Store (RS), which is well optimised for query operations. Read-Store supports only a very restricted form of insert, namely the batch movement of records from WS to RS, a task that is performed by the tuple mover.

While till now the buzz in the database industry has been about “Big Data”, which denotes the huge volumes of data expected to be generated by peta-scale computing, it is not just the data that matters. After all, DBMS and data analytics are not just about raw data; they are about converting data into information, which is then converted by analytics tools into business insights. Therefore, the term “Big Data” internally covers the following requirements as well:

1. Any future database system should be able to handle huge volumes of data (as denoted by “Big Data” needs).
2. They should be able to process and query the data at great speeds (hence the need for fast data). This requirement brings forth the need for complex programming models that can query and process large data, such as Map-Reduce.
3. They should be able to analyse the data and convert it into business intelligence using complex analytics (hence the need for deep analytics).

Therefore the challenge for future database systems is not just about big data, but about handling big data that requires fast query responses and deep analytics.

Taking advantage of emerging hardware

It is not only the database industry that is undergoing many changes to address the twin challenges of big data and cloud computing. The hardware industry is at an inflection point today as we discuss below.

In 1965, Dr Gordon Moore from Intel predicted that the transistor density of semiconductor chips would double approximately every 18 to 24 months — this is popularly referred to as Moore’s Law. For many decades, till now, such an exponential growth in the number of transistors on the chip has roughly translated into improvements in processor performance. Moore’s Law enabled processor performance, more specifically single-thread performance, to double every 18 months — thereby allowing software developers to deliver increasingly complex functionality and greater performance without having to rewrite their code.

Though Moore’s Law itself continues to hold good even now, the diminishing returns from hardware ILP extraction techniques, and the constraints on increasing the clock frequencies due to the limitations of power consumption and heat dissipation of the chip have forced chip manufacturers to look towards multi-core processor designs to improve overall system performance, instead of the traditional single-core processor designs.

With multiple cores on a single chip executing simultaneously, it is possible to meet the throughput demands of an application while keeping the processor clock frequencies moderate, to contain power consumption and the heat generated. So, what do multi-core processors mean to future database systems?

Multi-core systems require database systems that can extract greater parallelism, in both intra- and inter-query processing. This requires Massively Parallel Databases (MPP Databases), which support “Shared Nothing” architectures.

While parallel databases are known to scale to hundreds of nodes, they have not been shown to scale to thousands of nodes and beyond. On the other hand, non-traditional database architectures, like data stores supporting Map-Reduce, have been scaled to thousands of nodes with extremely high availability and fault resiliency.

Hence, the question that needs to be answered is: Are massively parallel databases the right solution for tomorrow’s multi-core era or is it the Map-Reduce data stores?

A detailed discussion that compares the relative merits of these two systems was described in the paper, “A Comparison of Approaches to Large-Scale Data Analysis” [PDF].

Current state-of-the-art approaches have also proposed combining massively parallel databases with the Hadoop architecture, as proposed in HadoopDB, which is described in the paper, “HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads” [PDF].

Another interesting direction for the future of database technology is to take advantage of the emerging GPU Many-Core architectures. There has been work on off-loading many of the data query operators to GPU architectures. Techniques for mapping many database operations to GPUs are discussed in the paper, “Fast Computation of Database Operations using Graphics Processors” [PDF].

The most important hardware innovation for future databases is, of course, the introduction of Non-Volatile RAM. Databases have traditionally been using the buffer pool in memory to speed up database operations, while also maintaining the ACID properties.

The introduction of NVRAM takes away the need for the buffer pool, and requires a database redesign. While current databases have been designed for optimising disk reads, which are much slower than main-memory accesses, this will change drastically with NVRAM, since RAM is going to be persistent. Therefore, newer database systems explicitly designed for NVRAM are the need of the day.

While we have been discussing the challenges for future databases, I would like to bring to the reader’s attention an informative blog on state-of-the-art database design — dbmsmusings.blogspot.com — which is maintained by Prof Daniel Abadi, who is a pioneer in modern database design. His insightful articles on database research are a must-read for database programmers.

The genesis of shared computing dates back to the time when mainframes fed dumb clients. Then came the era of server-based computing, when these mainframes were replaced by servers and the earlier dumb clients by full-fledged PCs. Over time, thin clients have gained traction in many server-based computing setups — where most, if not all applications are run on the server.

This server-based computing was intended to provide the same advantages as mainframe computing, while mitigating the cost and environmental factors — but it created a completely different set of disadvantages, the key one being the constrained user experience with limited desktop interface performance, especially when graphical applications are used. Apart from this, thin clients, which can be called scaled-down versions of PCs, invariably require special customisation and administration, expensive high-end server components, and so on.

Another option that has emerged to overcome these disadvantages, while still tapping the benefits of server-based computing, has been the zero client, based on the concept of desktop virtualisation. The concept behind these virtual desktops is to optimally use the power of the PC, which remains under-utilised in most cases, as most of us use a small fraction of its power. Desktop virtualisation enables a single PC to be “virtualised” (or shared) by many users — where all users get to experience their own individual computing session.

Relevance of desktop virtualisation for organisations

It is important to evaluate the suitability of desktop virtualisation for organisations of different sizes. There are a number of reasons and advantages that CTOs of companies of all sizes and markets can consider before adopting desktop virtualisation.

Shared computing or desktop virtualisation is an ideal solution for companies moving to cloud and Web-based computing. It works fine for CIOs seeking to better manage PC proliferation and costs. It is ideal for education and public sector institutions seeking to provide desktop access to all constituencies at a low initial cost of purchase, and even for those who want to achieve sustainability through low on-going costs.

Other benefits of desktop virtualisation include ease of centralised management, enhanced security as a result of limited access to critical infrastructure, low cost of entry, and dramatically reduced life-cycle and maintenance costs. And, what if we use open source operating systems along with desktop virtualisation?

This makes the solution even more compelling from the cost perspective.

Desktop virtualisation methods

To explore further, we decided to try out two popular methods of desktop virtualisation — USB and PCI. To evaluate how both of these methods fare, we performed a test using the available USB and PCI solutions to assess the difference in client PC performance, where server configuration remained the same — and are the server configuration details:

• Computer system used: HP MS6000 extended configuration
• Operating system: Ubuntu 10.04
• Processor: Intel Core 2 Quad Q9500
• Chipset: Intel Q43 Express
• RAM: 6 GB DDR3 (1333 MHz)
• Hard disk drive: 500 GB SATA 3.0 Gb/s
• Removable media: 16x SATA DVD writer drive
• Graphics: Integrated Intel Graphics Media Accelerator 4500 (Intel Graphics Media Accelerator driver installed using Nvidia graphics driver 96.43.18 for Ubuntu 10.04.)

We installed Ubuntu 10.04 on the server, then we installed a desktop virtualisation software that is required to connect client machines with the server. We also installed VLC Player. After configuring the server, we connected a total of three clients, first using USB and then PCI.

We then recorded readings for server performance while playing HD video on VLC — initially on the first client; then we connected the second client and played the same video on both client machines. Subsequently, we recorded the performance of the server with three clients connected to it and playing the same HD video.

Here are a few inferences based on the readings as shown in the above table:

• PCI is technically more reliable than USB for networking. You are less likely to experience dropped connections or a sluggish response time to your modem when using PCI instead of USB.
• Ethernet cables can reach a longer distance than USB cables. A single Ethernet cable can run 10 metres (32 ft) on a direct connection with PCI, while USB cable runs are limited to approximately 5 metres (16 feet).

The test demonstrates that PCI is better suited for network computing, while USB works well for peripheral connectivity.

In a nutshell

According to recent studies, desktop virtualisation solutions result in 75 per cent lower maintenance and 90 per cent lower energy costs. The low entry and reduced lifecycle cost of desktop virtualisation is turning the old economics of PC purchasing and maintenance on its head.

Amongst the different variants of virtual desktop devices, PCI scores over USB significantly in terms of performance, optimum utitilisation of resources as well as user experience. This indeed makes shared computing using PCI a superior value proposition over USB for organisations that want to enable wider access to computing at a low cost.

If asked, “What are the two mega-trends in the computing industry likely to be in the coming decade?”, most IT industry folks would name “Big Data” and “Cloud Computing” as the driving forces shaping the industry today. The computing world is shifting from enterprise-centric to data-centric workloads driven by the “Big Data” revolution, while cloud computing is becoming mainstream, reinventing utility/elastic computing as the new mantra for the IT industry.

The influence of these two paradigms is driving the revolution in different fields of the computing industry, such as processor/platform architectures, programming models, programming languages and software stacks, to name just a few. After all, no one would have paid attention to “Map-Reduce” as a programming paradigm, if it was not for Web 2.0 and the shift towards cloud computing.

The field of databases is no exception, and has been influenced heavily by these two driving forces. Cloud computing is driving the momentum towards making the database available as a service on the cloud. “Big Data” is changing the traditional ways in which data is stored, accessed and manipulated, with the arrival of the NoSQL movement and domain specific databases, resulting in moving computing closer to data. And if you ask the Internet-savvy the cheeky question, “What is the connection between Cassandra, Voldemort and Dynamo?” (No, this is not related to Harry Potter!), you can expect the majority to give you the correct answer — that they are all specialised NoSQL databases.

The fact that databases are no longer the domain of the few specialised expert programmers signifies the shift of the database movement from enterprise-centric workloads to focusing and delivering on the needs of social media networks, collaborative computing, massively multi-player online gaming, etc.

Cloud computing is transforming the way data is stored, retrieved and served. Computing resources like servers, storage, network and applications (including databases) are hosted, and made available as cloud services, for a price. Cloud platforms have evolved to offer many IT needs as online services, without having to invest in expensive data centres and worry about the hassle of managing them. Cloud platforms virtually alleviate the need of having your own expensive data-centre.

Today, those managing cloud platforms offer to design, develop, test, deploy and host apps in the cloud environment, with impressively economical cost models. Amazon EC2, Google App Engine, Microsoft Azure, Appistry CloudIQ, AppScale, AT&T Synaptic and RackSpace are just a few of the offerings.

There are various classes of cloud computing services, such as:

1. SaaS: In simple terms, SaaS is a software delivery model wherein business application software is hosted on the Internet/cloud centrally, and can serve multiple customers “on demand”.
2. PaaS: This provides all systems and environments encompassing the software development life cycle, including development, testing, deploying and the hosting of business applications. Examples include Google App Engine and Microsoft’s Azure.
3. IaaS: Infrastructure, in terms of computing resources and operating systems, is also offered as a service.

After all, hosting of business applications on the cloud also entails maintaining and manipulating the data by the applications.

Initially, it was left to developers to install, manage and use their choice of database instance on the cloud, with the burden of all the database administration tasks being left to the developer. The advantage of this is that you choose your own database and have full control over how the data is managed.

In order to simplify the burden on the users of their cloud offerings, many PaaS vendors today have started offering database services on the cloud. All physical database administration tasks, such as backup, recovery, managing the logs, etc., are managed by the cloud provider. The responsibility for logical administration of the database, including table tuning and query optimisation, rests on the developer.

The choice of databases is also limited typically to MySQL or Oracle RDBMS. Examples include Amazon’s Relational Database Service (RDS), Joyent‘s MySQL and Microsoft’s SQL Azure. Salesforce.com offers Database.com, which is actually built over Oracle’s Real Application Clusters. Though Database.com itself does not support traditional SQL, the query language it offers is built upon SQL, and is known as “Salesforce Object Query Language” (SOQL), with limited querying capabilities. This is internally translated to SQL by its system.

While these are cloud offerings of database services, their underlying technology is still traditional SQL-based database technology, not specifically reinvented for the cloud.

Of late, there has also been a considerable buzz around offering “Database as a Service (DaaS)”, wherein an organisation’s database needs are met by database offerings on the cloud. There are two use-case scenarios:

1. A single large organisation that has many individual databases which can be migrated to a private cloud for the organisation, and…
2. Outsourcing the data management needs of small and medium organisations to a public cloud provider, who caters to multiple small and medium businesses.

A true DaaS offering should satisfy certain requirements such as:

• Freeing the end developer/user from database administration, tuning and maintenance activities, while offering high performance, availability and fault tolerance, as well as advanced features like snapshot, analytics and time travel.
• Elasticity, or the ability to dynamically adjust to changing workloads. Elasticity is required to meet user SLAs while minimising the cloud provider’s infrastructure, power and administration expenses.
• Security and privacy guarantees, and a pay-as-per-usage pricing model. Today, there aren’t any true DaaS offerings that satisfy all these requirements. Therefore, these cloud-computing needs will drive the next generation of database evolution.

Big Data explosion and its impact on databases

The term “Big Data” is used to represent the explosive growth in online data, which has significantly outpaced the increases in CPU processing power, memory and storage capacity over the last few years. For instance, the amount of online data indexed by Google has grown from 5 exabytes in 2002 (1 exabyte is equal to 1 million trillion bytes) to 280 exabytes in 2009, numbers that are conclusively beyond the processing capabilities of any single relational database.

This explosion in data is not just limited to the Web, but has also occurred at the enterprise. Where data was earlier being generated from simple in-house data entry feeds, database management has to cater to data from multiple external data sources such as customers, GPS, mobile devices, the general public, point-of-sale devices, sensor data and so on.

There are new kinds of data, such as Web pages, digitised content such as books and records, music, videos, photos, satellite images, scientific data, messages, tweets and sensor data — each with different data-processing requirements.

Traditionally, databases only needed to cater to enterprise-centric workloads such as OLTP/OLAP. However, Big Data has ushered in a whole new set of data-centric workloads, such as Web search, massively multi-player online games, online message systems like Twitter, sensor networks, social network analysis, media streaming, photo processing, etc. The data management needs of all these data-types cannot be met by traditional database architectures. These data-centric workloads have different characteristics in the following areas:

1. Response time requirements — such as real-time versus non-real-time.
2. Data types:
   • Structured data that fits in well with traditional RDBMS schemas.
   • Semi-structured data, like XML or email.
   • Fully unstructured data, such as binary or sensor data.
3. Processing complexity:
   • Simple data operations, such as aggregate, sort or upload/download, with a low compute-to-data-access ratio.
   • Medium compute complexity operations on data, such as pattern matching, search or encryption.
   • Complex processing, such as video encoding/decoding, analytics, prediction, etc.

Big Data has brought forth the issue of “database as the bottleneck” for many of these data-centric workloads, due to their widely varying requirements. The inability of the traditional RDBMS to scale up to massive data sets led to alternatives such as Data Sharding and Scale-Out Architectures, and subsequently to the NoSQL movement, which we will discuss later.

Database evolution from the 1960s onwards

There has been a huge evolution from the simple systems of the 1960s to what we have today. Let’s look at some of the stages in this evolution.

Flat and hierarchical databases

In a flat model, the data is stored as records and delimiters in a simple file. In  hierarchical data, model data is organised into a tree-like structure using parent/child relationships with a one-to-many ratio (see this Wikipedia article).

This was the precursor to relational databases, with no support for querying, and the responsibility of data base administration was ad-hoc, being left to the individual maintainer to take care of, without any software support.

Relational databases

A relational database is a set of relations such that the data satisfies the predicates which describe the constraints on the possible values and their combinations. It provides a declarative method for specifying data and queries. RDBMS software describes data structures for storing the data, as well as the retrieval procedures.

Relations are represented as tables in the database. A table describes a specific entity type, and all attributes of a specific record are listed under an entity type. Each individual record is represented as a row, and an attribute as a column. This is the relational database model as proposed by Codd in the 1960s.

The relational model was the first database model to be described in the formal terms of relational algebra. The relational database model went on to become the de-facto standard for all enterprise database management systems from the 1960s till the late nineties.

Object-oriented databases

In the mid-eighties, object-oriented databases were proposed, in order to allow greater programming flexibility by allowing objects to be directly stored in databases. Relations in a relational database represent behaviours, whereas interconnection between objects cannot be represented easily in the relational form.

OODBMS were intended to address this shortcoming. In an OODBMS, application data is represented by persistent objects that match the objects used in the programming language. However, object-oriented databases were not very successful, since they were more focused on addressing the programmer needs rather than the business intelligence needs of the organisation.

Columnar databases

These organise data from the same attribute as columns of values, as opposed to storing it as rows on disk. This results in large I/O savings in analytical and data-warehousing type of data retrieval, that largely accesses a set of columns. Note that columnar databases are relational, and support ACID semantics, as well as providing SQL support.

A popular columnar database that offers state-of-the-art analytical capabilities is Vertica. It is based on CStore, a column-oriented academic database research project described in this paper [PDF].

Vertica has decoupled its Read Store (optimised for read-only accesses) from the Write Store (optimised for high performance updates and inserts) to evolve a hybrid model that offers excellent scalability. The high degree of compression that can be achieved due to the nature of columnar data, grouped together with the rest of the architecture, provides powerful analytical capabilities (white papers).

There have been several commercial and open source RDBMS products, including IBM’s DB2, Oracle Database, Microsoft SQL Server, MySQL and many others. Historically, relational databases have been providing transaction processing with the clarity that emerged from their formal mathematical models, and an elegant way of storing/retrieving data using SQL. When the reality of planetary-scale data management kicked in with the Big Data explosion, combined with the need for massive Web capabilities fuelled by Web 2.0, the industry felt the need for alternatives to traditional RDBMS.

Implementations of RDBMSs are generally tuned for their specific category of usage — say, OLTP, data warehousing, decision-support regimes, etc. Big Data applications are characterised by mostly read accesses, need for quick retrieval of query results even if the results are not fully complete, streaming media requests, textual search in large number of documents, 24X7 Web requests with varying data access patterns. However, RDBMS are not tuned for such big data application characteristics.

Architectural shifts on data-sharing models

A number of techniques have been proposed to address the changing needs of data management driven by Big Data and the Cloud. These include:

1. Data replication, which creates multiple copies of the databases. The copies can be read-only, with one master copy where updates occur, and then are propagated to the copies — or the copies can be read-write, which imposes the complexity of ensuring the consistency of the multiple copies.
2. Memory caching of frequently accessed data, as popularised by the memcached architecture.
3. From the traditional “Shared Everything Scale-up” architecture, the focus shifted to “Shared Nothing Scale-out” architectures. The shared-nothing architecture allows independent nodes as the building blocks, with information replicated, maintained and accessed. Database sharding is a method of horizontal partitioning in a database, which typically partitions its data among many nodes on different databases, with replication of the application’s data via synchronisation. Shared-disk clustered databases, such as Oracle RAC, use a different model to achieve scalability, based on a “shared-everything” architecture that relies upon high-speed connections between servers. The dynamic scalability required for cloud database offerings still remains elusive in both these approaches. “Shared-nothing” architectures require time-consuming and disturbing data rebalancing when nodes are added/deleted. While node addition/deletion is faster in the “Shared-everything” architecture, they have scaling issues with increasing node counts.

Note that using the above techniques seriously impacts the maintenance of the ACID properties satisfied by traditional RDBMS engines. For instance, maintaining multiple read/write copies of the database impacts data consistency. Data sharding impacts atomicity requirements. Schema changes are time-consuming, and need to be propagated to multiple nodes in such data replicated/sharded/partitioned architectures.

Various SQL operations, such as joins, cannot be implemented at the database layer, since the database is partitioned; they need to be implemented in the application middleware layer. Therefore, supporting both RDBMS and distributed databases, which can scale to the needs of Big Data and the Cloud, have conflicting requirements.

Concurrency control

Relational data stores implement pessimistic concurrency, implying that updates to the records are protected and serialised. The locking overhead associated with the pessimistic concurrency control presents significant challenges for any light-weight implementation that needs to meet the high-performance requirements for massive data-stores.

On the contrary, many of the non-relational database implementations lean towards optimistic concurrency control, with a relaxed consistency model.

Shifts in the programming paradigm

The non-relational data models allow one to massively scale and perform in parallel. Map-Reduce (MR) techniques allow processing of partitioned subproblems in a distributed manner, with a greater degree of efficiency. There are libraries available in several forms that allow distributed processing of the map and reduction operations, with map operations executed in parallel.

Map-Reduce functions are both defined as key/value pairs, largely capable of operating on top of NoSQL data stores. It also provides inherent fault tolerance to recompute partial map results.

When does a static schema not make sense? Or, when does it need to be dynamic?

A database schema refers to the organisation of data to create a blueprint of how a database will be constructed. It specifies, based on the database administrator’s knowledge of possible applications, the facts that can enter the database, or those of interest to the possible end-users.

There is an incredible amount of diversity in terms of how data is structured in the Big Data era. The requirements for many data collections are different, and it could be a daunting task to attempt to unify all types of collections with a single schema. Instead of creating a “one size fits all” approach at the database level, the administrators who use this approach often look for flexibility in schemas. With the inability to design a predetermined schema during the design phase, a traditional SQL-based relational database is less likely to be appropriate.

The widely varying requirements of data management under Big Data and cloud computing resulted in the industry looking for alternatives to RDBMS. This led to the growth of non-relational distributed databases. These non-relational distributed database systems, which vary widely in their design, have come to be referred to by the term “NoSQL”, signifying that they are different from the traditional relational database systems that support a structured query language.

What is NoSQL?

NoSQL stands for “Not-Only-SQL”. It is the emergence of a growing number of non-relational, distributed data stores that typically do not attempt to provide ACID guarantees. NoSQL databases may not require fixed table schemas, and they typically scale horizontally. NoSQL architecture often provides weak consistency guarantees and restricted transactional support.

The origins of the NoSQL movement can be traced to what is now known as CAP theorem. Recall the fact that in order to handle massive datasets, databases turned to “Shared Nothing” partitioned systems. In 2002, Eric Brewster made the following conjecture in the PODC conference keynote talk [PDF]:

It is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

1. Consistency (all nodes see the same data at the same time)
2. Availability (node failures do not prevent survivors from continuing to operate)
3. Partition tolerance (the system continues to operate despite arbitrary message loss)

According to the theorem, a distributed system can satisfy any two of these guarantees at the same time, but not all three. Therefore, the “Shared Nothing” partitioned database architectures moved towards non-relational databases, which sacrificed consistency in order to provide high availability, scalability and partition tolerance. These partitioned non-relational databases moved from the traditional ACID semantics supported by RDBMS to BASE semantics.

BASE stands for “Basically Available, Soft state, Eventually consistent”. Under the BASE semantics, it is enough for the database to eventually be in a consistent state. ACID is pessimistic, and forces consistency at the end of every transaction. BASE is optimistic, and accepts that the database consistency will be in a state of flux. In simple terms, eventual consistency means that while a database may be inconsistent at certain points of time, it will eventually become consistent; i.e., eventually, all database nodes will receive the latest consistent updates. This relaxed consistency allows BASE systems to provide high scalability.

A detailed discussion of ACID versus BASE semantics, and how correctness can still be maintained under BASE semantics, can be found in the ACM queue article. Incidentally, it was this article that coined the term “BASE” for such partitioned database architectures.

Types of NoSQL systems

Several NoSQL systems employ a distributed architecture, similar to the “Shared-Nothing” model. Simplistic implementations use associative arrays or key-value pairs. Often, they are implemented with distributed hash table (DHT), multi-dimensional tables, etc. A wide variety of distinct families exist under the NoSQL movement. Let’s look at these families now.

Simple key-value store

This is a schema-less data store that allows the application to store its data, and allows it to manage, most often with minimal data-type support. Dynamo (Amazon), Voldemort (LinkedIn) use the Key-Value Distributed Hash Table from implementing their databases.

SimpleDB provides simple key/value pairs, stored in a distributed hash table, but interoperates well with the rest of its cloud building blocks. Dynamo is Amazon’s major research paradigm for non-relational database design, with a simpler model with massive scaling abilities, and extraordinarily high availability requirements. It allows applications to relax their consistency guarantees, under certain failure scenarios. The techniques used to make Dynamo work and perform well include consistent hashing, vector clocks, Merkle tree data structure and Gossip (a distributed information sharing approach).

Dynomite is an open source implementation of Dynamo, written in Erlang. A detailed description of Dynamo is available from Werner Vogel’s paper [PDF].

Table-oriented NoSQL data stores

These are similar to key-value stores, but define the value as a set of columns. An example of a table-oriented NoSQL store is Google’s BigTable. One of the leaders in this space, Google’s BigTable is integrated with its cloud computing platform (Google App Engine) and offers simplified SQL capabilities called GQL.

BigTable and its clones are implemented as sparse, multi-dimensional sorted maps, instead of simple key-value stores. The row, column and timestamp are used to index data. Atomicity is guaranteed at a low-level row (updates to a single row are always transactional). Locality groups provide the ability to combine different columns to impose access control and hints about data that are typically accessed together.

Hypertable and HBase are two open source clones of BigTable.

One of the key differences between these implementations is the underlying file system that actually stores the data. BigTable uses Google’s proprietary file system (Google File System — GFS) while the open source clones use HadoopFileSystem or KosmosFileSystem (KFS). These are open source implementations of Google File System. HBase, in turn, provides additional database capabilities, map/reduce integration, etc.

Document-oriented data stores

These NoSQL key-value data stores are highly structured, and include complex self-defining objects as their values. Many of the popular document databases, such as MongoDB or CouchDB, use JavaScript Object Notation (JSON).

CouchDB defines a basic key/value storage mechanism to store documents in JSON (JavaScript Object Notation) format. It allows the creation of persistent views on top of this data, similar to database tables which can be queried. The storage engine for CouchDB does support ACID properties, and is intended to be a distributed fault-tolerant system. It has the capabilities to scale down and hence, can be used for mobile computing, efficiently.

A similar project is MongoDB, which does not provide ACID properties, but has powerful querying capabilities.

Graph databases

A graph database is a kind of NoSQL database that uses graph structures with nodes, edges, and properties to represent and store information. Nodes represent entities, and properties are information that relate to nodes. Edges connect nodes to nodes/properties representing the relationship. Most of the important information is really stored in the edges. Compared with relational databases, graph databases are often faster for associative data sets, scale more naturally to large data sets, and are more suitable for changing data/evolving schemas. Conversely, relational databases are typically faster at performing the same operation on large numbers of data elements. Examples of graph databases are Neo4j and hypergraphDB.

Various NoSQL implementations differ considerably on how consistency is achieved, what data types are supported, the structure and nature of how the data is stored, and the support of languages/libraries/interfaces for access. Implementations embrace what is best for them by considering how their targeted class of Web services would need to scale.

They also vary in terms of whether the key-values are stored in-memory, on-disk, or both; hierarchically or tabular; duple or triplet; single or multiple value per key, etc. A detailed discussion of NoSQL databases can be found in the paper “No Relation: The Mixed Blessings of Non-Relational Databases”, available here.

What’s around the corner for databases?

The question that has frequently been asked is whether the NoSQL movement signifies the end of traditional RDBMS.

While the NoSQL movement has helped to answer the initial needs of massive data sets of Web 2.0, traditional OLTP and OLAP enterprise applications still depend on RDBMS. Therefore, we expect that both NoSQL and traditional RDBMS would continue to coexist for the next decade.

Regarding the question on whether today’s databases satisfy the challenges of data management posed by the Cloud and Big Data, we should look back at database history for our answer. Recall that the RDBMS revolution enabled the conversion of business data into information, driving business processes and business intelligence. It is not sufficient for NoSQL databases to support high availability, scalability and low latency needs. They also need to provide state-of-the-art analytics, which can power business intelligence while being elastic to fit the cloud environment.

The opinion widely shared by many in the database industry is that, “The real database revolution driven by Big Data and the Cloud is just around the corner.” So we do have a lot of interesting innovations to look forward to in the database space over the next few years.

Why is there a need for load balancers? While managing a Web services infrastructure, Web administrators often find it a challenge to cope with increased website hits, while maintaining high availability of the servers. This situation gets even tougher when a new Web application or functionality is released, attracting more users per day.

Optimisation of server performance is thus a continuous job. Consider a Web server hosting a site running a few applications. When the site gains more users, there are many more page requests. Serving each request uses a definite amount of CPU, memory and network resources. Adding powerful resources can only solve the problem to some extent, while introducing other challenges. When the Web server hits the ceiling in terms of its resource limit, it starts dropping Web requests, which results in a bad user experience — a “broken” Web page.

And if the Web server goes down, for some reason, the entire site becomes non-functional. This can certainly result in a loss of reputation, and in some cases, also a monetary loss for the organisation. To preempt such situations, IT management teams must deploy load-balancing solutions in the data-centre infrastructure. We will soon discuss how a load balancer can not only distribute traffic, but also help ease network operations tasks.

How does a load balancer work?

First-generation balancing devices were implemented around BSD UNIX versions. A new trend of balancing products is typically in the form of an appliance running a Linux distribution; some enterprise-grade appliances use Red Hat or similar Linux flavours.

Figure 1: Typical load balancer setup

Functionally, a load balancer can balance traffic by distributing it among two or more servers. Figure 1 shows a typical Web farm configuration with a load-balancing device that acts as a front-end server to handle all Web requests. Each silo hosts a different set of applications, whereas all servers in a given silo host identical applications.

From the configuration point of view, the device is configured with two separate IP ranges. One is used to handle incoming traffic, and the other, called virtual servers, is used to connect to the nodes under its control. Thus, it forms an agent service between the requesting client and the responding server. It also acts on the requests intelligently, based on the configured rules, to choose a recipient node with the least workload at that particular time.

Rules define how a request should be handled, and also how to handle special conditions such as node preference, session management, etc. The load-balancing device then makes a separate TCP connection with the recipient Web server, and redirects the requests to it, while it keeps track of the request processing.

In the technical sense, a load balancer balances underlying TCP connections, rather than actual Web requests. It is a misconception that a load balancer checks resource utilisation (such as CPU, memory, etc.) on a controlled server. In reality, it simply checks the network response time of a server, which is a result of the server’s overall resource utilisation. Since it acts as a catalyst in improving the scalability of a server farm, it maintains data for each node under its control, like the number of requests processed in history, the response time by each host for requests, the fault trend of each host, etc.

In earlier days, load balancing solutions were implemented around simple round-robin techniques, which did help distribute the load, but did not provide fault tolerance features, since they lacked the necessary intelligence. In today’s advanced data centres, load balancers are used to effectively distribute traffic for Web servers, databases, queue managers, DNS servers, email and SMTP traffic, and almost all applications which use IP traffic. Balancing DNS servers helps distribute DNS queries to servers that are dispersed geographically, which is useful for disaster-recovery implementations.

Using load balancers to achieve fault tolerance

In a server farm, servers often experience downtime due to unforeseen resource failure or scheduled maintenance. These resource failures can be at the hardware level or simply at the software application level. In a business-critical infrastructure, such situations should be transparent, never affecting the user. As discussed earlier, since the balancing device maintains separate TCP connectivity with the controlled node, it can be further used to achieve fault tolerance.

A configurable “heart beat”, called a monitor, is maintained by the balancer with each node. This can be a simple ICMP ping, or an FTP/HTTP connection to retrieve data. Upon an appropriate response from the node, the load balancer becomes aware that the node is live, and marks it as an active participant eligible for the balancing process. If the server or its application resource fails, the balancer waits for a certain period of time for a “heart beat” from the node; upon non-compliance, it marks that node as a non-participant, and removes it from the silo.

Once marked thus, the load balancer doesn’t send traffic to that node. However, it still keeps polling to see if the node is back online, and if found to be so, marks the node as an active participant again and starts sending traffic to it. If a fault situation occurs while the request is being transferred to a node, modern load balancers are capable of detecting that too, and taking (configurable) corrective action.

This feature can further be explored by the operations team for maintenance purposes. A service instance can be configured on a node — for example, a separate Web instance running under a separate IP address, with a dummy page on it. A monitor can be configured to access that page periodically. If the server is to be taken offline for maintenance purposes, the operations person can stop the dummy site, which results in the server being marked as a non-participant.

It can then be shut down or have other administration work done on it. Once maintenance is completed, the dummy site service can be started again, bringing the server back into the silo. This feature can be further extended by configuring many such monitors at the application level that can be reported upon in a dashboard via a network monitoring product, for an operations admin view.

Layer 7 load balancing

Earlier versions of load balancers used to work at the OSI model Layer 2 (link aggregation), or Layer 4 (IP-based). Since the requests flow through the balancing devices, it made sense to read into the requests at Layer 7, to bring additional flexibility in balancing techniques. Adding such flexibility offers higher scalability, better manageability and high availability.

Layer 7 load balancing primarily operates on the following three techniques:

1. URL parsing
2. HTTP header interception
3. Cookie interception

Typically, a Layer 7 rule structure looks somewhat like the one shown below. However, the exact syntax varies for each vendor and device model. As seen in the example, a request is first parsed based on the virtual directory being accessed, then by a particular cookie field’s content, and is finally sent to a default pool, if the first two conditions are not matched.

{
if (http_qstring, "/") = "mydir"
   sendto server_pool1
else{
if cookie("mycookie") contains "logon_cookie"
   sendto server_pool2
else {
   sendto server_pool3
}

Since the request is intercepted and interpreted at Layer 7, the possibilities of adding intelligence grow exponentially. Rules can be configured to distribute traffic based on a field in the HTTP header, the source IP address or custom cookie fields, to name just a few. There are endless possibilities to make intelligent traffic distributions.

For example, if the incoming request is from a smartphone, it can be sent to servers hosting mobile applications. If the request is for a URL that hosts a simple HTML-based site, it can be routed to an economical server farm. If a login cookie is not present in the request, it can be sent to a login server, avoiding loading down other busy servers.

As the Layer 7 rules bring programmability to balancing techniques, they can further be explored for the benefit of the technology operations staff. When a roll-out of a newer version is planned in an existing database server farm, the new set of servers can be configured as a separate pool to perform migration mock-tests, and can be brought online once the tests are passed.

In case the roll-out experiences problems, merely switching pools back to the original settings can achieve a rollback with minimum downtime. As another example, many mission-critical Web farms require to maintain legacy server operating systems for stability reasons, while new applications demand the latest and greatest platforms. In such cases, separate server pools can be configured for new applications, and traffic distribution can be achieved by checking Web request URLs at Layer 7.

Load balancing at Layer 7 also helps improve the return on investment (RoI) of an IT infrastructure. Consider a Web portal which caters to a high volume of users with Web pages that are content rich, with JavaScript and images. Since the scripts and images don’t change quite often, these can be treated as static content, and hosted on a separate set of servers. As a result, the Web servers running important business logic use fewer resources, which means that we can accommodate more users per server, or host more applications per server, and thus reduce the effective cost of hosting. This also proves that a carefully configured Layer 7 load balancer can achieve higher application performance throughputs on a given data-centre infrastructure footprint.

Additional features in a load balancer appliance

Besides powerful traffic distribution features, most industry-grade modern load balancers also come with features which are essential to take additional tasks from the managed nodes, or other infrastructure components. SSL negotiation is one such feature that can handle heavy volumes of SSL handshaking — which would otherwise take a performance toll on Web servers. Another great feature is cookie persistence, which helps applications stick to a particular server, in order to maintain a stateful session with it.

Many new load-balancer trends provide admin features such as traffic monitoring and TCP buffering; security features such as content filtering, and an intrusion detection firewall; and also performance-based features such as HTTP caching, HTTP compression, etc. Since a load-balancing device is a front-end component in a server farm, it comes equipped with high-speed network ports, such as Gigabit Ethernet and fibre connections.

Open source load-balancing solutions

Multiple vendors provide industry-grade enterprise load-balancing solutions, such as F5 networks (BigIP), Citrix Netscaler, Cisco, Coyote Point, etc. These devices are rich in features, provide flexible rule programmability, and exhibit high performance throughput — but they do come with a price tag and support cost.

For those who are interested in FOSS, there are multiple distributions available on the Linux platform, which offer features from simple load balancing to full-featured appliance-grade products. Let’s look at three such ‘most wanted’ solutions.

LVS (Linux Virtual Server) is one famous solution, which has proved to be industry-grade software, and can be used to build highly scalable and available Linux cluster servers to cater to high volumes of Web requests. It comes with ample documentation, which helps build a load-balanced farm, step by step.

Ultra Monkey is another interesting solution, which provides failover features in addition to basic load balancing: if one load-balancer device fails, the other can take over to provide device-level fault tolerance. It supports multiple Linux flavours such as Fedora, Debian, etc.

Another powerful, but lesser-known implementation is Crossroads for Linux, which is a TCP-based load balancer providing a very basic form of traffic distribution. The beauty of this product is that its source code can be easily modified to serve just one task, such as DNS or Web balancing, without any bells and whistles — thus achieving a very high performance for that single purpose.

Configuring Layer 7 rules on a load balancer is an art, and needs a deep understanding of networking protocols and server operations. Features of load balancers can also be used as an aid to the operations and maintenance tasks.

“Postgres Plus is an open source database typically deployed in high profile, mission-critical applications. Our open source products provide capabilities that address a range of enterprise requirements (application development enhanced performance, runtime management, usability, and scalability), which enable organisations to build and deploy applications that solve critical business problems. We also provide 24×7 ‘follow the sun’ technical support, training and professional services needed to support all phases of evaluation, development, deployment, and ongoing production of mission critical systems,” says Ashish Mehra, director India operations, EnterpriseDB Software India.

Based on open source PostgreSQL, which is developed by the largest independent RDBMS community in the world, EnterpriseDB’s Postgres Plus Standard Server and Postgres Plus Advanced Server are products suited for transaction-intensive and mixed-load applications. Typically, Postgres Plus is deployed as an online transaction processing (OLTP) database in support of enterprise applications such as enterprise resource planning (ERM), customer relationship management (CRM), supply chain management (SCM) and other applications that require databases to support high concurrency, performance, scalability, and security.

But with multiple players (both proprietary and open source) in the RDBMS market, what makes Postgres Plus products a cut above the rest?

While the total cost of ownership of a 16-CPU ( four server, four CPUs/server) Oracle configuration is $1,261,600 over three years, the TCO of a comparably configured Postges Plus Advanced Server deployment is $215,760. This would mean a TCO savings of $1,045,840, or 83 per cent.”Ashish Mehra, director India operations, EnterpriseDB Software India

Easy on the pocket

Being open source software, Postgres Plus is cost effective as compared to its strong proprietary counterparts like Oracle, Microsoft, and IBM. Postgres Plus Advanced Server includes a breakthrough suite of compatibility technologies that run Oracle applications with little or no changes at a much lower cost. “The most significant difference between the two databases is around cost. While the total cost of ownership of a 16-CPU (four server, four CPUs/server) Oracle configuration is $1,261,600 over three years, the TCO of a comparably configured Postges Plus Advanced Server deployment is $215,760. This would mean a TCO savings of $1,045,840, or 83 per cent,” says Mehra.

NTT, a Japan-headquartered telecommunications company, couldn’t agree more. They switched from commercial RDBMS products for their telecom business operation and back office systems to PostgreSQL and have availed significant cost benefits. “We originally estimated to save $20-30 million for five years by deploying PostgreSQL to in-house systems. But after adding Postgres Plus Advanced Server to our options, we now estimate the savings to double,” testifies Takeshi Tachi, senior manager, NTT Open Source Software Center, Nippon Telegraph and Telephone Corporation.

InMobi Global Media Adnetwork, formerly mKhoj Solutions, that opted for EnterpriseDB in 2007, saw similar savings. “We chose Postgres Plus to solve our pain areas, namely, scalability and support issues. Postgres Plus was one-tenth the cost of other RDBMS. Further, we have seen huge cost reductions in our IT costs thereafter,” says Mohit Saxena, VP (technology), InMobi Global Media Adnetwork.

We chose Postgres Plus to solve our pain areas, namely, scalability and support issues. Postgres Plus was one-tenth the cost of other RDBMS. Further, we have seen huge cost reductions in our IT costs thereafter.” Mohit Saxena, VP (technology), InMobi Global Media Adnetwork

Apart from the most obvious way of reducing IT expenditures by saving on commercial licensing fees, EnterpriseDB offers numerous strategies for organisations to cut costs. New line of business (LOB) application development and deployment, replication for reporting and business intelligence, and migrating non-mission critical and mission critical applications away from high-priced commercial databases are some leading strategies. “Query, reporting and BI activities degrade the performance of OLTP applications. By offloading those queries to lower-cost non-production databases, Postgres Plus’ replication capabilities can provide real-time data warehousing at a fraction of the cost of Oracle’s replication solutions. This eliminates OLTP performance problems while ensuring timely delivery of critical information to business stakeholders,” says Mehra. For example, FTD, the worldwide leader in floral-related products and services, implemented the Postgres Plus Advanced Server Replication Server module to improve performance of their production systems while still meeting the needs of their vendor network. “By moving their vendor-facing order tracking system away from their Oracle-based production environment and onto replicated systems running on Postgres Plus Advanced Server, the performance of their production systems increased more than 400 per cent during the next peak ordering season – all while reducing the cost of operating this system by more than 80 per cent,” says Mehra.

Rich features

The fundamental features of Postgres Plus Standard Server and Advanced Server distinguish them from their primary open source competitors, like MySQL and Ingres. “PostgreSQL contains a single unified storage engine capable of performing extremely fast for all load types: OLTP (with full ACID support), reporting and mixed usage. MySQL, on the other hand, has pluggable storage engines specialised for particular types of usage; this type of configuration can result in bottlenecks as applications grow and change. Subqueries, too, are poorly optimised in MySQL. Further, user defined data types in Postgres Plus give users more options for customised solutions than MySQL, also building room for database enforced encryption,” says Mehra.

The Oracle compatibility features found in Postgres Plus Advanced Server distinguish it from its distant cousin Ingres, another strong open source database competitor. “EnterpriseDB has added powerful and convenient Oracle features to Postgres Plus Advanced Server that are standard fare in the minds of many DBAs and developers, such as: function packages, dynamic runtime instrumentation, query optimisation hints, Oracle SQL extensions, explicit transaction controls, and data dictionary views,” says Mehra.

Further, Postgres Plus Standard Server and Postgres Plus Advanced Server come with many productivity tools like Postgres Studio (graphical tool for database and cluster creation/maintenance, SQL environment, and more), EDB SQL (SQL command line environment), EDB Loader (bulk data loader with error handling), DBA Management Server (for DBAs to handle monitoring, job scheduling, SQL terminal, software update management), DBA Monitoring Console (for resource usage and management), GRidSQL Monitoring Console for distributed data, and the Oracle Replication console.

Performance enhancer

EnterpriseDB’s Postgres Plus products have multiple features across many facets of the database to help improve performance. While GridSQL partitions data across multiple machines and transparently performs queries, Asynchronous Pre-Fetch can optimise regular index scans and bitmap index scans by issuing concurrent I/O requests to RAID (Redundant Array of Inexpensive Disks) hardware on Linux systems. On the other hand, Multi-Version Concurrency Control (MVCC) allows for high performance in applications that are both read and write intensive.

The best example of performance enhancement using Postgres Plus is hi5, a leading social networking site that deployed OLTP PostgreSQL installations, running on hundreds of servers. “The system supports the data transactions of more than 56 million active users each month. In June 2008, the company delivered more than 18.5 billion page views that were supported by PostgreSQL, serving nearly 11 million visitors to the site every day,” boasts Mehra of Postgres Plus.

NTT, too, saw better performance when they deployed Postgres Plus for transactional telecom business applications. “We deployed PostgreSQL for years, but earlier versions resulted in performance degradation in long-time operations requiring periodic data-vacuum operation. After PostgreSQL 8.3 released in February 2009, the performance degradation had been completely resolved, and EnterpriseDB has contributed significantly to this improvement,” says Tachi. Adding on, Saxena says: “Postgres Plus is the heart of our growth. With every release we have been setting new performance benchmarks. Postgres has helped us achieve even [previously thought] unachievable levels. This needs to be seen in the light of the fact that we are yet to use the capacity of Postgres Plus to its fullest.”

Scalability

EnterpriseDB solutions are highly scalable. Postgres Plus Advanced Server with the GridSQL configuration allows a single database to be partitioned across multiple commodity hardware machines for expandability. “InfiniteCache is a Postgres Plus Advanced Server feature providing an infinitely expandable cache across commodity hardware providing flexible growth management. The compression technology allows multi-gigabyte databases to reside in memory for lightning fast performance,” says Mehra.

Vouching for it, Saxena says: “InMobi is in a business where our traffic and our volumes are bound to grow exponentially. This is why we chose Postgres Plus and have faced no scalability issues so far. Today, we have two data centres in India and US. We plan to expand to Japan and see no problem with regard to managing databases so far.”

Strong technical base

Postgres comes with strong technical base and support. The Postgres community provides robust and well-tested fixes and enhancements across multiple platforms. Postgres user communities (like User Groups) provide a wealth of collaborative information to users, ensuring vendor independence and a strong ecosystem. This is where Postgres surpasses competitors like Ingres with no community outside of the Ingres Corporation.

Foolproof support

EnterpriseDB’s foolproof support has resolved the migration woes traditionally faced by organisations adopting open source RDBMS. EnterpriseDB offers a wide range of support options for Postgres — from free assets such as tutorials, product documentation and technical whitepapers to for-fee training, services, consulting, and subscription offerings. “Our training classes are developed and run by Postgres community’s leading contributors, like Bruce Momjian. Our Jump Start and Packaged Services offerings, like RemoteDBA and Architectural Health Checks, enable organisations to quickly develop skills and insight for fast realisation of the benefits of Postgres Plus,” say Mehra. “Migration involves two things – customisation and support. Migration is very easy with EnterpriseDB as they have plug-ins for all our existing databases. Further, their support is unmatchable. We use remote support from them,” testifies Saxena.

NTT, too, would vouch for it. Though their initial migration from commercial DBMS to PostgreSQL was a struggle, migration to Postgres Plus Advanced Server thereafter was a cakewalk. “Our estimates show that the total effort of [our] system migration project using Postgres Plus could be halved compared to the migration using the plain PostgreSQL,” says Tachi. The smooth experience has made NTT Japan look at migrating legacy accounting systems from commercial OS and DBMS to Linux and Postgres Plus Advanced Server. “We estimated this migration to be troublesome and not compensate the licensing cost saving before, but now we feel it is worth to try by deploying Advanced Server (Postgres Plus),” says Tachi.

Road ahead!

Today, EnterpiseDB employs over 100 associates worldwide, supporting more than 300 customers. Its business partners include Red Hat, Synnex, Compiere, Tomax, Contegix, Thunip, Elastra, immixGroup, Fujitsu, IBM, Continuent, and many other IT bigwigs. With EnterpriseDB winning consecutive trophies for Postgres, we might see them perform the same magic that Red Hat did for Linux. History sure does repeat itself!