MySQL хранится рутина против MySQL-альтернативы?

Question

MySQL хранится рутина против MySQL-альтернативы?

0

Мы используем базу данных mysql с 150 000 записей (имен). Наши поиски в поле "имена" выполняются с помощью функции автозаполнения в php. У нас есть таблица, индексированная, но все еще чувствую, что поиск немного вялый (несколько полных секунд против чего-то вроде Google Finance с почти мгновенным ответом). Мы придумали w/2 возможности, но хотели получить больше информации:

Можем ли мы создать кучу (много тысяч или более) хранимых процедур для ускорения поиска или создадим, что многие хранимые процедуры завершают db?
Есть ли более быстрая альтернатива mysql для операторов "select" (скорость при вставке и обновлении строк не слишком важна, поэтому мы можем принести в жертву, если это необходимо). Я смутно слышал о BigTable и других, которые не поддерживают инструкции JOIN.... нам нужны операторы JOIN для некоторых наших других запросов, которые мы делаем.

спасибо

Marissa Levy 18 янв. 2011, в 01:53

Источник

0

Стоп. Вы пробовали dev.mysql.com/doc/refman/5.1/en/optimization.html ? Обычно дает фантастические результаты, особенно при первом использовании.
Osw 18 янв. 2011, в 01:04
0

Я буду читать о кэшировании. Есть ли хорошая статья (или видео), в которой сравниваются сильные и слабые стороны каждой из основных баз данных (например, mysql против oracle против cassandra и т. Д.)? Прежде чем углубляться в mysql, я хочу убедиться, что у меня есть подходящая d-база
Brent 18 янв. 2011, в 01:20
1

Подождите, select name from names where name like 'foo%' limit 10 занимает секунды ?! Это не должно Это простая операция с индексами. Вы уверены, что у вас есть индексы? Пожалуйста, приведите пример запроса вместе с выводом explain .
derobert 18 янв. 2011, в 06:22

Показать ещё 1 комментарий

Теги:

mysql

database

cassandra

oracle

bigtable

3 ответа

0

Да, вам нужно истечь кеш, если вы измените данные, но, как вы сказали, это не так, что вы можете даже сделать это на полуавтоматической основе и не беспокоиться об этом, если это необходимо. Вы должны проверить эту статью в MySQL.com, а также, возможно, изучить механизм хранения MEMORY (извините, новый и не может размещать более одного гиперссылка на сообщение?!), которая требует немного кодирования для использования, но может быть чрезвычайно эффективной.

Какое фактическое время запроса (vs page time)? На достаточно современном сервере, который не загружен в ад, MySQL должен иметь возможность делать запрос автозаполнения на 150 тыс. Строк намного, намного, быстрее, чем две секунды. Отсутствуют некоторые индексы?

tkrajcar 18 янв. 2011, в 00:09

0

Вам необходимо кэшировать информацию в памяти, чтобы избежать повторных вызовов в базу данных.

Bnjmn 17 янв. 2011, в 22:56

0

не замедлили бы нас тысячи и тысячи операторов select в кеше? Закрывающий пример, который у меня есть, - это функция автопоиска Google Finance .... будет ли практично хранить все вызовы тикеров (и частичных тикеров) в кеше или они, вероятно, делают что-то еще?
Brent 18 янв. 2011, в 01:03
0

также, что происходит, когда базовые данные изменяются в таблице ... продолжает ли кэш возвращать старые данные?
Brent 18 янв. 2011, в 01:06
0

пара сотен тысяч записей не является проблемой для кэша.
Gary Myers 18 янв. 2011, в 02:24
0

нет, я имею в виду пару сотен тысяч кэшированных запросов. У меня миллионы записей
Brent 23 янв. 2011, в 17:04

Показать ещё 2 комментария

Ещё вопросы

Стоп. Вы пробовали dev.mysql.com/doc/refman/5.1/en/optimization.html ? Обычно дает фантастические результаты, особенно при первом использовании.
Я буду читать о кэшировании. Есть ли хорошая статья (или видео), в которой сравниваются сильные и слабые стороны каждой из основных баз данных (например, mysql против oracle против cassandra и т. Д.)? Прежде чем углубляться в mysql, я хочу убедиться, что у меня есть подходящая d-база
Подождите, select name from names where name like 'foo%' limit 10 занимает секунды ?! Это не должно Это простая операция с индексами. Вы уверены, что у вас есть индексы? Пожалуйста, приведите пример запроса вместе с выводом explain .
не замедлили бы нас тысячи и тысячи операторов select в кеше? Закрывающий пример, который у меня есть, - это функция автопоиска Google Finance .... будет ли практично хранить все вызовы тикеров (и частичных тикеров) в кеше или они, вероятно, делают что-то еще?
также, что происходит, когда базовые данные изменяются в таблице ... продолжает ли кэш возвращать старые данные?
пара сотен тысяч записей не является проблемой для кэша.
нет, я имею в виду пару сотен тысяч кэшированных запросов. У меня миллионы записей

Osw · Accepted Answer · 2011-01-18T07-15-00.000Z

Забудьте о хранимых процедурах. Они не помогут вам.
Mysql - хороший выбор, который часто считается самой быстрой СУБД. И нет необходимости искать "более быструю альтернативу выбору оператора".

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