Я сделал два предположения для этого эффективного решения:
- Существует BLOB-эквивалент строки или мы можем обработать его как двоичный файл
- Мы можем сохранить смещение или указатель на начало каждой строки.
На основании этих предположений решение:
1. прочитайте строку, сохраните длину в hashmap как ключ, чтобы у нас была более легкая hashmap. Сохраните список как запись в hashmap для всех строк, длина которых указана в ключе. Построение этой хэш-карты - это O (n).
При сопоставлении смещений для каждой строки в хэш-карте сравните двоичные объекты со всеми существующими записями в списке строк (смещений) для этой длины ключа, за исключением записи -1 в качестве смещения. Если найден дубликат, удалите обе строки и сохраните смещение - 1 в этих местах в списке.
Итак, рассмотрим сложность и использование памяти:
Память Hashmap, сложность пространства = O (n), где n - количество строк
Сложность времени - если нет дубликатов, но все строки одинаковой длины, учитывая длину каждой строки = m, рассмотрим количество строк = n, тогда это будет O (n). Поскольку мы предполагаем, что можем сравнивать BLOB-объекты, значение m не имеет значения.
Это был худший случай.
В других случаях мы экономим на сравнениях, хотя у нас будет немного дополнительного места, необходимого в hashmap.
Кроме того, мы можем использовать mapreduce на стороне сервера, чтобы разделить набор и объединить результаты позже. И используя длину или начало строки в качестве ключа сопоставления.