En la era de la nube, ahora más que nunca, necesitamos comprender el impacto del código sh * t en el funcionamiento de los sistemas y plataformas, ¡porque los costos informáticos son una preocupación arquitectónica!
Cuando decimos:
[matemáticas] O (n ^ 2) [/ matemáticas]
- ¿Cómo funciona la función Rolling Hash utilizada en el algoritmo Rabin Karp?
- ¿Alguien puede dar el algoritmo detallado del algoritmo mejorado de segunda oportunidad?
- ¿Alguien puede ayudarme a dibujar un árbol de recursión para la ecuación [matemáticas] T (n) = T (n-2) + n [/ matemáticas]?
- ¿Es 'Cracking the Coding Interview' una lectura obligatoria cuando se postula para ser un ingeniero front-end?
- ¿Cuáles son las ventajas de los algoritmos de aprendizaje de refuerzo como LinUCB sobre otros algoritmos de predicción de CTR en línea como la regresión logística en línea?
Sabemos que a medida que aumenta el número de elementos, este algoritmo comenzará a tomar n veces más operaciones que hacerlo en tiempo lineal (O (n)). Eso significa que si se le cobra por cómputo, algo que toma 100 milisegundos, realmente se puede hacer en 10 ms y con la multitarea, esto significa que puede obtener aproximadamente 9 o 10 veces más procesamiento por dólar de gasto.
A veces ves gente que dice “Sí, ¡pero puedo poner índices en mi base de datos!”
Y yo soy como …
Debido a que los índices funcionan mejor al unir y evitar escaneos de tabla, pero el efecto de cada índice es naturalmente lineal. Déjame darte otro ejemplo:
La base de datos tiene 3 tablas y desea unirlas todas. la mesa del medio es una de muchos a muchos. Un clutz escribirá algo como esto:
seleccione my_life.dear_gawd_why, is_a.person_asking_this_question
from (unión interna my_life is_a en my_life.id = is_a.mylife_id)
desperdicio de unión interna en waste.id = is_a.waste_id
donde waste.id = @someshit
Y decir
“Sí, ¡optimizaré mis índices! Soy el rey del mundo!
Luego les daré una bofetada y reescribiré esto como:
seleccione my_life.dear_gawd_why, is_a.person_asking_this_question
from (seleccione * from is_a donde is_a.waste_id = @someshit) shorty inner únete a my_life en my_life.id = shorty.mylife_id)
Entonces, ¿por qué reescribí eso así?
Combinatoriamente, la primera opción da como resultado que todos los índices se unan tanto en la primera como en la segunda tabla, y el resultado de eso, se una en la tercera tabla. Si imaginas los números como
- my_life = 10,000 registros
- is_a = 17,000 registros
- desperdicio = 1,000
Y waste.id id de coincidencia = @someshit es decir, 100.
Esto da como resultado un índice almacenado en la memoria del producto cartesiano de 170,000,000,000 de registros (que tiene sus propios problemas de complejidad de espacio: ¿tiene 170GB + en su máquina? Está fuera de la memoria virtual) que luego debe rastrear debajo del capó para llegar al máximo 1 x 100 x 10,000 = 1,000,000 de registros coincidentes.
Por el contrario, mi camino te da el prefiltro de 100 registros para unirte. Lo que significa que el máximo que podría tener que rastrear es 10,000 x 100 x 1,000 = 1,000,000,000 para luego encontrar el máximo de 1,000,000 de registros coincidentes. 170 veces más rápido, incluso con índices.
Es este tipo de combinatoria lo que diferencia a los ingenieros de software reales de los “programadores”, no es que quiera perjudicar a los programadores.
Si desea otro consejo, hice uno hace mucho tiempo para mostrar la diferencia, incluso contra la vainilla, de las bibliotecas de objetos de lenguaje fuera de la caja.
Optima local codiciosa, no una marca mundial óptima Codementor
