Base de datos NoSQL para series temporales

Qué tal https://www.elastic.co/

#3 Al contrario, de hecho hemos pensado en dejar el servicio de escritura en node, el problema son las consultas.

Te explico un poco más por poner en contexto el problema, capturamos paquetes a lo largo de las 24 horas del día, consultas un día, tenemos una función que nos devuelve en un json el conteo de los paquetes por horas. Como node es más chulo que un ocho con su asincronía nos va devolviendo las horas como a él le da la gana y en el front no podemos pintar las gráficas hasta que no ha terminado de procesar el último rango. A todo esto es singlethreading y debe estar atendiendo también los paquetes que le llegan.

Si el problema es sin duda alguna como está planteado el esquema, tenemos una colección por cada cliente que nos manda información y metemos ahí todos los paquetes que nos llegan de él. He pensado en reducir las colecciones a días u horas incluso.

Se nota mucho que somos n00bs en este tema, yo de hecho estoy terminando la carrera todavía. Aprendemos a medida que andamos, por eso cualquier ayuda u opinión o tirón de orejas es bien recibido.

#2 guay, le echaré un ojo. Gracias!

#7 "Node es más rápido que Java, vamos, de lejos.".

Maemia, lo que hay que leer.

"¿Quizá el servidor sea un poco cutre?"

Quiza es que esta usando Mongo para lo que NO se debe usar? Una relacional con los indices bien montados se refollaria a todo lo que tiene montado.

#7 Ahí está el quid del problema.

Repito hasta la saciedad que el código es puta porquería, más que nada para que no me eché a los perros.

Está disponible en https://github.com/CompadreHackTeam/Hermes

Y el fragmento de código responsable de la lentitud de la respuesta es una llamada recursiva que devuelve el numero de paquetes por franjas horarias

function iteratorSearch(i, plusHourDate, nextDate, arrayJsonObject, clientCollection,callback) {
    var jsonObject = {};

if (i == 0) {
    callback(null,arrayJsonObject);
} else {
    //Hacer la primera consulta tal y como viene, luego se añade una hora en la siguiente iteracion
    clientCollection.distinct("mac",
        {
            "date": {
                '$gte': plusHourDate,
                '$lt': nextDate
            }
        }, function (err, obj) {
            if (err != null)
                callback(err,null);
            else {
                //concatenar al json magico
                jsonObject.fhour = getWellTime(plusHourDate);
                jsonObject.clients = obj.length;

                arrayJsonObject.push(jsonObject);
                console.log(jsonObject);

                plusHourDate.setHours(plusHourDate.getHours() + 1);
                nextDate.setHours(nextDate.getHours() + 1);

                iteratorSearch(i - 1, plusHourDate, nextDate, arrayJsonObject, clientCollection,callback);
            }
        });
}
}

https://github.com/CompadreHackTeam/Hermes/blob/master/repository/PacketRepository.js

Esa es la madre del cordero, pero esa función se escribió después de 16 horas de curro a las 3 de la mañana.

A parte, al final el objetivo es reducir el numero de documentos que traemos de mongo por consulta

#9Zerokkk:

yo sigo esperando razones reales y datos de verdad.

El problema es que tú en lo único que piensas es en webs normales y corrientes, aquí quiere trabajar con series temporales y hay mejores opciones que Node, Mongo y las cosas que siempre dices.

#13Zerokkk:

¿InfluxDB, por qué?

Porque está creada específicamente para series temporales. Escala a millones de escrituras por segundo, te facilita la compresión y borrado de los datos antiguos, consultas en tiempo real de los datos que insertas, soporta OpenTSDB, está escrita en un lenguaje de verdad (Go) y varios detalles más que te facilitan el trabajo con series temporales.