IOTA se reuné con Couchbase, abriendo una serie de discusiones puestos en la mesa; en la discusión de los permanodos es una con una larga historia y es una que siempre parece volver. Con la publicación de instantáneas locales se hace cada vez más incierto si sus datos permanecerán vivos durante más de 30 días en la maraña. Sin embargo, con las instantáneas locales también es posible separar las preocupaciones! Y esto es realmente genial!
Para nuestro proyecto, al igual que para muchos otros proyectos; queremos elegir si mantenemos los datos disponibles en la maraña o no para fines específicos de la aplicación. Snapshotting se pone simplemente -un dolor de cabeza- cuando se trata de esto y con localsnapshotting activado hace cada vez más difícil mantener los datos vivos en la maraña. Idealmente queremos guardar selectivamente los datos y poder lo que no queremos almacenar, pero para ello primero tenemos que ser capaces de almacenar todo y movernos desde allí.
Así que decidí hacer un pequeño experimento para implementar un proveedor de persistencia diferente a RocksDB y ZeroMQ. Uno para una base de datos externa, couchbase!
Los beneficios de Couchbase
Al utilizar un proveedor de persistencia externo, podemos mantener la instancia en ejecución de IRI relativamente pequeña sin sacrificar las capacidades de almacenamiento y disponibilidad de datos.
- Podemos ejecutar múltiples nodos IRI que utilizan un almacenamiento en clúster de back-end para que podamos ejecutarlo con una actualización cercana al 100%.
- Podemos configurar nodos IRI con diferentes roles: Activo la mayor parte de la maraña viva y algunos nodos IRI exclusivamente para acceder a las partes históricas de la maraña.
- El API no ha cambiado!
- Podemos escalar de forma independiente el servicio de almacenamiento back-end sin necesidad de apagar nunca nuestros nodos IRI.
Abre la búsqueda de semipermanentes que puedan almacenar datos de forma selectiva.
¿Por qué couchbase?
Hace unos meses, durante un gran esfuerzo de la comunidad para crear un permanode (localsnapshotting etc era todo desconocido en ese entonces) ya escribí un documento con algunas consideraciones que todavía se mantienen en esta discusión (Wide-column, Graph, Key value etc vs CAP)
La conclusión fue elegir para RiakDB con un sesgo personal a tener una mejor experiencia en comparación con couchbase; y las características más avanzadas que forman parte de la versión de código abierto (como la replicación de centros de datos cruzados). Los miembros de la comunidad notificaron que el equipo de Riak de Basho estaba en problemas con una gran posibilidad de que Riak fuera descontinuado.
Así que ahora…. ¿por qué couchbase?
- A partir del documento: Un almacén de valores clave es el mejor almacén para todo tipo de Tangle
- Couchbase tiene una configuración sin maestro, por lo que todos los nodos pueden participar en las operaciones de escritura. Esto se opone a otras configuraciones como mongodb que son maestro-esclavo donde las escrituras son un cuello de botella. Master-less permite una escala horizontal adecuada tanto en la escritura como en la lectura.
- Dado que Tangle es asincrónico por naturaleza, tener nodos backend e índices no inmediatamente consistentes no es un problema (es consistente con el escritor; lo que significa que si se escribe algo en un nodo, el mismo nodo tendrá una vista y actualización consistente de los datos).
- Permite el desalojo del índice de claves: la mayoría de los sistemas mantienen las claves primarias en la memoria. Para algo como la maraña de datos de alta cardinalidad; esta característica es de suma importancia para mantener bajo control el uso de la memoria de un sistema de base de datos en constante crecimiento (la mayoría de los datos no se utilizan).
- Es muy fácil de configurar y administrar
- Puede manejar datos binarios, esto es importante ya que el almacenamiento de Trits en un formato de texto codificado UTF-8; no es eficiente a escala masiva.
- Los servicios (almacenamiento, indexación, almacenamiento en caché, etc.); son escalables de forma independiente. Para el ajuste del rendimiento de cada caso de uso específico, esto es muy importante.
Para IOTA
- Este fue un esfuerzo para mostrarme a mí mismo, a mysoundsafe y a la comunidad; que se puede hacer y que me encanta recibir comentarios al respecto. El proyecto está en pañales (1 commit) y lejos de estar terminado; aunque la mayoría de las funcionalidades de la API funcionan normalmente. Algunas notas al margen de la versión actual:
- No hay pruebas todavía (todas las pruebas anteriores pasaron y son compatibles hacia atrás!)
- Sólo ha sido probado en una red de prueba personal (con coo y todo); fácilmente tratando con 40tx por segundo (un poco engañado con MWM3)
- Ha pasado mucho tiempo desde que hice Java, los comentarios constructivos son bienvenidos ?
- El orden de las transacciones cambiadas; con IRI el orden depende del orden IRI ‘vio’ las transacciones y con couchbase el orden se basa en el orden ASCII 9ABCDE…. de los ID de la transacción.
- Probablemente aparezcan más cosas