En este contexto, uno de los algoritmos más utilizados para la detección de anomalías es Isolation Forest.

Isolation Forest es un algoritmo de unsupervised anomaly detection, cuyo principio fundamental es que las observaciones anómalas suelen ser más fáciles de aislar que aquellas que representan patrones normales del sistema. A diferencia de otros enfoques, no modela explícitamente el comportamiento normal, sino que se centra en identificar observaciones que presentan características significativamente distintas al resto.

Fundamentos del algoritmo Isolation Forest

1. Construcción del bosque

El algoritmo construye un conjunto de árboles binarios denominados Isolation Trees (iTrees). Cada árbol se genera a partir de una muestra aleatoria del conjunto de datos y se construye mediante particiones recursivas.

A diferencia de los árboles de decisión clásicos, los splits se realizan seleccionando de forma aleatoria:

• una característica (variable), y
• un valor dentro del rango observado de dicha característica.

Este componente estocástico es clave, ya que evita sesgos hacia estructuras específicas de los datos y permite aislar puntos de forma eficiente sin necesidad de criterios de optimización como la ganancia de información.

2. Proceso de aislamiento de las observaciones

La hipótesis central del algoritmo es que las observaciones anómalas, al encontrarse en regiones de baja densidad del espacio de características o presentar valores extremos, requieren menos particiones para quedar aisladas en un árbol.

Por el contrario, las observaciones normales suelen estar rodeadas de puntos similares y, por lo tanto, necesitan un mayor número de divisiones para ser aisladas completamente.

En términos computacionales, esto se traduce en que las anomalías presentan menores profundidades promedio en los árboles del bosque.

3. Cálculo del puntaje de anomalía

Una vez construido el bosque, se calcula para cada observación un puntaje de anomalía basado en la longitud promedio del camino (average path length) necesario para aislarla en todos los árboles.

Formalmente:

• Observaciones con caminos cortos (pocas particiones) reciben puntajes más altos.
• Observaciones con caminos largos se consideran normales.

Este puntaje es continuo y permite ordenar las observaciones según su grado relativo de anomalía, sin necesidad de definir reglas rígidas o modelos probabilísticos explícitos.

Ventajas del enfoque Isolation Forest

Entre las principales ventajas del algoritmo se encuentran:

1. Alta eficiencia computacional y escalabilidad, lo que lo hace adecuado para grandes volúmenes de datos.
2. Independencia de supuestos distributivos, a diferencia de métodos estadísticos clásicos.
3. Buen desempeño en espacios de alta dimensionalidad.
4. Interpretabilidad relativa, basada en profundidad de árboles y aislamiento de observaciones.
5. Robustez frente a datos ruidosos.
6. Selección automática de umbrales, evitando la calibración manual de criterios de anomalía.

Estas características lo hacen especialmente atractivo para contextos institucionales donde los datos suelen ser heterogéneos y complejos.

La imagen oficial de NGINX no incluye PHP por defecto, ya que se centra únicamente en el servidor web NGINX. Si deseas ejecutar PHP en el mismo contenedor que NGINX, necesitarás configurar un entorno adecuado para ello.Puedes crear una imagen personalizada basada en NGINX que incluya PHP. Para ello, crearás un archivo Dockerfile que combine NGINX y PHP-FPM (que es el manejador de PHP recomendado para NGINX). Aquí te dejo un ejemplo de un Dockerfile que agrega PHP a la imagen de NGINX:

# Usa la imagen oficial de NGINX como base
FROM nginx:latest

# Instala PHP y PHP-FPM
RUN apt-get update && \
    apt-get install -y php-fpm php-mysql

# Copia un archivo de configuración personalizado para NGINX
COPY default.conf /etc/nginx/conf.d/

# Exponer el puerto 80
EXPOSE 80

# Inicia PHP-FPM y NGINX cuando se inicie el contenedor
CMD service php7.4-fpm start && nginx -g 'daemon off;'

FROM nginx: Usamos la imagen base de NGINX.

apt-get install -y php-fpm php-mysql: Instalamos PHP-FPM y extensiones de PHP necesarias como php-mysql para poder conectar a bases de datos MySQL, entre otros.

COPY default.conf: Esto asume que tienes un archivo de configuración para NGINX que define cómo manejar las solicitudes PHP (lo veremos más adelante).

CMD: Se usa para iniciar tanto PHP-FPM como NGINX al mismo tiempo. php-fpm procesa las solicitudes PHP, y NGINX sirve las páginas.

Ejemplo de de archivo default.conf

server {
    listen 80;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

1 – Crear cuenta

2 – Configurar claves ssh
— crear claves ssh
ssh-keygen -t rsa -b 4096 -C ""

3- En setting – ssh keys agregar la clave. recuperada desde id_rsa.pub

--ver clave publica
    cat ~/.ssh/id_rsa.pub

4- Crear un repositorio en github.

¿Qué es un modelo de datos?

Es una vista conceptual de diferentes datos representados en un diagrama, el cual permite reducir la complejidad de los datos.

Modelamiento de datos: Proceso de crear datos a partir de un conjunto de datos disponible.

• -d – run the container in detached mode (in the background)
• -p 80:80 – map port 80 of the host to port 80 in the container
• docker/getting-started – the image to use

Trabajando con un Dockerfile

docker build -t getting-started .

• -t Final image
• . dockerfile en el directorio

You can stop and remove a container in a single command by adding the «force» flag to the docker rm command. For example: docker rm -f <the-container-id>

Para montar una usb https://geekytheory.com/tutorial-raspberry-pi-6-montar-usb-disco-duro

Cliente transmission https://www.atareao.es/tutorial/raspberry-pi-primeros-pasos/transmission-en-raspberry-pi/

VPN PPTP https://help.ubuntu.com/community/PPTPServer

Copy y paste: https://chartio.com/resources/tutorials/understanding-strorage-sizes-for-mysql-text-data-types/

TEXT data objects, as their namesake implies, are useful for storing long-form text strings in a MySQL database. The four TEXT data object types are built for storing and displaying substantial amounts of information as opposed to other data object types that are helpful with tasks like sorting and searching columns or handling smaller configuration-based options for a larger project. The different TEXT objects offer a range of storage space from 1 byte to 4 GB and are not designed for storing computational values. It’s common to see these used to store product descriptions for a sales site, property summaries for realty database, and long-form article text on a news website. TEXT objects are best used when VARCHAR and other string-based data objects are insufficient to handle storing the desired amount of information. However, the smallest TEXT type, TINYTEXT, shares the same character length as VARCHAR. TEXT objects differentiate themselves from other string storage types by removing the requirement to specify a storage length, not stripping bytes when selected, and do not pad unused character space for efficient disk storage. Since TEXT objects are not stored in the server’s memory, they require data overhead for retrieval. The following sizes assume the database is using the UTF-8 encoding.

TINYTEXT: 255 characters – 255 B

The TINYTEXT data object is the smallest of the TEXT family and is built to efficiently store short information strings. This type can store up to 255 bytes (expressed as 2^8 -1) or 255 characters and requires a 1 byte overhead. This object can be used to store things like short summaries, URL links, and other shorter objects. TINYTEXT shines over VARCHAR when storing data that’s under 255 characters with an inconsistent length and no need to be used for sorting criteria.

TEXT: 65,535 characters – 64 KB

The standard TEXT data object is sufficiently capable of handling typical long-form text content. TEXT data objects top out at 64 KB (expressed as 2^16 -1) or 65,535 characters and requires a 2 byte overhead. It is sufficiently large enough to hold text for something like an article, but would not be sufficient for holding the text of an entire book.

MEDIUMTEXT: 16,777,215 – 16 MB

The MEDIUMTEXT data object is useful for storing larger text strings like white papers, books, and code backup. These data objects can be as large as 16 MB (expressed as 24^2 -1) or 16,777,215 characters and require 3 bytes of overhead storage.

LONGTEXT: 4,294,967,295 characters – 4 GB

The LONGTEXT data object is for use in extreme text string storage use cases. It is a viable option when the MEDIUMTEXT object is not big enough. Computer programs and applications often reach text lengths in the LONGTEXT range. These data objects can be as large as 4 GB (expressed as 2^32 -1) and store up to 4,294,967,295 characters with 4 bytes of overhead storage,

TEXT vs. BLOB

BLOBs are an alternative type of data storage that share matching naming and capacity mechanisms with TEXT objects. However, BLOBs are binary strings with no character set sorting, so they are treated as numeric values while TEXT objects are treated as character strings. This differentiation is important for sorting information. BLOBs are used to store data files like images, videos, and executables.

Usage Notes

• Using TEXT fields for select and search queries will incur performance hits because the server will call the objects individually and scan them during the query instead of paging data stored in the memory.
• Enabling strict SQL will enforce the maximum character lengths and truncate any entered data that exceeds those limits.
• TEXT columns require an index prefix length and can’t have DEFAULT values, unlike CHAR and VARCHAR objects.
• Estimating size by word count: assume average English word is 4.5 letters long and needs 1 extra character for spacing. Example, a site that consists of 500 word articles would use about 2,750 characters on average for the article text data. TINYTEXT’s 255 character capacity is insufficient for this use case, while TEXT’s 65535 character capacity offers storage for articles that hit over 11,900 words based on the average criteria.

La solucion es cambier el usuario al cual esta asociado el origin.

git config --get remote.origin.url
git remote set-url origin http://usuariogit@repositorio.git