Oracle team helps to integrate enterprise systems and improve database performance
Wu Chengyang, vice president of Oracle and General Manager of the Greater China technology product department, stressed that the integration of information systems is an important measure for enterprises to transition from the big data era. database construction should be considered at the platform layer, instead of the application layer, this avoids the formation of information islands. When developing relational databases, Oracle Enterprise databases should be the first to be promoted.
What aspects should CIOs consider when selecting database platforms?
I think one of the problems that enterprises often talk about today is integration. Why are you talking about integration? Because integration is a lot of things that are not integrated now, it is an information isolated island. Because there is an information isolated island, integration is required. On the other hand, why does the information islands exist? No one wants to make it an isolated island when building a system. The reason is that when the CIO chooses to build an entire enterprise system, it wants to be driven by applications. That is to say, he is constantly building an application. For example, I want to build an ERP application, for example, I need to build a personnel application, and so on. There are various applications and risky applications. In this way, you will find that every application has been created, but when he has established 10 or 20 applications, for example, a bank has at least 70 or 80 applications, and after building 70 or 80 applications, he discovered that there was an information islands between the original application and the application system, and then he began to want integration. In fact, if you think about the platform layer issues when you choose, you can solve the problem of information islands to a large extent in the early stages, rather than after-the-fact solutions. In this platform layer, the most important thing is to consider the database first. The selection of your data database is very important. Therefore, if I think I give CIOs the first suggestion, you should first consider building a platform, not only do you need to build a variety of applications based on your business needs, but the platform is also very important. In this way, in terms of database selection, I think the important thing is that you should choose a database as a cloud service.
You may ask, how do you create cloud services for databases today? We all know that there are many types of databases. Oracle is of course the most important relational database. Oracle's market share is also very high, exceeding 50%. But you will find that there are some other databases, and even some open source databases. For example, MySQL, which is very famous in Oracle, also has some others, such as non-relational databases, such as noSQL. How can we choose these things? Since you want to build a database service platform, you should first understand what you are relational and what are non-relational. This is the most important point. Today, you cannot use a relational database to solve all non-relational and relational problems. The world is not just a black-and-white world. To put it simply, for example, we know that noSQL and Hadoop are very important in non-relational systems. This is the most famous technology, there is a trend in the industry that I can use Hadoop to solve all problems, not only non-relational problems, but also relational problems. This option is incorrect? First, I can tell you that this answer is definitely incorrect. Why? Hadoop is actually a technology invented by Google, but today, even in Google itself, its relational databases are also addressed by relational databases, rather than Hadoop.
The second problem is, can I use MySQL to solve this problem? Since I agree, I don't need Hadoop to solve this problem. Can I use MySQL to solve this problem? MySQL is also a relational database, but it is only open-source. First of all, it should be clear that all enterprise databases of Oracle and MySQL Databases of Oracle come from the same company, Oracle. MySQL our positioning is to solve some simple transactional work, while the enterprise level is the enterprise level database of Oracle. We all say that I can solve it either at the enterprise level or with MySQL, whether you want your investment to be at the database or the entire application layer. Because MySQL cannot support a large amount of data, it is required to split the database.
For example, if you are a cook, you want to have a variety of ingredients behind you. Your ingredients include meat, fish, and vegetables, there may be some other ingredients. Are you using a big refrigerator or several small refrigerators. If you divide it into several small refrigerators, you need to make it clear that the meat is in the No. 1 refrigerator, the fish is in the No. 2 refrigerator, and your vegetables are in the No. 3 refrigerator. If you have a variety of ingredients, you must be very clear. Therefore, at the application level, you must be sure that I want to fetch meat from the first refrigerator, but if you say that Oracle's relational database, enterprise-level databases are placed in a big refrigerator, the whole is a one thousand-litre refrigerator, where everything is put in, as long as it is inside, you can get what you want. This is actually an Oracle relational database, which is a simple example of the difference between MySQL and MySQL.
That is to say, you choose Oracle enterprise-level databases. For you, you do not need to do too much work at the application layer. If you choose MySQL, you need to do a lot of work at the application layer to ensure that your database shard can meet the requirements of your entire system. In this case, you have to make a choice, not to say that MySQL cannot be used, but to what exactly you need. For CIOs, I just want to do some work at the application layer, and then I split it into every database. Is that all right? The answer is yes. But there is a problem that you should never forget. First, you need to rely on this integrator for a long time. In this way, you have a high demand for the integrator and a high dependence on it. To some extent, he is bound by an integrator. This is the first problem.
The second problem is that in the future, the database is not only important, but also many options. If you use a camera, you will know that the camera will be equipped with a variety of lenses. The camera can take a lot of photos, which is very closely related to the camera. There will be fewer options on MySQL, and there will be a lot of options on Oracle, these functions are not required. For example, security, such as data consistency, and so on, all have various options. Therefore, after you use MySQL, you need to find someone to develop these options so that you can achieve performance. So you can see that if you choose MySQL, the answer is theoretically acceptable. The question is, are you willing to invest so much resources to do such a thing, we can actually see the popular methods in the industry. You leave these professional tasks to professional people. In fact, as an enterprise, database development, option development is not your strength, but your strength is your business.
Therefore, you should give the database affairs to professional database personnel, which is done by Oracle. So in general, we give CIOs suggestions. First, when you choose your application, when you choose the entire system, you should not only consider the application layer, but must select the platform layer, to reduce the risk of information islands in the future. When selecting the platform layer, the most important thing is the database and database selection. It is impossible to use Hadoop to solve all the problems today. In turn, using MySQL as an open source database, compared with Oracle, it can indeed solve the problem of relational databases. However, the problem is that everyone's value orientation is different. If the total cost of ownership is determined, it must be that Oracle's enterprise-level database has a better TCO.