Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 7 years ago
viewed 13898 times
Share this article


On April 12th, 2010, CUBRID globalization team consisting of three members participated at the MySQL Conference & Expo. Many attendees were surprised to see CUBRID at the conference. Their faces were full of questions: CUBRID? At MySQL Conference?

cubrid-vs-mysql.jpgAs the conference proceeded, most common and most intriguing question was "What is the difference between CUBRID and MySQL?" Below we provided one of the differences between these two database solutions, though there are many more.

CUBRID is a fully-featured Database Management System just like MySQL, but faster, especially in those cases when a web application generates huge concurrent requests.

For instance, assume you have a bulletin-board system, or a blogging system, or a forum web site, or, simply put, a web application which has hundreds of thousands of articles and tens of thousands of visitors, i.e. the high traffic web site. Typically, what you want to do is to keep track of how many times a certain article on the web site was viewed by users. This is a common and most frequent request done by such systems.

In this case, once a user clicks on an article title, the system has to display the contents of this article as well as increment the table field, let's say read_count, by 1, saying that one more user has viewed the current article. In order to perform these operations, on the back-end of the system the database administrator usually makes two separate requests to a database server. Here is the pseudo-code of these two requests:

1. SELECT article FROM  article_table WHERE article_id = 130,987

2. UPDATE article_table SET read_count = read_count + 1 WHERE article_id = 130,987

Does anyone see any problem in these requests? The problem is hidden in the second UPDATE query. What is it? The UPDATE query does generate a long-lasting and expensive lock of the working record. It usually takes somewhat 5 to 10 ms to update the record. What if the current record is a hot-spot? It will generate a considerable delay if thousands of concurrent visitors click the same article at the same time. Then, this makes a sense.

So, how does CUBRID resolve this issue? We introduced many unique optimized features in CUBRID 2008 R2.1, which, in fact, do not exist in other database systems. One of such is so called Click Counter. In order to perform the above mentioned task, CUBRID does not require a database administrator to make two separate requests. Instead, CUBRID has a build-in query-function, in this case INCR(), which almost does not lock the record.

1. SELECT article, INCR(read_count) FROM  article_table WHERE article_id = 130,987

Once SELECT query is run, CUBRID increments the mentioned table field by 1 on the fly and automatically returns the updated data to the user. Thus, CUBRID DBMS processes up to six times more queries than other Open Source or Proprietary Database Solutions, i.e. more users are served at the same time, less delay, more performance, higher user satisfaction. We do not claim that CUBRID is a replacement for MySQL. It is an alternative database solution which runs faster. We do not suggest anyone to replace their MySQL with CUBRID, unless you need a faster solution and you know what you are doing.

For more information on CUBRID Benchmark Test Results see:

comments powered by Disqus