Why is Orm performance better than ibatis? ZZ javaeye

There are many layers of cache, including Web Server front-end cache, dynamic page static, page segment cache, query cache, and object cache. Different levels of cache apply to different application scenarios and have different roles. If you can, you can use them all together. They are not in conflict, but this topic is quite large and will not be discussed now. For OLTP web applications, as long as there is no problem with the quality of code writing, the final performance bottleneck is undoubtedly database query. The application server layer can be horizontally expanded, but the database is a single point and it is difficult to horizontally expand. Therefore, how to effectively reduce the database query frequency and reduce the database pressure is the root cause of Web application performance problems. All of the above cache methods can directly or indirectly reduce database access, but cache is applicable in scenarios. Although news websites are very suitable for Dynamic Static Page technology, however, e-commerce websites are not suitable for static dynamic pages, and there are not many scenarios for page caching and query caching. However, object caching is the most widely used in all cache technologies. For any OLTP application, you can also use Object Caching even if real-time requirements are high, and it is a good ORM implementation, the object cache is completely transparent and does not require hard coding of your program code. How to Use object caching without using object caching is not a matter of tuning skills, but an issue of the architecture of the entire application. Before you develop an application, you need to know what the final scenario of this application is? The number of users and data volume. How will you deploy this application: OK, maybe you prefer SQL, So you choose ibatis. In the database design, large tables have many redundant fields and will try to eliminate the associations between large tables. When the number of users and access volume are high, you will choose to use Oracle, hire senior dBA for database optimization and SQL optimization, which is the path most companies are going to do. But I tell you there is another way to go. You can choose an ORM (not necessarily hibernate). In the database design, you can avoid large tables, more table associations, and perform operations in an object-oriented manner through the Orm. When the user volume and access volume are high, in addition to the Optimization on the Database End, you also have the object cache path. How does object cache improve performance? For example: On the Forum list page, you need to display the topic's paging list, the name of the topic author, and the author of the topic's last reply to the post. If ibatis is, what are you going to do?   SQL code Select... from topic left join user left join Post .....   You need to join the user table to get the name of the topic author. Then you also need to join the post table to get the final reply post, and then join the user table to get the final reply author name. Maybe you said, I can design table redundancy, add username in the topic, and add username in the post, so the complex table Association is eliminated through large table redundancy fields:   SQL code Select... from topic left join Post...   Okay, not to mention the maintenance of redundant fields, it is still the association query of the two large tables. Then let's see how the ORM works?   SQL code Select * From topic where... -- paging Condition   This SQL statement is easier than the associated query above. Maybe you said, no, what about the author's information? What about the reply author information? Are these SQL statements not sent? If SQL is sent, isn't that the notorious n + 1 problem? You are right. In the worst case, there will be many SQL statements: SQL code Select * from user where id = topic_id ...; .... Select * from user where id = topic_id ...; Select * From post where id = last_topic_id ...; .... Select * From post where id = last_topic_id ...; Select * from user where id = post_id ...; .... Select * from user where id = post_id ...;   In fact, n + 1 is simply a 3N + 1 SQL statement. Why do you still say that the ORM performance is high? Because the object cache is working, you can see that all the subsequent 3N SQL statements are primary key-based single table queries, the 3N statements can all hit the cache in ideal conditions (busy web sites. In fact, there is only one SQL statement:   SQL code Select * From topic where... -- paging Condition   Compared with the large table join query after the condition query of a single table is simplified through field redundancy, when the data volume reaches a certain level (tens of thousands ), the query speed will be at least one order of magnitude, and the pressure on the database is very small, this is the real power of object cache! For further analysis, if ORM is used, we will not consider the cache, so it will be 3 N + 1 SQL statement. But is the execution speed of the 3N + 1 SQL statement slower than that of the ibatis large table join query? Not necessarily! In the case of ORM, the first SQL statement is a single-Table conditional query. In the case of indexing, the speed is very fast, and the next 3N SQL statements are single-Table Primary Key queries, in a busy database system, almost all the SQL statements hit the data buffer of the database. However, using ibatis for large table join queries may result in full table scanning, which has very poor performance. So the conclusion is: even if no object cache is used, the performance of the n + 1 SQL statement OF THE ORM may still exceed the associated query of the large table of ibatis, and the pressure on the database is much lower. This conclusion seems incredible, but after my practice, it turns out to be a fact. The premise is that both the data volume and access volume are relatively large; otherwise, this effect cannot be seen. Take the application scenario in the preceding example as an example. Because the javaeye website uses ror activerecord, this scenario actually sends 3 N + 1 SQL statement. I can see from the log that this dense SQL statement is really worried about performance, so I tried to use the find: Include option to go to eager fetch, forcing activerecord to send a single complex association query. Unfortunately, after comparison in the production. log of the website server, we found that after using: include, a single complex association query takes more time and the database pressure is greater. After memcached is used, the performance of the 3N + 1 piece is improved significantly. Therefore, the performance comparison is as follows: Orm + cache> ORM n + 1> ibatis association query So why can the application cache further improve the performance because the cost of accessing the cache is much lower than that of accessing the database. The application uses the primary key to get the value from the cache server. This is a very simple algorithm with minimal overhead. The process of sending an SQL statement for primary key query to the database involves a complex process, including SQL parsing, execution plan optimization, placeholder parameter substitution, read-only transaction protection and isolation, etc, in the end, although it also hits the data buffer of the database, the overhead is indeed large. Berkeleydb is an excellent proof. It claims that its query speed is 1000 times that of Oracle, not because it is better than Oracle, but because it is essentially a large cache, no additional overhead for queries.     Bytes --------------------------------------------------------------------------------------------------------------------------- I have never used ibatis, so it is hard to say performance problems. However, it is easy to use. The new company is ibatis, and this article mainly refers to the cache of hibernate. Is there no cache for ibatis? This article is really unconvincing. Therefore, if you do not select the best one, select the most appropriate one. This fit depends on the needs of the project, the characteristics of the technology, and the mastery of the technology by software developers.