Desde una perspectiva de escalabilidad, ¿debería una startup adoptar NoSQL desde el primer día o debería convertirse gradualmente a medida que crecen la base de usuarios y los datos?

Un simple: no

¿Por qué siente que necesita una solución NoSQL? ¿Que problema estas tratando de resolver? ¿Cómo te ha fallado un RDBMS? ¿Cuál ves que es tu punto clave de falla?

Como startup, su mayor problema no es la escala, es hora de comercializar. Si está escalando para un millón de usuarios y no puede obtener 100, esencialmente ha perdido el tiempo de sus inversores cuando podría haber pasado ese tiempo iterando sobre las características del producto que le permitieron salir adelante en el mercado.

Jeff Dean de Google tiene una excelente cita a seguir: “Asegúrese de que su diseño funcione si la escala cambia en 10X o 20X pero la solución correcta para X a menudo no es óptima para 100X”

Obtenga su producto viable mínimo, repita agregando usuarios / empresas / productos, sea lo que sea que su negocio necesite, y luego afine las áreas que considera que no está escalando o desarrollando lo suficientemente rápido.

Si planea seguir esa ruta algún día solo por mierdas y risas, escriba todas sus capas de acceso a datos con envoltorios y fachadas para que pueda cambiar el backend sin afectar las piezas frontales.

Por ejemplo, tiene un objeto de usuario con una fábrica a su alrededor, ese objeto de usuario podría haberse hidratado de un archivo plano, una base de datos, cassandra, redis, lo que sea y su front-end no notaría la diferencia. Concéntrese en crear esa separación limpia de capas y apis desde el principio, preocúpese por el resto cuando lo necesite.

Utilizando ese enfoque, pude reemplazar MySQL con Redis como back-end para algunas de nuestras funciones de análisis en tiempo real y la interfaz no tuvo que cambiar una línea de código.

Un simple: sí.

¿Por qué? Porque con NoSQL necesita cambiar algunos puntos importantes sobre cómo su aplicación procesa los datos. Por ejemplo, con una base de datos NoSQL no puede confiar en un JOIN realizado por una base de datos relacional. En cambio, debe unir manualmente los datos dentro del código de su aplicación (que de todos modos es mejor, porque es más escalable).

Dado que este trabajo en el “corazón de su aplicación” es a menudo crítico, le recomiendo que lo haga al principio cuando su código aún es escaso y su mente aún está abierta a nuevas cosas.

Además, la migración de datos existentes de una base de datos relacional a una base de datos NoSQL puede ser una molestia y seguramente terminará en algunas interrupciones de su servicio.

Creo que considera NoSQL por las razones equivocadas. Si fuera usted, trataría de responder esta simple pregunta: “¿mi modelo de datos es complejo y fundamentalmente relacional?”

Si la respuesta es sí, entonces vaya con un RDBMS. Probablemente no obtendrá una escalabilidad sustancialmente mayor al usar un almacén de datos NoSQL de todos modos.

Si sus datos no son fundamentalmente relacionales, entonces debería considerar los almacenes de datos NoSQL simplemente porque simplificará su código. Si su modelo de datos es relacional pero simple, probablemente puede desnormalizar y volver al caso anterior.

Ahora, sobre la escalabilidad, seré directo: si almacena propiedades de texto simples en su base de datos, seguramente no tendrá que preocuparse por eso en los próximos meses. Y si almacena activos binarios en la base de datos, está haciendo algo mal …