performance - Rendimiento Riak-resultados inesperados

nosql

Question

En los últimos días jugué un poco con riak. La configuración inicial fue más fácil de lo que pensé. Ahora tengo un clúster de 3 nodos, todos los nodos que se ejecutan en el mismo vm para realizar pruebas.

Admito que la configuración de hardware de mi máquina virtual está muy degradada (1 CPU, 512 MB de RAM) pero aún estoy bastante sorprendido por el bajo rendimiento de riak.

Mapa reducido

Jugando un poco con reducción de mapa, tenía alrededor de 2000 objetos en un cubo, cada uno de aproximadamente 1k - 2k de tamaño como json. Utilicé esta función de mapa:

function(value, keyData, arg) {
    var data = Riak.mapValuesJson(value)[0];

    if (data.displayname.indexOf("max") !== -1) return [data];
    return [];
}

Y tomó más de 2 segundos solo para realizar la solicitud http y devolver su resultado, sin contar el tiempo que tomó en mi código de cliente para deserializar los resultados de json. La eliminación de 2 de los 3 nodos parece mejorar ligeramente el rendimiento a poco menos de 2 segundos, pero esto todavía me parece muy lento.

¿Es esto lo que se espera? Los objetos no eran tan grandes en tamaño de bytes y 2000 objetos en un compartimiento tampoco.

Insertar

La inserción por lotes de alrededor de 60.000 objetos en el mismo tamaño que el anterior tomó bastante tiempo y en realidad no funcionó.

Mi script que insertó los objetos en riak murió alrededor de 40.000 o menos y dijo que ya no podía conectarse al nodo riak. En los registros de riak encontré un mensaje de error que indicaba que el nodo se había quedado sin memoria y había muerto.

Pregunta

Esta es realmente mi primera oportunidad en Riak, así que definitivamente existe la posibilidad de que arruinara algo.

• ¿Hay alguna configuración que podría modificar?
• ¿Las configuraciones de hardware están demasiado limitadas?
• Tal vez la biblioteca de cliente PHP que utilicé para interactuar con riak es el factor limitante aquí.
• Ejecutar todos los nodos en la misma máquina física es bastante estúpido, pero si esto es un problema, ¿cómo puedo probar mejor el rendimiento de riak ?
• ¿Es el mapa reducir realmente tan lento? Leí sobre el impacto en el rendimiento que map map tiene en la lista de correo de riak, pero si Map Reduce es lento, ¿cómo se supone que debe realizar "consultas" para los datos necesarios casi en tiempo real? Sé que Riak no es tan rápido como Redis.

Realmente me ayudaría mucho si alguien con más experiencia en riak pudiera ayudarme con algunas de estas preguntas.

Answer 1

Esta respuesta es un poco tarde, pero quiero señalar que la implementación mapreduce de Riak está diseñada principalmente para trabajar con enlaces, no con grupos completos.

El diseño interno de Riak en realidad está bastante optimizado para trabajar con cubos enteros. Esto se debe a que los cubos no se consideran tablas secuenciales sino un espacio de claves distribuido en un grupo de nodos. Esto significa que el acceso aleatorio es muy rápido, probablemente O (log n), pero no me cite al respecto, mientras que el acceso en serie es muy, muy, muy lento. El acceso en serie, la forma en que Riak está actualmente diseñado, significa necesariamente pedir a todos los nodos sus datos.

Incidentalmente, los "cubos" en la terminología de Riak son, de manera confusa y decepcionante, no implementados de la forma en que probablemente piensa. Lo que Riak llama un cubo es en realidad solo un espacio de nombres. Internamente, solo hay un depósito, y las claves se almacenan con el nombre del depósito como prefijo. Esto significa que no importa qué tan pequeño o grande sea su cubeta, enumerar las claves en una sola cubeta de tamaño n tomará m tiempo, donde m es el número total de claves en todas las cubetas.

Estas limitaciones son opciones de implementación de Basho, no necesariamente defectos de diseño. Cassandra implementa exactamente el mismo modelo de partición que Riak, pero admite exploraciones de rango secuenciales eficientes y mapreduce en grandes cantidades de claves. Cassandra también implementa cubos verdaderos.

Answer 2

No tengo experiencia directa con Riak, pero he trabajado un poco con Cassandra, que es similar.

En primer lugar, el rendimiento probablemente dependerá mucho de la cantidad de núcleos disponibles y de la memoria. Estos sistemas suelen ser muy dinámicos y concurrentes y se benefician de una gran cantidad de núcleos. 4+ núcleos y 4GB + de RAM serían un buen punto de partida.

En segundo lugar, MapReduce está diseñado para el procesamiento por lotes, no para consultas en tiempo real.

Riak y todos los almacenes similares de Key-Value están diseñados para un alto rendimiento de escritura, un alto rendimiento de lectura para búsquedas simples, sin ninguna consulta compleja.

Solo para comparación, Cassandra en un solo nodo (6 núcleos, 6 GB) puede hacer 20,000 inserciones individuales por segundo.

Answer 3

Una recomendación que tendría ahora que ha pasado algún tiempo y se han producido varias versiones nuevas de Riak es esta. Nunca confíe en el mapa completo / reducción, no es una operación optimizada, y es muy probable que haya otras formas de optimizar su mapa / reducción para que no tenga que mirar tantos datos para extraer los singlets que necesita.

Los índices secundarios ahora disponibles en las versiones más nuevas de Riak son definitivamente el camino a seguir en este sentido. Coloque un índice en los objetos que desea encontrar (quizás llamado ''ismax_int'' con un valor de 0 o 1). Puede asignar / reducir un índice secundario con cientos de miles de claves en microsegundos que un análisis completo de cubos tomaría varios segundos en considerar.