c# - litedb - ¿Cuáles son algunos de los "pasos mentales" que un desarrollador debe tomar para comenzar a pasar de SQL a NO-SQL(CouchDB, FathomDB, MongoDB, etc.)?

litedb viewer (2)

Tengo mi mente firmemente envuelta alrededor de bases de datos relacionales y cómo codificar eficientemente contra ellas. La mayor parte de mi experiencia es con MySQL y SQL. Me gustan muchas de las cosas que escucho sobre bases de datos basadas en documentos, especialmente cuando alguien en un podcast reciente mencionó enormes beneficios de rendimiento. Entonces, si voy a seguir ese camino, ¿cuáles son algunos de los pasos mentales que debo seguir para pasar de SQL a NO-SQL?

Si hay alguna diferencia en tu respuesta, soy un desarrollador de C # principalmente (hoy, de todos modos). Estoy acostumbrado a ORM como EF y Linq a SQL. Antes de los ORM, hice rodar mis propios objetos con genéricos y lectores de datos. Tal vez eso importa, quizás no.

Aquí hay algunos más específicos:

¿Cómo necesito pensar en las uniones?
¿Cómo voy a consultar sin una instrucción SELECT?
¿Qué sucede con mis objetos almacenados existentes cuando agrego una propiedad en mi código?

(siéntase libre de agregar sus propias preguntas aquí)

En primer lugar, cada tienda NoSQL es diferente. Así que no es como elegir entre Oracle o Sql Server o MySQL. Las diferencias entre ellos pueden ser vastas.

Por ejemplo, con CouchDB no puede ejecutar consultas ad-hoc (consultas dinámicas si lo desea). Es muy bueno en los escenarios en línea - fuera de línea, y es lo suficientemente pequeño como para ejecutarse en la mayoría de los dispositivos. Tiene una interfaz REST, por lo que no hay controladores ni bibliotecas ADO.NET. Para consultarla, use MapReduce (ahora esto es muy común en el espacio NoSQL, pero no es ubicuo) para crear vistas, y éstas están escritas en varios idiomas, aunque la mayor parte de la documentación es para Javascript. CouchDB también está diseñado para fallar, es decir, si algo sale mal, simplemente reinicia el proceso (el proceso de Erlang, o grupo de procesos vinculados, es decir, no la instancia completa de CouchDB, por lo general).

MongoDB está diseñado para tener un alto rendimiento, tiene controladores y parece ser un salto menor para muchas personas en el mundo .NET debido a esto. Aunque creo que en situaciones de colisión es posible perder datos (no ofrece el mismo nivel de garantías transaccionales en torno a las escrituras que hace CouchDB).

Ahora ambos son bases de datos de documentos y, como tales, comparten en común que sus datos no están estructurados. No hay tablas, ningún esquema definido, son esquemas. Sin embargo, no son como un almacén de valor-clave, ya que insisten en que los datos que usted persiste son inteligibles para ellos. Con CouchDB esto significa el uso de JSON, y con MongoDB esto significa el uso de BSON.

¡Hay muchas otras diferencias entre MongoDB y CouchDB y estas se consideran en el espacio NoSQL como muy cercanas en su diseño!

Aparte de las bases de datos de documentos, se trata de soluciones orientadas a la red como Neo4J, tiendas de columnas (orientadas a columnas en lugar de filas en la forma en que persisten los datos) y muchas otras.

Algo que es común en la mayoría de las soluciones NoSQL, además de MapReduce, es que no son bases de datos relacionales, y que la mayoría no hace uso de la sintaxis de estilo SQL. Las consultas típicas siguen un modo imperativo de programación en lugar del estilo declarativo de SQL.

Otro rasgo típicamente común es que la consistencia absoluta, como la que suelen proporcionar las bases de datos relacionales, se intercambia por modelos de consistencia eventuales.

Mi consejo para cualquier persona que desee utilizar una solución NoSQL sería que primero comprendan realmente los requisitos que tienen, que comprendan los SLA (qué nivel de latencia se requiere, qué tan consistente debe permanecer esa latencia a medida que se amplían las soluciones, qué escala de carga se prevé) la carga es consistente o se incrementará; la consistencia con la que los usuarios deben ver la información debe ser, en caso de que siempre vean sus propias escrituras cuando hacen consultas, sus escrituras deben ser inmediatamente visibles para todos los demás usuarios, etc ...). Comprenda que no puede tenerlo todo, lea el teorema de Brewers CAP, que básicamente dice que no puede tener consistencia absoluta, 100% de disponibilidad, y sea tolerante a la partición (haga frente cuando los nodos no pueden comunicarse). Luego, examine las distintas soluciones NoSQL y comience a eliminar aquellas que no están diseñadas para cumplir con sus requisitos, comprenda que el cambio desde una base de datos relacional no es trivial y tiene un costo asociado (he encontrado el costo de mover una organización en esa dirección, en términos de reuniones, discusiones, etc. en sí misma es muy alta, lo que impide centrarse en otras áreas de beneficio potencial). La mayoría de las veces no necesitará un ORM (la parte R de esa ecuación simplemente desapareció), a veces solo la serialización binaria puede estar bien (con algo como DB4O, por ejemplo, o un almacén de valores clave), cosas como el JSON de Newtonsoft / La biblioteca BSON puede ayudar, al igual que automapper. Me parece que trabajar con C # 3 es un costo definido en comparación con trabajar con un lenguaje dinámico como, por ejemplo, Python. Con C # 4, esto puede mejorar un poco con cosas como ExpandoObject y Dynamic from DLR.

Para ver sus 3 preguntas específicas, con todo depende de la solución NoSQL que adopte, por lo que no es posible una respuesta, sin embargo, con esa advertencia, en términos muy generales:

Si persiste el objeto (o el agregado es más probable) como un todo, sus uniones normalmente estarán en código, aunque puede hacer algo de esto a través de MapReduce.
Una vez más, depende, pero con Couch ejecutaría un GET sobre HTTP en un recurso específico o en una vista de MapReduce.
Lo más probable es que nada. Solo manténgase atento a los escenarios de serialización y deserialización. La dificultad que he encontrado se encuentra en la forma en que administras las versiones de tu código. Si la propiedad es puramente para empujar a una interfaz (GUI, servicio web), entonces tiende a ser un problema menor. Si la propiedad es una forma de estado interno en el que se basará el comportamiento, esto puede volverse más complicado.

¡Espero que ayude, buena suerte!

Solo deja de pensar en la base de datos.

Piensa en modelar tu dominio. Construya sus objetos para resolver el problema en cuestión siguiendo buenos patrones y prácticas y no se preocupe por la persistencia.