Distanza di Levenshtein in T-SQL


Risposte:


101

Ho implementato la funzione standard di modifica della distanza di Levenshtein in TSQL con diverse ottimizzazioni che migliorano la velocità rispetto alle altre versioni di cui sono a conoscenza. Nei casi in cui le due stringhe hanno caratteri in comune all'inizio (prefisso condiviso), caratteri in comune alla loro fine (suffisso condiviso) e quando le stringhe sono grandi e viene fornita una distanza massima di modifica, il miglioramento della velocità è significativo. Ad esempio, quando gli input sono due stringhe di caratteri da 4000 molto simili e viene specificata una distanza di modifica massima di 2, questo è quasi tre ordini di grandezza più veloce deledit_distance_withinfunzione nella risposta accettata, restituendo la risposta in 0,073 secondi (73 millisecondi) contro 55 secondi. È anche efficiente in termini di memoria, utilizzando uno spazio uguale alla più grande delle due stringhe di input più uno spazio costante. Usa un singolo "array" nvarchar che rappresenta una colonna, e fa tutti i calcoli sul posto, più alcune variabili int helper.

Ottimizzazioni:

  • salta l'elaborazione del prefisso e / o del suffisso condiviso
  • ritorno anticipato se una stringa più grande inizia o finisce con l'intera stringa più piccola
  • ritorno anticipato se la differenza di dimensioni garantisce il superamento della distanza massima
  • utilizza solo un singolo array che rappresenta una colonna nella matrice (implementato come nvarchar)
  • quando viene fornita una distanza massima, la complessità temporale va da (len1 * len2) a (min (len1, len2)) cioè lineare
  • quando viene fornita una distanza massima, tornare in anticipo non appena si sa che la distanza massima limite non è raggiungibile

Ecco il codice (aggiornato il 20/01/2014 per velocizzarlo un po 'di più):

-- =============================================
-- Computes and returns the Levenshtein edit distance between two strings, i.e. the
-- number of insertion, deletion, and sustitution edits required to transform one
-- string to the other, or NULL if @max is exceeded. Comparisons use the case-
-- sensitivity configured in SQL Server (case-insensitive by default).
-- 
-- Based on Sten Hjelmqvist's "Fast, memory efficient" algorithm, described
-- at http://www.codeproject.com/Articles/13525/Fast-memory-efficient-Levenshtein-algorithm,
-- with some additional optimizations.
-- =============================================
CREATE FUNCTION [dbo].[Levenshtein](
    @s nvarchar(4000)
  , @t nvarchar(4000)
  , @max int
)
RETURNS int
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @distance int = 0 -- return variable
          , @v0 nvarchar(4000)-- running scratchpad for storing computed distances
          , @start int = 1      -- index (1 based) of first non-matching character between the two string
          , @i int, @j int      -- loop counters: i for s string and j for t string
          , @diag int          -- distance in cell diagonally above and left if we were using an m by n matrix
          , @left int          -- distance in cell to the left if we were using an m by n matrix
          , @sChar nchar      -- character at index i from s string
          , @thisJ int          -- temporary storage of @j to allow SELECT combining
          , @jOffset int      -- offset used to calculate starting value for j loop
          , @jEnd int          -- ending value for j loop (stopping point for processing a column)
          -- get input string lengths including any trailing spaces (which SQL Server would otherwise ignore)
          , @sLen int = datalength(@s) / datalength(left(left(@s, 1) + '.', 1))    -- length of smaller string
          , @tLen int = datalength(@t) / datalength(left(left(@t, 1) + '.', 1))    -- length of larger string
          , @lenDiff int      -- difference in length between the two strings
    -- if strings of different lengths, ensure shorter string is in s. This can result in a little
    -- faster speed by spending more time spinning just the inner loop during the main processing.
    IF (@sLen > @tLen) BEGIN
        SELECT @v0 = @s, @i = @sLen -- temporarily use v0 for swap
        SELECT @s = @t, @sLen = @tLen
        SELECT @t = @v0, @tLen = @i
    END
    SELECT @max = ISNULL(@max, @tLen)
         , @lenDiff = @tLen - @sLen
    IF @lenDiff > @max RETURN NULL

    -- suffix common to both strings can be ignored
    WHILE(@sLen > 0 AND SUBSTRING(@s, @sLen, 1) = SUBSTRING(@t, @tLen, 1))
        SELECT @sLen = @sLen - 1, @tLen = @tLen - 1

    IF (@sLen = 0) RETURN @tLen

    -- prefix common to both strings can be ignored
    WHILE (@start < @sLen AND SUBSTRING(@s, @start, 1) = SUBSTRING(@t, @start, 1)) 
        SELECT @start = @start + 1
    IF (@start > 1) BEGIN
        SELECT @sLen = @sLen - (@start - 1)
             , @tLen = @tLen - (@start - 1)

        -- if all of shorter string matches prefix and/or suffix of longer string, then
        -- edit distance is just the delete of additional characters present in longer string
        IF (@sLen <= 0) RETURN @tLen

        SELECT @s = SUBSTRING(@s, @start, @sLen)
             , @t = SUBSTRING(@t, @start, @tLen)
    END

    -- initialize v0 array of distances
    SELECT @v0 = '', @j = 1
    WHILE (@j <= @tLen) BEGIN
        SELECT @v0 = @v0 + NCHAR(CASE WHEN @j > @max THEN @max ELSE @j END)
        SELECT @j = @j + 1
    END

    SELECT @jOffset = @max - @lenDiff
         , @i = 1
    WHILE (@i <= @sLen) BEGIN
        SELECT @distance = @i
             , @diag = @i - 1
             , @sChar = SUBSTRING(@s, @i, 1)
             -- no need to look beyond window of upper left diagonal (@i) + @max cells
             -- and the lower right diagonal (@i - @lenDiff) - @max cells
             , @j = CASE WHEN @i <= @jOffset THEN 1 ELSE @i - @jOffset END
             , @jEnd = CASE WHEN @i + @max >= @tLen THEN @tLen ELSE @i + @max END
        WHILE (@j <= @jEnd) BEGIN
            -- at this point, @distance holds the previous value (the cell above if we were using an m by n matrix)
            SELECT @left = UNICODE(SUBSTRING(@v0, @j, 1))
                 , @thisJ = @j
            SELECT @distance = 
                CASE WHEN (@sChar = SUBSTRING(@t, @j, 1)) THEN @diag                    --match, no change
                     ELSE 1 + CASE WHEN @diag < @left AND @diag < @distance THEN @diag    --substitution
                                   WHEN @left < @distance THEN @left                    -- insertion
                                   ELSE @distance                                        -- deletion
                                END    END
            SELECT @v0 = STUFF(@v0, @thisJ, 1, NCHAR(@distance))
                 , @diag = @left
                 , @j = case when (@distance > @max) AND (@thisJ = @i + @lenDiff) then @jEnd + 2 else @thisJ + 1 end
        END
        SELECT @i = CASE WHEN @j > @jEnd + 1 THEN @sLen + 1 ELSE @i + 1 END
    END
    RETURN CASE WHEN @distance <= @max THEN @distance ELSE NULL END
END

Come menzionato nei commenti di questa funzione, la distinzione tra maiuscole e minuscole dei confronti dei caratteri seguirà le regole di confronto in vigore. Per impostazione predefinita, il confronto di SQL Server è quello che comporterà confronti senza distinzione tra maiuscole e minuscole. Un modo per modificare questa funzione in modo che sia sempre sensibile al maiuscolo / minuscolo sarebbe aggiungere un confronto specifico ai due punti in cui vengono confrontate le stringhe. Tuttavia, non l'ho testato a fondo, soprattutto per gli effetti collaterali quando il database utilizza un confronto non predefinito. Ecco come le due linee verrebbero modificate per forzare confronti sensibili al maiuscolo / minuscolo:

    -- prefix common to both strings can be ignored
    WHILE (@start < @sLen AND SUBSTRING(@s, @start, 1) = SUBSTRING(@t, @start, 1) COLLATE SQL_Latin1_General_Cp1_CS_AS) 

e

            SELECT @distance = 
                CASE WHEN (@sChar = SUBSTRING(@t, @j, 1) COLLATE SQL_Latin1_General_Cp1_CS_AS) THEN @diag                    --match, no change

1
Come possiamo usarlo per cercare le prime 5 corde più vicine in una tabella? Voglio dire, diciamo che ho una tabella dei nomi delle strade con 10m di righe. Inserisco la ricerca nel nome di una via ma 1 carattere è scritto in modo errato. Come posso cercare le prime 5 corrispondenze più vicine con le massime prestazioni?
MonsterMMORPG

1
A parte la forza bruta (confrontando tutti gli indirizzi), non puoi. Levenshtein non è qualcosa che può facilmente trarre vantaggio dagli indici. Se puoi restringere i candidati a un sottoinsieme più piccolo tramite qualcosa che può essere indicizzato, come un codice postale per l'indirizzo o un codice fonetico per i nomi, ad esempio, allora Levenshtein dritto come quello nelle risposte qui può essere applicato in modo fattibile al sottoinsieme. Per applicare a un intero set che è grande, dovresti andare a qualcosa come Levenshtein Automata, ma implementarlo in SQL va ben oltre lo scopo della domanda SO a cui si risponde qui.
accetta - fatto con SOverflow il

@MonsterMMORPG in teoria potresti fare il contrario e calcolare tutte le possibili permutazioni per una data distanza di Levenshtein. Oppure potresti provare a vedere se le parole nei tuoi indirizzi compongono un elenco abbastanza breve da essere utile (probabilmente ignorando le parole che appaiono solo raramente).
TheConstructor

@MonsterMMORPG - è tardi, ma ho pensato di aggiungere una risposta migliore. Se conosci il numero minimo di modifiche consentite, puoi utilizzare il metodo Symmetric Delete come è stato fatto nel progetto symspell su GitHub. È possibile memorizzare un piccolo sottoinsieme di permutazioni di appena eliminazioni, quindi cercare qualsiasi nel piccolo insieme di permutazioni di eliminazione della stringa di ricerca. Sul set restituito (che sarebbe piccolo se si consente solo 1 o 2 distanza di modifica massima), si esegue quindi il calcolo completo del levenshtein. Ma dovrebbe essere molto, molto meno che farlo su tutte le corde.
accetta - fatto con SOverflow

1
@DaveCousineau: come indicato nei commenti sulla funzione, i confronti tra stringhe utilizzano la distinzione tra maiuscole e minuscole per le regole di confronto di SQL Server in vigore. Per impostazione predefinita, questo in genere significa case insensitive. Guarda la modifica al mio post che ho appena aggiunto. L'implementazione di Fribble in un'altra risposta si comporta in modo simile per quanto riguarda le regole di confronto.
accetta - fatto con SOverflow il

58

Arnold Fribble aveva due proposte su sqlteam.com/forums

Questo è il più giovane del 2006:

SET QUOTED_IDENTIFIER ON 
GO
SET ANSI_NULLS ON 
GO

CREATE FUNCTION edit_distance_within(@s nvarchar(4000), @t nvarchar(4000), @d int)
RETURNS int
AS
BEGIN
  DECLARE @sl int, @tl int, @i int, @j int, @sc nchar, @c int, @c1 int,
    @cv0 nvarchar(4000), @cv1 nvarchar(4000), @cmin int
  SELECT @sl = LEN(@s), @tl = LEN(@t), @cv1 = '', @j = 1, @i = 1, @c = 0
  WHILE @j <= @tl
    SELECT @cv1 = @cv1 + NCHAR(@j), @j = @j + 1
  WHILE @i <= @sl
  BEGIN
    SELECT @sc = SUBSTRING(@s, @i, 1), @c1 = @i, @c = @i, @cv0 = '', @j = 1, @cmin = 4000
    WHILE @j <= @tl
    BEGIN
      SET @c = @c + 1
      SET @c1 = @c1 - CASE WHEN @sc = SUBSTRING(@t, @j, 1) THEN 1 ELSE 0 END
      IF @c > @c1 SET @c = @c1
      SET @c1 = UNICODE(SUBSTRING(@cv1, @j, 1)) + 1
      IF @c > @c1 SET @c = @c1
      IF @c < @cmin SET @cmin = @c
      SELECT @cv0 = @cv0 + NCHAR(@c), @j = @j + 1
    END
    IF @cmin > @d BREAK
    SELECT @cv1 = @cv0, @i = @i + 1
  END
  RETURN CASE WHEN @cmin <= @d AND @c <= @d THEN @c ELSE -1 END
END
GO

1
@Alexander, sembra funzionare ma cambierei i nomi delle tue variabili in qualcosa di più significativo. Inoltre, mi sbarazzerei di @d, sai la lunghezza delle due stringhe nel tuo input.
Lieven Keersmaekers,

2
@Lieven: non è una mia implementazione, l'autore è Arnold Fribble. Il parametro @d è una differenza massima consentita tra le stringhe dopo aver raggiunto la quale sono considerate troppo diverse e la funzione restituisce -1. Viene aggiunto perché l'algoritmo in T-SQL funziona troppo lentamente.
Alexander Prokofyev

Dovresti controllare il codice dell'algoritmo psuedo su: en.wikipedia.org/wiki/Levenshtein_distance, non è molto migliorato.
Norman H

13

IIRC, con SQL Server 2005 e versioni successive è possibile scrivere stored procedure in qualsiasi linguaggio .NET: utilizzando l'integrazione con CLR in SQL Server 2005 . Con questo non dovrebbe essere difficile scrivere una procedura per il calcolo della distanza di Levenstein .

Un semplice Hello, World! estratto dall'help:

using System;
using System.Data;
using Microsoft.SqlServer.Server;
using System.Data.SqlTypes;

public class HelloWorldProc
{
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void HelloWorld(out string text)
    {
        SqlContext.Pipe.Send("Hello world!" + Environment.NewLine);
        text = "Hello world!";
    }
}

Quindi nel tuo SQL Server esegui quanto segue:

CREATE ASSEMBLY helloworld from 'c:\helloworld.dll' WITH PERMISSION_SET = SAFE

CREATE PROCEDURE hello
@i nchar(25) OUTPUT
AS
EXTERNAL NAME helloworld.HelloWorldProc.HelloWorld

E ora puoi provare a eseguirlo:

DECLARE @J nchar(25)
EXEC hello @J out
PRINT @J

Spero che sia di aiuto.


7

È possibile utilizzare l'algoritmo di distanza di Levenshtein per confrontare le stringhe

Qui puoi trovare un esempio T-SQL su http://www.kodyaz.com/articles/fuzzy-string-matching-using-levenshtein-distance-sql-server.aspx

CREATE FUNCTION edit_distance(@s1 nvarchar(3999), @s2 nvarchar(3999))
RETURNS int
AS
BEGIN
 DECLARE @s1_len int, @s2_len int
 DECLARE @i int, @j int, @s1_char nchar, @c int, @c_temp int
 DECLARE @cv0 varbinary(8000), @cv1 varbinary(8000)

 SELECT
  @s1_len = LEN(@s1),
  @s2_len = LEN(@s2),
  @cv1 = 0x0000,
  @j = 1, @i = 1, @c = 0

 WHILE @j <= @s2_len
  SELECT @cv1 = @cv1 + CAST(@j AS binary(2)), @j = @j + 1

 WHILE @i <= @s1_len
 BEGIN
  SELECT
   @s1_char = SUBSTRING(@s1, @i, 1),
   @c = @i,
   @cv0 = CAST(@i AS binary(2)),
   @j = 1

  WHILE @j <= @s2_len
  BEGIN
   SET @c = @c + 1
   SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j-1, 2) AS int) +
    CASE WHEN @s1_char = SUBSTRING(@s2, @j, 1) THEN 0 ELSE 1 END
   IF @c > @c_temp SET @c = @c_temp
   SET @c_temp = CAST(SUBSTRING(@cv1, @j+@j+1, 2) AS int)+1
   IF @c > @c_temp SET @c = @c_temp
   SELECT @cv0 = @cv0 + CAST(@c AS binary(2)), @j = @j + 1
 END

 SELECT @cv1 = @cv0, @i = @i + 1
 END

 RETURN @c
END

(Funzione sviluppata da Joseph Gama)

Utilizzo:

select
 dbo.edit_distance('Fuzzy String Match','fuzzy string match'),
 dbo.edit_distance('fuzzy','fuzy'),
 dbo.edit_distance('Fuzzy String Match','fuzy string match'),
 dbo.edit_distance('levenshtein distance sql','levenshtein sql server'),
 dbo.edit_distance('distance','server')

L'algoritmo restituisce semplicemente il conteggio stpe per cambiare una stringa in un'altra sostituendo un carattere diverso in un unico passaggio


Questo purtroppo non copre il caso in cui una stringa è vuota
Codeman

2

Stavo cercando un esempio di codice anche per l'algoritmo di Levenshtein ed ero felice di trovarlo qui. Ovviamente volevo capire come funziona l'algoritmo e stavo giocando un po 'con uno degli esempi sopra su cui stavo giocando un po' che è stato pubblicato da Veve . Per capire meglio il codice ho creato un EXCEL con Matrix.

distanza per FUZZY rispetto a FUZY

Le immagini dicono più di 1000 parole.

Con questo EXCEL ho scoperto che c'era il potenziale per un'ulteriore ottimizzazione delle prestazioni. Non è necessario calcolare tutti i valori nell'area rossa in alto a destra. Il valore di ogni globulo rosso risulta nel valore della cella sinistra più 1. Questo perché, la seconda stringa sarà sempre più lunga in quell'area rispetto alla prima, il che aumenta la distanza del valore di 1 per ogni carattere.

È possibile riflettere ciò utilizzando l'istruzione IF @j <= @i e aumentando il valore di @i prima di questa istruzione.

CREATE FUNCTION [dbo].[f_LevenshteinDistance](@s1 nvarchar(3999), @s2 nvarchar(3999))
    RETURNS int
    AS
    BEGIN
       DECLARE @s1_len  int;
       DECLARE @s2_len  int;
       DECLARE @i       int;
       DECLARE @j       int;
       DECLARE @s1_char nchar;
       DECLARE @c       int;
       DECLARE @c_temp  int;
       DECLARE @cv0     varbinary(8000);
       DECLARE @cv1     varbinary(8000);

       SELECT
          @s1_len = LEN(@s1),
          @s2_len = LEN(@s2),
          @cv1    = 0x0000  ,
          @j      = 1       , 
          @i      = 1       , 
          @c      = 0

       WHILE @j <= @s2_len
          SELECT @cv1 = @cv1 + CAST(@j AS binary(2)), @j = @j + 1;

          WHILE @i <= @s1_len
             BEGIN
                SELECT
                   @s1_char = SUBSTRING(@s1, @i, 1),
                   @c       = @i                   ,
                   @cv0     = CAST(@i AS binary(2)),
                   @j       = 1;

                SET @i = @i + 1;

                WHILE @j <= @s2_len
                   BEGIN
                      SET @c = @c + 1;

                      IF @j <= @i 
                         BEGIN
                            SET @c_temp = CAST(SUBSTRING(@cv1, @j + @j - 1, 2) AS int) + CASE WHEN @s1_char = SUBSTRING(@s2, @j, 1) THEN 0 ELSE 1 END;
                            IF @c > @c_temp SET @c = @c_temp
                            SET @c_temp = CAST(SUBSTRING(@cv1, @j + @j + 1, 2) AS int) + 1;
                            IF @c > @c_temp SET @c = @c_temp;
                         END;
                      SELECT @cv0 = @cv0 + CAST(@c AS binary(2)), @j = @j + 1;
                   END;
                SET @cv1 = @cv0;
          END;
       RETURN @c;
    END;

Come scritto, questo non darà sempre i risultati corretti. Ad esempio, gli ingressi ('jane', 'jeanne')restituiranno una distanza di 3, quando la distanza dovrebbe essere 2. Per correggere questo codice aggiuntivo dovrebbe essere aggiunto che scambia @s1e @s2se @s1ha una lunghezza inferiore a @s2.
accetta - fatto con SOverflow il

2

In TSQL il modo migliore e più veloce per confrontare due elementi sono le istruzioni SELECT che uniscono tabelle su colonne indicizzate. Quindi è così che suggerisco di implementare la distanza di editing se vuoi beneficiare dei vantaggi di un motore RDBMS. Anche i cicli TSQL funzioneranno, ma i calcoli della distanza Levenstein saranno più veloci in altri linguaggi rispetto a TSQL per confronti di grandi volumi.

Ho implementato la distanza di modifica in diversi sistemi utilizzando serie di join su tabelle temporanee progettate solo a tale scopo. Richiede alcuni passaggi di pre-elaborazione pesanti - la preparazione delle tabelle temporanee - ma funziona molto bene con un gran numero di confronti.

In poche parole: la pre-elaborazione consiste nel creare, popolare e indicizzare le tabelle temporanee. Il primo contiene gli ID di riferimento, una colonna di una lettera e una colonna charindex. Questa tabella viene popolata eseguendo una serie di query di inserimento che suddividono ogni parola in lettere (utilizzando SELEZIONA SUBSTRING) per creare tante righe quante sono le parole nell'elenco di origine (lo so, sono molte righe ma il server SQL può gestire miliardi di righe). Quindi crea una seconda tabella con una colonna di 2 lettere, un'altra tabella con una colonna di 3 lettere, ecc. Il risultato finale è una serie di tabelle che contengono ID di riferimento e sottostringhe di ciascuna parola, nonché il riferimento della loro posizione nella parola.

Una volta fatto ciò, l'intero gioco consiste nel duplicare queste tabelle e unirle contro il loro duplicato in una query di selezione GROUP BY che conta il numero di corrispondenze. Questo crea una serie di misure per ogni possibile coppia di parole, che vengono poi riaggregate in una singola distanza di Levenstein per coppia di parole.

Tecnicamente questo è molto diverso dalla maggior parte delle altre implementazioni della distanza di Levenstein (o delle sue varianti), quindi è necessario comprendere a fondo come funziona la distanza di Levenstein e perché è stata progettata così com'è. Esamina anche le alternative perché con quel metodo ti ritroverai con una serie di metriche sottostanti che possono aiutare a calcolare molte varianti della distanza di modifica allo stesso tempo, fornendoti interessanti potenziali miglioramenti di apprendimento automatico.

Altro punto già citato dalle risposte precedenti in questa pagina: prova a preelaborare il più possibile per eliminare le coppie che non richiedono la misurazione della distanza. Ad esempio una coppia di due parole che non hanno una sola lettera in comune dovrebbe essere esclusa, perché la distanza di modifica può essere ricavata dalla lunghezza delle stringhe. Oppure non misurare la distanza tra due copie della stessa parola, poiché è 0 per natura. Oppure rimuovi i duplicati prima di eseguire la misurazione, se l'elenco di parole proviene da un testo lungo è probabile che le stesse parole appaiano più di una volta, quindi misurare la distanza solo una volta farà risparmiare tempo di elaborazione, ecc.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.