2008-12-10 15 views
7

He estado leyendo algunos tutoriales sobre cómo comenzar a usar Rails 2.0.Rails 2.0: ¿Por qué no usar sqlite3?

(Tiempo de espera: genio idea nombre del sitio web concebido a partir de un error tipográfico que acabo de hacer: "tutoRAILS". En este momento, volviendo a mi pregunta)

En la mayoría de los tutoriales que he estado leyendo, que parece alentar el uso de MySQL en lugar de sqlite3. ¿Hay alguna razón para esto, como rendimiento o cualquier otra cosa? Estoy probando Rails en mi PC con InstantRails en este momento, y son lo suficientemente agradables para incluir MySQL en su configuración, pero he estado haciendo mis aplicaciones experimentales usando sqlite3. ¿Me falta algo importante de sqlite3, o es solo una preferencia general que otros tienen para MySQL?

Respuesta

11

SQLite es un buen motor, pero todavía es un en proceso (o de escritorio) motor de estilo. Los motores en proceso tienen debilidades inherentes en términos de concurrencia que los hacen una elección fundamentalmente pobre en comparación con los motores basados ​​en servidor como MySQL para sitios web u otros escenarios con el potencial para un gran acceso de escritura simultánea.

Ver esta página en el sitio web de SQLite:
http://www.sqlite.org/whentouse.html

SQLite por lo general será un gran trabajo como el motor de base de datos de baja a sitios web de tráfico medio

y

si ... estás pensando en dividir el componente de la base de datos en una máquina separada, entonces definitivamente deberías considere usar un motor de base de datos cliente/servidor de clase empresarial en lugar de SQLite.

+3

También dicen: 'cualquier sitio que obtenga menos de 100K hits/día debería funcionar bien con SQLite. La cifra 100K hits/day es una estimación conservadora, no un límite superior difícil. Se ha demostrado que SQLite funciona con 10 veces esa cantidad de tráfico ". Dicho esto, SQlite está bien para el 95% de los sitios de Internet. – Niteriter

1

Creo que es principalmente una cuestión de mantener el nivel de fricción bajo en el tutorial. Si es un recién llegado, recomendaría MySql solo porque será más fácil hacer el tutorial. sqlite es una buena solución de escritorio de lo contrario.

+0

Otorgado No uso Rails, pero personalmente encontré que SQLite es mucho más fácil de usar que MySQL –

4

SQLite es increíble, pero tiene problemas de rendimiento con múltiples lectores y escritores concurrentes.

Al igual que en el caso de Joel, si su sitio tiene poco tráfico, esto rara vez será un problema, pero en actividad media a veces obtengo DB bloqueados (y consultas colgadas). En este caso, es mejor una base de datos con mejor soporte para múltiples usuarios concurrentes.

Personalmente, si utilizo una capa DB-agnostic para acceder a la base de datos, entonces es fácil cambiar de una a la otra, por lo que es fácil comenzar con SQLite y pasar a otra cuando sea necesario.

3

Siempre empiezo con SQLite. Si necesito prototipar un proyecto de Rails, puedo estar funcionando sin literalmente. Construir algunos andamios, ejecutar mis migraciones, escribir algunas pruebas y me voy a las carreras.

Sin embargo, si un proyecto llega al punto en el que lo implementará, y cuando lo haga, sugeriría MySQL o PostgreSQL para un mejor rendimiento.

SQLite también tiene sus ventajas para pequeñas aplicaciones integradas o si no tiene los gastos generales para ejecutar una base de datos para una herramienta que solo unas pocas personas usarán.

0

Tenga en cuenta que Sqlite es el motor predeterminado para el marco Camping.Tiene sentido ya que ambos apuntan a pequeña y rápida, no grande y empresarial

2

Dado que Rails 2.0, sqlite3 es la base de datos predeterminada, por lo que ciertamente no hay ningún prejuicio en contra. Sin embargo, muchos tutoriales Rails preceden a Rails 2.0 cuando la base de datos predeterminada era MySQL.

Como muchos otros lo han mencionado, sqlite3 es una buena base de datos que permite una aplicación rápida y fácil de usar. Para su entorno de desarrollo de Rails, tiene patas: es probable que funcione bien, incluso si su aplicación se vuelve compleja. Para el entorno de prueba de Rails, también es una muy buena opción: es muy rápido y la mayoría de las pruebas tienen demandas de bases de datos relativamente simples y tienden a no requerir concurrencia o no cumplir con las limitaciones de sqlite3.

Sin embargo, para muchos, si no la mayoría, los sitios web de producción, una base de datos diseñada para más de concurrencia pueden ser llamados para - MySQL, PostgreSQL, etc ..

2

Para algo así como un blog de motor SQLite rieles funcionará muy bien, incluso en volúmenes bastante altos porque es todo lo que lee y muy pocos escribe. De hecho, la mayoría de sus visitas serán páginas almacenadas en caché, dependiendo de si permite comentarios y cuán activos son sus hilos de comentarios, puede salirse con la suya con un único proceso de raíles porque su servidor web se encargará de casi todas las solicitudes.

Con una base de datos SQLite, cada proceso de rieles tiene que luchar por un bloqueo del sistema de archivos en el archivo para escribir, por lo que terminará bloqueando mucho si tiene muchos procesos escritos. Una forma de pensar sobre esto es considerar cuántos procesos de rieles tendrá ... si va a necesitar más de 3-4, probablemente SQLite no sea una buena opción.

Cuestiones relacionadas