!!! This article has participated in the "Newcomer Creation Ceremony" event to start the road to gold creation together. For more dry goods articles, you can visit Cainiao
[Mandatory] The use of stored procedures is prohibited. Stored procedures are difficult to debug and extend, and have no transferability.
In fact, this sentence is enough to explain the problem. Some small partners will definitely wonder why they use stored procedures a lot when working in companies such as banks or securities? That's what we're going to talk about today, the first two questions
1. Why banks are using stored procedures
Such systems as banks usually use commercial databases such as Oracle, DB2, etc. These suppliers should have complete solutions that can help banks avoid a lot of risks. Some peripheral businesses of the bank will use some domestic distributed databases or open source databases such as MySQL.
Banks are data-centric, and in the early stages of business construction, banks did not have good domestic databases, so they purchased databases with successful experience such as Oracle and DB2. And each database has its own set of stored procedure development methods. As long as you master the development skills of stored procedures, there is no problem with the data interaction process. The front-end use of go, java, and c++ is the second concern.
But in recent years, Internet companies are disabling stored procedures.
1. Closed source
First of all, in fact, to go to IOE (for localization), it should be because some databases are not open source, you don't know whether your core data will be stolen or not. 2. Data migration
If it is possible to cut the database, data migration is a better way to migrate, but a large number of stored procedures must be rewritten. Once rewritten, who can ensure that the new stored procedures will be executed without problems on the new platform. Who dares to bring risks to the core business.
Although I have been shouting to go to IOE, I will use open source databases such as Mysql to make some attempts in some peripheral businesses, but the core business is still Oracle, DB2 and other databases.
3. Problems in distributed scenarios In the case of horizontal sub-tables, it is impossible to use stored procedures to process the analysis results of all data. Stored procedures should only act on locally fragmented databases.
4. Database pressure surges Everyone knows the distributed cache architecture. The purpose of this is to screen from top to bottom, and to make a small number of requests to the database as much as possible to reduce database pressure. It should be eighty or ninety percent of the processing speed, all at the database SQL level.
It should be because the stored procedure itself is at the database level, and many caches before are futile, and when the data is finally processed, it is still necessary to go to the stored procedure for processing.
5. Distributed global transactions cannot be guaranteed If we process data import in a horizontal sharding situation, the data should be evenly distributed in each table. If shard 1 and shard 2 are successful, shard 3 should be rolled back because a certain field has failed to pass the test. Can the data of shard 1 and shard 2 be rolled back through the stored procedure of shard 3? What about the state data before the import.
Obviously it is impossible, and there is no API for cross-process database interaction at the database level, so the stored procedure is not easy to use in distributed scenarios.
6. Difficult to debug, no built-in version management scheme
Many students have experienced this. When we are dealing with millions of databases, it is very likely that it should be a field of a certain row, which will cause the stored procedure to execute abnormally. How can you quickly find that one from the millions of databases? , this is quite laborious.
7. Fragmentation of business execution In the scenario where the bank should be the core business, the bank will let its employees write stored procedures to process business data such as running water and bills. The developers of the peripheral outsourcing system do not know so much about the core business. You only need to call the stored procedure written by the bank employee, of course, this is also a clear responsibility.
But there is a particularly disgusting thing. If the execution of the stored procedure fails on a certain day, the abnormal information received by the peripheral system is very small. It may only prompt, a certain row of the stored procedure, the abnormal time, and do not know the data scene at that time. As an outsourcer, you can only guess which piece of execution is abnormal, and then locate which stored procedure called an error according to the local log, and then go to the database to analyze the abnormal execution according to the database. Thinking about it makes my hair go numb, is this the case, I understand everything.
an interesting post