Хранение расстояний в MySQL

Question

В моей базе данных есть таблица "colors".

Пользователь вводит цвет через пользовательский интерфейс, и сервер ищет наиболее похожий цвет, существующий в таблице цветов, вычисляя расстояние цветов в пространстве HCL.

Я реализую алгоритм кэширования, который должен хранить расстояние между ранее вычисленными цветовыми расстояниями, чтобы избежать повторных математических операций.

Каков наилучший макет стола для такой цели?

Answer 1

Как сказал Усама, это выглядит как преждевременная оптимизация. Исходя из вашего описания алгоритма, я бы:

• Предварительно рассчитать векторы HCL для всех цветов в базе данных и сохранить таблицу, в которой идентификатор цвета сопоставляется с его вектором 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) INDEX (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, но на основании описания в Color :: Similarity :: HCL кажется, что для ввода расстояния нужны два цвета.

Так что я думаю, что по крайней мере два набора RGB и соответствующее расстояние между ними должны быть сохранены. Я не уверен в вашем случае использования, но если выбран диапазон выбора, вы также можете сохранить выбор пользователя.

Кажется, что будет только конечное число комбинаций, хотя? Кажется, что вы могли бы сделать математику один раз для каждой комбинации, и просто иметь таблицу поиска?