Comments 37
Хоть тресни, не могу понять, при чем тут файлы, блокировки на чтение и прочие радости. Ваши данные целиком помещаются в оперативную память, а дальше уже дело техники и удобной структуры. В MySQL тоже можно соответствующим образом подкрутить конфигурацию, так что сомневаюсь я насчет такой разницы в производительности.
Для ноды логичнее их в память закинуть. Для PHP поскольку потоков сразу несколько и нужно при каждом запросе их грузить в память, лучше закинуть на диск. В идеале на виртуальный (который в памяти находится). Всякие мем-кешед предназначены не для этого.
Тоже не понял, о чём статья. Описываются данные, но даже не указан их объём в байтах (или я не нашёл), не указаны настройки mysql, может быть, там индексы в память не влазят (не говоря уже о данных). Если структура простая (id -> word), то можно и в мем-кешеде хранить, почему бы и нет.
Можно написать отдельный демон, который бы хранил все в памяти, а потоки соединялись бы с ним через UNIX-сокет.
Либо просто использовать mmap()/mlock(), отобразив файл целиком в оперативную память, и дисковый кэш линукса сделает за вас всю работу. Тут, правда, скорее всего придется модуль на C для PHP городить.
Так бы у вас получилась цифра ближе к 1.000.000 запросов в секунду вместо 50.000.
Либо просто использовать mmap()/mlock(), отобразив файл целиком в оперативную память, и дисковый кэш линукса сделает за вас всю работу. Тут, правда, скорее всего придется модуль на C для PHP городить.
Так бы у вас получилась цифра ближе к 1.000.000 запросов в секунду вместо 50.000.
Ну расшарить данные между _потоками_ вообще не должно быть проблемы. Между процессами в принципе тоже, хоть та же SharedMemory.
Еще странно, что «виртуальный диск который хранится в памяти(!)» вам подходит, а «всякий мем-кешед» не угодил.
А в последних версиях mariadb, насколько я помню, целый ворох движков в том числе in memory
Про дисковый кэш вам уже тоже сказали.
Статья, в самом деле, вызывает некоторое недоумение. imho.
Еще странно, что «виртуальный диск который хранится в памяти(!)» вам подходит, а «всякий мем-кешед» не угодил.
А в последних версиях mariadb, насколько я помню, целый ворох движков в том числе in memory
Про дисковый кэш вам уже тоже сказали.
Статья, в самом деле, вызывает некоторое недоумение. imho.
Ждем следующей статьи: «Быстрая морфология или оперативка против файлов на диске», с тысячекратной разницей…
Так если вы всё равно пришли к хэшу, зачем CRC? Есть более быстрые и простые реализации хэша для строк. А что касается базы данных, есть ощущение, что с индексом вы что-то просто напутали. Запускайте профилировщик запроса, пробуйте хэш-индексы и innodb, которая не блокирует всю таблицу. А ещё при условии того что это копеечная (с точки зрения памяти сервера) база, есть смысл поиграться с in-memory table.
P.S. База маленькая, так что если написать грамотную реализацию на С++ с использованием Perfect Hash (гуглить gpref) и поднять всё это как демон — будет вообще ураган.
P.S. База маленькая, так что если написать грамотную реализацию на С++ с использованием Perfect Hash (гуглить gpref) и поднять всё это как демон — будет вообще ураган.
CRC короче. CRC позволяет экономить место и поиск чуть быстрее. Во вторых у разных словоформ разная длина от 1 до 35 символов. Поэтому, если не использовать CRC32 нужно создавать еще один файл, в котором находятся позиция словоформы во втором файле. Это дополнительный код, место и задержки.
Вероятность ошибки всегда есть. Как минимум из-за того, что появляются новые слова неологизмы и их нет в базе. CRC32 увеличивает вероятность ошибки незначительно.
>>Запускайте профилировщик запроса, пробуйте хэш-индексы и innodb, которая не блокирует всю таблицу.
Я пробовал почти все. Блокировка все равно. У нас только чтение.
Вероятность ошибки всегда есть. Как минимум из-за того, что появляются новые слова неологизмы и их нет в базе. CRC32 увеличивает вероятность ошибки незначительно.
>>Запускайте профилировщик запроса, пробуйте хэш-индексы и innodb, которая не блокирует всю таблицу.
Я пробовал почти все. Блокировка все равно. У нас только чтение.
P.S. База маленькая, так что если написать грамотную реализацию на С++ с использованием Perfect Hash (гуглить gpref) и поднять всё это как демон — будет вообще ураган.
Мне пока скорости хватает. В этой статье 1.5 к слов, т.е. он может 33 таких статьи разбирать в секунду. Без кеширования, на обычном НМДЖ.
Я бы так не был уверен. При первом же запросе ваша база ложится в кэш ОСи и при последующих запросах всё крутится в оперативной памяти, а то и в L2. Т.е. вы по сути меряете производительность не диска, а оперативной памяти. Кэширование есть всегда, просто оно прозрачное. Более того, оно может сыграть злую шутку с тем, кто гоняет синтетические бенчмарки.
Я это проверял, скорость при первом обращении не сильно ниже, чем при последующих.
В кеш ОС попадает, если файл целиком читать, а если кусочками, то он может лечь в кеш диска. Но он весит 50 мб, а у меня кеш на диске 8 мб. Т.е. полностью он не может лечь на диск.
В кеш ОС попадает, если файл целиком читать, а если кусочками, то он может лечь в кеш диска. Но он весит 50 мб, а у меня кеш на диске 8 мб. Т.е. полностью он не может лечь на диск.
Вы путаете кэш VFS (в случае linux) с кэшем контроллера диска. Первый кэш имеет размер незанятой RAM (у linux) и обойти его без явного на то указания у вас не получится.
И это
>В кеш ОС попадает, если файл целиком читать, а если кусочками, то он может лечь в кеш диска.
тоже не так, вы ошибаетесь. Прочитать можно здесь
И это
>В кеш ОС попадает, если файл целиком читать, а если кусочками, то он может лечь в кеш диска.
тоже не так, вы ошибаетесь. Прочитать можно здесь
Кстати, если взять длину массива кратной двойке:
2^22
4194304
можно будет просто зациклить массива через побитовое И. (с) Кнут, том третий по-моему. Хотя боюсь тут уже упирается в переключение контекста из-за системных вызовов.
2^22
4194304
можно будет просто зациклить массива через побитовое И. (с) Кнут, том третий по-моему. Хотя боюсь тут уже упирается в переключение контекста из-за системных вызовов.
> Поскольку словоформ около 2уъ миллионов, а 2^32 = 4 млрд, мы получаем вероятность коллизии 0.05%.
Почитайте ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B4%D0%BD%D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Почитайте ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B4%D0%BD%D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Я это знаю. В этом случае не влияет на вероятность.
Почему не влияет? Если по табличке посмотреть, то вероятность коллизии 75% при кол-во записей больше 10000
Почему парадокс дней рождения возникает? Поскольку если в группе N элементов, у них N * (N-1) комбинаций и вероятность того, что в одной из комбинаций выстрелит событие возрастает. Здесь нет пар.
Это покажет вероятность возникновения хотя бы одной коллизии (пары). По данной в вики формуле получается 99%. Оно так и есть — у автора там вообще более 1к коллизий, что сильно покрывает формулировку «хотя бы одна пара». Был бы хэш md5 — совсем другой вопрос, вероятность даже хотя бы одной пары будет невелика: ~5.9e-29.
UPD: вы всех сбили с мысли. Автором имелась в виду вероятность коллизии, когда один из элементов пары фиксирован. Такая вероятность и правда составляет 5 тысячных.
А вы смотрели phpmorphy? Он использует базу слов aot и работает без базы
В MySQL есть движок (тип таблиц) MEMORY специально для вашего случая. Данные размещаются в памяти, поиск идет по хешу. Попробуйте.
Особо не вникая в статью — да, mysql не панацея. Сам убеждался, что если его тулить куда ни попадя, то можно поиметь много проблем с нехваткой ресурсов.
Скажем так — у mysql своя область применения, и думать что она охватыват все базы — ошибка.
В моем случае делать самописную базу под свои специфические нужды я стал только когда довольно много времени потратил на mysql и rrd, но не добился приемлемого результата.
Скажем так — у mysql своя область применения, и думать что она охватыват все базы — ошибка.
В моем случае делать самописную базу под свои специфические нужды я стал только когда довольно много времени потратил на mysql и rrd, но не добился приемлемого результата.
не только AOT имеет свободную базу, есть еще nlp.lsi.upc.edu/freeling/
А mystem от самого яндекса пробовали? У них есть контекстное снятие омонимии.
А как на счет memcached или redis. Или, например, heap-таблиц в mysql?
Ваш выигрыш за счет помещения часто-считываемых файлов в кеш ssd. А на современных ОС в оперативную память.
Ваш выигрыш за счет помещения часто-считываемых файлов в кеш ssd. А на современных ОС в оперативную память.
Какая же у вас каша в голове!
Всем «теоретикам» на заметку, всем кто советовал Memory в MySQL :)
Так получилось, что у меня уже лет 8 валяется на сервере табличка со всеми словоформами. И на эксперемент мне пришлось потратить минут 10.
Сервер 2 x Xeon 5460, памяти валом. Тестировал на «Войне и Мир», это что-то около 390к слов.
Перенес словоформы в HEAP хранилище (MEMORY), запустил… Перенес в InnoDB, запустил… В MyISAM, запустил…
Результаты:
Memory: 5k слов/сек
InnoDB: 4.2k слов/сек
MyISAM: 4k слов/сек
Понятно, что если бы я запустил не 1, а 10 потоков, то результат на Memory был бы около 50к/слов, но не надо забывать что это довольно мощный сервер и грузить его только этой задачкой было бы весьма глупо.
Почему такой результат, объяснить очень просто. Как ни крути, но при любом MySQL запросе есть КУЧА накладных расходов, и в данном случае, учитывая простоту самого запроса эти накладные расходы (запрос + синтан + создание курсора + возвращение данных) намного превышают время выполнения самого запроса.
Так что результат автора 50к/сек наверное стоил того, чтобы проделать описанную в посте работу.
Если кому интересно, могу и на Mongo запустить.
Так получилось, что у меня уже лет 8 валяется на сервере табличка со всеми словоформами. И на эксперемент мне пришлось потратить минут 10.
Сервер 2 x Xeon 5460, памяти валом. Тестировал на «Войне и Мир», это что-то около 390к слов.
Перенес словоформы в HEAP хранилище (MEMORY), запустил… Перенес в InnoDB, запустил… В MyISAM, запустил…
Результаты:
Memory: 5k слов/сек
InnoDB: 4.2k слов/сек
MyISAM: 4k слов/сек
Понятно, что если бы я запустил не 1, а 10 потоков, то результат на Memory был бы около 50к/слов, но не надо забывать что это довольно мощный сервер и грузить его только этой задачкой было бы весьма глупо.
Почему такой результат, объяснить очень просто. Как ни крути, но при любом MySQL запросе есть КУЧА накладных расходов, и в данном случае, учитывая простоту самого запроса эти накладные расходы (запрос + синтан + создание курсора + возвращение данных) намного превышают время выполнения самого запроса.
Так что результат автора 50к/сек наверное стоил того, чтобы проделать описанную в посте работу.
Если кому интересно, могу и на Mongo запустить.
Хорошо бы выложить это в open source.
Разработанный движок не позволяет склонять фразу?
Разработанный движок не позволяет склонять фразу?
>2014
>считывающей головке
Плюс еще можно заюзать memory-mapped file и ускориться еще раз в сто.
Кажется, что вы только что изобрели транзакции в БД.
>считывающей головке
Плюс еще можно заюзать memory-mapped file и ускориться еще раз в сто.
Если тормозит база записи, то, в некоторых случаях, быстрее будет записывать что-то вроде лога с изменениями, а при синхронизации переводить этот лог в нормальную базу
Кажется, что вы только что изобрели транзакции в БД.
Sign up to leave a comment.
Быстрая морфология или файлы против MySQL