关于您的餐桌
首先,我认为您应该将数据类型更改为纯数组。
CREATE TABLE public.vector (
id serial NOT NULL,
vctor double precision [3] --for three dimensional vectors; of course you can change the dimension or leave it unbounded if you need it.
);
INSERT INTO public.vector (vctor) VALUES (ARRAY[2,3,4]);
INSERT INTO public.vector (vctor) VALUES (ARRAY[3,4,5]);
所以
SELECT * FROM public.vector;
会产生以下数据
id | vctor
------|---------
1 | {2,3,4}
2 | {3,4,5}
也许不是您期望的答案,但请考虑一下
您可能已经知道,计算向量之间的余弦涉及计算幅度。我认为问题不在于算法,而在于实现;它需要计算对 RDBMS 来说代价高昂的平方和平方根。
现在,谈谈效率;调用数学函数时,服务器进程不承担负载。在 PostgreSQL 中,数学函数 (look here) 从 C 库运行,因此它们非常高效。然而,最终,宿主必须分配一些资源来进行这些计算。
在服务器内部实施这些相当昂贵的操作之前,我确实会仔细考虑。但是没有一个正确的答案;这取决于您如何使用数据库。例如,如果它是一个有数千个并发用户的生产数据库,我会将这种计算移到其他地方(中间层或用户应用程序)。但是如果用户很少,并且您的数据库是用于小型研究操作,那么它可以将其实现为存储过程或在服务器内部运行的进程,但请记住,这将影响可伸缩性或可移植性。当然,还有更多考虑因素,例如将处理多少行,或者您是否打算触发触发器等。
考虑其他替代方案
制作客户端应用
您可以用 VB 或您选择的语言编写一个快速而体面的程序。并让客户端应用程序进行繁重的计算,并将数据库用于它最擅长的存储和检索数据。
以不同方式存储数据
对于这个特定的示例,您可以存储单位向量加上幅度。这样,求任意两个向量之间的余弦就可以简单地简化为单位向量的点积(只有乘除,没有平方也没有平方根。)
CREATE TABLE public.vector (
id serial NOT NULL,
uvctor double precision [3], --for three dimensional vectors; of course you can change the dimension or make it decimal if you need it
magnitude double precision
);
INSERT INTO public.vector (vctor) VALUES (ARRAY[0.3714, 0.5571, 0.7428], 5.385); -- {Ux, Uy, Uz}, ||V|| where V = [2, 3, 4];
INSERT INTO public.vector (vctor) VALUES (ARRAY[0.4243, 0.5657, 0.7071], 7.071); -- {Ux, Uy, Uz}, ||V|| where V = [3, 4, 5];
SELECT a.vctor as a, b.vctor as b, 1-(a.uvctor[1] * b.uvctor[1] + a.uvctor[2] * b.uvctor[2] + a.uvctor[3] * b.uvctor[3]) as cosine_distance FROM public.vector a
JOIN public.vector b ON a.id != b.id;
导致
a | b | cosine_distance
-----------------------------|------------------------------|------------------
{0.3714,0.5571,0.7428,5.385} | {0.4243,0.5657,0.7071,7.071} | 0.00202963
{0.4243,0.5657,0.7071,7.071} | {0.3714,0.5571,0.7428,5.385} | 0.00202963
即使您必须计算服务器内部向量的大小,您也需要为每个向量计算一次,而不是每次都需要计算其中两个之间的距离。随着行数的增加,这变得更加重要。例如,对于 1000 个向量,如果要使用原始向量分量获得任意两个向量之间的余弦差,则必须计算 999000 次。
以上任意组合
结论
当我们追求效率时,大多数时候并没有一个规范的答案。相反,我们必须考虑和评估权衡取舍。它始终取决于我们需要实现的最终目标。数据库非常适合存储和检索数据;他们肯定可以制造其他东西,但这会带来额外的成本。如果我们可以忍受增加的开销,那很好;否则我们必须考虑替代方案。