Base de datos mapeada en memoria Lightning

Lightning Memory-Mapped Database ( LMDB ) es una base de datos transaccional integrada en forma de almacén clave-valor . LMDB está escrita en C con enlaces API para varios lenguajes de programación . LMDB almacena pares clave/dato arbitrarios como matrices de bytes, tiene capacidad de búsqueda basada en rangos, admite múltiples elementos de datos para una sola clave y tiene un modo especial para agregar registros (MDB_APPEND) sin verificar la consistencia. ^{[ 1 ]} LMDB no es una base de datos relacional , es estrictamente un almacén clave-valor como Berkeley DB y DBM .

LMDB también puede utilizarse simultáneamente en entornos multihilo o multiprocesamiento, con un rendimiento de lectura que escala linealmente por diseño. Las bases de datos LMDB solo pueden tener un escritor a la vez; sin embargo, a diferencia de muchas bases de datos clave-valor similares, las transacciones de escritura no bloquean a los lectores, ni los lectores a los escritores. LMDB también se distingue porque permite que varias aplicaciones en el mismo sistema abran y utilicen simultáneamente el mismo almacén LMDB, lo que permite escalar el rendimiento. Además, LMDB no requiere un registro de transacciones (lo que aumenta el rendimiento de escritura al no tener que escribir los datos dos veces) porque mantiene la integridad de los datos de forma inherente por diseño.

El diseño de LMDB se discutió por primera vez en una publicación de 2009 en la lista de correo de desarrolladores de OpenLDAP , ^{[ 2 ]} en el contexto de la exploración de soluciones a la dificultad de gestión de caché causada por la dependencia del proyecto de Berkeley DB . Un objetivo específico era reemplazar las múltiples capas de configuración y almacenamiento en caché inherentes al diseño de Berkeley DB con una única caché administrada automáticamente bajo el control del sistema operativo del host .

Posteriormente se inició el desarrollo, inicialmente como una bifurcación de una implementación similar del proyecto ldapd de OpenBSD . ^{[ 3 ]} La primera versión disponible públicamente apareció en el repositorio de código fuente de OpenLDAP en junio de 2011. ^{[ 4 ]}

El proyecto se conocía como MDB hasta noviembre de 2012, después de lo cual se le cambió el nombre para evitar conflictos con el software existente. ^{[ 5 ]}

Internamente, LMDB utiliza estructuras de datos de árbol B+ . La eficiencia de su diseño y su reducido tamaño tuvieron el efecto secundario no deseado de proporcionar también un buen rendimiento de escritura. LMDB tiene una API similar a la de Berkeley DB y dbm . LMDB trata la memoria del ordenador como un único espacio de direcciones, compartido entre múltiples procesos o hilos mediante memoria compartida con semántica de copia en escritura (conocida históricamente como almacenamiento de un solo nivel ). La mayoría de las arquitecturas informáticas modernas anteriores tenían un espacio de direcciones de memoria de 32 bits , lo que imponía un límite estricto de 4 GB al tamaño de cualquier base de datos que se mapeara directamente en un almacenamiento de un solo nivel. Sin embargo, los procesadores de 64 bits actuales implementan en su mayoría espacios de direcciones de 48 bits, lo que proporciona acceso a direcciones de 47 bits o 128  TB de tamaño de base de datos, ^{[ 6 ]} haciendo que las bases de datos que utilizan memoria compartida vuelvan a ser útiles en aplicaciones del mundo real.

Las características técnicas específicas más destacables de LMDB son:

• Su uso del árbol B+ . Con una instancia de LMDB en memoria compartida y el tamaño del bloque del árbol B+ configurado al tamaño de página del sistema operativo, el acceso a un almacenamiento LMDB es extremadamente eficiente en cuanto a memoria. ^{[ 7 ]}
• Los nuevos datos se escriben sin sobrescribir ni mover los datos existentes. Esto garantiza la integridad y la fiabilidad de los datos sin necesidad de registros de transacciones ni servicios de limpieza.
• La provisión de un modo de escritura y adición único (MDB_APPEND) ^{[ 1 ]} se implementa permitiendo que el nuevo registro se agregue directamente al final del árbol B+ . Esto reduce la cantidad de operaciones de lectura y escritura de páginas, lo que resulta en un rendimiento mucho mayor, pero requiere que el programador se asegure de que las claves ya estén ordenadas al almacenarlas en la base de datos.
• La semántica de copia en escritura ayuda a garantizar la integridad de los datos , además de proporcionar garantías transaccionales y acceso simultáneo por parte de los lectores sin necesidad de bloqueo, incluso por parte del escritor actual. Las nuevas páginas de memoria necesarias internamente durante las modificaciones de datos se asignan mediante la semántica de copia en escritura por el sistema operativo subyacente: la propia biblioteca LMDB nunca modifica los datos antiguos a los que acceden los lectores porque simplemente no puede hacerlo: cualquier actualización de memoria compartida crea automáticamente una copia completamente independiente de la página de memoria en la que se está escribiendo.
• Dado que LMDB utiliza mapeo de memoria, puede devolver punteros directos a las direcciones de memoria de las claves y los valores a través de su API, evitando así copias de memoria innecesarias y costosas. Esto se traduce en un rendimiento mucho mayor (especialmente cuando los valores almacenados son extremadamente grandes) y amplía los posibles casos de uso de LMDB.
• LMDB también realiza un seguimiento de las páginas de memoria no utilizadas, utilizando un árbol B+ para controlar las páginas liberadas (que ya no son necesarias) durante las transacciones. Al controlar las páginas no utilizadas, se evita por completo la necesidad de recolección de basura (y una fase de recolección de basura que consumiría ciclos de CPU). Las transacciones que necesitan páginas nuevas reciben primero páginas de este árbol de páginas libres no utilizadas; solo después de que estas se agoten, se expandirá a áreas previamente no utilizadas del archivo mapeado en memoria subyacente . En un sistema de archivos moderno con soporte para archivos dispersos , esto ayuda a minimizar el uso real del disco.

El formato de archivo de LMDB, a diferencia del de Berkeley DB , depende de la arquitectura. Esto significa que se debe realizar una conversión antes de mover una base de datos de una máquina de 32 bits a una de 64 bits, ^{[ 8 ]} o entre computadoras con diferente orden de bytes . ^{[ 9 ]}

En 2011, Google publicó un software que permitía a los usuarios generar microbenchmarks comparando el rendimiento de LevelDB con SQLite y Kyoto Cabinet en diferentes escenarios. ^{[ 12 ]} En 2012, Symas añadió soporte para LMDB y Berkeley DB y puso a disposición del público el software de benchmarking actualizado. ^{[ 13 ]} Los benchmarks resultantes mostraron que LMDB superó a todas las demás bases de datos en operaciones de lectura y escritura por lotes. SQLite con LMDB sobresalió en operaciones de escritura, y particularmente en escrituras síncronas/transaccionales.

Las pruebas de rendimiento mostraron que el sistema de archivos subyacente tiene una gran influencia en el rendimiento. JFS con un registro externo funciona bien, especialmente en comparación con otros sistemas modernos como Btrfs y ZFS . ^{[ 14 ] [ 15 ]} Zimbra ha probado el rendimiento de back-mdb frente a back-hdb en OpenLDAP, con LMDB superando claramente al back-hdb basado en BDB. ^{[ 16 ]} Muchos otros usuarios de OpenLDAP han observado beneficios similares. ^{[ 17 ]}

Desde el trabajo inicial de evaluación comparativa realizado en 2012, se han llevado a cabo múltiples pruebas de seguimiento con motores de bases de datos adicionales para cargas de trabajo tanto en memoria ^{[ 18 ]} como en disco ^{[ 19 ],} caracterizando el rendimiento en múltiples CPU y tamaños de registro. Estas pruebas muestran que el rendimiento de LMDB es inigualable en todas las cargas de trabajo en memoria y sobresale en todas las cargas de trabajo de lectura y escritura en disco con grandes tamaños de registro. El código del controlador de evaluación comparativa se publicó posteriormente en GitHub ^{[ 20 ]} y se amplió aún más su cobertura de bases de datos.

LMDB fue diseñado para resistir la pérdida de datos ante fallos del sistema y de las aplicaciones. Su enfoque de copia en escritura nunca sobrescribe los datos que se están utilizando. Evitar las sobrescrituras significa que la estructura en el disco/almacenamiento siempre es válida, por lo que los fallos de la aplicación o del sistema nunca pueden dejar la base de datos en un estado corrupto. En su modo predeterminado, en el peor de los casos, un fallo puede perder datos de la última transacción de escritura aún no confirmada. Incluso con todos los modos asíncronos habilitados, solo un fallo catastrófico del sistema operativo o una pérdida de energía del hardware ^{[ 21 ],} y no simplemente un fallo de la aplicación, podría potencialmente resultar en alguna corrupción de datos .

Dos artículos académicos del Simposio USENIX OSDI ^{[ 22 ]} cubrieron los modos de falla de los motores de DB (incluido LMDB) bajo una pérdida repentina de energía o caída del sistema. ^{[ 23 ] [ 24 ]} El artículo de Pillai et al. no encontró ninguna falla en LMDB que ocurriría en los sistemas de archivos del mundo real considerados; la única falla identificada por el estudio en LMDB solo se relaciona con sistemas de archivos hipotéticos. ^{[ 25 ]} El artículo de Mai Zheng et al. afirma señalar fallas en LMDB, pero la conclusión depende de si se utiliza fsync o fdatasync. El uso de fsync mejora el problema. La selección de fsync sobre fdatasync es un cambio en tiempo de compilación que no es el comportamiento predeterminado en las compilaciones actuales de LMDB para Linux, pero sí lo es en macOS, *BSD, Android y Windows. Por lo tanto, las compilaciones predeterminadas de LMDB para Linux son las únicas vulnerables al problema descubierto por los investigadores de Zhengmai; sin embargo, los usuarios de Linux pueden simplemente recompilar LMDB para utilizar fsync en su lugar. ^{[ 26 ]}

Cuando se le proporciona una base de datos corrupta, como una producida por fuzzing , LMDB puede fallar. El autor de LMDB considera que este caso no es preocupante, pero ha producido una solución parcial en una rama separada. ^{[ 27 ]}

En junio de 2013, Oracle cambió la licencia de Berkeley DB (un proyecto relacionado) de la licencia Sleepycat a la Licencia Pública General Affero , ^{[ 28 ]} restringiendo así su uso en una amplia variedad de aplicaciones. Esto provocó que el proyecto Debian excluyera la biblioteca a partir de la versión 6.0. También se criticó que esta licencia no es amigable con los redistribuidores comerciales. Se generó un debate sobre si el mismo cambio de licencia podría ocurrir con LMDB. El autor Howard Chu aclaró que LMDB es parte del proyecto OpenLDAP, que tenía su licencia de estilo BSD antes de que él se uniera, y seguirá siendo así. No se transfiere ningún derecho de autor a nadie al registrarse, lo que haría imposible una medida similar a la de Oracle. ^{[ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ]}

El problema de la licencia de Berkeley DB ha provocado que las principales distribuciones de Linux, como Debian , eliminen por completo el uso de Berkeley DB, prefiriendo LMDB. ^{[ 38 ]}

Hay envoltorios para varios lenguajes de programación, como C++, ^{[ 39 ] [ 40 ]} Java, ^{[ 41 ]} Python, ^{[ 42 ] [ 43 ]} Lua, ^{[ 44 ]} Rust, ^{[ 45 ] [ 46 ]} Go, ^{[ 47 ]} Ruby, ^{[ 48 ]} Objective C, ^{[ 49 ]} Objective CAML, ^{[ 50 ]} JavaScript, ^{[ 51 ]} C#, ^{[ 52 ]} Perl, ^{[ 53 ]} PHP, ^{[ 54 ]} Tcl ^{[ 55 ]} y Common Lisp. ^{[ 56 ]} Una lista completa de envoltorios se puede encontrar en el sitio web principal. ^{[ 57 ]}

Howard Chu adaptó SQLite 3.7.7.1 para usar LMDB en lugar de su código B-tree original , llamando al resultado SQLightning. ^{[ 58 ]} Una prueba de inserción citada de 1000 registros fue 20 veces más rápida (que el SQLite original con su implementación B-Tree). ^{[ 59 ]} LMDB está disponible como almacenamiento de respaldo para otros proyectos de código abierto incluidos Cyrus SASL, ^{[ 60 ]} Heimdal Kerberos, ^{[ 61 ]} y OpenDKIM. ^{[ 62 ]} También está disponible en algunos otros proyectos NoSQL como MemcacheDB ^{[ 63 ]} y Mapkeeper. ^{[ 64 ]} LMDB se usó para hacer que el almacenamiento en memoria Redis persistiera datos en disco. El backend existente en Redis mostró un comportamiento patológico en casos raros, y se buscó un reemplazo. Sin embargo, la API barroca de LMDB fue criticada, obligando a codificar mucho para hacer cosas simples. Sin embargo, su rendimiento y fiabilidad durante las pruebas fueron considerablemente mejores que los de los almacenes de back-end alternativos que se probaron. ^{[ 65 ]}

En el sitio web principal se mantiene una lista actualizada de las aplicaciones que utilizan LMDB. ^{[ 66 ]}

Muchos proyectos de software libre populares distribuyen o incluyen soporte para LMDB, a menudo como mecanismo de almacenamiento principal o único.

• Los sistemas operativos Debian , ^{[ 67 ]} Ubuntu , ^{[ 68 ]} Fedora , ^{[ 69 ]} y OpenSuSE ^{[ 70 ] .}
• OpenLDAP para el cual LMDB fue desarrollado originalmente a través de back-mdb . ^{[ 71 ]}
• Postfix a través del adaptador lmdb_table . ^{[ 72 ]}
• PowerDNS , un servidor DNS.
• CFEngine utiliza LMDB por defecto desde la versión 3.6.0. ^{[ 73 ]}
• Shopify utiliza LMDB en su sistema SkyDB. ^{[ 74 ]}
• Knot DNS es un servidor DNS de alto rendimiento.
• Monero es una criptomoneda de código abierto creada en abril de 2014 que se centra en la privacidad, la descentralización y la escalabilidad.
• El middleware Enduro/X utiliza LMDB para el almacenamiento en caché opcional de los microservicios XATMI (SOA). En la primera solicitud, se invoca el servicio; en la siguiente solicitud, el proceso cliente lee el resultado guardado directamente desde LMDB.
• Controlador de dominio de Active Directory de Samba
• Nano es una criptomoneda de código abierto, de igual a igual, creada en 2015 que prioriza las transacciones rápidas y sin comisiones.
• Meilisearch es un motor de búsqueda de código abierto, ultrarrápido, fácil de usar e hiperrelevante. ^{[ 75 ]}
• LMDB-IndexedDB es un envoltorio de JavaScript alrededor de IndexedDB para brindar soporte para LMDB en navegadores web. ^{[ 76 ]}

LMDB utiliza de forma novedosa técnicas informáticas bien conocidas, como la semántica de copia en escritura y los árboles B+, para proporcionar garantías de atomicidad y fiabilidad, así como un rendimiento que puede resultar difícil de aceptar, dada la relativa simplicidad de la biblioteca y el hecho de que ninguna otra base de datos de clave-valor similar ofrece las mismas garantías o rendimiento general, a pesar de que los autores afirman explícitamente en sus presentaciones que LMDB está optimizada para lectura, no para escritura. Además, dado que LMDB se desarrolló principalmente para su uso en OpenLDAP , sus desarrolladores se centran principalmente en el desarrollo y mantenimiento de OpenLDAP, no en LMDB en sí. Por lo tanto, el escaso tiempo que los desarrolladores dedicaron a presentar los primeros resultados de la prueba de rendimiento fue criticado por no indicar las limitaciones y por dar una impresión de "solución milagrosa" que no resultaba adecuada para abordar la perspectiva de un ingeniero ^{[ 77 ]} (cabe señalar que, sin embargo, las preocupaciones planteadas fueron posteriormente abordadas adecuadamente a satisfacción del revisor por el desarrollador principal de LMDB ^{[ 78 ]} ) .

La presentación impulsó a otros desarrolladores de bases de datos a analizar el código en profundidad para comprender cómo y por qué funciona. Las reseñas varían desde breves ^{[ 79 ]} hasta exhaustivas. El desarrollador de bases de datos Oren Eini escribió una serie de 12 artículos sobre su análisis de LMDB, que comenzó el 9 de julio de 2013. La conclusión fue del tipo "un código base impresionante... que necesita urgentemente mejoras", principalmente debido a la excesiva longitud de los métodos y la duplicación de código. ^{[ 80 ]} Esta reseña, realizada por un desarrollador .NET sin experiencia previa en C , concluyó el 22 de agosto de 2013 con: "Más allá de mis problemas con el código, la implementación es realmente brillante. La forma en que LMDB logra incluir tanta funcionalidad sin hacer nada es bastante impresionante... Aprendí mucho del proyecto, y ha sido una experiencia frustrante, molesta y fascinante". ^{[ 81 ]}

Existen otras numerosas reseñas sobre LMDB ^{[ 82 ] [ 83 ]} en varios idiomas, incluido el chino. ^{[ 84 ]}

• Almacén de clave-valor ordenado
• libmdbx (también conocido como MDBX) es una versión profundamente revisada y ampliada de LMDB que, según sus desarrolladores, "supera al legendario LMDB en cuanto a funcionalidades y fiabilidad, sin ser inferior en rendimiento". Cabe destacar que MDBX se utiliza en Ethereum (Erigon, Reth), en productos de StarkWare Industries y Positive Technologies , así como en muchos otros proyectos de software.