Esta es la última parte de una serie cuyo objetivo es introducir qué son las bases de datos y dar algunas opiniones sobre las tecnologías de bases de datos disponibles, por qué deberías usarlas y cuándo deberías usarlas de forma no técnica. En la entrada anterior, comparamos diferentes tecnologías SQL y exploramos casos de uso y por qué elegiríamos una sobre otra. En esta entrada de blog, abordamos cuestiones de escala y respondemos a la pregunta "¿Necesito un servidor?".
El objetivo de esta entrada de blog es darte una idea de la escala, para que puedas acotar tus decisiones sobre bases de datos. Para responder a la pregunta titular: No. Usted no necesita un servidor. Puede ejecutar MySQL en una Raspberry Pi y obtener tanto o más rendimiento que el que obtendría de algún mega-servidor de 10u cuyo mantenimiento mensual cuesta más que una Pi; lo digo no sólo por el valor de shock, sino porque es probablemente cierto.
Las preguntas que debes hacerte en el contexto de tu proyecto/producto son:
- ¿Cuántos datos necesito guardar?
- ¿A cuántos datos necesito acceder?
- ¿Con qué frecuencia necesito acceder a esos datos?
- ¿Cuántas conexiones necesitan editar los mismos datos simultáneamente?
Las respuestas a estas preguntas pueden darle una idea de la escala.
Para dar algunos ejemplos de lo que puede considerarse una gran cantidad de datos, he aquí algunos escenarios posibles:
- Usted captura datos rotacionales disparados por conteos de encoder para 10 entradas a velocidades variables, el motor funciona 24/7
- Obtener datos instantáneos de una media de 100 rotaciones una vez al día durante el periodo de mantenimiento del motor no es una gran cantidad de datos.
- Transmitir todos los datos a una base de datos durante el periodo de mantenimiento es una gran cantidad de datos.
- Tienes un sistema de control de calidad que realiza pruebas en unos 50 productos al día y almacena información para 100 entradas más o menos
- Almacenar los datos es fácil. Para este caso de uso, no suele haber límite superior y, dado que la información de los productos suele archivarse y no se accede a ella con mucha frecuencia una vez que el producto se ha vendido, la mayoría de los datos tienen un acceso muy bajo.
- Si se trata de una empresa muy distribuida, con millones de productos al día, en la que los datos deben ser consultados por la logística y por un experto en estadísticas de eficiencia, es posible que se necesite un servidor para atender todas esas conexiones.
Una vez que se tiene una idea de los datos, es importante tener una idea clara de cómo se piensa utilizarlos. Mientras que abrir 100 MB de datos ASCII en una hoja de cálculo Excel es a veces pedir demasiado, el mismo proceso en una base de datos es un paseo por el parque.
Por lo general, una base de datos puede servir datos lo suficientemente rápido como para que no sea necesario almacenarlos en caché o en un búfer. El problema es cuando varias personas (o aplicaciones) necesitan acceso de escritura a los datos, algo que no es un caso de uso normal para Excel y que suele ser una limitación básica del almacenamiento de datos basado en archivos. SQL puede hacer esto, pero para que el servicio SQL sea accesible de forma remota, un servidor puede ser la solución más razonable.
Las bases de datos pueden complicar considerablemente el esfuerzo de desarrollo de software, sobre todo la primera vez, pero ofrecen importantes ventajas a largo plazo y encajan fácilmente en la categoría de desarrollo excesivo o a prueba de futuro de una aplicación cuando se implantan al principio del ciclo de vida del proyecto.
Con esto concluye esta serie de tres artículos sobre bases de datos. Esperamos que haya aprendido algo nuevo.
- https://upload.wikimedia.org/wikipedia/commons/6/69/Wikimedia_Foundation_Servers-8055_35.jpg
- Por Evan-Amos - Obra propia, Dominio público, https://commons.wikimedia.org/w/index.php?curid=56262833
