distanze Memorizzazione in MySQL

Question

Ho una tabella "colori" nel mio database.

L'utente inserisce un colore trogolo l'interfaccia utente, e le ricerche di backend per il colore più simile alla ricerca esistente nella tabella di colori, calcolando la distanza dei colori nello spazio di HCL.

Io implementare un algoritmo di caching, che dovrebbe conservare la distanza tra le distanze di colori calcolati in precedenza, al fine di evitare operazioni matematiche ripetuti.

Qual è la migliore disposizione della tabella per tale scopo?

Answer 1

Come ha detto Osama, questo appare come l'ottimizzazione prematura. Sulla base della sua descrizione dell'algoritmo, lo farei:

• pre-calcolare i vettori di HCL per tutti i colori presenti nel database, e memorizzare una tabella che associa un ID colore per il suo vettore HCL.
• Il tavolo deve essere conservato con il MySQL spaziale estensioni , che ti permettono di ricerca per i vicini di un punto.
• Quando si sceglie un nuovo colore, trasformarlo in HCL, e query per i vicini del suo punto nello spazio HCL.
• Se è necessaria la memorizzazione nella cache a tutti, vorrei memorizzare nella cache i colori a grana grossa, quindi c'è qualche possibilità che gli utenti rivisitano un colore precedentemente selezionato.

Answer 2

si potrebbe fare questo:

table colors(r,g,b)
table colordistance(user_r,user_g,user_b,r,g,b,distance)

, ma cosa si aspetta agli utenti di mantenere entrare gli stessi numeri ??? Il numero massimo di righe in questa tabella è 16777216 se si include solo il colore più vicino.

Ho ancora il sospetto che l'accesso al database è più lento rispetto al calcolo, così sto pensando della citazione " ottimizzazione prematura è la radice di tutti i mali ".

Vorrei correre senza alcun caching del calcolo fino a quando lo vedo come un problema reale.

Answer 3

Suppongo che il tuo colore "distanze" sono calcolati come qualcosa di simile:

sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2)

Supponendo che si sta utilizzando 8 bit pixel, non ci sarebbe (256 ^ 3) ^ 2 mappature distinte nella tabella. Questo è un sacco di spazio di tabella. (Si potrebbe probabilmente compattare un sacco, ma ... vedi punto successivo).

L'altra cosa che dovete considerare è il costo di una ricerca nel database per trovare una distanza di colore rispetto al costo di fare il calcolo. La mia ipotesi è che una ricerca nel database vorrebbe un millesimo di secondo o più, ma il computo metrico dovrebbe prendere 1 microsecondo o meno.

Tutto sommato, utilizzando una tabella di database suona come una pessima idea per me.

Answer 4

Ecco quello che vi consiglio:

table colors(color_id, color_name, r, g, b)

table color_distances(color_1_id, color_2_id, distance)

Indici: PRIMARIO (color_1_id, color_2_id) INDEX (color_1_id, distanza, color_2_id)

color_distances conterrebbe tutte le possibili combinazioni color_id, e sarebbero stati aggiornati solo se necessario.

Selezione sarebbe allora semplice:

SELECT similar_colors.*
FROM colors as similar_colors, color_distances
WHERE color_distances.color_1_id = <selected_color_id>
ORDER BY color_distances.distance ASC

Answer 5

Io non sono troppo familiarità con HCL, ma in base alla descrizione a Colore: : somiglianza :: HCL sembra che due colori sono necessari come input per la distanza

.

Così penserei almeno due insiemi di RGB e la distanza tra di loro secondo deve essere conservato. Non sono sicuro del vostro caso d'uso, ma se si seleziona la gamma di scelte, si consiglia di conservare l'utente-selezione pure.

Sembra che ci sarebbe solo un numero finito di combinazioni però? Sembra che si possa fare i conti una volta per ogni combinazione, e solo una tabella di ricerca?