Yo prefiero el Hyundai Kona o también conocimdo como el Hyundai Vagina, pero cada uno con sus gustos.
#23524 Es que no es tan sencillo como decir que si tienes que ir a trabajar a un sitio con un horario ya eres falso autónomo pues depende de los acuerdos a los que llegues.
Las características principales del TRADE es que no estás dentro de la estructura de la empresa, estableces tu tarifa y utilizas medios de producción propios. Lo que me dejas con la duda es si cumplir un horario es suficiente para considerarlo dentro de la estructura de la empresa con lo que eso conlleva. Yo sigo pensando que depende de la situación.
Voy a renovar monitor, que setup usan? Creo que voy a poner un monitor solo UHD:
https://www.amazon.es/gp/product/B01CDYB0QS/ref=ox_sc_act_title_1?smid=A1AT7YVPFBWXBL&psc=1
alguna recomendación?
Consulta de MySQL:
Tengo una tabla tochilla de 10 millones de registros.
Tengo otra tabla que se va llenando en función de los datos que se procesan de la primera.
Para saber qué datos toca procesar, miro los datos que están en la primera tabla que no están en la segunda. Para esto, uso un LEFT JOIN con un "right_table.id" IS NULL.
El problema es que cuando el número de cosas que voy metiendo en la segunda va creciendo, la query me tarda como 20-25 segundos, lo cual es muy jodido, ¿alguna idea de optimizar un left join para sacar nulos? ¿otra forma de hacer esto? xD
#23562 Joder, yo pensaba que eras el puto amo porque llevabas desde los cinco años programando y nos vienes con dudas de SQLite.
Apuntalos en un papel y vas tachando.
Nah, ahora en serio:
- Si la tabla principal no cambia: Tabla auxiliar con IDs de la tabla principal y recorres y eliminas registros de esta
- Si la tabla principal crece, pero las tareas son 'crecientes': guarda el ultimo ID por el que te has quedado y partes de ahí
- Se me había ocurrido una tercera, pero llegando a casa se me ha ido de la cabeza, si la recuerdo la escribo xD
#23563 Probados y no hay mucha diferencia, si bien hay una mejora sustancial, sigue tardando unos 16 segundos lo cual me fastidia un poco... Si le quito el "right_table.id" IS NULL la consulta es instantánea, es lo que me jode (join incluído). Tiene pinta que como ese null viene del LEFT JOIN y no puede indizarse me está penalizando bastamente al tener que escanear todos los resultados (10 millones) y descargar los que no sean nulos...
#23564 Desde los 12, tampoco te cebes xD. Y tampoco soy el puto amo, intento hacer mi trabajo lo mejor que puedo, pero hay cosas que se me escapan, y no se me ocurre magia arcana para optimizar esta mierda... 
#23565 Coño, cuando he visto el mensaje por primera vez no habías puesto las respuestas xD.
Te digo:
- 1.: La tabla principal como tal no cambia, según proceso un item de la primera, lo meto en la segunda. Lo de la tabla auxiliar realmente no lo termino de ver, aunque tampoco lo descarto... Pero prefiero evitarlo.
- 2.: Guardar el último ID lo descarto totalmente, hacerlo como lo tengo ahora me da una ventaja, dado que es un sistema que procesa muchos items simultaneos, si por lo que sea un hilo peta o un item no me lo puede procesar, la siguiente iteración me recoge ese ítem al no existir en la segunda tabla. Si uso un ID como offset para hacer un where id > last_id me como esos registros. Lo que se me ocurre es hacer una primera pasada procesando mediante este método (tomando el último ID como offset) y luego hacer pasadas con mi método actual hasta que todo quede procesado, lo cual dejaría este problema para los items que no se hayan procesado con el primero (que deberían ser pocos).
- 3.: Me parece buena idea, la pondré en práctica <3.
#23566 Pues se puede optimizar de varias maneras:
Añade un bool a la primera tabla que indique si está computado o no y te olvidas de joins que el problema seguramente es que no esté utilizando los índices (te puede crear tablas temporales y demás, es complicado saberlo xD)
Te creas un index con todos los campos que haya en el where.
Te creas un index a todos los campos que devuelva el select, si tienes suerte ni si quiera mira en la tabla y los recupera directamente desde los indices.
No soy experto en mysql y tampoco sé si mejoraría mucho el rendimiento pero es ir probando cosas.
yo le metía una cola, y que el consumer solo desencole si ha sido capaz de procesar ese elemento. Con RabbitMQ es una implementación super sencilla, capaz de escalar consumers, y que te certifica que nunca 2 consumers van a procesar el mismo elemento
no soy nada partidario de usar tablas temporales
#23566 Crea un 'trigger' que escriba en la tabla B lo que quieres al momento de actualizar la tabla A
#23567 Eso significa que tengo que ir elemento por elemento actualizando de false a true, el problema es que en el entorno en que estoy trabajando cada consulta tiene una latencia algo elevada (el hardware es algo limitado), si fuera ir una por una hay muchos problemas que me habría ahorrado.
En cuanto a crear el index con los campos que haya en el where, el problema es que cuando haces un LEFT JOIN y la sentencia WHERE IS NULL se refiere a la segunda tabla, te estás refiriendo a un nulo, a algo que no existe, por lo que no está indizado. Eso es lo que hace que haya este problema, no puedes indizar algo que no existe.
Crear el index con los campos del select es más de lo mismo, ese where sobre algo "inindizable" me jode la vida xD.
#23568 Sobre la cola, el problema es que el sistema no se ha tratado como algo que realice tareas de manera atómica (por lo dicho anteriormente) sino que las transacciones son globales, los 10 millones de registros van asociados a una sola operación, y si falla algo, se reinicia el proceso y se procesan los 10 millones de registros de nuevo. En parte es tedioso pero en mi entorno de trabajo esto es natural y obligatorio (preservación digital). Si hay un problema, hay que asegurar la integridad del proceso empezando de cero, y para eso un sistema de colas carece de cierto sentido. Si no, el sistema de colas nos habría facilitado bastante, no solo para atomizar las operaciones sino para poder crear de manera más sencilla un sistema multinodo, pero es lo que hay.
#23569 La tabla A no se actualiza, la tabla A digamos que es una tabla que se escribe una única vez y sirve de índice, el resto de operaciones se realizan en base a la información de la tabla A y de otras tablas, pero la A es la que asegura la integridad del resto de cosas, tampoco me serviría.
P.d.: He optado por integrar la opción 2 de #23566 con un proceso mixto, primero proceso todo de manera secuencial y luego hago una pasada procesando los items que en el primer proceso no lo han hecho. Gracias a @MisKo por aclararme las ideas <3.
Yo migraría todo a Hive que va por HDFS, soporta consultas SQL y tiene soporte para MapReduce distribuido. Te quitas de rollos.
#23572 El sistema en sí no va mal y no hay penalización a mayor número de registros si se indiza bien (que creo que está hecho bien), así que de momento descarto tal cosa.
P.d.: He buscado HDFS en Google y me sale:
HDFS is a Java-based...Me detuve en Java xD.
#23573 No creo que sea big data ni mucho menos, no llegará a los 3.5GB la base de datos en este momento xD.
#23576 en verdad Ubuntu es mi primera opción, es más, estoy haciendo pruebas en una VM de la instalación antes de formatear, pero he visto las distros de Debian y Fedora y me han empezado a entrar dudas xd. Por ejemplo Fedora me está llamando mucho la atención.
#23575 si quieres vender tu alma a redhat, fedora. Si quieres vender tu alma a debian, debian.
No tiene mucho más xd
#23578 Qué te llama la atención? Cuidadin que las webs los logos los themes y wallpapers confunden mucho xd
