View
538
Download
4
Category
Preview:
Citation preview
ToroDB = MongoDB + PostgreSQLLa primera base de datos desarrollada en España
Gonzalo Ortiz <gortiz@torodb.com>Álvaro Hernández <aht@torodb.com>
ToroDB @NoSQLonSQL
¡DEMO!
ToroDB @NoSQLonSQL
Acerca de *8Kdata*
● Investigación y Desarrollo en bases de datos
● Consultoría, Formación y Desarrollo PostgreSQL
● Fundadores de PostgreSQL España, el 3er PUG mayor del mundo (450 a fecha de hoy)
● Gonzalo: Desarrollador Principal de ToroDB
● Álvaro: CTO de 8Kdata. Twitter: @ahachete
www.8kdata.com
ToroDB @NoSQLonSQL
ToroDB en una diapositiva
● BBDD NoSQL orientada a documentos
● La 1ª bbdd desarrollada en España
● Software libre (AGPL)
● Compatible con el protocolo de Mongo
● Usa PostgreSQL para almacenamiento
ToroDB @NoSQLonSQL
¿Por qué no usar RDBMs para construir NoSQLs?Perspectiva técnica
● El modelo de Documento atrae a muchos. Pero todas las NoSQL han reinventado la rueda, partiendo de 0
● DRY: ¿por qué no usar RDBMs? Han demostrado que son durables, confiables, potentes y flexibles
● ¿Por qué no usar PostgreSQL?
ToroDB @NoSQLonSQL
● El mercado NoSQL es aún una fracción del tamaño del mercado relacional
● Las empresas sufren para introducir nuevos “stacks”: certificaciones, contratos de soporte, expertise técnico...
● ¿Por qué no ofrecer el modelo de documento pero sobre las IT actuales?
¿Por qué no usar RDBMs para construir NoSQLs?Perspectiva de negocio
ToroDB @NoSQLonSQL
ToroDBAlmacenamiento de datos
ToroDB @NoSQLonSQL
¿Cómo se almacenan los datos?
● Los datos se almacenan en blobs tablas
● Los documentos se dividen por niveles de jerarquía en subdocumentos que no tienen niveles anidados. Cada subdocumento se almacena separado
● Los subdocumentos se clasifican por “tipo”. Cada tipo se mapea a una tabla
ToroDB @NoSQLonSQL
● La tabla structure almacena el “schema” del subdocumento
● Las claves del documento se mapean a columnas con su nombre original
● Las tablas de datos se crean dinámicamente para encajar en el tipo exacto de cada subdocumento
¿Cómo se almacenan los datos?
ToroDB @NoSQLonSQL
{ "name": "ToroDB", "data": { "a": 42, "b": "hello world!" }, "nested": { "j": 42, "deeper": { "a": 21, "b": "hello" } }}
¿Cómo se almacenan los datos?
ToroDB @NoSQLonSQL
El documento se divide en los siguientes subdocumentos:
{ "name": "ToroDB", "data": {}, "nested": {} }
{ "a": 42, "b": "hello world!"}
{ "j": 42, "deeper": {}}
{ "a": 21, "b": "hello"}
¿Cómo se almacenan los datos?
ToroDB @NoSQLonSQL
select * from demo.t_3┌─────┬───────┬────────────────────────────┬────────┐│ did │ index │ _id │ name │├─────┼───────┼────────────────────────────┼────────┤│ 0 │ ¤ │ \x5451a07de7032d23a908576d │ ToroDB │└─────┴───────┴────────────────────────────┴────────┘select * from demo.t_1┌─────┬───────┬────┬──────────────┐│ did │ index │ a │ b │├─────┼───────┼────┼──────────────┤│ 0 │ ¤ │ 42 │ hello world! ││ 0 │ 1 │ 21 │ hello │└─────┴───────┴────┴──────────────┘select * from demo.t_2┌─────┬───────┬────┐│ did │ index │ j │├─────┼───────┼────┤│ 0 │ ¤ │ 42 │└─────┴───────┴────┘
¿Cómo se almacenan los datos?
ToroDB @NoSQLonSQL
select * from demo.structures┌─────┬────────────────────────────────────────────────────────────────────────────┐│ sid │ _structure │├─────┼────────────────────────────────────────────────────────────────────────────┤│ 0 │ {"t": 3, "data": {"t": 1}, "nested": {"t": 2, "deeper": {"i": 1, "t": 1}}} │└─────┴────────────────────────────────────────────────────────────────────────────┘
select * from demo.root;┌─────┬─────┐│ did │ sid │├─────┼─────┤│ 0 │ 0 │└─────┴─────┘
¿Cómo se almacenan los datos?
ToroDB @NoSQLonSQL
Almacenamiento e I/O en ToroDB
sólo necesita 29% - 68%del almacenamiento que requiere Mongo 2.6
ToroDB @NoSQLonSQL
¿Y el oplog de Mongo?¿Tailable cursors?
ToroDB @NoSQLonSQL
Oplog de MongoDB y tailable cursors
El oplog es una colección capped y de sistema, que contiene comandos DML idempotentes
Los tailable cursors son queries “abiertas”, donde los datos son enviados en streaming según llegan a la bbdd
Ambos muy usados (replicación, Meteor)
ToroDB @NoSQLonSQL
Es posible implementarlo gracias a logical decoding de PostgreSQL 9.4
Implementar el master de replicación es simplemente logical decoding convertido de vuelta a documento y en JSON
Los tailable cursors es logical decoding más aplicar la query para filtrar
Oplog de MongoDB y tailable cursors
ToroDB @NoSQLonSQL
ToroDBEl software
ToroDB @NoSQLonSQL
El software
ToroDB está escrito en Java, compatible (y diseñado) para JVM6 (y superior)
Apoyándonos en los hombros de gigantes:●PostgreSQL● Netty● HikariCP● Guava, Guice, findbugs● jOOQ
ToroDB @NoSQLonSQL
MongoWP: construye apps Mongo
● MongoWP es nuestra implementación del protocolo de red de MongoDB
● Basado en Netty, excelente framework NIO de alto rendimiento y asíncrono
● MongoWP ofrece un interfaz de callback para cualquier implementación de middleware Mongo (ToroDB, proxy...)
ToroDB @NoSQLonSQL
ToroDB: Developer Preview
● ToroDB fue lanzado públicamente en octubre de 2014, con soporte para CRUD y gran parte del API de consultas
● github.com/torodb
● Política RERO. Se agradecen comentarios, críticas, parches...
● AGPLv3
ToroDB @NoSQLonSQL
ToroDB: Developer Preview
● Clonar el repo, construir con Maven
● O descargar el JAR:http://maven.torodb.com/jar/com/torodb/torodb/0.21/torodb.jar
● Utilización:java -jar torodb-0.21.jar –helpjava -jar torodb-0.21.jar -d dbname -u dbuser -P 27017
Y conectar... ¡con la consola Mongo! :)
ToroDB @NoSQLonSQL
ToroDB: respuesta de la comunidad
ToroDB @NoSQLonSQL
ToroDB: respuesta de la comunidad
ToroDB @NoSQLonSQL
ToroDB: Roadmap
● La versión actual es para sólo un nodo
● Versión 1.0:
➔ Estimado Q4 2015➔ Calidad producción➔ Soporte de replicación de MongoDB➔ Alta compatibilidad con el API Mongo
ToroDB @NoSQLonSQL
ToroDB: prioridades del desarrollo
#1 Ofrecer la experiencia de MongoDB sobre infraestructuras IT ya existentes, como app servers y RDBMSs
#2 Ir más allá de lo que Mongo ofrece, como ACID y concurrencia
#3 Excelente rendimiento
ToroDB @NoSQLonSQL
Mejorando MongoDB
ToroDB @NoSQLonSQL
Mejorando MongoDB
MongoDB trajo el modelo de documento, HA fácil y sharding, y lo popularizó
Pero también varios problemas. ¿Y si fuera posible mejorarlo / solucionarlos?
¿No podemos aprovechar el modelo relacional y las RDBMs para ofrecer mejores características que MongoDB?
ToroDB @NoSQLonSQL
La falacia del “schema-less”
{“name”: “Álvaro”,“surname”: “Hernández”,“height”: 200,“hobbies”: [
“PostgreSQL”, “triathlon”]
}
ToroDB @NoSQLonSQL
{“name”: “Álvaro”,“surname”: “Hernández”,“height”: 200,“hobbies”: [
“PostgreSQL”, “triathlon”]
}metadata → ¿no es esto... schema?
La falacia del “schema-less”
ToroDB @NoSQLonSQL
metadata → ¿no es esto... schema?
{“name”: (string) “Álvaro”,“surname”: (string) “Hernández”,“height”: (number) 200,“hobbies”: {
“0”: (string) “PostgreSQL” , “1”: (string) “triathlon”
}}
La falacia del “schema-less”: BSON
ToroDB @NoSQLonSQL
● No existe tal “schema-less”
● Es más bien “attached-schema”
● Y esto tiene una sobrecarga, mucha duplicación del espacio ocupado por la metainformación
La falacia del “schema-less”
ToroDB @NoSQLonSQL
Duplicidades en Schema-attached
{ “a”: 1, “b”: 2 }{ “a”: 3 }{ “a”: 4, “c”: 5 }{ “a”: 6, “b”: 7 }{ “b”: 8 }{ “a”: 9, “b”: 10 }{ “a”: 11, “b”: 12, “j”: 13 }{ “a”: 14, “c”: 15 }
Contando “tipos de documentos” en millones de documentos: como máximo, miles de tipos
ToroDB @NoSQLonSQL
Así es como se guardan los datos en Mongo
Organización del almacenamiento
ToroDB @NoSQLonSQL
Organización del almacenamiento
Así es como se guardan en ToroDB
ToroDB @NoSQLonSQL
ToroDB: query “según la estructura”
● ToroDB a todos los efectos está particionando por tipo
● Las estructuras (que son los schemas de los documentos y las “claves de particionado”) se cachean en memoria
● Las consultas sólo escanean un subconjunto de los datos. Queries “negativas” se sirven desde memoria
ToroDB @NoSQLonSQL
Cheap single-node durability
● Sin journaling, MongoDB no es durable ni tolerante a caídas
● MongoDB requiere“j: true” para durabilidad real de un nodo. Pero ¿quién garantiza su uso consistente? ¿Quién lo usa por defecto?
● j:true crea tormentas de I/O
ToroDB @NoSQLonSQL
Lecturas “limpias”
¿De verdad?
ToroDB @NoSQLonSQL
http://docs.mongodb.org/manual/reference/write-concern/#read-isolation-behavior
“MongoDB will allow clients to read the results of a write operation before the write operation returns.”
“If the mongod terminates before the journal commits, even if a write returns successfully, queries may have read data that will not exist after the mongod restarts.”
“Other database systems refer to these isolation semantics as read uncommitted.”
Lecturas “limpias”
ToroDB @NoSQLonSQL
Por lo tanto, MongoDB sufre dirty reads. O tal vez llamémoslo “tainted reads”
¿Y ni siquiera con $snapshot? No:
“The snapshot() does not guarantee that the data returned by the query will reflect a single moment in time nor does it provide isolation from insert or delete operations.”
http://docs.mongodb.org/manual/faq/developers/#faq-developers-isolate-cursors
Lecturas “limpias”
ToroDB @NoSQLonSQL
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
Lecturas “limpias”:“Call me maybe”
ToroDB @NoSQLonSQL
ToroDB: mejorando MongoDB
● Durabilidad de un nodoPostgreSQL es 100% durable. Siempre. Y muy barato (no hay tormentas de I/O)
● Lecturas “limpias”En ToroDB los cursores se ejecutan en modeo REPEATABLE READ y READ ONLY
globalCursorDataSource.setTransactionIsolation("TRANSACTION_REPEATABLE_READ");
globalCursorDataSource.setReadOnly(true);
ToroDB @NoSQLonSQL
Operaciones atómicas
● En MongoDB no hay soporte para ops atómicas (insert/update/delete)
● Ni siquiera con $isolated:“Prevents a write operation that affects multiple documents from yielding to other reads or writes […] You can ensure that no client sees the changes until the operation completes or errors out. The $isolated isolation operator does not provide “all-or-nothing” atomicity for write operations.”http://docs.mongodb.org/manual/reference/operator/update/isolated/
ToroDB @NoSQLonSQL
Alta concurrencia
● MMAPv1 sigue siendo collection-locked
● WiredTiger es document-locked. No usar en producción hasta 3.2 ó 3.4
● Pero aún hay locks exclusivos. Las RDBMs tienen MVCC (algunas, como Pg) que implica lectores no bloquean sólo escritores a otros escritores a veces
ToroDB @NoSQLonSQL
● Operaciones en batch atómicas:Por defecto, las operaciones en batch son atómicas. Usa el flag ContinueOnError para que no sea así
● Máxima concurrencia:PostgreSQL usa MVCC. Los lectores y escritores no se bloquean
ToroDB: mejorando MongoDB
ToroDB @NoSQLonSQL
ToroDBRendimiento
(aka benchmarks)
ToroDB @NoSQLonSQL
Insert, 4 clients, Acknowledged
ToroDB @NoSQLonSQL
Insert, 4 clients, Journaled
ToroDB @NoSQLonSQL
ToroDBExperimentos. El futuro
ToroDB @NoSQLonSQL
ToroDB: direcciones de investigación
● Usar almacenamiento por columnas (CitusDB)
● Usar Postgres-XL como backend. Esto requeriría cambiar la caché de ToroDB a distribuida (ehcache, Hazelcast)
● Usar pg_shard para el sharding
ToroDB @NoSQLonSQL
Big Data hablando Mongo:Vertical ToroDB
¿Y si usáramos cstore para almacenar los datos verticalmente?
ToroDB @NoSQLonSQL
1.17% - 20.26% del espacio requerido,comparado con Mongo 2.6
Big Data hablando Mongo:Vertical ToroDB
ToroDB @NoSQLonSQL
ToroDBAportando a las comunidades
MongoDB y PostgreSQL?
ToroDB @NoSQLonSQL
● ToroDB es una alternativa para usar programas/utilidades/código MongoDB en entornos donde NO se quiere Mongo (pero sí se aceptan RDBMs como Pg)
● Es la solución cuando se necesitan características más avanzadas que Mongo (transacciones, lecturas limpias)
● DW/Big Data en SQL (OLTP Mongo)
ToroDB: aportando a MongoDB
ToroDB @NoSQLonSQL
● Competir directamente con NoSQL
●Ofreciendo una solución para hacer updates sobre JSON
● Hace PostgreSQL ¡Web Scale!
● Inspiración para futuras versiones de jsonb
ToroDB: aportando a PostgreSQL
Recommended