posted 3 years ago in CUBRID Life category by Esen Sagynov
Recently we have released CUBRID 3.1 Beta, and learnt what new features it brought to CUBRID users. Besides the new BLOB/CLOB data types, CUBRID 3.1 introduced the new HA (High-Availability) Monitoring feature. CUBRID Manager has also been improved. So, what's next? What comes with CUBRID 3.2? Should we wait for something extraordinary? Indeed, yes!
In CUBRID 3.2 roadmap there are four milestones created (the level of completion is fixed as of Dec. 3, 2010):
- 100% Completed
- 100% Completed
- 67% Completed
- 21% Completed
This is the second time CUBRID is introducing a massive support for MySQL syntax. The first partial MySQL syntax support was enabled in CUBRID 3.0 when 62 new SQL syntax extensions and other enhancements were introduced. In this second phase of MySQL Compatibility Extension the following items will be implemented (most of them have already been completed):
- Syntax Enhancements
- SHOW Statements
- Date/Time functions
- String Functions
- Aggregate Functions
- Other Functions
CUBRID is all about the increased performance and high optimizations for Web applications. In CUBRID 2.2 INSERT query performance was dramatically increased by modifying an algorithm to achieve I/O load balancing when the INSERT operations are concentrated at a certain point of time. Besides, the Increased Space Reusability was another performance enhancement in CUBRID 2.2. This time CUBRID 3.2 will be released with substantial index enhancements. This will be achieved by:
- Covering Index Covering index can produce dramatic performance improvements when all columns needed by the query are included in the index. With Covering Index, if you create an index on each column referenced in the query’s SELECT list and in any WHERE, HAVING, GROUP BY, and ORDER BY clauses, CUBRID will execute the query by accessing only the index.
- USING INDEX Clause CUBRID will support KEYLIMIT in USING INDEX clause in order to limit the results returned by index scans. When executing a query that has a USING INDEX clause, if no index is specified for certain tables, CUBRID optimizer will take into consideration all the available indexes for those tables.
- Fully utilize index on grouping and ordering When all the columns in GROUP BY or ORDER BY are included in an index, CUBRID will use that index for grouping and ordering.
- Enhanced Next-Key Lock CUBRID’s next-key locking algorithm is expected to be modified to lock key values, not tuples. The improvement should make use of algorithms described in C.Mohan’s ARIES/IM, and ARIES/KVL papers.
- Index Scan with LIKE Predicate CUBRID will be able to rewrite LIKE predicates with host variables into range predicates, in order to use those predicates in index scans.
- Descending Index Scan
- At this moment CUBRID only supports scanning of an index for ascending order (i.e, from left to right). Descending order scanning of index is expected to show increased performance of insert/update/delete operations.
- Limit Optimization Because the most of queries have limit (rownum, ordeby_num, groupby_num) filter, it is very crucial for performance.
CUBRID HA Feature Improvements
Many aspects of the CUBRID HA feature is going to be significantly improved for stability, functionality and convenience purposes in CUBRID 3.2. You can read more details about it in my next blog Overview of New High-Availability Features in CUBRID 3.2.
These are the major performance enhancements CUBRID 3.2 is expected to have by February of the next year. Is there anything else in your opinion that CUBRID should focus on in its next releases? Join this conversation by leaving your comments below.
More information about the current state of CUBRID 3.2 implementation can be found at the following resources: