In the world of relational database, we are all aware of the benefits that row oriented databases deliver to businesses. They have been designed to support the relational model, have driven the broad adoption of an approachable open language for managing data (SQL), and have been the foundation for high transaction applications including online airline reservation systems, massive online commerce solutions and massively multiplayer online games.
Over the course of many years these entrenched row oriented databases have been challenged by the likes of object/relational, NoSQL solutions and even Map/Reduce (though it is certainly not a database). Sometimes row-oriented databases are either overkill or not a suitable fit for the task at hand. NoSQL differs significantly from the row oriented relational database, especially when it comes to dealing with large volumes of unstructured data. As an example it may be useful for rapidly storing and retrieving large volumes of user profile data or applications that don't have heavy transaction processing requirements. One may choose a NoSQL solution for a particular project where it would be considered a best fit. This doesn't mean the company is going to toss out a row oriented transactional database like Oracle or DB2.
This is the same case for columnar databases like Infobright.
Infobright was designed to be a low footprint, easy to use, self-tuning, high performing and low cost solution for handling analytic style big data and queries. We never position ourselves as a database for handling heavy and intensive transactional queries with lots of DML (inserts/updates/deletes). Based on the relational model with MySQL compatibility, we at Infobright find ourselves frequently operating side-by-side the transactional system or replacing transactional databases for projects where they simply had trouble satisfying the analytic needs of the business. In many cases, executing analytic style queries against a transactional database while that database is also handling large volumes of transactional data can bring the system to its knees, causing a great deal of contention and very poor performing queries. Infobright can sit side-by-side these transactional systems, ingesting data at a pretty rapid clip to support the analytic requirements that would have challenged the transactional row-based relational database. This is a perfect fit for Infobright technology.
Therefore, when considering a project that involves lots of analytic data and analytic queries, where you want to avoid contention with your transactional database, Infobright would be happy to sit by side with your transactional system, where rows and columns can definitely live together.
Post Comment