Como desarrollador, he estado usando Couchbase Server durante un par de meses y me encanta. Después de haber escrito varias aplicaciones, he llegado a aprender muchos (pero no todos) de los entresijos de Couchbase. Para ser un buen desarrollador de Couchbase, no basta con saber usar las APIs, hace falta un poco más.
Para ofrecerle una rápida visión general de lo que los desarrolladores pueden obtener de Couchbase, hemos elaborado este documento Los 10 mejores lista de cosas que deberías saber. No están en ningún orden en particular, pero es una buena colección de información que deberías saber si estás construyendo tu aplicación con Couchbase.
Allá vamos...
#10. El acceso a documentos en Couchbase es fuertemente consistente, el acceso a consultas es eventualmente consistente
Couchbase garantiza una fuerte consistencia asegurándose de que todas las lecturas y escrituras de un documento en particular van a un único nodo en un cluster. Esto es para el acceso al documento (clave / valor ). Las vistas son finalmente consistentes en comparación con los documentos almacenados subyacentes.
#9. Las escrituras son asíncronas por defecto pero pueden controlarse
Por defecto, las escrituras en Couchbase son asíncronas - la replicación y la persistencia ocurren en segundo plano, y el cliente es notificado de un éxito o un fracaso. Las actualizaciones se almacenan en memoria, se vuelcan al disco y se replican a otros nodos Couchbase de forma asíncrona.
Utilizando las API con restricciones de durabilidad dentro de la aplicación, puede elegir que la actualización se replique a otros nodos o persista en disco, antes de que el cliente responda a la aplicación.
#8. Couchbase dispone de operaciones atómicas para contar y anexar
Couchbase soporta operaciones atómicas incr/decr y append para blobs.
Por ejemplo:
cb.set("miclave", 1)
x = cb.incr("miclave")
pone x #=> 2
incr es tanto escribir como devolver el valor resultante.
La operación de actualización se produce en el servidor y se proporciona a nivel de protocolo. Esto significa que es atómica en el clúster, y ejecutada por el servidor. En lugar de una operación en dos etapas, se trata de una única operación atómica.
#7. Empezar con todo en un cubo
Un bucket es equivalente a una base de datos. En un mismo bucket se almacenan objetos de diferentes características o atributos. Por lo tanto, si usted se está moviendo de un RDBMS, debe almacenar los registros de varias tablas en un solo cubo.
Recuerde crear un atributo "tipo" que le ayudará a diferenciar los distintos objetos almacenados en el bucket y a crear índices sobre ellos. Se recomienda empezar con un bucket e ir ampliándolo cuando sea necesario.
#6. Intenta usar 5 o menos buckets en Couchbase. Nunca más de 10.
Los documentos no tienen un esquema fijo, varios documentos con esquemas diferentes pueden estar en el mismo bucket. La mayoría de las implantaciones tienen un número reducido de cubos (normalmente 2 o 3) y sólo unas pocas llegan a 5. Aunque no existe un límite estricto en el software, el máximo de 10 buckets se debe a la sobrecarga de CPU y de IO de disco del motor de persistencia y al hecho de que asignamos una cantidad específica de memoria a cada bucket. Ciertamente planeamos reducir esta sobrecarga en futuras versiones, pero eso no cambiaría nuestra recomendación de tener sólo unos pocos cubos.
#5. Utilizar CAS en lugar de GetL casi siempre
Cierre optimista o pesimista, ¿cuál elegir? Si su aplicación necesita bloqueo, considere primero el uso de CAS(bloqueo optimista) antes de utilizar GetL (bloqueo pesimista).
Pero recuerda, el bloqueo puede no ser bueno para todos los casos - tu aplicación puede tener un problema si hay una contención de bloqueo. Un hilo puede mantener un bloqueo y ser desprogramado por el sistema operativo. Entonces todos los hilos que quieran adquirir este bloqueo serán bloqueados. Una opción es evitar el bloqueo por completo siempre que sea posible mediante el uso de operaciones atómicas. Estas API pueden ser muy útiles en datos muy disputados.
#4. Utilizar operaciones multiobjetivo
Una vez que su aplicación cliente tiene una lista de IDs de documentos, el enfoque de mayor rendimiento para recuperar elementos en masa utilizando una solicitud multi-GET. Esto ofrece un mejor rendimiento que un bucle en serie que intenta obtener cada elemento de forma individual y secuencial.
#3. Mantenga actualizadas sus bibliotecas de clientes
Asegúrate de que estás usando la librería cliente más reciente. Las librerías cliente de Couchbase están disponibles en Java, .NET, C/C++, Ruby, Python y PHP.
#2. Modele sus datos mediante documentos JSON
Couchbase Server soporta JSON y formato de documento binario. Primero, intenta modelar tus datos usando JSON. Los documentos JSON pueden ser indexados y consultados. Puedes almacenar blobs binarios y realizar consultas de rango a partir de los nombres de las claves. Empiece creando documentos a partir de objetos de nivel de aplicación. Los documentos que crecen continuamente o bajo alta contención de escritura deben ser divididos.
#1. Utilizar eficazmente los índices
Utilice el acceso de clave primaria tanto como sea posible. Couchbase tiene claves y metadatos en memoria - los accesos a datos son rápidos. Usa índices secundarios para rutas menos sensibles al rendimiento o para analíticas. Empieza con 4 documentos de diseño y menos de 10 vistas por documento de diseño. Cree unos cuantos índices "largos" que puedan utilizarse para múltiples consultas y utilice un filtrado creativo. Construye índices para "emitir" la menor cantidad de datos posible: utiliza "null" para el valor si no tienes ninguna función de reducción.
¿Sólo 10 cosas? No, ¡por supuesto que no! Couchbase es un sistema de base de datos NoSQL y después de probarlo descubrirás que hay mucho más que aprender. Si crees que me he dejado algo importante que debería estar en la lista de los 10 mejores, siéntete libre de añadirlo usando los comentarios de abajo.
¡Que aproveche!
Enlaces relacionados
- Guía del desarrollador de Couchbase
- Documentación de Couchbase
- Página para desarrolladores de Couchbase
No sé dónde escribir esta petición... pero sería útil que las vistas soportaran parámetros de usuario. Por ejemplo, puedo llamar a la vista para que emita todas las cervezas que tienen un rango de alcohol de [4,8 a 5,4]... de momento, para conseguir esto tengo que crear una nueva vista para cada permutación de filtro...
Puede conseguirlo utilizando lo que llamamos una consulta de rango. Tendrá el siguiente aspecto
Mapa :
function (doc, meta) {
if (doc.abv) {
emit(doc.abv);
}
}
Esto creará un índice donde el ABV es la clave.
A continuación, puede consultar esta vista utilizando los siguientes parámetros:
?startkey=4.8&endkey=5.4
Yo estoy usando aquí parámetros URL, pero en tu aplicación usarás la API de tu SDK de Cliente.
Gran artículo para alguien como yo que está empezando con Couchbase, tengo una pregunta, puede couchbase ser utilizado para este escenario.
El usuario tiene un formulario para rellenar fuera de línea, y luego sincronizar de nuevo cuando se conecta, quiero mostrarle el estado de la sincronización de todo el registro, si se sincroniza o no, ¿es posible en CB si sí, entonces cómo.