Перевод по словарю

Тема в разделе "PHP", создана пользователем rus-us, 23 фев 2009.

Статус темы:
Закрыта.
Модераторы: latteo
  1. rus-us

    rus-us

    Регистр.:
    8 сен 2007
    Сообщения:
    153
    Симпатии:
    72
    Задача:
    сделать переводчик с англ. на рус. по словарю
    словарь сейчас хранится в текстовых файлах (максимальный файл около 6000 строк. 900кб)
    в таком виде:
    Как лучше организовать поиск перевода для 1 слова, без учета регистра?

    Сейчас я просто загружаю файл через file_get_contents() и регуляркой нахожу нужный кусок текста.
    Интерисует самый оптимальный вариант.
     
  2. nulled-dc

    nulled-dc Создатель

    Регистр.:
    30 янв 2009
    Сообщения:
    11
    Симпатии:
    3
    Вообще, лучше всего через mysql.
    Если же использовать БД не представляется возможным, и слово требуется только одно, то я бы попробовал, исходя из предположения что словарь упорядочен по алфавиту, что-то типа того (кидаю примерный алгоритм, а не код:(

    1. хранил количество слов в отдельном файле, пусть это будет число t
    2. сделал некий коэффициент k = t / 25 - это будет среднее количество слов для одной английской буквы.
    3. с целью поиска слова на букву с номером w считывал файл начиная с позиции pos = (w - 1) * k
    4. дальше считывал бы либо на строку назад, либо на строку вперед, в зависимости от того, в какую сторону промазал. и так, пока не поймаешь слово.
    оптимизировать такой алгоритм можно бесконечно. начиная от таблицы коэффициентов для разных букв алфавита вместо k (в пункте 2), заканчивая более интелектуальной работой пункта 4 (переход не на 1 строку назад/вперед, а сразу на несколько, в зависимости от того как сильно промазал).

    еще более быстрый вариант - создать скриптик, который по словарю сделает трехуровневую файловую структуру вида:
    /a/
    /a/ab/
    /a/ab/abricos.txt
    /a/ab/absolute.txt
    и т.д.
    где в текстовых файлах будет перевод. тогда перевод слова будет по обращению к файлу, если нет файла- нет и перевода.
     
  3. ewg777

    ewg777

    Регистр.:
    6 авг 2007
    Сообщения:
    763
    Симпатии:
    321
    Явное извращение!
    Просто 26 файлов (каждый файл - первая буква).
    Или sqlite ;)
     
  4. nulled-dc

    nulled-dc Создатель

    Регистр.:
    30 янв 2009
    Сообщения:
    11
    Симпатии:
    3
    Насчет явного извращения не согласен. 26 файлов вместо 1 - быстрее, но все еще очень далеко от оптимальности. И медленное построчное чтение файлов никуда не исчезло. А ведь требуется именно оптимизация по скорости работы и ресурсоемкости, если я правильно понял ТС.

    Если у кого вопросы, почему каталога 2 - потому что никогда не помешает возможность лазить по созданной куче файлов из шелла. Лучше 25 каталогов и в каждом максимум 25 подкаталогов с N файлов, чем 25 каталогов, в каждом из которых 25 * N файлов.
     
  5. serjinio

    serjinio

    Регистр.:
    10 май 2007
    Сообщения:
    439
    Симпатии:
    49
    перегоняйте однозначно в mysql..сначала немного помучаетесь..потом спасибо скажете....:)
    всего то две таблички...в нете море примеров по поиску в бд....а на многих фришных хостах есть mysql сервер...
     
  6. venetu

    venetu

    Регистр.:
    28 мар 2007
    Сообщения:
    735
    Симпатии:
    261
    Какой mysql? Какие файлы? 900кб великолепно влазит в память. Целиком.
    В виде
    'acronym' => 'акроним',
    'apple' => 'яблоко',
    и т.д.

    И "переводчик" делается через обычный str_replace(array_keys(), array_values()). Втупую и очень быстро. Причем быстро как в плане скорости работы, так и в плане собственно написания.
     
  7. rus-us

    rus-us

    Регистр.:
    8 сен 2007
    Сообщения:
    153
    Симпатии:
    72
    Я изначально разбил файлы по буквам, и потом просто загоняю файл в строку и регуляркой нахожу совпадение.
    Просто у меня сомнения насчет нагрузки.

    А вот mysql меня вполне устроит, если будет выиграш в скорости и уменьшиться нагрузка.
    Если таблица будет на 70 000 строк, mysql нормально справится?

    venetu
    А как насчет массива в 5000-6000 строк(1 файл)
    Или 70 000 если полный словарь?
     
  8. ewg777

    ewg777

    Регистр.:
    6 авг 2007
    Сообщения:
    763
    Симпатии:
    321
    А как на счёт самому проверить?

    А если флудить дальше, меня скоро забанят?
     
  9. nulled-dc

    nulled-dc Создатель

    Регистр.:
    30 янв 2009
    Сообщения:
    11
    Симпатии:
    3
    Уж лучше тогда оставить как и есть, это не оптимизация, а разбазаривание ресурсов. Если у чела будет штук 10 одновременных обращений к этому так сказать "словарю", то это уже не 900 а 9000 Кб.

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

    Добавлено через 4 минуты
    С этого и следовало начинать. Нормально он справится, даже не думай о том чтоб от него отказываться.
     
    rus-us нравится это.
  10. venetu

    venetu

    Регистр.:
    28 мар 2007
    Сообщения:
    735
    Симпатии:
    261
    И в результате для перевода коротенькой статьи в 1000 знаков оно будет делать порядка 150-200 селектов к базе. По-твоему это рациональное использование ресурсов? Или приемлемая скорость работы?

    А вот тут я вообще запутался. Словарь же не модифицируется вроде. Зачем его копировать? Один раз от памяти отожрать 900кб - никто и не пикнет. Даже если 900 метров словарь будет весить, т.е. в тысячу раз больше, чем сейчас - все равно на современных серваках с 4Gb оперативы он все еще влезет в память, и str_replace() нормально отработает. Но в 1000 раз словарь просто так не увеличишь, у него есть объективный предел кол-ва слов. А значит код этот будет работать считай с любым словарем в любом обозримом будущем. И да, это экономичней, чем загонять словарь сначала в мускул, потом мускул в ту же память, и потом дергать по одному слову.

    И не забывай, самый ценный ресурс на планете - это ТЫ.
     
Статус темы:
Закрыта.