ventajas topologia raspberry para mixta malla desventajas datos crear conectar arbol database raspberry-pi2 database-replication nosql

database - raspberry - topologia malla ventajas y desventajas



ReplicaciĆ³n de la base de datos en la red de malla Raspberry Pi (5)

  1. Debes considerar la plataforma Erlang OTP y la base de datos Mnesia

  2. Si prefiere el lenguaje C, puede considerar SQlite en la base de datos de memoria junto con el marco nanomsg

¿Alguien tiene una buena sugerencia sobre qué base de datos debo usar para lograr la replicación en un número variable de objetivos? Tengo una red de malla de servidores Raspberry Pi, cada uno de los cuales puede contener una base de datos. Quiero que el contenido de cada base de datos se replique en toda la red, pero no puedo garantizar qué nodos están disponibles en cualquier momento.

La mayoría de las bases de datos de nosql (CouchDB, Cassandra, por ejemplo) parecen admitir solo los objetivos definidos en la configuración.

Entonces (asumiendo que nosql es la mejor opción de base de datos); ¿Existe una base de datos nosql que pueda replicarse a un número variable de objetivos?


Para este escenario, recomendaría el Sistema de archivos distribuidos de Hadoop (HDFS) .

Características que hacen que HDFS sea atractivo para su escenario:

  • Es un sistema de archivos distribuido con un factor de replicación variable (el valor predeterminado es 3, con el que es casi imposible perder datos).
  • Puede escalar hasta miles de máquinas diferentes
  • No depende de la alta disponibilidad de nodos individuales: maneja automáticamente la falla de los nodos y replica los datos de los nodos caídos

En cuanto a la base de datos real ... HBase, Mongo o Cassandra son todas buenas opciones aquí, elija el que le resulte más cómodo: HDFS se hará cargo de toda la replicación por usted.


Recomiendo echar un vistazo a Hazelcast . Lo hacen bastante bien en la replicación de memoria en un clúster que podría cambiar. Tendría que escribir un cliente personalizado para almacenar los datos en una base de datos local de su elección si desea una persistencia respaldada por disco, pero Hazelcast puede encargarse de la replicación en un clúster en la memoria y tiene mucha flexibilidad.


Según esta respuesta SO:

https://.com/a/8787999/2020565

Y al revisar su sitio web, tal vez debería consultar Elliptics: http://www.ioremap.net/projects/elliptics/

La red no utiliza servidores dedicados para mantener la información de metadatos, admite el almacenamiento de objetos redundantes. Los puntos de referencia de escritura de tamaño pequeño a mediano se pueden encontrar en la página eblob.


Según mi experiencia, Elasticsearch tiene una gestión de clústeres excelente y fácil de usar, es compatible con funciones sencillas como el autodiscovery de nodos, la replicación de datos, el rebalanceo automático, etc., consulte los docs . Por lo general, se usa para replicar datos de otra base de datos para que pueda buscarse, pero no veo por qué no se podría usar en este contexto también.

Básicamente, cuando creas una "tabla" (llamada "índice" en ES), decides que en cuántas "particiones" (llamadas "fragmentos") los datos deben particionarse, y ad-hoc establece que cuántas réplicas de eso tabla que desea tener (esto no coincide al 100% con la terminología correcta, ya que un "índice" puede consistir en múltiples "tipos", pero creo que esta es la mejor analogía).

Un proyecto de ejemplo con tres Pis está here .

También he leído un poco sobre Cassandra y me imagino que tendría características similares, por ejemplo, las particiones y las réplicas se mencionan here .