Come deve corrispondere un app store matchmaking per ciascun utente?

Non memorizzerei le corrispondenze.

Invece, determinerei "le caratteristiche che contano" e ho un campo di bit per ognuna. Ad esempio, potresti decidere "maschio o meno", quindi hai un bitfield per questo, e se la prima voce è per un maschio, imposti bit0, e se la seconda voce è per un maschio, imposti bit1, e così via . Quindi potresti decidere anche "oltre 40", quindi crei un altro bitfield per quello, e se la prima voce è per qualcuno sopra i 40, imposti bit0, e se la seconda è per qualcuno sopra i 40, imposti bit1, ecc.

Ora se vuoi cercare "maschi sopra i 40" ottieni il bitfield per "maschio" e il bitfield per "over 40" e tu E loro; dandoti un bitfield che rappresenta "i maschi oltre i 40".

Se fatto correttamente; un laptop economico dovrebbe essere in grado di gestire milioni di partite al secondo.

In realtà ho creato un sito di "appuntamenti" qualche tempo fa con un algoritmo di corrispondenza simile. Quello che ho imparato dalla costruzione di quel sito:

• Dovrai memorizzare nella cache i risultati della tua corrispondenza
• Riduci il tuo problema assicurandoti di tenere conto dell'orientamento sessuale. Ad esempio sarebbe una perdita di tempo per l'utente essere abbinato a un genere a cui non sono interessati.
• Dai la priorità ai calcoli delle corrispondenze che si adattano strettamente all'interno delle preferenze dell'utente (fascia d'età, religione, distanza dall'utente, ecc.). Assicurati anche di controllare le preferenze in entrambi i modi (UtenteA - > UtenteB e UtenteB < - UtenteA). L'Utente A potrebbe non interessarsi alla religione ma all'Utente B potrebbe interessare molto.

In sostanza si lavora per ridurre il problema impostato, quindi dare la priorità al proprio lavoro. In questo modo non passi molto tempo a calcolare un milione di partite per UserA mentre altri 10 utenti non hanno ancora calcolato alcuna corrispondenza.

Abbiamo fatto una sorta di round robin in cui dovevamo calcolare un certo numero di partite per ciascun utente prima di passare a quello successivo. Questo era davvero necessario solo durante il primo mese in cui il sito è stato bombardato da persone che si sono iscritte.

Speriamo che questo ti aiuti.

A seconda del tipo di partite di cui stiamo parlando, potresti essere in grado di registrare quali partite sono state fatte e con quali criteri. In questo caso, potrebbe essere utile un record intermedio per queste corrispondenze.

Specialmente se le proprietà su cui agisce l'algoritmo di matching possono cambiare, potrebbe essere impossibile ottenere un risultato riproducibile.

Vorrei andare con la memorizzazione delle partite. Puoi quindi anche registrare altre informazioni, ad esempio se gli utenti corrispondenti sono d'accordo con la corrispondenza, il che ti aiuterà a migliorare la corrispondenza.

Devi elaborare con attenzione come vengono create le corrispondenze prima di decidere come memorizzarle. Quando saprai come vengono create esattamente le partite, le domande sullo storage saranno più facili e più ovvie da gestire. Aspettatevi una combinazione di vari approcci da utilizzare:

1. In viaggio. Modifica di un insieme di regole di marketing (test A / B, campagne di promozione) che definiscono un insieme di [non] corrispondenze in base agli attributi dell'utente, al momento, al dispositivo dell'utente, agli ordini precedenti, ecc.
2. Off-line. Algoritmi di punteggio in esecuzione una volta ogni ora / giorno / mese e produzione di corrispondenze per utente / gruppo di marketing.

In genere è preferibile calcolare in movimento per consentire la massima flessibilità. E solo quando si verifica un problema di prestazioni sposta una parte del calcolo nell'algoritmo off-line.

Ricorda che oltre ad avere solo un elenco di corrispondenze per utente, spesso hai bisogno di una sorta di priorità tra loro.