“I can't just walk with the flag“ Postgres - our everything ”. We need to prove with our hands that this works ”- Alexey Lustin
Our current source is Alexey Lustin , IT evangelist in the world of 1C, infrastructure engineer in the DevOps and NoOps concepts for 1C.
Alexey and his colleagues are engaged in professional services for businesses working with the 1C platform. They teach clients how to effectively use 1C on a bunch of PostgreSQL + Linux. It turns out that very often the problem lies not in the platform itself, but in inept operation. At PG Day'17 Russia, Alexey will hold a master class on switching to PostgreSQL for 1C under the code name Fighting fears .
In the framework of today's publication, Alexey will vividly show why the methodology they propose is successful. And it will explain in no less detail what practical skills you will acquire at the master class.
')
PG Day: Alexey, tell us about yourself. Who are you, what do you do, how did you come to your specialization?
Alexey : I call myself an evangelist for Automation Driven Development . This is such a concept “from the automation of IT staff activities”, so that developers and infrastructure workers get rid of the routine and free up time for interesting work. For the last four years I have been trying to make friends two worlds with the help of the concept of CICD (Continuous Integration and Continuous Delivery): developers and infrastructure engineers. For this, our team was organized. And the main priority is on the “world of 1C”, as the least automated from the point of view of the process.
How did we come to this? In large companies, a lot of regulations. To comply with them requires a manual process. To do this, allocate "manual" people. When we come to large enterprises with an audit, we find that 80-90% of the time the employees spend on this routine : update the base, measure performance, monitor, draw conclusions, and carry out manual tests. 80% of the time completely inefficient work. It is justified in terms of the risks of the enterprise, I agree with that. We understand that in a large company, such a number of regulations was born as a response to some kind of accident and everything else. Only these 80% are an obvious candidate for automation.
By the way, “IT-specialists” for some reason are often considered to be a servicing division, and not a salary. Nobody thinks that by reducing the routine, you can start doing interesting things. It is more efficient to automate a business, to invent something breakthrough for your own startup - to test a new hypothesis or to cut down a bubble.
From this “jumps away everything” that we do with our hands.
For business, since the 2000s, the 1C platform, which, starting from the old version 7.7, works on the Microsoft contour and on the MS SQL DBMS, is considered to be the most effective. I have a certain vision of why this is happening. Initially, Microsoft was enough breakthrough technology in the world of DBMS. Postgres was then a lot of Linux (version 8, and so on), and, probably, the company 1C itself was not very interesting. Then the main thing was to get a quick result. This is MS SQL did. It is considered that MS SQL is stable for 1C. In general, this is probably the case. His query optimizer begins to cope, and does not show errors in the design of the tables and the relationships between them. A logically erroneous project on 1C in conjunction with MS SQL, launched on some minimum amount of data, begins to fail only after certain thresholds. And in Postgres, these errors are detected even at the initial stage of the start of the information system - logical errors in the structure of the DBMS immediately take off, you immediately see misunderstandings, everything works slowly. Therefore, usually everyone starts to scold Postgres, no one ever scolds developers.
I say this: 1C and Postgres work well! The problem is not in them, the problem in the competence of the owners of the circuit. Even on large volumes of databases there are precedents. For example, when the total amount of databases with compression is terabyte and more (there are also such installations). But, as practice shows, they are directly proportional to the level of competence of the owners of this circuit - developers and devops. Their competence level is much higher than those who own the same installation with the same amount of data and transactions per second in MS SQL. There you can put incomprehensible comrades, and they will code something, MS SQL compensates for their low level of competence. The difference is not in Postgres and MS SQL - the only difference is competency.
Hence the whole story with courses, github accounts and various scripting publications. Personally, my social goal is to ensure that performance experts in the 1C-world (in fact, system administrators who administer the entire circuit - and the application server 1C, and DBMS) increase their level of competence.
How did I come to this? Imagine that you have two hundred 1C nicknames in training, and the task is to run at least 100 information systems on linux. The last five years ago I had such a magical experience: it was necessary to shift the strategic focus from the MS SQL contour to Postgres. In 2006, within the framework of Infostar, we organized the 1C + Postgres community (calculated more for geeks). We were given the task to migrate at least some of the systems on Postgres. It turned out that the problem is not at all in Postgres and not in 1C. The problem is precisely the competence level of administrators who are responsible for the DBMS, and 1C-nick, and developers, and so on. They simply cannot test their hypotheses when PostgreSQL is used as a DBMS. It seems to them that they are deployed quickly on a productive basis - and everything will work by itself. Then just have something to tweak. With Postgres, this is not possible.
Well, I can say about myself. Since I am an evangelist of engineering practices DevOps, I have to prove with my hands that it works. I can't just walk with the flag "Postgres - our everything". They say to me: "Prove it." I sit down with the team (we are not very many, by the way), and we, through wagons, dockers, and all sorts of automated scripts, prove that we are right. We are convinced that we are not just populists.
PG Day: You have touched upon an interesting topic - the problems of transition from the Windows MsSQL platform to Linux from Postgres. What advice, based on your practice, do you give to eliminate these problems when you are asked to help with making this transition?
Alexey : We have a certain check-list, called “struggle with objections during the transition.” 1C produce typical information systems. Now it’s usually like: if you want to deploy a comprehensive enterprise automation (starting with a salary and ending with financial accounting). Install 1C - you will get full ERP and go ahead, go into business, do not bother with automation. In that case, you win.
But when “biznesmenish”, it is forced to refine itself , “podrichtovyvat.” We have to hire developers and infrastructure managers at various levels. And they "finish" you. Over the past fifteen years, 95% of 1C installations are atypical. There are statistics that in Russia there are about half a million different atypical installations. They were "dopilivali" some comrades for a particular businessman, with different levels of quality. If the “parent” company releases an information system in which the structure of the tables is more or less debugged (because within the 1C company, the models are still debugged: both the IDEF diagrams and ERwin, probably - everything works fine there). When it comes to a particular businessman, the developers “finish”, and they may not know anything about the data model, or about the theory of sets. Can roll data scheme is simply impossible.
Therefore, the first objection with which we are fighting is whether the system will start at all. First you just have to show. It is possible to unload the entire information system and load it into another DBMS circuit, this is their cool feature in the 1C world: you can make the transfer not with pg_dump or MS SQL backups, but with your own internal tool. So, you take and transfer to the Postgres circuit.
However, there is one feature - it’s better to install the 1C server not on Linux, but on Windows, because of problems with the active directory and the kerberos library. This is not due to Postgres, but with the kerberos static linking feature of CentOS, under Ubuntu, and not only. In general, there is such a recommendation that you only install Postgres on Linux. At the same time, you strongly resist not to run it on Windows. You leave the Windows server running 1C and transfer the base. You measure how much time the base will be transferred - to deploy from the backup and move to a productive state. If you have a terabyte base, then our magic metering is 36 hours. Third-party tools, when from MS SQL to Postgres, of course, would work faster. But, nevertheless, we choose a regular tool, although it is longer, but the least risky.
Expand and run stupid things - some report, for example. This is the most revealing. Reports start to work faster by 15-20%. It is provable. You take it on one circuit and on the second, you launch it, and your reports are generated by 20% faster. This is the first such wow effect. By the way, even the reason why this happens is known. In the end, it proves that “it” works.
Everyone is usually afraid of Linux, from the word "absolutely." You deployed Postgres to them, proved that it works faster on some operations, but they still continue to be afraid of Linux. You have to convince that there is no Linux, there is Postgres. There is an installed package and several commands - apt-get install or yum. You teach the administrator basic commands - that there are block devices, they look a little differently than in Windows, and this is scripted as a vagrant file. You show him how it works so that he can deploy a Linux virtual machine for games in the form of a vagrant, which roughly repeats his Postgres settings in production. And he starts to play with him: he launches various Linux commands, looks at how updates work, how to work with backups, with console pg_dump and with something else.
Usually, administrators come from the Windows world who were previously “admin” of MS SQL. They say: “How to back up?” (After all, he has a certain Maintenance Plan, which is adopted in MS SQL). You prepare him a sign that shows how he did it on MS SQL, and how it is done on Postgres: how to recalculate statistics (and how it is generally called PostgreSQL), how to look at the query plan for a long file, and so on. It usually consists of 15 to 20 main points. As a result, it ceases to be scary - everything that he did before is more or less present in the circuit of PostgreSQL.
And then you start having fun with the Postgres contour. This is also the main trouble when you explain that, in fact, there is no Microsoft-adopted "mouse-keeping". You have either nano or vim, and you change the parameters. Moreover, if there is an opportunity to launch a newer version, then you are already showing him the alter system construction. For most DBAs, this is a clear construction - that you can change the system variables, almost but, of course, not quite) analogue of the MS SQL trace flag. You show how to calculate memory, you learn how to calculate the volume of connections in Excel, you count transactions per second, in general, you learn how to work with the Postgres circuit, that this is not magic at all. Naturally, you immediately provide links to Bartunov's videos or some kind of open Postgres Pro training. Quickly enough you group a list of small 5-6 webinars - and they are imbued with how it all works. Links, again, on Github give.
And the experiments, I remind you, are conducted on vagrant. One example: it slows down the DBMS (1C and DBMS are located on several infrastructure servers), everyone is used to the fact that this is supposedly 1C, and no one does anything . And when you launch Postgres, you immediately see that there are problems with the network infrastructure. You need to measure it with iperf and some other Linux toolkit. This often reveals the presence of strange network routes between the dedicated infrastructure. It turns out the problem is not in 1C and not in MS SQL, but the problem is in the network between them, but MS SQL somehow lived, but on PG it is already impossible. Strange jumps, transitions between incomprehensible nodes - this is also quickly detected. For some reason, Postgres monitoring tools are so fun and low-level that they show these numbers fairly quickly. You start telling such magic about the infrastructure, they quickly penetrate. That's all.
The main goal is to transfer the base and learn how to own it productively. They set up a productive circuit themselves, repeat the scripts that they made on vagrant. In production, we do not climb - this is our technique. In fact, it turns out their productive. If they are not sure what we showed them, then we continue training, evidence, and so on.
And we are not engaged in the support of the product, by the way. There are people who do it more professionally - we will recommend them better. They are direct admins. In the world of Postgres, everyone knows who specializes in what - we specialize in the general circuit and vagrant, that is, the Postgres and 1C acceptance circuits. But as soon as the transfer to the production takes place, I say: “Guys, here is a list of people who specialize in PG in production - all questions are there. Do not believe the Russians - please contact the 2ndQuadrant. ” There are people who were born immediately with a beard and with a keyboard, sharpened by vim, in one hand. At night, they mentally rebuild the Linux kernels. Therefore, I don’t climb to the production side with the team, although I’m taking monitoring from there to identify the developers' problems with the same pgBadger, which, by the way, I recommend to everyone.
This is a killer feature from the Postgres world for infrastructure workers: show how your database lives with replicas. In this report, you can “dive for a month” and explore. Yes, in MS SQL there are such things, but they are very expensive. And here right from the github docker box, almost like an installer: launched and forgot .
If you sum up - you take and step by step you fight “with standard objections”. You show that on Postgres it works, and in some scenarios it works faster, and you show the script itself.
The fight against objections against Linux happens like this : you leave the 1C server on a familiar Windows, and you do Postgres on Linux. So close the first objection - type, no-no-no, not everything on Linux, only Postgres! A little bit of Linux.
I launched it, added a little Linux, demonstrated that it all works and outlined - on which scenarios it is faster. First he showed an ecosystem where he could get free information if needed, then connected extensions that allow him to manage the whole thing more comfortably. Further, sequentially, it showed how the optimizer works, restored the maintenance plan so that it would be understandable. You do everything consistently to convince you that Postgres is not scary, it's easy.
The task is to immerse in the principles that are taken when owning the Postgres circuit so that it is clear where to get the information and how to debug it. We work in the paradigm - we change nothing on the product, first we look, then we apply.
Our proof is scripts on github. This is also such a position - to lay out even the initial developments in open access.
PG Day: Tell us more about your workshop at the conference. How will work be built? Prejudices regarding the operation of 1C on the platform will be decided on such a check list, about which you told?
Alexey : Yes, the ideology will be the following: expand the contour of Postgres - several boxes will appear in the “stock” mode. We have a special tool that shows the results - it, for example, shows how 1C behaves in the stock Postgres Pro, without anything, without basic settings, in the “microwave” mode.
Then we divide the work into 4 sections : data, logs of PostgreSQL, WAL and pg_dump. And we look at the results on the same scenarios that were before. After this, the third box is configured already in postgres.conf, specifically for typical users in the test loop, with their usual load. They calculate registers, otchetik launch, directories write, read them actively and so on. The report will show the principles on which our test circuit lives, so that everyone can repeat it later. After that, we’ll show the results of properly configuring the postgres.conf base infrastructure.
Then the next section - how to see the main “rakes” in 1C, the main mistakes? This is about what extensions you can see typical errors of 1C programmers (moreover, on typical configurations of a PCP, UT, and so on). They are known - this is a fun work with the temp directory, with temporary tables in subqueries (1C-nicknames like to make mistakes so much), incomprehensible composite joins, when you have an implicit 1C join and a classic misses is made into an index (this is just a disaster 1C, 1C -programmers "hate hate" put indexes and fall into them). How to identify this quickly, how to see where the developer made a mistake - we show this in the second section.
That is, we have a scenario, how 1C behaves, and how to look, how to identify, find a place. In 1C there is a regular tool, but it is paid. Therefore, we will not advertise it, all 1C-nicknames already know that this is the Performance Management Center, it parses the query plans. But there is a free, it is called "developer tool". You start and look at the request plan with Postgres and the code section in 1C that caused it. If you know the criteria for the query that concerns you, you can find a problem site for free . You do not need to buy a corporate tool package for 300 thousand. Accordingly, make recommendations. Or, if you are a developer yourself ... It happens that you are a performance expert, you have access to Postgres and saw this konfu yourself (in the 1C world this happens very often), then you can fix it yourself. It becomes clear where was wrong.
: , , , Postgres, , Alpine, 1 – , , . . . , , , 1 . , 1 .
, , “1” . . OLAP OLTP. 2,5 – . “-”.
. 1 . , . , , . , . bloat. – . , . , 1. . , 1. .
.
, , -. Postgres – . , , . , MS SQL, – . Postgres , , , ( , , ). . , MS SQL . , . «».
. .
PG Day: , . , , - , . , !
Alexey and his colleagues are engaged in professional services for businesses working with the 1C platform. They teach clients how to effectively use 1C on a bunch of PostgreSQL + Linux. It turns out that very often the problem lies not in the platform itself, but in inept operation. At PG Day'17 Russia, Alexey will hold a master class on switching to PostgreSQL for 1C under the code name Fighting fears .
In the framework of today's publication, Alexey will vividly show why the methodology they propose is successful. And it will explain in no less detail what practical skills you will acquire at the master class.
')
PG Day: Alexey, tell us about yourself. Who are you, what do you do, how did you come to your specialization?Alexey : I call myself an evangelist for Automation Driven Development . This is such a concept “from the automation of IT staff activities”, so that developers and infrastructure workers get rid of the routine and free up time for interesting work. For the last four years I have been trying to make friends two worlds with the help of the concept of CICD (Continuous Integration and Continuous Delivery): developers and infrastructure engineers. For this, our team was organized. And the main priority is on the “world of 1C”, as the least automated from the point of view of the process.
How did we come to this? In large companies, a lot of regulations. To comply with them requires a manual process. To do this, allocate "manual" people. When we come to large enterprises with an audit, we find that 80-90% of the time the employees spend on this routine : update the base, measure performance, monitor, draw conclusions, and carry out manual tests. 80% of the time completely inefficient work. It is justified in terms of the risks of the enterprise, I agree with that. We understand that in a large company, such a number of regulations was born as a response to some kind of accident and everything else. Only these 80% are an obvious candidate for automation.
By the way, “IT-specialists” for some reason are often considered to be a servicing division, and not a salary. Nobody thinks that by reducing the routine, you can start doing interesting things. It is more efficient to automate a business, to invent something breakthrough for your own startup - to test a new hypothesis or to cut down a bubble.
From this “jumps away everything” that we do with our hands.
For business, since the 2000s, the 1C platform, which, starting from the old version 7.7, works on the Microsoft contour and on the MS SQL DBMS, is considered to be the most effective. I have a certain vision of why this is happening. Initially, Microsoft was enough breakthrough technology in the world of DBMS. Postgres was then a lot of Linux (version 8, and so on), and, probably, the company 1C itself was not very interesting. Then the main thing was to get a quick result. This is MS SQL did. It is considered that MS SQL is stable for 1C. In general, this is probably the case. His query optimizer begins to cope, and does not show errors in the design of the tables and the relationships between them. A logically erroneous project on 1C in conjunction with MS SQL, launched on some minimum amount of data, begins to fail only after certain thresholds. And in Postgres, these errors are detected even at the initial stage of the start of the information system - logical errors in the structure of the DBMS immediately take off, you immediately see misunderstandings, everything works slowly. Therefore, usually everyone starts to scold Postgres, no one ever scolds developers.
I say this: 1C and Postgres work well! The problem is not in them, the problem in the competence of the owners of the circuit. Even on large volumes of databases there are precedents. For example, when the total amount of databases with compression is terabyte and more (there are also such installations). But, as practice shows, they are directly proportional to the level of competence of the owners of this circuit - developers and devops. Their competence level is much higher than those who own the same installation with the same amount of data and transactions per second in MS SQL. There you can put incomprehensible comrades, and they will code something, MS SQL compensates for their low level of competence. The difference is not in Postgres and MS SQL - the only difference is competency.
Hence the whole story with courses, github accounts and various scripting publications. Personally, my social goal is to ensure that performance experts in the 1C-world (in fact, system administrators who administer the entire circuit - and the application server 1C, and DBMS) increase their level of competence.
How did I come to this? Imagine that you have two hundred 1C nicknames in training, and the task is to run at least 100 information systems on linux. The last five years ago I had such a magical experience: it was necessary to shift the strategic focus from the MS SQL contour to Postgres. In 2006, within the framework of Infostar, we organized the 1C + Postgres community (calculated more for geeks). We were given the task to migrate at least some of the systems on Postgres. It turned out that the problem is not at all in Postgres and not in 1C. The problem is precisely the competence level of administrators who are responsible for the DBMS, and 1C-nick, and developers, and so on. They simply cannot test their hypotheses when PostgreSQL is used as a DBMS. It seems to them that they are deployed quickly on a productive basis - and everything will work by itself. Then just have something to tweak. With Postgres, this is not possible.
Well, I can say about myself. Since I am an evangelist of engineering practices DevOps, I have to prove with my hands that it works. I can't just walk with the flag "Postgres - our everything". They say to me: "Prove it." I sit down with the team (we are not very many, by the way), and we, through wagons, dockers, and all sorts of automated scripts, prove that we are right. We are convinced that we are not just populists.
PG Day: You have touched upon an interesting topic - the problems of transition from the Windows MsSQL platform to Linux from Postgres. What advice, based on your practice, do you give to eliminate these problems when you are asked to help with making this transition?
Alexey : We have a certain check-list, called “struggle with objections during the transition.” 1C produce typical information systems. Now it’s usually like: if you want to deploy a comprehensive enterprise automation (starting with a salary and ending with financial accounting). Install 1C - you will get full ERP and go ahead, go into business, do not bother with automation. In that case, you win.
But when “biznesmenish”, it is forced to refine itself , “podrichtovyvat.” We have to hire developers and infrastructure managers at various levels. And they "finish" you. Over the past fifteen years, 95% of 1C installations are atypical. There are statistics that in Russia there are about half a million different atypical installations. They were "dopilivali" some comrades for a particular businessman, with different levels of quality. If the “parent” company releases an information system in which the structure of the tables is more or less debugged (because within the 1C company, the models are still debugged: both the IDEF diagrams and ERwin, probably - everything works fine there). When it comes to a particular businessman, the developers “finish”, and they may not know anything about the data model, or about the theory of sets. Can roll data scheme is simply impossible.
Therefore, the first objection with which we are fighting is whether the system will start at all. First you just have to show. It is possible to unload the entire information system and load it into another DBMS circuit, this is their cool feature in the 1C world: you can make the transfer not with pg_dump or MS SQL backups, but with your own internal tool. So, you take and transfer to the Postgres circuit.
However, there is one feature - it’s better to install the 1C server not on Linux, but on Windows, because of problems with the active directory and the kerberos library. This is not due to Postgres, but with the kerberos static linking feature of CentOS, under Ubuntu, and not only. In general, there is such a recommendation that you only install Postgres on Linux. At the same time, you strongly resist not to run it on Windows. You leave the Windows server running 1C and transfer the base. You measure how much time the base will be transferred - to deploy from the backup and move to a productive state. If you have a terabyte base, then our magic metering is 36 hours. Third-party tools, when from MS SQL to Postgres, of course, would work faster. But, nevertheless, we choose a regular tool, although it is longer, but the least risky.
Expand and run stupid things - some report, for example. This is the most revealing. Reports start to work faster by 15-20%. It is provable. You take it on one circuit and on the second, you launch it, and your reports are generated by 20% faster. This is the first such wow effect. By the way, even the reason why this happens is known. In the end, it proves that “it” works.
Everyone is usually afraid of Linux, from the word "absolutely." You deployed Postgres to them, proved that it works faster on some operations, but they still continue to be afraid of Linux. You have to convince that there is no Linux, there is Postgres. There is an installed package and several commands - apt-get install or yum. You teach the administrator basic commands - that there are block devices, they look a little differently than in Windows, and this is scripted as a vagrant file. You show him how it works so that he can deploy a Linux virtual machine for games in the form of a vagrant, which roughly repeats his Postgres settings in production. And he starts to play with him: he launches various Linux commands, looks at how updates work, how to work with backups, with console pg_dump and with something else.
Usually, administrators come from the Windows world who were previously “admin” of MS SQL. They say: “How to back up?” (After all, he has a certain Maintenance Plan, which is adopted in MS SQL). You prepare him a sign that shows how he did it on MS SQL, and how it is done on Postgres: how to recalculate statistics (and how it is generally called PostgreSQL), how to look at the query plan for a long file, and so on. It usually consists of 15 to 20 main points. As a result, it ceases to be scary - everything that he did before is more or less present in the circuit of PostgreSQL.
And then you start having fun with the Postgres contour. This is also the main trouble when you explain that, in fact, there is no Microsoft-adopted "mouse-keeping". You have either nano or vim, and you change the parameters. Moreover, if there is an opportunity to launch a newer version, then you are already showing him the alter system construction. For most DBAs, this is a clear construction - that you can change the system variables, almost but, of course, not quite) analogue of the MS SQL trace flag. You show how to calculate memory, you learn how to calculate the volume of connections in Excel, you count transactions per second, in general, you learn how to work with the Postgres circuit, that this is not magic at all. Naturally, you immediately provide links to Bartunov's videos or some kind of open Postgres Pro training. Quickly enough you group a list of small 5-6 webinars - and they are imbued with how it all works. Links, again, on Github give.
And the experiments, I remind you, are conducted on vagrant. One example: it slows down the DBMS (1C and DBMS are located on several infrastructure servers), everyone is used to the fact that this is supposedly 1C, and no one does anything . And when you launch Postgres, you immediately see that there are problems with the network infrastructure. You need to measure it with iperf and some other Linux toolkit. This often reveals the presence of strange network routes between the dedicated infrastructure. It turns out the problem is not in 1C and not in MS SQL, but the problem is in the network between them, but MS SQL somehow lived, but on PG it is already impossible. Strange jumps, transitions between incomprehensible nodes - this is also quickly detected. For some reason, Postgres monitoring tools are so fun and low-level that they show these numbers fairly quickly. You start telling such magic about the infrastructure, they quickly penetrate. That's all.
The main goal is to transfer the base and learn how to own it productively. They set up a productive circuit themselves, repeat the scripts that they made on vagrant. In production, we do not climb - this is our technique. In fact, it turns out their productive. If they are not sure what we showed them, then we continue training, evidence, and so on.
And we are not engaged in the support of the product, by the way. There are people who do it more professionally - we will recommend them better. They are direct admins. In the world of Postgres, everyone knows who specializes in what - we specialize in the general circuit and vagrant, that is, the Postgres and 1C acceptance circuits. But as soon as the transfer to the production takes place, I say: “Guys, here is a list of people who specialize in PG in production - all questions are there. Do not believe the Russians - please contact the 2ndQuadrant. ” There are people who were born immediately with a beard and with a keyboard, sharpened by vim, in one hand. At night, they mentally rebuild the Linux kernels. Therefore, I don’t climb to the production side with the team, although I’m taking monitoring from there to identify the developers' problems with the same pgBadger, which, by the way, I recommend to everyone.
This is a killer feature from the Postgres world for infrastructure workers: show how your database lives with replicas. In this report, you can “dive for a month” and explore. Yes, in MS SQL there are such things, but they are very expensive. And here right from the github docker box, almost like an installer: launched and forgot .
If you sum up - you take and step by step you fight “with standard objections”. You show that on Postgres it works, and in some scenarios it works faster, and you show the script itself.
The fight against objections against Linux happens like this : you leave the 1C server on a familiar Windows, and you do Postgres on Linux. So close the first objection - type, no-no-no, not everything on Linux, only Postgres! A little bit of Linux.
I launched it, added a little Linux, demonstrated that it all works and outlined - on which scenarios it is faster. First he showed an ecosystem where he could get free information if needed, then connected extensions that allow him to manage the whole thing more comfortably. Further, sequentially, it showed how the optimizer works, restored the maintenance plan so that it would be understandable. You do everything consistently to convince you that Postgres is not scary, it's easy.
The task is to immerse in the principles that are taken when owning the Postgres circuit so that it is clear where to get the information and how to debug it. We work in the paradigm - we change nothing on the product, first we look, then we apply.
Our proof is scripts on github. This is also such a position - to lay out even the initial developments in open access.
PG Day: Tell us more about your workshop at the conference. How will work be built? Prejudices regarding the operation of 1C on the platform will be decided on such a check list, about which you told?
Alexey : Yes, the ideology will be the following: expand the contour of Postgres - several boxes will appear in the “stock” mode. We have a special tool that shows the results - it, for example, shows how 1C behaves in the stock Postgres Pro, without anything, without basic settings, in the “microwave” mode.
Then we divide the work into 4 sections : data, logs of PostgreSQL, WAL and pg_dump. And we look at the results on the same scenarios that were before. After this, the third box is configured already in postgres.conf, specifically for typical users in the test loop, with their usual load. They calculate registers, otchetik launch, directories write, read them actively and so on. The report will show the principles on which our test circuit lives, so that everyone can repeat it later. After that, we’ll show the results of properly configuring the postgres.conf base infrastructure.
Then the next section - how to see the main “rakes” in 1C, the main mistakes? This is about what extensions you can see typical errors of 1C programmers (moreover, on typical configurations of a PCP, UT, and so on). They are known - this is a fun work with the temp directory, with temporary tables in subqueries (1C-nicknames like to make mistakes so much), incomprehensible composite joins, when you have an implicit 1C join and a classic misses is made into an index (this is just a disaster 1C, 1C -programmers "hate hate" put indexes and fall into them). How to identify this quickly, how to see where the developer made a mistake - we show this in the second section.
That is, we have a scenario, how 1C behaves, and how to look, how to identify, find a place. In 1C there is a regular tool, but it is paid. Therefore, we will not advertise it, all 1C-nicknames already know that this is the Performance Management Center, it parses the query plans. But there is a free, it is called "developer tool". You start and look at the request plan with Postgres and the code section in 1C that caused it. If you know the criteria for the query that concerns you, you can find a problem site for free . You do not need to buy a corporate tool package for 300 thousand. Accordingly, make recommendations. Or, if you are a developer yourself ... It happens that you are a performance expert, you have access to Postgres and saw this konfu yourself (in the 1C world this happens very often), then you can fix it yourself. It becomes clear where was wrong.
: , , , Postgres, , Alpine, 1 – , , . . . , , , 1 . , 1 .
, , “1” . . OLAP OLTP. 2,5 – . “-”.
. 1 . , . , , . , . bloat. – . , . , 1. . , 1. .
.
, , -. Postgres – . , , . , MS SQL, – . Postgres , , , ( , , ). . , MS SQL . , . «».
. .
PG Day: , . , , - , . , !
Source: https://habr.com/ru/post/331448/
All Articles