¿Qué tan rápido es Berkeley DB SQL en comparación con SQLite?

benchmarking berkeley-db

Question

Oracle lanzó recientemente un back-end de Berkeley DB a SQLite . Resulta que tengo una base de datos SQLite de cientos de megabytes que podría beneficiarse de "un rendimiento, concurrencia, escalabilidad y confiabilidad mejorados", pero el sitio de Oracle parece carecer de mediciones de las mejoras. ¿Alguien ha hecho alguna evaluación comparativa?

Answer 1

Además del Berkeley DB Book que Brian menciona, también puede encontrar útiles los siguientes recursos:

• Los foros en línea de Berkeley DB pueden proporcionar muchas sugerencias tanto de los usuarios como de los desarrolladores del producto. Ver foro Berkeley DB ,
• El conjunto de documentación Berkeley DB, que se puede encontrar here . En particular, hay varias secciones en la Guía de referencia que cubren el ajuste, el rendimiento y el rendimiento.

Answer 2

Esa es una pregunta un poco cargada. Los resultados variarán drásticamente según las velocidades de acceso al disco, el tamaño de la memoria caché, el número de insertos y las lecturas, divisiones de páginas, concurrencia, etc., etc.

En general, BerkeleyDB puede ser extremadamente rápido: recientemente diseñé una plataforma de análisis de datos para un empleador que era capaz de hacer inserciones de 40 k por segundo en un sistema x86 de 8 núcleos (mientras que al mismo tiempo realizaba miles de lecturas por segundo) con un conjunto de datos en el rango 30G. Esto fue con protección transaccional completa.

Sin embargo, ese fue el mejor de los casos: hubo momentos en los que las inserciones podían bajar hasta 2k por segundo, dependiendo de los datos entrantes y de lo que se almacenaba actualmente en Berkeley. El rendimiento disminuye significativamente si tiene E / S de disco lento y una tasa de aciertos de caché deficiente o si expande constantemente el DB y ocasiona divisiones de página. También hay una gran cantidad de ajuste que puede hacer para aumentar el rendimiento de su conjunto de datos particular.

En general, es un sistema excelente, pero la documentación y el conocimiento son bastante escasos. Recomiendo The BerkeleyDB Book como probablemente la mejor referencia disponible actualmente.

Answer 3

Participé en la evaluación beta del código BDB SQLite y una de las cosas que intenté controlar fue la diferencia en el rendimiento. En este punto, no puedo publicar exactamente lo que encontré hasta que al menos otra persona evalúe mi código, ejecute las pruebas y confirme los números que obtuve (lo que se está haciendo). Sin embargo, puedo generalizar aquí y decir que hay casos en los que BDB ofrece mejoras de rendimiento significativas sobre SQLite, específicamente en el área de manejo de cargas pesadas que implican concurrencia de escritura.

En general, hay dos medidas de eficacia "rápida" - (1) eficiencia: ¿cuánto tiempo lleva realizar un proceso único XYZ vs. (2) concurrencia: cuántas veces pueden hacer muchos procesos XYZ por unidad de tiempo? El problema principal que BDB aborda es la concurrencia: procesamiento de transacciones a gran escala. Por lo tanto, piensa en muchas conexiones concurrentes que escriben y / o modifican los contenidos de la base de datos.

SQLite por diseño usa el bloqueo de nivel de base de datos, por lo que hay un máximo de un escritor que puede trabajar en la base de datos a la vez. Por lo tanto, la tasa de transacciones de SQLite se mantiene más o menos constante con el número de conexiones simultáneas, por lo que su escalabilidad en aplicaciones de escritura intensiva se mide realmente por su eficiencia (1).

Por otro lado, BDB utiliza el bloqueo de nivel de página, que permite que varios escritores trabajen en la base de datos en un momento dado (siempre que estén trabajando en páginas separadas). Por lo tanto, la tasa de BDB aumenta potencialmente con el número de conexiones, por lo que su escalabilidad es una cuestión de eficiencia (1) y concurrencia (2), que puede sumar.

Principalmente, lo que se reduce a es la concurrencia (escritura). BDB puede impulsar más TPS que SQLite para múltiples escritores. Por transacción, me refiero a algo que modifica la base de datos (¿cómo son de alguna ayuda real para las operaciones de solo lectura?). Dicho esto, para la concurrencia de lectura (aplicaciones que principalmente hacen SELECT), SQLite podría ir cara a cara con BDB porque el bloqueo ya no es un problema crítico.

En cuanto al tamaño del conjunto de datos, no estoy seguro. No he investigado eso. En última instancia, ambos usan B-trees para el almacenamiento. Puede haber factores en sus respectivas implementaciones para considerar, pero no he investigado eso. Sé que SQLite puede manejar con gracia conjuntos de datos en cientos de MB y GB de doble dígito (y tal vez más ahora que se ha cambiado la implementación del mapa de página sucia).

Por lo tanto, si tiene una aplicación que emplea muchas conexiones que modifican una base de datos determinada y la contención de la página es relativamente baja, entonces BDB puede ofrecer mejoras significativas en el rendimiento. Pero la contención de la página es una variable crítica. En el límite, si tuviera una base de datos BDB cuyos datos constaran de una sola página, su rendimiento coincidiría con la de SQLite en todos los casos porque el bloqueo de nivel de página aquí degenera efectivamente en el equivalente al bloqueo de nivel de base de datos, todo el mundo está peleando una cosa. Sin embargo, a medida que aumenta el número de páginas en BDB (y la contención de la página disminuye), entonces el TPS máximo comenzará a crecer con el número de conexiones simultáneas. Luego, desde ese punto, la memoria se convierte en el siguiente factor limitante. Pero esa es otra historia.

Por cierto, estoy en el proceso de escribir un artículo sobre el uso de BDB para quienes provienen de SQLite.

Artículo enlaces:

Oracle Berkeley DB SQL API vs. SQLite API - Una evaluación técnica

Oracle Berkeley DB SQL API vs. SQLite API - Integración, beneficios y diferencias