Ну я думаю его можно сделать, например чтобы сравнить скорость MySQL с hadoop на этой задаче. Одна из проблем заключается в том что оно тоже может будет исполняться слишком долго и таким образом нельзя будет показать что оно вообще работает (с другой стороны, вряд ли больше нескольких часов для подпоследовательностей длиной 9).

И SQL очень непрактичен для таких вещей:
1. Даже переделать мои запросы чтобы они принимали и пробел и подчёркивание в качестве разделителей уже проблема
2. Как-то сигнализировать, что встретились входные данные больше 20 элементов - тоже
3. Если у perl кончится память, то он просто остановится - тоже неприятно, но хотя бы можно заметить. А MySQL вероятно молча продолжит выполнение, только намного медленнее.


Просмотрел сейчас топик "Как отсортировать 1 миллиард записей?" :) Может вам вообще лучше вернуться к тому решению когда была эта большая таблица в которой надо было найти дубликаты (для этого её не обязательно сортировать). C помощью group_concat() и group by ... having count(*) > 1 как в моих запросах. Проблема в том что для этого требуется память. Если бы там было мало различных значений - то памяти нужно немного. А если там почти все записи - разные, то их все желательно разместить в памяти чтобы была максимальная скорость поиска дупликатов. Память для этого в MySQL выделяется примерно так:



64 гигабайт наверное должно хватить для вашего случая (но нужно экспериментировать, я в MySQL такого не пробовал по вышеуказанным причинам).

Ну это сильно зависит от данных. Если у них грубо говоря энтропия низкая (много повторений одних и тех же значений) - то всё и прекрасно пройдёт. А если, например, менеджер может потом подсунуть этой же программе хаотические данные чтобы показать что она тормозит и не работает - то что тут сделаешь?



Вообще, есть конечно идея как это всё ускорить. Но да, пока не будет большей определённости и меньшей загадочности зачем это всё нужно и какая природа у входных данных, пожалуй забью её проверять.