Cajitas que piensan

Designing Data-Intensive Applications : Chapter 2

  • Sql gran ganador de la contienda.
  • Como el lenguaje limita nuestro pensamiento, NoSQL busca darnos un lenguaje mas dinamico y flexible con el cual modelar.
  • Persistencia híbrida o poliglota para obtener lo mejor de 2 mundos.
  • Si uso SQL en un lenguaje orientado a objetos, necesito una capa que haga el mapeo de objetos a desnormalización de tablas, filas, columnas.
    • Como esto es un embole, usamos ORM pero es tan automagico, que oculta cosas.
  • Si quiero guardar json entero y no preocuparme por desnormalizar, normalmente pierdo las funcionalidades de la BD.
    • Si bien tengo todo localmente (todo lo de un usuario en una sola query), paso a tener que implementar los joins en la app y no en la BD.
    • Simpleza en el modelo de documento, pero si el documento es densamenta anidado complejiza sus acceso a elementos profundos.
  • Mongo en el 2.4 empiezo a tener algo que ya no es solo documental, puedo tener referencias en el job a la org y una colección de organizations separada (esto puede ser bueno para cargar info incrementalmente onda GraphQL)
  • En el modelo de red, precisas manejar como dev los access path que es lo que resuelve el motor de base de datos por si solo. El motor abstrae la query de la implementacion de la misma en el schema.
  • Schema-on-read is similar to dynamic (runtime) type checking in programming languages, whereas schema-on-write is similar to static (compile-time) type checking.
  • Brillante ejemplo de lenguaje imperativo y declarativo en la web usando CSS o JS.
  • A usability problem with MapReduce is that you have to write two carefully coordinated JavaScript functions, which is often harder than writing a single query. Moreover, a declarative query language offers more opportunities for a query optimizer to improve the performance of a query. For these reasons, MongoDB 2.2 added support for a declarative query language called the aggregation pipeline [9].

Ejemplos:

//data stored with this direction
CREATE (p:Person)-[:LIKES]->(t:Technology)

//query relationship backwards will not return results
MATCH (p:Person)<-[:LIKES]-(t:Technology)

//better to query with undirected relationship unless sure of direction
MATCH (p:Person)-[:LIKES]-(t:Technology)

O algo mas complejo

(p:Person {name: "Jennifer"})-[rel:LIKES]->(g:Technology {type: "Graphs"})

Con Gremlin:

g.V().has('name', 'hercules').out('father').out('father').values('name')

Con SPARQL:

select ?s ?p ?o where {?s ?p ?o} limit 10