М
ладно, всем хорошей недели, если не найду до пятницы - опубликуюсь сюда
Size: a a a
2020 January 27
AB
Типа Московсое руби-сообщество, Питерское сообщество и т.д.
Всем привет. В Алматы, Кз не знаете случайно?
MS
@rubyist должен знть
AB
Спасибо!)
2020 January 29
ЯК
Кто-нибудь подскажет группу PHPшников бишкека?
ЯК
Если такая существует вообще
DS
на скользкую дорожку встаете =)
KO
Ярослав Коробейников
Кто-нибудь подскажет группу PHPшников бишкека?
ЯК
AK
Добрый вечер,
[Sphinx, Solr, Elastic..]
Вопрос 1: как лучше и чем лучше сделать полнотекстовый поиск по разным таблицам за 1 раз с объединением?
Вопрос 2: как называется это, чтобы погуглить?
Например, такая задача:
[Sphinx, Solr, Elastic..]
Вопрос 1: как лучше и чем лучше сделать полнотекстовый поиск по разным таблицам за 1 раз с объединением?
Вопрос 2: как называется это, чтобы погуглить?
Например, такая задача:
AK
AK
Т.е. нужно из БД (из N таблиц) собрать все email-ы и имена пользователей, и потом сделать autocomplete с неточным поиском.
Я вижу реализацию подобным образом (может быть я не прав)
Я вижу реализацию подобным образом (может быть я не прав)
AK
AK
Я понимаю, что конкретно в этом случае, можно написать 1 sql запрос с объединением результатов, но сводные статистические-таблицы позволили бы не делать массивных выборок и ускорить получение данных.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
KO
Я понимаю, что конкретно в этом случае, можно написать 1 sql запрос с объединением результатов, но сводные статистические-таблицы позволили бы не делать массивных выборок и ускорить получение данных.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
searchkick / elasticsearch смотрели?
RK
Я понимаю, что конкретно в этом случае, можно написать 1 sql запрос с объединением результатов, но сводные статистические-таблицы позволили бы не делать массивных выборок и ускорить получение данных.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
Просмотрев требования к RAM, я пошел смотреть в сторону https://sphinxsearch.com с его враппером для руби ThinkingSphinx.
Что смутило:
- как я понял, ThinkingSphinx навязывает парадигму, что индекс должен строиться относительно 1й activerecord-таблицы.
Т.е. индексатор потом пройдет по всем записям из таблицы result_table и по идее заиндексирует их.
Значит, предварительно мне нужно в эту таблицу данных самому сгенерировать.
Мне же кажется чище было бы сохранить эти данные на стороне Sphinx, т.к. он в любом случае делает индекс, почему бы в этот момент не стротить сразу же И данные для этого индекса?
- на стороне самого Sphinx вроде как есть поддержка realtime index, которые можно было бы обновлять в режиме per-record, но поддержка со стороны ThinkingSphinx я так понимаю еще кривая (как я например удалю индекс, который больше не актуален? https://freelancing-gods.com/2013/07/22/rewriting-thinking-sphinx-introducing-realtime-indices.html)
Ну вот такая каша в голове, просьба пнуть куда-нибудь в правильную сторону.
у постгря есть свой FTS ну и подобное на эластике делается обычно
2020 January 30
KO
https://www.rwpod.com/posts/2020/01/25/cafe-011.html
интересная инфа о core команде руби и их японских особенностях. а также затрагивают тему "умирает ли руби?"
интересная инфа о core команде руби и их японских особенностях. а также затрагивают тему "умирает ли руби?"
