sqlite o mysql para grandes conjuntos de datos

Question

Estoy trabajando con grandes conjuntos de datos (decenas de millones de registros, a veces, cientos de millones), y quiero usar un programa de base de datos que enlace bien con R. Estoy tratando de decidir entre mysql y sqlite. Los datos son estáticos, pero hay muchas consultas que debo hacer.

En este link to sqlite help, se establece que:.

"Con el tamaño de página predeterminado de 1024 bytes, una base de datos SQLite tiene un tamaño limitado a 2 terabytes (241 bytes) E incluso si pudiera manejar grandes bases de datos, SQLite almacena toda la base de datos en un solo archivo de disco y muchos sistemas de archivos limitan el tamaño máximo de los archivos a algo menor. Por lo tanto, si está contemplando bases de datos de esta magnitud, haría bien en utilizar un motor de base de datos cliente/servidor que se propague su contenido en múltiples archivos de disco, y quizás en múltiples volúmenes ".

No estoy seguro de lo que esto significa. Cuando he experimentado con mysql y sqlite, parece que mysql es más rápido, pero no he construido pruebas de velocidad muy rigurosas. Me pregunto si mysql es una mejor opción para mí que sqlite debido al tamaño de mi conjunto de datos. La descripción anterior parece sugerir que este podría ser el caso, pero mis datos no están cerca de 2TB.

Hubo un discussion on stackoverflow que tocó esto y se refirió a la misma página de información sqlite, pero no resolvió completamente esta cuestión.

Agradecería cualquier información sobre la comprensión de esta limitación del tamaño máximo de archivo del sistema de archivos y cómo esto podría afectar la velocidad para las tablas de indexación y las consultas en ejecución. Esto realmente podría ayudarme en mi decisión de qué base de datos usar para mi análisis.

Answer 1

El motor de base de datos SQLite almacena toda la base de datos en un solo archivo. Esto puede no ser muy eficiente para archivos increíblemente grandes (el límite de SQLite es de 2 TB, como lo ha encontrado en la ayuda). Además, SQLite está limitado a un usuario a la vez. Si su aplicación está basada en la web o puede terminar siendo multiproceso (como un AsyncTask en Android), mysql es probablemente el camino a seguir.

Personalmente, como ya has hecho las pruebas y mysql es más rápido, me gustaría ir con mysql. Será más escalable yendo hacia el futuro y te permitirá hacer más.

Answer 2

SQL si está utilizando principalmente esto como un servicio web. SQLite, si lo desea, puede funcionar fuera de línea.

SQLite generalmente es mucho más rápido, ya que la mayoría (o TODOS) de los datos/índices se almacenarán en la memoria. Sin embargo, en el caso de SQLite. Si los datos se dividen en varias tablas, o incluso múltiples archivos de base de datos SQLite, desde mi experiencia hasta el momento. Incluso para millones de registros (aún tengo cientos de millones), es mucho más efectivo que SQL (compensar la latencia/etc). Sin embargo, es cuando los registros se dividen en diferentes tablas, y las consultas son específicas de dichas tablas (no consultas todas las tablas).

Un ejemplo sería una base de datos de elementos utilizada en un juego simple. Si bien esto puede no parecer mucho, se emitirá un UID para variaciones uniformes. Entonces, el generador pronto se resolverá rápidamente con más de un millón de 'estadísticas' con variaciones. Sin embargo, esto se debió principalmente a que cada 1000 conjuntos de registros se dividieron entre diferentes tablas. (ya que principalmente extraemos registros a través de su UID). Aunque la realización de la división no se midió correctamente. Obtuvimos consultas que eran fácilmente 10 veces más rápidas que SQL (Principalmente debido a la latencia de la red).

Aunque, curiosamente, terminamos reduciendo la base de datos a unas 1000 entradas, con el elemento [pre-fix]/[suf-fix] determinando las variaciones. (Como Diablo, solo que estaba escondido).Que resultó ser mucho más rápido al final del día.

En una nota lateral, sin embargo, mi caso se debió principalmente a que las consultas se alinearon una tras otra (esperando la anterior). Sin embargo, si puede hacer múltiples conexiones/consultas al servidor al mismo tiempo. La caída de rendimiento en SQL, es más que compensada, desde su lado del cliente. Suponiendo que estas consultas no se ramifican/interactúan entre sí (por ejemplo, si tiene un resultado consulta esto, sino que)

Answer 3

No estoy seguro de lo que esto significa. Cuando he experimentado con mysql y sqlite, parece que mysql es más rápido, pero no he construido pruebas de velocidad muy rigurosas.

La versión corta corta es:

1. Si su aplicación tiene que encajar en un teléfono o algún otro sistema embebido, utilizar SQLite. Para eso fue diseñado.

2. Si su aplicación podría necesitar más de uno conexión simultánea, no utilizan SQLite. Uso PostgreSQL, MySQL con InnoDB, etc.

Answer 4

Parece que (en R, por lo menos), que SQLite es impresionante para ad hoc análisis. Con los paquetes RSQLite o sqldf, es muy fácil cargar datos y comenzar. Pero para los datos que usará una y otra vez, me parece que MySQL (o SQL Server) es el camino a seguir porque ofrece muchas más funciones en términos de modificación de su base de datos (por ejemplo, agregar o cambiar claves) .