Сообщение Полнотекстовый поиск - как выбрать, не проверяя? от 24.07.2021 10:51
Изменено 24.07.2021 10:52 Shmj
Полнотекстовый поиск - как выбрать, не проверяя?
Такой вопрос. Допустим вам нужен полнотекстовый поиск по некому списку сообщений. Если этих сообщений, к примеру, 150 тыс. и общий их объем данных около 150 Мб — то это говно-вопрос, по сути, можно просто тупо искать без всякой индексации, загрузив единожды все это дело в ОЗУ. Будет быстро.
Просто тупой поиск на моем старом ноуте — 17 миллисекунд. А что такое 120 МБ памяти по нашим временам? Да это пустое место, которым можно пренебречь.
Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 120 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?
Скрытый текст | |
Вывод: 76800000 17 | |
Просто тупой поиск на моем старом ноуте — 17 миллисекунд. А что такое 120 МБ памяти по нашим временам? Да это пустое место, которым можно пренебречь.
Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 120 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?
Полнотекстовый поиск - как выбрать, не проверяя?
Такой вопрос. Допустим вам нужен полнотекстовый поиск по некому списку сообщений. Если этих сообщений, к примеру, 150 тыс. и общий их объем данных около 150 Мб — то это говно-вопрос, по сути, можно просто тупо искать без всякой индексации, загрузив единожды все это дело в ОЗУ. Будет быстро.
Просто тупой поиск на моем старом ноуте — 17 миллисекунд. А что такое 150 МБ памяти по нашим временам? Да это пустое место, которым можно пренебречь.
Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 150 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?
Скрытый текст | |
Вывод: 76800000 17 | |
Просто тупой поиск на моем старом ноуте — 17 миллисекунд. А что такое 150 МБ памяти по нашим временам? Да это пустое место, которым можно пренебречь.
Ок. Как сделать дешевле? Или если данных мало, несколько сотен мегабайт — то самое тупое решение будет ничем не хуже промышленного?
Берем СУБД бесплатную и популярную. Номер 1 сейчас — это postgre (ранее была MySQL) — кто мы такие, чтобы противиться сообществу. Там есть полнотекстовый поиск из коробки. Загружаем эти же 150 Мб. текста, разбив на порции. Но почему-то получилось медленее, видимо связано с тем, что хранится на диске все это дело и пока данных мало, то смысла в СУБД нет (или типа выбрать опцию, чтобы не загружала на диск а держала в памяти данные этой таблицы).
Далее, еще все юзают Elastic Search. Тоже нужно ставить и проверять как поведет себя именно с твоим количеством данных.
Ну и вопрос. Можно ли как-то сделать выбор не проверяя все самому? То есть какая-то сводная таблица с результатами тестов и пр. — есть где-нибудь?