Duplicar posibles:
What are the performance characteristics of sqlite with very large database files?base de datos con una tabla que contiene 700 millones de registros
Quiero crear una aplicación .NET que utiliza una base de datos que contendrá alrededor de 700 millones de discos en una de sus tablas. Me pregunto si el rendimiento de SQLite satisfaría este escenario o debería usar SQL Server. Me gusta la portabilidad que me da SQLite.
Vaya para SQL Server seguro. 700 millones de registros en SQLite es demasiado.
Con SQLite que haya limitación siguiente
Salida en este tema: What are the performance characteristics of sqlite with very large database files?
SQLite debe ser capaz de manejar esta cantidad de datos. Sin embargo, puede que tenga que configurarlo para permitir que crezca a este tamaño, y no debe tener esta cantidad de datos en una instancia "en memoria" de SQLite, solo en principios generales.
Para obtener más información, consulte this page que explica los límites prácticos del motor SQLite. La configuración de configuración relevante es el tamaño de página (normalmente 64 KB) y el recuento de páginas (hasta un valor máximo de int de 64 bits de aproximadamente 2.100 millones). Haga los cálculos, y toda la base de datos puede ocupar más de 140TB. Una base de datos que consta de una sola tabla con 700m filas sería del orden de decenas de gigs; facilmente manejable
Sin embargo, solo porque SQLite PUEDE almacenar esa cantidad de datos no significa que DEBERÍA. El mayor inconveniente de SQLite para las grandes áreas de almacenamiento de datos es que el código SQLite se ejecuta como parte de su proceso, utilizando el hilo al que se lo llama y ocupando la memoria en su entorno limitado. No se obtienen las herramientas disponibles en los DBMS de servidor para "dividir y conquistar" grandes consultas o áreas de almacenamiento de datos, como la replicación/clustering. Al tratar con una tabla grande como esta, la inserción/supresión tomará mucho tiempo para colocarla en el lugar correcto y actualizar todos los índices. La selección PUEDE ser habitable, pero solo en consultas indexadas; una página o una exploración de tabla te matará.
He tenido tablas con recuentos de registros similares y sin problemas de recuperación.
Para empezar, el hardware y la asignación al servidor es donde puede comenzar. Ver esto por ejemplos: http://www.sqlservercentral.com/blogs/glennberry/2009/10/29/suggested-max-memory-settings-for-sql-server-2005_2F00_2008/
Independientemente del tamaño o número de registros, siempre y cuando:
que debe estar bien. Además, establecer el tipo/tamaño de columna adecuado para cada columna ayudará.
700m es mucho.
Para que tenga una idea. Digamos que su tamaño de registro fue de 4 bytes (almacenando esencialmente un único valor), entonces su base de datos va a superar los 2 GB. Si su tamaño de registro es algo más cercano a 100 bytes, entonces está más cerca de 65 GB ... (eso no incluye el espacio utilizado por los índices y los archivos de registro de transacciones, etc.).
Trabajamos mucho con bases de datos grandes y nunca consideraría SQLLite para nada de ese tamaño. Francamente, "Portabilidad" es la menor de sus preocupaciones aquí. Para consultar un DB de ese tamaño con cualquier tipo de capacidad de respuesta, necesitará un servidor de base de datos de tamaño adecuado. Me gustaría iniciar con 32 GB de RAM y unidades de disco rápidas.
Si escribe un 90% o más, es posible que tenga una memoria RAM más pequeña. Si se lee pesado, querrá intentar construirlo para que la máquina pueda cargar la mayor cantidad posible de DB (o al menos índices) en la RAM. De lo contrario, dependerá de las velocidades del eje del disco.
La portabilidad está sobrevalorada. – jason