Count(*) и память

Приветствую Вас!
Сразу два с половиной вапроса.

  1. Как в одном запросе получит результат поиска и количество найденого?
    К примеру у меня запрос type=plain k бд ‘SELECT id FROM index WHERE MATCH(‘keyword’)’ Я пытался добавить к запосу Select id, count(*) from…, но оно возвращает 1. То есть один результат. Во как. Допустим можно кончно в foreac добавить $i++ или еще один запрос, но оно очень долго считает и кажется, что это не то, что нужно…, посколь оно будет грузить сервер ненужными подсчетами итд. Есть ли такая функция и как бы это сотворить? :thinking:

  2. Настройка памяти. Допустим что есть запросы, где результатов тысч 50 и более, и запрос явно тормозит или чуть притормажывает. А тепер внимане сам вопрос: где и как подстроить память, чтобы manticore себе не в чем неотказывала? :laughing: :wink:

  3. Почему не работает полностбю сортировка? К примеру, по моим наблюдениям, ежели результатов меньше чем тысяча, то order by чевото_там asc автоматом идёт по id asc, но когда результатов больше, то работает как часы китайские(шутка) - работает как надо. Это так задумано!? В чём фишка и как это исправить?

Зарание благадорю за ваше горячее стремление помоч мне. :wink::laughing: Спосибо!

По п.1 я использую “show meta;” после запроса, получая таким образом число найденных результатов, с учётом настроенных параметров поиска (max_matches, limit и т.п.) Manticore Search Manual: Searching > Options

Спасибо! Надо будет попробовать отфильтровать и сравнить по времени с count(*) запросом. Я так понимаю, что show meta также делает дополнительный запрос куда-то … :roll_eyes: Но возможно оно быстрее будет.

А по остальному что Вы думаете?

По памяти и сортировке подсказать не могу, увы: наоборот радуюсь что Мантикора по сравнению со Сфинксом не загружает весь индекс в оперативку, а делает это по необходимости. А сортировкой попросту не пользуюсь, предпочитая порядок результатов согласно их релевантности.

Upd. также с теми задачами что доводилось сталкиваться мне - обычно 50 000 результатов - это слишком много, и желательно уточнить запрос, чтобы их остались десятки. Но это с теми задачами, что были у меня при использовании Мантикоры.

Нет, не делает. С show meta должно быть максимально быстро.

А тепер внимане сам вопрос: где и как подстроить память, чтобы manticore себе не в чем неотказывала?

Почитайте про mlock тут Manticore Search Manual: Creating an index > Local indexes > Plain and real-time index settings

  1. Почему не работает полностбю сортировка? К примеру, по моим наблюдениям, ежели результатов меньше чем тысяча, то order by чевото_там asc автоматом идёт по id asc, но когда результатов больше, то работает как часы китайские(шутка) - работает как надо. Это так задумано!? В чём фишка и как это исправить?

Неявной сортировки в последних версиях нет, если только речь не идёт о запросе с MATCH() - тогда сортируется по полнотекстовой релевантности. А если без MATCH(), то как получится. Идея такая, что если пользователю всё равно как сортировать (т.к. ORDER BY нет), то и не нужно тратить его ресурсы/время на это.

1 Like

Понятное дело… Меня не покидает мысль, что вот сегодняшний пользователь ленивый и ему нужно всё и сразу и по порядку. :rofl: К примеру, ежели он ввёл в поиск слово ‘бельё’ или ‘пиво’ то ему нужны все результаты и уточнять поиск он не собирается…- сразу вердикт - сайт г*вно - нет выбора. :rofl: … Философский вопрос - что лучше, но я всё болше склоняюсь к тому, что мне на сайте нужны не только умные… :wink::roll_eyes::laughing:

С тем, что пользователь сейчас ленивый и делать ничего не хочет я полностью согласен. Но в случае с неявной сортировкой ситуация неоднозначная, т.к. при запросе типа select * from t where <no match() here> нет уверенности, что пользователь хочет получить результаты отсортированные именно по id. Он нигде об этом не заявлял. Таким уж прям стандартом это не является. Я б скорее ожидал дефолтную сортировку по времени добавления документов, что может не совпадать с id. А делать такие результаты по умолчанию для всех - значит замедлить очень много поисковых запросов для большого количества людей, и в конечном итоге ещё и нанести вред экологии, увеличив углеродный след. На это мы пойти не можем. Хочешь отсортированное по id - добавь order by id asc/desc. Большого труда это, к счастью, не составляет.

  1. Как я понимаю - там получается, что чтобы оно работала нужно две фишки включать --iostats и --cpustats Разве оно не будет давать доп нагрузку?

  2. Спасибо.

  3. С сортировкой у меня where matches() и order by оба нужны. Первый чтобы выводил нужное, второй чтобы нужное сортировать. Они не несут одну и туже функцию.

Однако, как я уже говорил, то до тисячи результатов у меня не срабатывает order by, выше тысячи сортеруется. Вы не знаете в чём там дело может быть? :roll_eyes::thinking: У меня всё добавлено ORDER BY id DESC, тобиш самое свежое в начало…

Я с Вами полностью разделяю мысль о всём зелёном. Я тоже против лишней нагрузки -( тем более - что она мне денег стоит), не говоря уж о экологии, что конечно на порядок выше…

Нет, для того, чтоб увидеть total в show meta это не нужно.

С сортировкой у меня where matches() и order by оба нужны. Первый чтобы выводил нужное, второй чтобы нужное сортировать. Они не несут одну и туже функцию. Однако, как я уже говорил, то до тисячи результатов у меня не срабатывает order by, выше тысячи сортеруется. Вы не знаете в чём там дело может быть? :roll_eyes::thinking:

Нужны примеры запроса и ответа, показывающие то, что вы говорите. Для этого добавьте в select list (после select и перед where) weight(), а также всё, по чему вы делаете order by

  1. Понимаете, я php классом от manticore не пользуюсь и у меня просто запросы типа $db(“SELECT id FROM index WHERE MATCH(my_searh) ORDER BY dataadd asc LIMIT 500; show meta;”), так добавив там в конце show meta; запрос не возвращает total. Может я чтото не то делаю? :roll_eyes::thinking::laughing: Как оно выводится в php?

  2. Спасибо буду пробывать.
    Попробовал и нет разницы. Запрос к примеру такой же как в пункте 1. К примеру, условия для сортировки ORDER BY id desc, то есть - отношения к весу поиска не имеют от слова вообще. Однако забавно то, что при большом количестве резултатов(1т и более) оно работает и тот же запрос с меньшем количеством результатов не работает. :thinking::roll_eyes: Конечно это можно решить и другим путём, но не уж то так оно задумано и нет у вас к примеру фишки min_count_for_orderby=1000? :laughing::wink:

П.С.
Вполне допускаю мысль, что сортировка результатов до 1т. может считается трудоёмкой и не очень рациональной и ‘автор’ оставил её на усмотрение пользователя… Может так оно и лучше.

И того 1. пункт актуален.

Попробуйте делать отдельный запрос для show meta в том же connection’е.

но не уж то так оно задумано и нет у вас к примеру фишки min_count_for_orderby=1000?

Такого нет.

Да, возвращает NULL. Может ето из-за план индекса. А сеажите, пожалуйста, нету ли доступного класса для php manicore, типа - manticore.php для последней версии , то есть, одного php файла, как было когдато на sphinks?
Кажется что это то что нужно.

Есть клиент для php - GitHub - manticoresoftware/manticoresearch-php: Official PHP client for Manticore Search
Там есть метод getTotal() manticoresearch-php/searchresults.md at master · manticoresoftware/manticoresearch-php · GitHub

select * from index where … ; show meta;

ключевой момент здесь, что при использовании show meta запроса получается два (разделены точкой с запятой) “обычные” и простые коннекты через mysqli или pdo по-умолчанию не настроены для работы с multiquery и выполняют лишь один запрос. Копайте в этом направлении. Например, тут можно почитать или (быстрее) будет подсмотреть реализацию мультизапросов в каком-нибудь классе db-подключения в любимых php-фреймворках или orm.

Похоже, что так и есть. Так по сути всё одно два запроса но с одним конектом. :+1: А у Вас, Frozen, разом не затерялся класс мульти подточеный под manticore?

Дело не в методе, как подсчитать найденый резултат с лишним запросом, конектом…
Дело в коротком коде с максимум информацией и эффективностью. Потому было хорошо, когда был имено класс пхп к примеру - sphinks.php, где тоже я 90% удолял всякой всячины, чтобы оно раболо быстро и не занималось лишним подсчётам на авось пригодится… Просто, Вы поймите, я не хотел бы инсталироват кучу ненужных мне функцый и тысячи строк кода с manticore-php. К тому-же, я использую план индексы. Чтото я очкую, что это manticore-php будет допом грузить сервер и долго исполнятся. :wink::blush:

просто как пример. проще некуда, наверное: метод возвращает массив с результатами.

class ManticoreConnect{
	
	private $connect = null;

	public function __construct() {
		mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
		try {
			$this->connect = new \mysqli('127.0.0.1', '', '', '' , 9306);	
		} catch (\Exception $e) {
			throw new \Exception('Manticore connection FAILED : \'' . $e->getMessage() . '\'');
		}
		
		$this->connect->set_charset("utf8");
		$this->connect->query("SET SQL_MODE = ''");	
	}
	
	public function multiQuery($sql) {

		$multiquery = $this->connect->multi_query($sql);

		if (!$this->connect->errno) {
			$results = [];
			if ($this->connect->more_results()) {
				do {
					if ($query = $this->connect->store_result()) {
						if ($query instanceof \mysqli_result) {
							$data = array();
							while ($row = $query->fetch_assoc()) {
								$data[] = $row;
							}
							$result = new \stdClass();
							$result->num_rows = $query->num_rows;
							$result->row = isset($data[0]) ? $data[0] : array();
							$result->rows = $data;
							$query->free();
							$results[] = $result;
							if (!$this->connect->more_results()) {
								break;
							}
						}
					}
				} while ($this->connect->next_result());
			}
			return $results;
		} else {
			throw new \Exception('Query Error: ' . $this->connect->error  . '<br />Error No: ' . $this->connect->errno . '<br />' . $sql);
		}
	}
}	

не будет. оверхед от php-кода - копеечный. официальный php-клиент хорош.

или вот еще вариант

О, спасибо за наводку на на библиотеку, а то я свой Query Builder для Manticore начал писать, основанный на PDO. Официальный клиент неплох, но реализует не все возможности, которые доступны через SQL, что не удивительно, т.к. сами разработчики провозглашают девиз “SQL-first”, а php-клиент работает по http на json

Спасибо за примерчик. Можно и по сложней, ежели имеется. Типа - тут не дураки сидят (шутка) :laughing::laughing::laughing:
Значит данный класс возвращает массивы (кучу данных) и если я правильно понял, то обрабатывается этот массив с помосщу json?
Может есть у Вас пример обработки этого массива, так сказать, как отсортировать id от прочего и прочее от id…? У меня(в теории) получается с несколькими foreach, к примеру foreach(){foreach(){}}… итд. Нету ли способа обработки массива по проще и по приличнее, так сказать - обкатонова под manticore db?

П.с.
По сколь, тема интересная не только мне, то могит быть можно это ришить колегионално? Коллеги, подклучайтесь. Любая информация полезна.

Кстати, много ходят слухов, что мултиквери лехко поддаются скул инфекциям, что в рт режиме может быть не очень прекрасно… Какие мнения?

@Sergey чтоб не плодить лишних тем, спрошу тут попутно: а Manticore полностью поддерживает SphinxQL? Или есть у движка, скажем так, свой диалект, отличающийся от родительского?