| |
|
|
| | Интересует вопрос как реализовать поиск в высоконагруженом проекте.
Поиск должен быть для пользователя по множеству критериев, начиная от возраста, роста,..... и заканчивая цветом глаз.
Пока что кроме битовой маски в mysql мемори таблице ничего на ум не приходит.
Может кто то уже такое реализовывал, может какие то другие, новые технологии....? | |
| |
|
|
| |
|
|
| |
для: Filsh
(01.08.2012 в 23:57)
| | | Довольно абстрактная постановка вопроса... в MySQL очень много инструментов в том числе для высокоскоростной работы... можно кэшировать результаты запросов (которые наверняка будут регулярно повторяться), можно разносить реплицировать базу данных и под поиск выделить отдельный сервер. Возможностей очень много самых различных... | |
| |
|
|
| |
|
|
| |
для: cheops
(02.08.2012 в 07:42)
| | | Да, в том и дело что абстрактно, мне не нужно реализации, это я все сам могу сделать.
Просто у нас в текущем проекте поиск сделан по битовой маске и таблица лежит в оперативной памяти, ну и там куча серверов, репликация,.... Эта таблица у нас получается громадная и много критериев для поиска, из-за этого происходят тяжелые математические операции(просчет битов, сдвиги) и не смотря на то что все кешируется оно все равно медленно работает, хотя и выдержывает приличную нагрузку. Сейчас у меня задача сделать подобный поиск для своего проекта и меня интересуют альтернативы, может Sphinx, или еще что то? | |
| |
|
|
| |
|
|
| |
для: Filsh
(02.08.2012 в 09:00)
| | | Нет возможности разбить громадную таблицу на несколько меньшего размера? | |
| |
|
|
| |
|
|
| |
для: cheops
(02.08.2012 в 09:31)
| | | Ну в принципе можно. | |
| |
|
|
| |
|
|
| |
для: Filsh
(02.08.2012 в 19:31)
| | | Чем меньше объем таблицы, тем быстрее она обрабатывается. | |
| |
|
|
| |
|
|
| |
для: cheops
(02.08.2012 в 21:30)
| | | Если Вам еще интересно, то выбрал я Neo4j.
http://neo4j.org/
Провел на нем маленькое тестирование по скорости, а вместе с тем еще и разобрался с ним немного и хочу поделится
Это графовая база, вначале я запихнул туда около миллиона узлов и соединил их по связям пол, возраст, город и т.д.
потом я понял что это все бред, потому как возраст меняется, город тоже и перестраивать граф очень накладно и чем дальше в лес тем чаше это нужно делать. Потом я сделал типа такой структуру
Украина
|
Киев Харьков
| |
мужчина женщина мужчина женщина
| | | |
user1 user2 user3 user4 user5 user6 user7 user8
|
И у каждого юзера свойства типа возраст, цвет глаз и т.д. Засунул я туда по 50 000 пользователей на каждый пол, то есть на один город получилось 100 000
Тестировал на
i7(4 виртуальных ядра)
8 Гб оперативы
в итоге получил время выполнения поиска с критериями ~ 0.05с - 0.06с
это если в графе я конкретно указываю на каком узле искать, если говорить ему найди мне во всем городе, то это больше примерно в два раза, если в Украине - то это уже секунды. Вообщем нужно задавать поиск максимально близкий к нужной вершине.
Тест проводился без индексов и кеширования. Для моего проекта 100 000 пользователей на один город очень приличный результат и если я его смогу добиться, то там уже будут более глобальные проблемы чем производительность поиска))
По оптимизации - добавить индекс + кеширование.
Может кто то уже пробовал с Neo4j работать, буду очень рад если поделитесь опытом.
P.S. Не получается сделать красиво иллюстрацию графа, извиняйте) | |
| |
|
|
