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