MySQL에 거리 저장

Question

내 데이터베이스에 "색상" 테이블이 있습니다.

사용자가 사용자 인터페이스를 통해 색상을 입력하면 백엔드는 색상 테이블에 존재하는 가장 유사해 보이는 색상을 검색하여 HCL 공간에서 색상 간의 거리를 계산합니다.

반복되는 수학 연산을 피하기 위해 이전에 계산된 색상 거리 사이의 거리를 저장하는 캐싱 알고리즘을 구현하겠습니다.

이러한 목적에 가장 적합한 테이블 레이아웃은 무엇입니까?

Answer 1

Osama가 말했듯이 이는 조기 최적화처럼 보입니다.알고리즘에 대한 설명을 바탕으로 다음을 수행합니다.

• 데이터베이스의 모든 색상에 대한 HCL 벡터를 미리 계산하고 색상 ID를 HCL 벡터에 매핑하는 테이블을 저장합니다.
• 테이블은 다음을 사용하여 저장되어야 합니다. MySQL 공간 확장, 포인트의 이웃을 쿼리할 수 있습니다.
• 새로운 색상이 선택되면 이를 HCL로 변환하고 HCL 공간에서 해당 지점의 이웃을 쿼리합니다.
• 캐싱이 필요한 경우에는 거친 색상을 캐시하므로 사용자가 이전에 선택한 색상을 다시 방문할 가능성이 있습니다.

Answer 2

당신은 이것을 할 수 있습니다 :

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

그러나 사용자가 동일한 숫자를 계속 입력 할 것으로 기대합니까 ??? 이 테이블의 최대 행 수는 가장 가까운 색상 만 포함 된 경우 16777216입니다.

나는 여전히 데이터베이스 액세스가 계산보다 느리다고 의심되므로 인용문을 생각하고 있습니다. "조기 최적화는 모든 악의 근원입니다".

실제 문제로 볼 때까지 계산을 캐싱하지 않고 실행합니다.

Answer 3

나는 당신의 색상 "거리"가 다음과 같은 것으로 계산된다고 가정합니다.

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

8 비트 픽셀을 사용하고 있다고 가정하면 테이블에 (256^3)^2 개의 별개의 매핑이있을 것입니다. 그것은 많은 테이블 공간입니다. (아마도 많이 압축 할 수는 있지만 ... 다음 요점을 참조하십시오.)

고려해야 할 또 다른 사항은 계산 비용과 계산 비용을 찾기 위해 데이터베이스 조회 비용입니다. 내 생각에 데이터베이스 조회는 밀리 초 이상이 걸릴 것이지만 메트릭 계산은 1 마이크로 초 이하가되어야합니다.

대체로 데이터베이스 테이블을 사용하는 것은 나에게 정말 나쁜 생각처럼 들립니다.

Answer 4

내가 추천하는 것은 다음과 같습니다.

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

table color_distances(color_1_id, color_2_id, distance)

색인 : 기본 (Color_1_ID, Color_2_ID) 색인 (Color_1_ID, 거리, Color_2_ID)

Color_Distances에는 가능한 모든 Color_ID 조합이 포함되어 있으며 필요에 따라 업데이트됩니다.

그런 다음 선택하면 간단합니다.

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

나는 HCL에 너무 익숙하지 않지만 설명을 바탕으로 색상 :: 유사성 :: HCl 거리의 입력으로 두 가지 색상이 필요한 것 같습니다.

따라서 적어도 두 개의 RGB 세트와 그 사이의 거리가 저장되어야한다고 생각합니다. 유스 케이스가 확실하지 않지만 선택 범위가 선택되면 사용자 선택도 저장할 수도 있습니다.

그래도 유한 한 수의 조합 만있는 것 같습니다. 각 조합에 대해 한 번 수학을 할 수 있고 조회 테이블 만 가지고있을 것 같습니까?