Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




y34hl0ve

Y como haríais vosotros el traspaso del CSV a la BD?

3 respuestas
PhDfailer

#54857 y por qué no les ayudas? es algo que literalmente ni hay que pensar

con convertir el .csv a algo con tipado donde no haya que hacer casting como .parquet y usar batches ya tienes el problema solucionado, para 150M rows no hay que calentarse la cabeza ni en paralelizar

#54871

1 1 respuesta
Kaledros
#54872PhDfailer:

y por qué no les ayudas?

Porque cobran más que yo y se me han acabado las ganas de arrimar el hombro en esta empresa para que después te la metan hasta el hígado, sinceramente.

6 2 respuestas
Runig666

#54873 Pocas cosas se han dicho más sinceras con menos palabras

8
PhDfailer
#54873Kaledros:

Porque cobran más que yo y se me han acabado las ganas de arrimar el hombro en esta empresa para que después te la metan hasta el hígado, sinceramente

Te entiendo, pero si te sigues amargando porque hay gente que cobra más que tú y sabe menos en algunos (o todos) los aspectos, te vas a quemar.

En este sector (ni en ninguno) no cobra más el que más sabe, es una mezcla de suerte, soft skills y conocimiento justo para venderles la moto a los managers. Solo hay que ver que si tienes una mujer americana y acceso a green card tu sueldo se multiplica x4 sin mucho esfuerzo.

1 respuesta
Kaledros
#54875PhDfailer:

si te sigues amargando

No es el caso, llevo ya un par de semanas echando CV por ahí a ver si me largo ya.

7
GaN2

#54867 Llorando están ahora mismo en Vercel porque no van a poder cubrir las ventas del mes con al agujero que deja el colega al llevarse sus proyectos.

De verdad, mira que hay att. whores en el mundo y tenéis que traer a midumeme

#54871 El primer problema es porque se exporta a un csv como temporal para luego reimportar. Pero digamos que los datos no estaban en la BBDD y son nuevos, todas las bases de datos tienen herramientas para importar datos de csv o lo que te salga del papo. Para que te vas a hacer algo custom cuando la BBDD ya te lo da hecho y seguramente mejor? Por ejemplo en el cáncer que es Oracle tienes SQL Loader:

https://docs.oracle.com/en/database/oracle/property-graph/22.1/spgdg/importing-data-csv-files.html

1 1 respuesta
desu

#54877 Sabrás tú más que los ingenieros senior arquitect alemanes y franceses HAHAHAHAH

Konishi

Independientemente del método exacto (otro formato, un importer nativo..) con 150M entradas digo yo que lo primero sería desglosarlo para poder ir haciéndolo en batches no?

Sí soy fpero, por algún lado hay que empezar

GaN2

1 respuesta
desu

#54880 Era una broma amigo el cual su hijo va con chaleco antibalas al colegio.

Hasta tú, que eres malo en programación, un incompetente, seguramente eres capaz de resolver eso que nuestros amigos alemanes.

Kaledros

Yo no tengo ni puta idea de cómo optimizar esa carga, pero como tengo media neurona funcional sé dos cosas: que no sé hacerlo y que tengo que asegurarme de que se haga de golpe y lo más rápido posible. Así que me pongo a investigar.

En primer lugar, está documentado: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.AnySource.html

En segundo, si el documento se me queda corto y aún me quedan concerns sobre el procedimiento y necesito resolver preguntas seguro que una empresa que se gasta millones al año en infra de Amazon tiene acceso a un señor de AWS que me citará una mañana y resolverá todas mis dudas.

Pero lo que desde luego no hago es asumir cosas y pensar que todo va a ir bien cuando se trata de algo que no conozco.

1 1 respuesta
JuAn4k4

#54882 Pero es que además si no sabían que iba a tardar tanto es porque no lo habían ni probado antes.

1 respuesta
Kaledros

#54883 Qué va, era todo puro wishful thinking, esto va a ir bien porque no sé qué puede ir mal.

1 1 respuesta
Dr_Manhattan

Se ve que en el otro foro no hay fperos con los que debatir tonterías

PD: no lo digo por kaledros, que ha traído un tema interesante hoy

2 1 respuesta
GaN2

#54884 What? Deciden hacer la migración en producción directamente sin haber probado ni rendimiento previamente en otro entorno? Y esa peña se lleva 80k?

1 respuesta
vivora

Y luego nosotros haciendo 3 días de infinitas pruebas para importar 5M y comprobar que todo está correcto y pensando que las demás empresas seguramente lo hagan mejor y lo testeen todo más :rofl:

1 respuesta
Seyriuu

Yo me imagino que habrán hecho pruebas en entornos previos, pero habrán cargado 10 registros, 100 registros... Y habrán extrapolado que si eso les ha llevado 0,XX segundos pues 150 millones en una horita los tenemos cargados

Faena hecha

2 respuestas
Runig666

#54885 Buena tirria me tienes, eso es que he debido de hacer algo bien XD

#54888 Si tienes 150 millones y pruebas 100 nada más...tienes lo que te has ganado.

Obviamente que si tienes 1000 registros pues en pruebas cargas 100 y a ser feliz con ver que están bien. Pero si tienes millones carga aunque sea medio.

Quiero creer que lo que han hecho los muy merluzos es probarlo en su local con 0 curro y una base de datos pirrica...y que tenga 0 que ver con prod, pero que cargarlo lo habrán cargado en su mayoría

#54887 Si te sirve de algo en cuanto a burradas hace no mucho después de probar la importación para un cliente durante 3 putos meses...porque el cliente es tremendamente majo, el día de la importación buena nos cambiaron el formato del fichero, vamos, columnas, datos y demás.
Metiéndonos prisa y cada vez que decíamos que ese no era para nada el formato preguntando que si habíamos subido ya.

...pues se lo comieron en producción a las malas y sin probarlo en dev solo de cabreo que llevábamos mi jefa y yo. Algún dato se fue a la puta porque encima el que nos mandaron ni estaba correcto, es divertido verles meses después aún corriendo datos a mano

No te preocupes, que si crees que lo estás haciendo mal, tienes razón...pero piensa que siempre habrá empresas que lo hagan peor porque no saben...y otros momentos donde desearas hacerlo bastante peor porque estas hasta los huevos XD

Kaledros

#54886 #54888 La realidad es mucho más ridícula.

Arrancaron el proceso y a los 20 minutos fueron a la DB a mirar cuántos registros se habían persistido. Ahí se dieron cuenta de dos cosas:

  • No podían acceder a la DB, porque
  • Lo estaban haciendo todo EN UNA SOLA TRANSACCIÓN.

Tuvieron que parar el proceso, contar las filas de la tabla y dividir 150M entre el resultado, lo que arrojó un resultado muy gracioso.

2
Wei-Yu

#54871 cargar datos a mansalva en una db no es un problema nuevo, todos los engines te dan herramientas para hacer cosas así. En sql server tienes bcp, pero sólo carga a una tabla. Estas herramientas normalmente eliminan trabajo adicional que hace la db (ej en el caso de sql server el log transaccional es distinto y creo recordar de cabeza que ni lo puedes replicar con log shipping pero igual me lo invento xd). Para que te hagas una idea busqué en google rápido y 100M en azure sql server se los traga en menos de 10 minutos (ni idea del tier).

Si son varias tablas y necesitas mantener el identity yo personalmente levantaría la mano y buscaría al adulto de db en la sala en vez de callarme. Sólo se me ocurre que si tu identity está en 100 y tienes 10 escrituras al día, generas a mano las relaciones en tablas de trabajo con el identity que empiece en 150, luego cargas esto sobre las tablas reales para después cambiar el identity a esas tablas para que empiece donde acabó tu carga.

100M no son tantos datos, pero ya has pasado dos puntos de escalabilidad imho, el primero cuando empiezas a hablar en términos de millones, que meterlo a piñón ya es forzar mucho el tema y el segundo cuando ya son varias docenas de millones o te estás acercando a los 100M que ahí es probable que tengas que revisar los planes que tenías a ver si hay que repensar algo.

Al final el problema real ni siquiera es técnico; al analizar no se identificó esto como un known unknown y no se hicieron pruebas en un entorno que replique las dimensiones de prod. Lo primero puede venir de los silos que se hacen cuando hay un lead/manager mandando todo y distribuyendo las tareas y cuando le llega al dev se tiene que pasar medio día jugando al teléfono estropeado y analizando a posteriori.

2
desu

Diferencia entre ingenieros y fperos.

Mis alumnos y alumnos de Miudev y Codely.

HAHAHAHAHAHAHAHHA

PaCoX

el mindudev es como el llados de la programacion, no?

Yo tmb me he encontrado gente que importa registros uno a uno, pero aun peor, usando un botón del navegador... el tío le daba el viernes y rezaba para que la gente de la limpieza no le diera a la regleta el fin de semana xd

2 respuestas
Kaledros

#54893 Qué va, no tienen nada que ver el uno con el otro. Llados es famoso.

liebgott

#54893 No, desu es como un Llados de la programacion. Mindundidev por lo menos no te insulta.

2 respuestas
Konishi

#54895 te falta mucho lore. Dependiendo de cómo de escocido esté te monta una serie de videos intentando desprestigiar tu producto o te manda a los de RRHH

carracho

#54895 Fuera coñas... me estoy viendo videos en youtube (parece que le está explotando el chiringo ahora) y el comportamiento de desu cuadra mucho con este tipo de personalidades de tiburon de hacendado.

r2d2rigo

Imagina vivir en esta realidad paralela.

2 1 respuesta
Sphere

Hago una entrevista con un recruiter, y me dice que para proceder con la siguiente ronda (hablar con la empresa cliente directamente) le tengo que dar una referencia. ¿Estamos locos? Solo doy referencias si tengo una oferta para firmar y esta depende del background check, porque si tuviera que darlas para todos los procesos que hago mis ex-compañeros me mandarían a tomar por culo.

Btw, no sabía que las empresas te suelen pedir que tengas seguro de responsabilidad civil para autónomos si te van a ofrecer un contrato como freelancer. ¿Recomendáis alguno en particular que no salga por un ojo de la cara, pero cubra ante posibles sustos como por ejemplo olvidarme el where en el delete from?

Wei-Yu

#54898 cuando tienes la tienda de campaña puesta en la cámara de eco

1

Usuarios habituales