Razones para usar SqLite en 2016

Fácil de manejar

Hay unas cuantas cosas que hay que entender para poder garantizar que el servidor de base de datos está configurado correctamente (buffers compartidos, tamaño efectivo caché, mem trabajo, mem trabajos de mantenimiento, tampones wal …). La actualización puede ser un proceso de miedo. Y además, ¿sabes dónde está su base de datos? ¿Puede señalar algún lugar y decir: «ese es mi base de datos»?

Quiero destacar la diferencia entre la gestión de un SQLite db en comparación con un servidor de base típica.

SQLite es fácil de manejar – es un solo archivo (o en algunos momentos un archivo + de registro de transacciones). El formato de archivo es estable a través de versiones principales, por lo que si tuviera un archivo de base de datos SQLite desde la versión 3.0.0 (en 2004), podría leerlo utilizando la última SQLite 3.10.0. Si quiero tener el archivo de base de datos conmigo en una unidad flash, copia el archivo, o mejor aún guardo en mi carpeta de Dropbox. Si quiero compartir algunos análisis de datos que estoy haciendo con un compañero de trabajo, sólo puede enviar una copia del archivo de base y están listos. Tener la base de datos en un único archivo con un formato estable es una característica.

SQLite es muy fácil de configurar. Las características SQLite son manejadas de dos maneras: banderas de compilación y declaraciones PRAGMA (configuración en tiempo de ejecución).

SQLite es desarrollado activamente por algunos ingenieros de software realmente sorprendentes. Las nuevas características de alta calidad se añaden a un ritmo impresionante. Recientemente SQLite añadió soporte para datos JSON a través de la extensión json1. SQLite también lanzó una versión mejorada de la extensión de búsqueda de texto completo, que incluye como resultado la clasificación utilizando el algoritmo BM25.

SQLite ahora funciona dos veces más rápido que la versión 3.8.0 y tres veces más rápido que la versión 3.3.9

A pesar de todos estos cambios y mejoras, SQLite raramente presenta errores. El conjunto de pruebas SQLite es ampliamente considerado como uno de los mejores en la industria.

Extensible y hackeable

Mi característica favorita de SQLite es su extensibilidad. Debido SQLite está integrado por su aplicación, que se ejecuta en el mismo espacio de direcciones y puede ejecutar código de la aplicación en su nombre. Tanto el conductor Python biblioteca SQLite estándar, pysqlite, y el conductor alternativo proporcionan APSW APIs para la definición de las funciones de encargo SQL, funciones de agregado, y colaciones. APSW va un paso más allá y ofrece APIs para definir tablas virtuales y sistemas de archivos virtuales!

La velocidad del rayo

SQLite es muy rápido. Se ejecuta en la misma máquina, lo que no hay sobrecarga de red al ejecutar consultas o la lectura de los resultados. Se ejecuta en el mismo espacio de direcciones, por lo que no existe un protocolo de alambre.

Modo WAL

La versión 3.7.0 de SQLite añadió un nuevo método de diario que utiliza un registro de escritura anticipada. Por sí mismo esto no es realmente una excelente noticia, pero lo que significa para los desarrolladores de aplicaciones Web (o cualquiera que se relacione con la concurrencia) es que los lectores ya no bloquean a los escritores, y viceversa. O, para decirlo de otro modo, la lectura y escritura puede producirse tanto simultaneamente.

 

database-sqlite

Optimizar tu MySQL

query_cache_size:
MySQL 4 proporciona una característica que puede resultar muy útil – una caché de consultas. En una situación en la base de datos tiene que ejecutar varias veces las mismas preguntas en el mismo conjunto de datos, devolviendo el mismo resultado cada vez, MySQL puede cachear resultados, evitando la sobrecarga de ejecución a través de los datos una y otra y es extremadamente útil en servidores con mucha carga.

key_buffer_size:
El valor de key_buffer_size es el tamaño del búfer utilizado con los índices. Cuanto mayor sea el buffer, más rápido terminará el comando SQL y el resultado será devuelto. Se supone que lo mejor es ajustar el key_buffer_size con al menos un cuarto de la memoria del servidor, pero no más de la mitad de la cantidad total. Idealmente, será lo suficientemente grande como para contener todos los índices (el tamaño total de todos los archivos. MYI en el servidor).

table_cache:
El valor predeterminado es 64. Cada vez que MySQL tiene acceso a una tabla, se coloca en la caché. Si el sistema accede a muchas tablas, es más rápido para tener estas en la caché. MySQL al ser multi-threaded, puede ejecutar muchas consultas sobre sobre una tabla a la vez, y cada uno de éstas abrirá una tabla.

sort_buffer:
El sort_buffer es muy útil para acelerar las operaciones de myisamchk (razón por la cual se fija mucho más alto para ese fin en los archivos de configuración por defecto), pero también puede ser útil cuando se realizan todos los días un gran número de ordenaciones o clasificaciones.

thread_cache:
Si se tiene un servidor con mucha carga que está recibiendo una gran cantidad de conexiones rápida, hay que configurar la thread_cache lo suficientemente alto para que el valor d threads_created en SHOW STATUS deja de aumentar. Esto debe tomar parte de la carga fuera de la CPU.

tmp_table_size:
(no incluido en el archivo de configuracion, pero este parámetro también se puede configurar).»Created_tmp_disk_tables» son el número de tablas temporales implícitos en el disco creado durante la ejecución declaraciones y «Created_tmp_tables» están basados en memoria. Obviamente, es malo si tiene que ir a la disco en lugar de la memoria todo el tiempo.

wordpress_mysql_backup