{"id":83337,"date":"2020-05-30T07:42:48","date_gmt":"2020-05-30T05:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh"},"modified":"2020-05-30T07:42:48","modified_gmt":"2020-05-30T05:42:48","slug":"k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","title":{"rendered":"\u00bfQu\u00e9 consecuencias puede tener la reducci\u00f3n del nivel de aislamiento de transacciones en bases de datos?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hola a todos. Soy Vladislav Rodin. Actualmente soy el director del curso \"Arquitecto de Cargas Altas\" en OTUS y tambi\u00e9n ense\u00f1o en cursos dedicados a la arquitectura de software.
\n<\/i>
\nAdem\u00e1s de ense\u00f1ar, como habr\u00e1n notado, me dedico a escribir contenido original para el blog de OTUS en Habr, y el art\u00edculo de hoy lo quiero dedicar al lanzamiento del curso \u00abPostgreSQL\u00bb<\/a><\/noindex>, el cual est\u00e1 abierto para inscripciones en este momento.<\/i><\/b><\/p>\n

\"\u00bfQu\u00e9
\n<\/p>\n

Introducci\u00f3n<\/h2>\n

\nEn \u00faltima vez<\/a><\/noindex> Hablamos de que las transacciones en bases de datos cumplen con dos objetivos: garantizar la tolerancia a fallos y el acceso a datos en un entorno concurrente. Para llevar a cabo plenamente estos objetivos, una transacci\u00f3n debe tener propiedades ACID. Hoy hablaremos en detalle sobre la letra I (aislamiento)<\/b> en este acr\u00f3nimo.
\n<\/a><\/noindex><\/p>\n

\u26a0\ufe0f Limitado<\/h2>\n

\nLa isolaci\u00f3n resuelve el problema del acceso a datos en un entorno concurrente, proporcionando efectivamente protecci\u00f3n contra condiciones de carrera. Idealmente, la isolaci\u00f3n significa serializaci\u00f3n, es decir, una propiedad que asegura que el resultado de la ejecuci\u00f3n de transacciones en paralelo sea el mismo que si se ejecutaran secuencialmente. El principal problema de esta propiedad es que es muy dif\u00edcil de garantizar t\u00e9cnicamente y, como consecuencia, afecta seriamente al rendimiento del sistema. Por esta raz\u00f3n, la isolaci\u00f3n a menudo se debilita, asumiendo los riesgos de que ocurran ciertas anomal\u00edas, de las cuales hablaremos a continuaci\u00f3n. La posibilidad de que surjan tales o cuales anomal\u00edas caracteriza precisamente el nivel de aislamiento de las transacciones.<\/p>\n

Las anomal\u00edas m\u00e1s conocidas son: lectura sucia, lectura no repetible, lectura fantasma, pero en realidad hay 5 m\u00e1s: escritura sucia, actualizaci\u00f3n perdida de cursor, actualizaci\u00f3n perdida, lectura sesgada, escritura sesgada.<\/p>\n

Escritura sucia<\/h2>\n

\nLa esencia de la anomal\u00eda radica en que las transacciones pueden sobrescribir datos no confirmados.<\/p>\n

\"\u00bfQu\u00e9
\n
\nEsta anomal\u00eda es peligrosa no solo porque los datos pueden entrar en conflicto despu\u00e9s de que ambas transacciones se confirmen (como en la imagen), sino tambi\u00e9n porque se rompe la atomicidad: puesto que permitimos sobrescribir datos no confirmados, no est\u00e1 claro c\u00f3mo revertir una transacci\u00f3n sin afectar a la otra. <\/p>\n

La anomal\u00eda se soluciona bastante f\u00e1cil: se coloca un bloqueo en la escritura antes de comenzar, impidiendo que otras transacciones cambien el registro hasta que se levante el bloqueo. <\/p>\n

Lectura sucia<\/h2>\n

\nLectura sucia significa leer datos no confirmados. <\/p>\n

\"\u00bfQu\u00e9
\n
\nLos problemas surgen cuando es necesario realizar acciones o tomar decisiones basadas en una muestra.<\/p>\n

Para corregir la anomal\u00eda se puede aplicar un bloqueo en la lectura, pero esto impacta fuertemente en el rendimiento. Es mucho m\u00e1s sencillo decir que para el rollback de una transacci\u00f3n, el estado original de los datos (antes del inicio de la escritura) debe ser necesariamente guardado en el sistema. \u00bfPor qu\u00e9 no leer desde all\u00ed? Esto es bastante econ\u00f3mico, por lo que la mayor\u00eda de las bases de datos eliminan la lectura sucia por defecto. <\/p>\n

Actualizaci\u00f3n perdida<\/h2>\n

\nLa actualizaci\u00f3n perdida se refiere a las actualizaciones perdidas, y la traducci\u00f3n refleja con bastante precisi\u00f3n la esencia del problema:<\/p>\n

\"\u00bfQu\u00e9
\n
\nDe hecho, el resultado de la transacci\u00f3n T2 fue cancelado. Esta situaci\u00f3n se corrige mediante bloqueos expl\u00edcitos o impl\u00edcitos de registros. Es decir, o bien simplemente realizamos la actualizaci\u00f3n del registro, y entonces se produce un bloqueo impl\u00edcito, o bien ejecutamos select for update<\/b>, lo que provoca un bloqueo tanto de lectura como de escritura. Tenga en cuenta que esta operaci\u00f3n es bastante peligrosa: al realizar una 'lectura inocente', bloqueamos otras lecturas. Algunas bases ofrecen una opci\u00f3n m\u00e1s segura, select for share<\/b>, que permite leer datos, pero no permite modificarlos. <\/p>\n

Actualizaci\u00f3n perdida del cursor<\/h2>\n

\nPara un control m\u00e1s fino, las bases pueden ofrecer otras herramientas, como un cursor. Un cursor es una estructura que contiene un conjunto de filas y permite iterar sobre ellas. declare cursor_name for select_statement<\/b>El contenido del cursor se describe mediante un select. <\/p>\n

\u00bfPara qu\u00e9 se necesita un cursor? La cuesti\u00f3n es que algunas bases de datos ofrecen bloqueo en todos los registros seleccionados por el select (estabilidad de lectura), o solo en el registro sobre el cual se encuentra el cursor en ese momento (estabilidad del cursor). En la estabilidad del cursor se realiza un bloqueo corto, lo que permite reducir la cantidad de bloqueos en caso de que estemos iterando sobre un gran conjunto de datos. Por eso, la anomal\u00eda de la actualizaci\u00f3n perdida se destaca para el cursor por separado.<\/p>\n

Lectura no repetible<\/h2>\n

\nLa lectura no repetible consiste en que durante la ejecuci\u00f3n de nuestra transacci\u00f3n, dos lecturas consecutivas del mismo registro dar\u00e1n diferentes resultados, porque otra transacci\u00f3n intervino entre estas dos lecturas, cambi\u00f3 nuestros datos y fue confirmada. <\/p>\n

\"\u00bfQu\u00e9
\n
\n\u00bfPor qu\u00e9 es un problema en absoluto? Imagina que el objetivo de la transacci\u00f3n T2 en la imagen es seleccionar todos los productos cuyo precio sea inferior a 150 u.e. Alguien m\u00e1s ha actualizado el precio a 200 u.e. Por lo tanto, el filtro establecido no funcion\u00f3.<\/p>\n

Estas anomal\u00edas dejan de ocurrir al agregar bloqueos en dos fases o al utilizar el mecanismo MVCC, del cual me gustar\u00eda hablar por separado. <\/p>\n

Lectura fantasma<\/h2>\n

\nSe denomina lectura fantasma a la lectura de datos que han sido a\u00f1adidos por otra transacci\u00f3n. <\/p>\n

\"\u00bfQu\u00e9
\n
\nComo ejemplo, se puede observar la selecci\u00f3n incorrecta del producto m\u00e1s barato cuando se produce esta anomal\u00eda. <\/p>\n

Deshacerse de las lecturas fantasma ya es bastante complicado. Un bloqueo convencional no es suficiente, ya que no podemos bloquear lo que a\u00fan no existe. Los sistemas 2PL utilizan bloqueo predictivo, mientras que los sistemas MVCC anulan las transacciones que pueden ser interrumpidas por una inserci\u00f3n. Tanto un mecanismo como el otro son bastante pesados.<\/p>\n

Deslizamiento de lectura<\/h2>\n

\nEl deslizamiento de lectura ocurre cuando trabajamos con m\u00faltiples tablas, cuyo contenido debe cambiar de manera coherente. <\/p>\n

Supongamos que hay tablas que representan publicaciones y su metainformaci\u00f3n:<\/p>\n

\"\u00bfQu\u00e9
\n
\nUna transacci\u00f3n lee de las tablas, mientras que otra las modifica:<\/p>\n

\"\u00bfQu\u00e9
\n
\nComo resultado de la ejecuci\u00f3n de la transacci\u00f3n T1, la publicaci\u00f3n tiene title = Bueno y updated_by = T2, lo que es una cierta incongruencia. <\/p>\n

De hecho, es una lectura no repetible, pero en el contexto de varias tablas.<\/p>\n

Para corregirlo, T1 puede colocar bloqueos en todas las filas que va a leer, lo que evitar\u00e1 que la transacci\u00f3n T2 modifique la informaci\u00f3n. En el caso de MVCC, la transacci\u00f3n T2 ser\u00e1 anulada. Protegerse de esta anomal\u00eda puede ser importante si utilizamos cursores. <\/p>\n

Deslizamiento de escritura<\/h2>\n

\nEsta anomal\u00eda tambi\u00e9n es m\u00e1s f\u00e1cil de explicar con un ejemplo: supongamos que en nuestro sistema al menos un m\u00e9dico debe estar de guardia, pero ambos m\u00e9dicos decidieron cancelar su guardia:<\/p>\n

\"\u00bfQu\u00e9
\n
\n\"\u00bfQu\u00e9
\n
\nLa anomal\u00eda llev\u00f3 a que ninguno de los m\u00e9dicos se presentara a la guardia. \u00bfPor qu\u00e9 sucedi\u00f3 esto? Porque la transacci\u00f3n verificaba una condici\u00f3n que pod\u00eda ser violada por otra transacci\u00f3n y, debido a la aislamiento, no pudimos ver este cambio.<\/p>\n

Esto es lo mismo que una lectura no repetible. Como opci\u00f3n, los selects pueden aplicar bloqueos a estos registros.<\/p>\n

El sesgo de escritura y el sesgo de lectura son combinaciones de las anomal\u00edas anteriores. Se puede considerar el sesgo de escritura, que es esencialmente una lectura fantasma. Consideremos una tabla que contiene los nombres de los empleados, sus salarios y el proyecto en el que est\u00e1n trabajando:<\/p>\n

\"\u00bfQu\u00e9
\n
\n\"\u00bfQu\u00e9
\n
\nComo resultado, obtenemos el siguiente panorama: cada gerente pens\u00f3 que su cambio no llevar\u00eda a un excedente presupuestario, por lo que realizaron cambios en el personal que, en conjunto, resultaron en un sobrepaso. <\/p>\n

La causa de este problema es exactamente la misma que en el caso del phantom read. <\/p>\n

Conclusiones<\/h2>\n

\nReducir el nivel de aislamiento de transacciones en una base de datos es un compromiso entre seguridad y rendimiento; la elecci\u00f3n de este nivel debe hacerse considerando los riesgos potenciales para el negocio al enfrentar determinadas anomal\u00edas.<\/p>\n

\nDescubre m\u00e1s sobre el curso.
\n<\/a><\/noindex><\/p>\n

Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d. \u0412 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u044f\u0432\u043b\u044f\u044e\u0441\u044c \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u0443\u0440\u0441\u0430 \u00ab\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0432\u044b\u0441\u043e\u043a\u0438\u0445 \u043d\u0430\u0433\u0440\u0443\u0437\u043e\u043a\u00bb \u0432 OTUS, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u044e \u043d\u0430 \u043a\u0443\u0440\u0441\u0430\u0445, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u044b\u0445 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u041f\u041e. \u041f\u043e\u043c\u0438\u043c\u043e \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u043d\u0438\u044f, \u043a\u0430\u043a \u0432\u044b \u043c\u043e\u0433\u043b\u0438 \u0437\u0430\u043c\u0435\u0442\u0438\u0442\u044c, \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0438\u0435\u043c \u0430\u0432\u0442\u043e\u0440\u0441\u043a\u043e\u0433\u043e \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430 \u0434\u043b\u044f \u0431\u043b\u043e\u0433\u0430 OTUS \u043d\u0430 \u0445\u0430\u0431\u0440\u0435 \u0438 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u044e\u044e \u0441\u0442\u0430\u0442\u044c\u044e \u0445\u043e\u0447\u0443 \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0438\u0442\u044c \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043a\u0443\u0440\u0441\u0430 \u00abPostgreSQL\u00bb, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043f\u0440\u044f\u043c\u043e \u0441\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":83338,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-83337","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00bfA qu\u00e9 puede llevar la reducci\u00f3n del nivel de aislamiento de transacciones en bases de datos | ProHoster","description":"Hola a todos. Aqu\u00ed est\u00e1 Vladislav Rodin.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a \u0447\u0435\u043c\u0443 \u043c\u043e\u0436\u0435\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043e\u0441\u043b\u0430\u0431\u043b\u0435\u043d\u0438\u0435 \u0443\u0440\u043e\u0432\u043d\u044f \u0438\u0437\u043e\u043b\u044f\u0446\u0438\u0438 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 \u0431\u0430\u0437\u0430\u0445 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u041d\u0430 \u0441\u0432\u044f\u0437\u0438 \u0412\u043b\u0430\u0434\u0438\u0441\u043b\u0430\u0432 \u0420\u043e\u0434\u0438\u043d.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/k-chemu-mozhet-privesti-oslablenie-urovnya-izolyaczii-tranzakczij-v-bazah-dannyh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-30T05:42:48+00:00","article:modified_time":"2020-05-30T05:42:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"83337","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:20:28","updated":"2022-09-28 14:57:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/83337","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=83337"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/83337\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/83338"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=83337"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=83337"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=83337"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}