MongoDB es una base de datos NoSQL ampliamente utilizada por su escalabilidad y flexibilidad. Sin embargo, si no se ajusta correctamente, puede convertirse en un cuello de botella para tus aplicaciones. En esta guía te explico cómo hacer tuning de MongoDB en servidores Linux para maximizar su rendimiento, con ejemplos prácticos y recomendaciones reales.

¿Por qué hacer tuning de MongoDB?

Por defecto, MongoDB está configurado para funcionar “de forma general”, pero cada entorno tiene requisitos distintos. Aplicar técnicas de tuning en MongoDB puede ayudarte a:

• Reducir latencias de escritura y lectura.
• Mejorar la respuesta bajo cargas altas.
• Aumentar la eficiencia del uso de memoria y CPU.
• Detectar cuellos de botella antes de que afecten al sistema.

Recomendaciones generales de tuning para MongoDB

1. Usa WiredTiger correctamente

WiredTiger es el motor de almacenamiento por defecto desde MongoDB 3.2. Asegúrate de que el parámetro cacheSizeGB esté bien dimensionado. Como regla general:

cacheSizeGB ≈ (RAM Total del sistema * 0.5) - RAM reservada para el sistema operativo y otros procesos

Ejemplo de ajuste:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 16

2. Ajusta los límites del sistema (ulimits)

Por defecto, muchos sistemas Linux imponen límites demasiado bajos para procesos como mongod.

Ajustes recomendados en /etc/security/limits.conf:

mongodb soft nofile 64000
mongodb hard nofile 64000
mongodb soft nproc 64000
mongodb hard nproc 64000

Y en /etc/systemd/system/mongod.service.d/override.conf:

[Service]
LimitNOFILE=64000

3. Desactiva Transparent Huge Pages (THP)

THP puede perjudicar gravemente el rendimiento de MongoDB.

Verifica si está activado:

cat /sys/kernel/mm/transparent_hugepage/enabled

Desactiva temporalmente:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Desactiva permanentemente: agrega al GRUB transparent_hugepage=never

4. Configura el commitIntervalMs en entornos con mucha escritura

Si tu sistema tiene mucha escritura continua, puedes ajustar commitIntervalMs para balancear durabilidad y rendimiento.

storage:
  journal:
    commitIntervalMs: 100

Métricas clave que debes monitorizar

• opcounters.insert, opcounters.query: tasa de operaciones
• mem.resident: uso de RAM por MongoDB
• connections.current: conexiones activas
• locks.*: bloqueos en colecciones o base de datos
• wiredTiger.cache.*: uso del cache interno

¿Tienes dudas sobre tu caso específico? ¡Déjalas en los comentarios y te ayudamos!

Iñaki Méndez

Técnico informático especializado en Linux, redes y ciberseguridad. Apasionado del software libre, comparto tutoriales y guías prácticas en Linuxbasico para ayudarte a dominar el entorno Linux desde cero.

La entrada Tuning de MongoDB en entornos Linux: Guía para mejorar el rendimiento se publicó primero en Linux Básico.

¿Qué pasa en las bases de datos si usan character set distintos a los Unicode?

Si el character set de destino contiene los caracteres del origen o unos de remplazo se podrá hacer la migración al Unicode, pero para esto necesitamos usar caracteres de reemplazo que resultan ser en la mayoría de los casos el simple usos de las diálisis a letras sin ellas.

Por ejemplo, si está migrando del conjunto de caracteres A al conjunto de caracteres B, entonces el conjunto de caracteres de destino B debe ser un superconjunto del conjunto de caracteres A. El carácter de destino, B, es un superconjunto si contiene todos los caracteres definidos en el conjunto de caracteres A.

Los caracteres que no están disponibles en el juego de caracteres B se convierten en caracteres de reemplazo, que a menudo se especifican por ejemplo como ä (a con una diéresis) se puede reemplazar por a. Los caracteres de reemplazo están definidos por el juego de caracteres de destino.

Posibles problemas

Se pueden ocasionar en la migración de WE8MSWIN1252 a AL32UTF8 están explicados en la documentación anterior DMU (Oracle Database Migration Assistant for Unicode).

Tales problemas como el truncamiento de datos y los problemas que pueden causar estas, así como la solución o que tener en cuenta antes de hacer una migración de las bases de datos usando el DMU.

¿Dónde consultar los problemas?

También podemos ver algunos de los problemas y su correspondiente medida en la hoja de cálculo Characterset_Report en la que brinda información de los problemas encontrados en el escaneo de la base de datos con su correspondiente descripción y cambios que se necesitan tomar en cada uno de los casos.

Como cambiar a los clientes sus character set en función al idioma de cada uno de ellos?

Lo primero que debemos analizar es que si su character set son compatibles con el character set al32utf8

Ventajas de al32utf8:

• Los caracteres suplementarios se almacenan en 4 bytes, por lo que no hay conversión de datos cuando los caracteres suplementarios se recuperan e insertan si la configuración del cliente es UTF-8.
• El almacenamiento de caracteres suplementarios requiere menos espacio en disco en AL32UTF8 que en UTF8.

Desventajas:

• No puede especificar la longitud de los tipos de SQL CHAR en número de puntos de código UCS-2 para caracteres suplementarios. Los caracteres suplementarios se tratan como un punto de código en lugar de los dos puntos de código estándar.
• El orden binario para las columnas SQL CHAR es diferente del orden binario de las columnas SQL NCHAR cuando los datos consisten en caracteres suplementarios. Como resultado, las columnas CHAR y las columnas NCHAR no siempre tienen el mismo tipo para cadenas idénticas. Explicación en el documento varchar2 (10 char).

Más información | Oracle

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada Migraciones a clientes usando base de datos universal se publicó primero en Linux Básico.

Las herramientas CSSCAN y CSALTER se usan en servidores de base de datos Oracle, generalmente en las versiones anteriores al 12c.

Para poder realizar una migración de un character set a otro realizaremos los pasos que explico a continuación.

La función CSSCAN es usado para descartar de la base de datos posibles problemas de conversión.

Identificando la cantidad de esfuerzo requerido por el servidor para llevar a cabo la tarea de la migración de un juego de caracteres a otro.

Por ejemplo del juego de carácter (character set) WE8MSWIN1252 al juego de caracteres AL32UTF8 usando la función CSSCAN y CSALTER combinadamente.

Con esta herramienta, tendremos toda la información sobre la migración, como por ejemplo la carga que este conlleva para el servidor o los caracteres que nos darán problemas de truncamientos al realizar el cambio.

Truncamientos

Cuidado con los caracteres que den problemas de truncamiento ya que estos dos caracteres estarán en conflicto sobre su significado en el juego de caracteres a la que va a ser migrado.

Por ejemplo puede llegar a eliminarse el carácter o a tomar un significado o carácter distinto en la que fue guardada como pasar de la ä a la a.

También puede ser un problema que dos caracteres de distintos lenguajes se guarden de la misma forma en el juego de caracteres de destino.

El proceso de migración

El proceso a realizar para ejecutar una migración en un servidor Oracle de una versión anterior al 12c usando el script CSALTER son las siguientes:

El primer paso a realizar es detener la base de datos en modo inmediato.

shutdown inmediate;

A continuación realizaremos una backup completa de la base de datos que vamos a migrar, es recomendable realizarlo en frio y con una copia de utilidad (expdp/impdp).

Al tener esta backup podremos fallar en la migración sin consecuencias ya que algo que debemos tener en cuenta en una migración es que no hay marcha atrás en los cambios realizados en ella.

Para continuar en la migración, volveremos a poner en marcha la base de datos usando el comando startup;

Y procederemos a ejecutar la utilidad csscaner que esta ubicado en $ORACLE_HOME /bin

$csscan "sys/password@db as sysdba" full=y

A continuación del comando nos pedirá que insertemos el nuevo juego de caracteres a la que vas a migrar la base de datos.

Para finalizar el proceso de migración:

Tendremos que iniciar el script CSALTER pero antes de esto deteniendo la base de datos y conectado con el usuario SYS.

Para ello tendremos que acceder a la dirección $ORACLE_HOME/RDBMS/admin y ejecutando csalter.plb

Y con este proceso de migración conseguiríamos migrar la base de datos de un juego de caracteres de Oracle anteriores a la versión 12c, para las bases de datos posteriores a este tenemos la herramienta añadida DMU.

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada CSSCAN y CSALTER para qué sirven y cómo usarlos se publicó primero en Linux Básico.

Es importante, diferenciar el uso de VARCHAR2 (n byte o char). A continuación, conoceremos qué es VARCHAR2 en Oracle Data Base.

Para diferenciar las dos cadenas de caracteres, hay que tener en cuenta que VARCHAR2 (byte) delimita en bytes mientras que VARCHAR2 (char) delimita el número de caracteres.

Aun así, se podría gestionar mejor los bytes de almacenamiento, usando NVARCHAR2, ya que su función es la misma que la de VARCHAR2 (10 CHAR).

Según el juego de caracteres usada en la base de datos, por ejemplo, AL32UTF8 los caracteres pueden ser de hasta 4 byte. Cosa que no pasa en WE8MSWIN1252 ya que en este caso todos los caracteres eran de un solo byte y no requiere almacenamiento multibyte.

Según el caso, cambiarían los bytes almacenados, dándonos un menor o mayor espacio, si por ejemplo, son caracteres de la zona de Asia.

En ese caso, mejor usar NVARCHAR2 antes que VARCHAR2 (n CHAR) y así será menor los bytes almacenados en la base de datos.

Usar NVARCHAR2 es mejor que VARCHAR2 (n CHAR) solo en el caso de que se vaya a usar la base de datos con caracteres asiáticos.

Es conveniente usar siempre el tipo de datos VARCHAR2 para almacenar cadenas de caracteres de longitud variable. Los cuales son todos aquellos caracteres que pueden ser de más de un byte de longitud.

Si la base de datos se ejecuta en un conjunto de caracteres de un solo byte (por ejemplo, US7ASCII, WE8MSWIN1252 o WE8ISO8859P1).

No importa si se usa VARCHAR2 (BYTE) o VARCHAR2 (CHAR) porque los caracteres en estos son de un solo byte y la cantidad delimitada en ambos casos sería la misma.

Solo hace una diferencia cuando la base de datos se ejecuta en un conjunto de caracteres de varios bytes (por ejemplo, AL32UTF8 o AL16UTF16).

Simplemente puede verse en este ejemplo:

CREATE TABLE my_table (
    VARCHAR2_byte VARCHAR2(1 BYTE), 
    VARCHAR2_char VARCHAR2(1 CHAR)
);

INSERT INTO my_table (VARCHAR2_char) VALUES ('€');
1 row created.

INSERT INTO my_table (VARCHAR2_char) VALUES ('ü');
1 row created.

INSERT INTO my_table (VARCHAR2_byte) VALUES ('€');
INSERT INTO my_table (VARCHAR2_byte) VALUES ('€')
Error at line 10
ORA-12899: value too large for column "MY_TABLE"."VARCHAR2_BYTE" (actual: 3, maximum: 1)

INSERT INTO my_table (VARCHAR2_byte) VALUES ('ü')
Error at line 11
ORA-12899: value too large for column "MY_TABLE"."VARCHAR2_BYTE" (actual: 2, maximum: 1)

Podemos apreciar que al insertar un carácter multibyte en un solo byte, nos dará el error de falta de espacio usando VARCHAR2 (1 BYTE) pero al insertarlo en VARCHAR2 (1 CHAR), nos dejara guardar el carácter que queramos sin importar su peso en byte, ya que en el caso de Unicode podrían ser de hasta 4 bytes.

Sin embargo, VARCHAR2 (4000 CHAR) no significa que tenga la garantía de almacenar hasta 4000 caracteres. El límite sigue siendo de 4000 bytes, por lo que en el peor de los casos puede almacenar solo hasta 1000 caracteres en dicho campo.

Además, después de la versión 12c, el máximo para varchar2 ahora es 32767 byte solo si el parámetro de inicialización “MAX_STRING_SIZE” está en “EXTENDED”, en el caso de no ser así, el máximo por defecto seguiría siendo de 4000 byte.

Si se necesita más que eso, sería conveniente usar una cadena de caracteres CLOB que nos daría un límite de bytes mayor.

En el PL/SQL, los bytes almacenados de las ambas formas, ya sea VARCHAR2 (n byte) o VARCHAR2 (n char) se guardaran usando los mismos bytes por carácter.

Acorde a esta información si sabemos exactamente la cantidad de bytes que serán almacenados, la mejor forma de guardarlos sería usando VARCHAR2 (n byte).

Sabiendo que siempre serán los mismos caracteres ya que al usar otros podría verse afectado el máximo de bytes de no saber cuántos byte van a ocupar esos caracteres y queremos delimitarlos en cantidad de caracteres, será más apropiado usar VARCHAR2 (n char).

Si te ha sido útil puedes leer mas entradas sobre bases de datos en nuestra web.

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada ¿Cómo diferenciar VARCHAR2 en Oracle Data Base? se publicó primero en Linux Básico.

DMU, es una herramienta gratuita descargable y es el método oficialmente compatible para migrar Bases de datos de Oracle 12c y sus character set.

También admite la migración en las bases de datos anteriores como Oracle 11.2, 11.1 y 10.2.

Su línea de comando hereda las utilidades de CSSCAN y CSALTER que han sido deshabilitadas a partir de Oracle 12c. Además, viene integrada en una interfaz gráfica fácil de usar.

Las tareas desafiantes, como la de identificación de los problemas de datos, la aplicación de acciones de limpieza de datos, la conversión de datos, entre otras, con su entorno gráfico fácil de usar mantiene la carga de trabajo manual propensa a errores al mínimo.

La DMU le permite convertir solo los datos que deben convertirse, a nivel de tabla, columna y fila.

Para su instalación

• Habrá que usar una arquitectura JDK que coincida con la arquitectura del sistema operativo.
• Instalar el paquete PL/SQL requerido en la base de datos.
• La funcionalidad entre el cliente DMU y su función DMU están en el paquete SYS.DBMS_DUMA_INTERNAL, este paquete no está instalado por defecto y habrá que instalarlo. Posteriormente iniciaremos sqlplus con la sesión de SYSDBA e iniciar el script ?/rdbms/admin/prvtdumi.plb.

• Al finalizar el script en caso de no tener la versión 8 de JDK (Java SE Development Kit) tendremos que instalarlo.
• A continuación, procederemos a instalar el DMU descargándola desde la página OTN con su Patch#30149496 y con su licencia Standart OTN Developer License sin este Patch no podremos instalar el DMU.
• Iniciaremos el DMU usando dmuW32.exe o dmuW64.exe acode con la arquitectura del sistema en el que lo vayamos a instalar.
• Antes de poder conectarse a una base de datos de destino para comenzar el proceso de migración, debe definir una conexión proporcionando el nombre de usuario administrativo de la base de datos, su contraseña y los datos de conexión de la red: el nombre de host, el puerto TNS y el nombre de servicio de la base de datos. El usuario debe tener privilegios SYSDBA en la base de datos.
• Cuando conectas por primera vez pedirá que instale un repositorio de migración de DMU.
• Después de todo este proceso estará listo para comenzar el proceso de migración a Unicode. Escaneara la base de datos para identificar problemas de convertibilidad, limpiara la base de datos de estos problemas y ejecutara el paso de conversión real.
• También se puede usar la aplicación para comprobaciones periódicas para ayudar a detectar cualquier aplicación o problema de configuración ETL rápidamente, evitando que se acumulen datos ilegales en la base de datos.

Truncamiento de datos

Cuando la base de datos se crea utilizando la semántica de bytes, los tamaños de los tipos de datos CHAR y VARCHAR2 se especifican en bytes, no en caracteres.

Por ejemplo, la especificación CHAR (20) en una definición de tabla permite 20 bytes para almacenar datos de caracteres. Cuando el conjunto de caracteres de la base de datos utiliza un esquema de codificación de caracteres de un solo byte, no se produce pérdida de datos cuando se almacenan caracteres porque el número de caracteres es equivalente al número de bytes.

Si el conjunto de caracteres de la base de datos usa un conjunto de caracteres multibyte, entonces el número de bytes ya no es igual al número de caracteres porque un carácter puede constar de uno o más bytes.

Durante la migración a un nuevo conjunto de caracteres, es importante verificar los anchos de columna de las columnas CHAR y VARCHAR2 existentes, ya que es posible que tengan que ampliarse para admitir una codificación que requiere almacenamiento multibyte. El truncamiento de datos puede ocurrir si la conversión causa la expansión de datos.

Por ejemplo:

La primera columna de la tabla anterior muestra los caracteres seleccionados.

La segunda columna muestra la representación hexadecimal de los caracteres en el juego de caracteres WE8MSWIN1252.

La tercera columna muestra la representación hexadecimal de cada carácter en el juego de caracteres AL32UTF8. Cada par de letras y números representa un byte.

Por ejemplo, ä (a con una diéresis) es un carácter de un solo byte (E4) en WE8MSWIN1252, pero se convierte en un carácter de dos bytes (C3 A4) en AL32UTF8. Además, la codificación del símbolo del euro se expande de un byte (80) a tres bytes (E2 82 AC).

Si los datos en el nuevo character set requieren un almacenamiento que es mayor que el tamaño de byte admitido de los tipos de datos, entonces debe cambiar su esquema. Puede que necesite usar columnas CLOB.

Antes de cambiar el character set

Antes de cambiar el character set de una base de datos, es necesario identificar posibles problemas en la conversión de la misma en una base de datos y posibles truncamientos de datos.

El escaneo de datos identifica la cantidad de esfuerzo requerido para migrar los datos al nuevo esquema de codificación de caracteres antes de cambiar el conjunto de caracteres de la base de datos.

Algunos ejemplos de lo que se puede encontrar durante un escaneo de datos son el número de objetos de esquema donde los anchos de columna deben expandirse y la extensión de los datos que no existen en el repertorio de caracteres de destino. Esta información ayuda a determinar el mejor enfoque para convertir el conjunto de caracteres de la base de datos.

Una vez identificados los posibles problemas de datos, deben limpiarse adecuadamente para garantizar que la integridad de los datos se pueda preservar durante la conversión de datos.

El paso de limpieza de datos podría requerir mucho tiempo y esfuerzo dependiendo de la escala y la complejidad de los problemas de datos encontrados. Puede tomar múltiples iteraciones de escaneo y limpieza de datos para abordar correctamente todas las excepciones de datos.

Nota: La conversión de datos es el proceso mediante el cual los datos de caracteres se convierten del character set de origen en la representación del character set de destino.

La conversión incorrecta de datos puede provocar daños en los datos, por lo tanto, realice una copia de seguridad completa de la base de datos antes de intentar migrar los datos a un nuevo conjunto de caracteres.

Tenemos dos enfoques para la migración de character set:

• La migración usando Database Migration Assistant for Unicode.
• La migración usando la exportación e importación completa.

Esta versión del Asistente de migración de base de datos para Unicode tiene algunas restricciones con respecto a qué bases de datos puede convertir. En particular, no convierte bases de datos con ciertos tipos de datos convertibles en el diccionario de datos.

Los métodos de migración de exportación / importación podrían usarse para superar estas limitaciones.

Posibles problemas con el truncamiento de datos

Si los nombres de usuario o contraseñas existentes de Oracle se crean en función de los caracteres que cambian de tamaño en el nuevo conjunto de caracteres, entonces los usuarios tendrán problemas para iniciar sesión debido a fallas de autenticación después de la migración a un nuevo conjunto de caracteres.

Esto ocurre porque los nombres de usuario, las contraseñas que están cifrados y almacenados en el diccionario de datos, pueden no actualizarse durante la migración a un nuevo conjunto de caracteres. Por ejemplo, si el conjunto de caracteres de la base de datos actual es WE8MSWIN1252 y el nuevo conjunto de caracteres de la base de datos es AL32UTF8, entonces la longitud del nombre de usuario “scött” (o con una diéresis) cambia de 5 bytes a 6 bytes. En AL32UTF8, “scött” ya no puede iniciar sesión debido a la diferencia en el nombre de usuario. Oracle recomienda que los nombres de usuario y las contraseñas se basen en caracteres ASCII. Si no lo están, debe restablecer los nombres de usuario y contraseñas afectados después de migrar a un nuevo conjunto de caracteres.

En el diccionario de datos de la base de datos, los nombres de los objetos de esquema no pueden exceder los 30 bytes de longitud.

Debe cambiar el nombre de los objetos de esquema si sus nombres superan los 30 bytes en el nuevo character set de la base de datos.

Por ejemplo

Un carácter tailandés en el conjunto de caracteres nacional tailandés requiere 1 byte. En AL32UTF8, requiere 3 bytes. Si ha definido una tabla cuyo nombre tiene 11 caracteres tailandeses. El nombre de la tabla debe acortarse a 10 o menos caracteres tailandeses cuando cambie el conjunto de caracteres de la base de datos a AL32UTF8, ya que de otro modo excedería el límite.

• Cuando los datos CHAR contienen caracteres que se expanden después de la migración a un nuevo conjunto de caracteres. El relleno de espacio no se elimina durante la exportación de la base de datos de forma predeterminada. Esto significa que estas filas serán rechazadas al importarlas a la base de datos con el nuevo juego de caracteres. La solución consiste en establecer el parámetro de inicialización BLANK_TRIMMING en TRUE antes de importar los datos CHAR.

Pasos antes de la conversión (migración)

En el proceso de escaneo de la base de datos podremos ver los posibles problemas que pudieran suceder en el proceso de conversión y la cantidad de datos que necesitan ser convertidos y los que no.

En el proceso de limpieza seleccionaremos los datos que vamos a limpiar y en que columna y que tipo de datos vamos a convertir a que.

Por ejemplo, si es necesario ampliar un varchar2 (10) a un varchar2 (10 CHAR) o a otro tipo de dato.

Podréis encontrar mas información y tutoriales acerca de bases de datos en nuestra página web.

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada DMU, asistente de migración Oracle para Unicode se publicó primero en Linux Básico.