Almacenes de valor clave frente a RDBM frente a bases de datos "en la nube" (SDB) [cerrado]

Question

Me siento cómodo en el espacio MySQL después de haber diseñado varias aplicaciones en los últimos años, y luego perfeccionar continuamente los aspectos de rendimiento y escalabilidad. También tengo algo de experiencia trabajando con memcached para proporcionar aceleraciones del lado de la aplicación en conjuntos de resultados consultados con frecuencia. Y recientemente implementé Amazon SDB como mi principal "base de datos". para un experimento de comercio electrónico.

Para simplificar en exceso, una rápida justificación que utilicé en mi mente para usar el servicio SDB fue que usar una estructura de base de datos sin esquema me permitiría concentrarme en el problema lógico de mi proyecto y acumular rápidamente contenido en mi almacén de datos . Es decir, no se preocupe por configurar y normalizar todas las posibles permutaciones de los atributos de un producto de antemano; simplemente comience a cargar los productos y el SDB simplemente recordará todo lo que esté disponible.

Ahora que he logrado superar las primeras iteraciones de mi proyecto y necesito configurar interfaces simples para los datos, me estoy enfrentando a problemas que había dado por sentado trabajando con MySQL. Ej: agrupación en sentencias select y sintaxis de límite para consultar '' elementos 50 a 100 ''. La ventaja de la facilidad que obtuve al usar la arquitectura de SDB sin esquema, la perdí por un golpe de rendimiento al consultar / recorrer un conjunto de resultados con poco más de 1800 elementos.

Ahora estoy leyendo sobre proyectos como el Gabinete de Tokio que están ampliando el concepto de almacenes de valores-clave en memoria para proporcionar una funcionalidad pseudo-relacional a velocidades ridículamente más rápidas (14 veces leí en alguna parte).

Mi pregunta: ¿Existen algunas pautas o heurísticas rudimentarias que yo, como diseñador / desarrollador de aplicaciones, pueda seguir para evaluar qué tecnología de base de datos es la más adecuada en cada etapa de mi proyecto?

Ej: en una etapa de creación de prototipos donde las incógnitas lógicas / técnicas de la aplicación hacen que la estructura de datos sea fluida: use SDB. En una etapa más madura en la que los entregables del usuario son una prioridad, use herramientas tradicionales en las que no tenga que pasar tiempo de desarrollo escribiendo lógica de clasificación, agrupación o paginación.

La experiencia práctica con estas herramientas sería muy apreciada.

¡Muchas gracias!

Shaheeb R.

Answer 1

Las nuevas soluciones no son balas de plata.

En comparación con el RDBMS tradicional, estos sistemas hacen mejoras en algún aspecto (escalabilidad, disponibilidad o simplicidad) al compensación otros aspectos (capacidad de consulta reducida, consistencia eventual, rendimiento horrible para ciertas operaciones).

Piense en estos no como reemplazos de la base de datos tradicional, sino que son herramientas especializadas para una necesidad conocida y específica.

Tome Amazon Simple DB por ejemplo, SDB es básicamente una gran hoja de cálculo, si así es como se ven sus datos, entonces probablemente funcione bien y la excelente escalabilidad y simplicidad le ahorrarán mucho tiempo y dinero.

Si su sistema requiere consultas muy estructuradas y complejas, pero insiste con una de estas nuevas y geniales soluciones, pronto se encontrará en medio de volver a implementar un RDBMS amateur, mal diseñado, con todos sus problemas inherentes.

A este respecto, si no sabe si esto se adaptará a sus necesidades, creo que en realidad es mejor hacer sus primeras iteraciones en un RDBMS tradicional porque le brindan la mejor flexibilidad y capacidad, especialmente en la implementación de un solo servidor y bajo carga modesta. (ver Teorema CAP ).

Una vez que tenga una mejor idea acerca de cómo se verán sus datos y cómo se utilizarán, entonces puede satisfacer sus necesidades con una solución alternativa.

Si desea la simplicidad de una solución alojada en la nube, pero necesita una base de datos relacional, puede consultar: Amazon Servicio de base de datos relacional

Answer 2

Los problemas que está encontrando son los motivos por los que los especialistas de RDBMS ven algunos de los sistemas alternativos con un ojo con ictericia. Sí, los sistemas alternativos manejan ciertos requisitos específicos extremadamente rápido, pero tan pronto como desee hacer algo más con los mismos datos, el más veloz de repente se convierte en el rezagado. Por el contrario, un RDBMS típicamente maneja las variaciones con mayor aplomo; Puede que no sea tan rápido como el fleetest para la carga de trabajo especializada que el fleetest está micro-optimizado para manejar, pero rara vez se deteriora tan rápido cuando se le pide que se ocupe de otras consultas.