Скорость индекса БД и кеширование

Question

У нас есть около 10K строк в таблице. Мы хотим иметь форму, в которой у нас есть выпадающий список, который содержит различные значения данного столбца в этой таблице. У нас есть индекс по рассматриваемому столбцу.

Чтобы повысить производительность, я создал небольшую кеш-таблицу, которая содержит различные значения, поэтому нам не нужно было делать select distinct field from table для строк по 10К. Удивительно, но кажется, что выполнение select * from cachetable (10 строк) не быстрее, чем выполнение выбора, отличного от 10К строк. Почему это? Индекс выполняет всю работу? При каком количестве строк в нашей главной таблице произойдет улучшение производительности при запросе кеш-таблицы?

Answer 1

Для БД 10K строк - это ничего . Вы не видите большой разницы, потому что фактическое время расчета минимально, большая часть которого расходуется на другие постоянные накладные расходы.

Трудно предсказать, когда вы начнете замечать разницу, но она, вероятно, будет около миллиона строк.

Если вы уже настроили кеширование и оно не наносит вреда, вы можете оставить его в.

Answer 2

10 тыс. Строк - это не много ... начинайте заботиться, когда достигнете 500 тыс. ~ 1 млн. Строк

Индексы отлично работают, особенно если у вас просто 10 различных значений для этого индекса.

Answer 3

Индекс выполняет всю работу?

Вы можете узнать, как выполняется запрос, просмотрев план выполнения.

Например, попробуйте это:

explain plan for select distinct field from table;

select * from table(dbms_xplan.display);

Я заметил, что вы не включили ORDER BY. Если вы не включите ORDER BY, то порядок набора результатов может быть случайным, особенно если оракул использует алгоритм HASH для составления отдельного списка. Вы должны это проверить.

Итак, я бы посмотрел на планы выполнения для исходного запроса, который, по вашему мнению, использует индекс, и на тот, который основан на таблице кеша. Возможно, опубликуйте их, и мы сможем прокомментировать, что на самом деле происходит.

Кстати, таблица кеша обычно реализуется как материализованное представление, особенно если основная таблица обычно довольно статична.

Answer 4

Это зависит от множества факторов - объема памяти, которую имеет ваша БД, размера строк в таблице, использования параметризованного запроса и т. Д., Но обычно 10K - это не много строк, особенно если таблица хорошо проиндексированный, то это не вызовет никакой потливости в современных СУБД.

Как правило, я обычно начинаю обращать пристальное внимание на проблемы с производительностью таблицы, когда она проходит отметку в 100К строк, а 500К обычно не вызывает особых проблем, если они правильно проиндексированы и к ним обращаются. Производительность обычно имеет тенденцию к катастрофическому падению на больших таблицах - у вас может быть все хорошо на 500K строках, но при ползании на 600K - но вам еще предстоит пройти долгий путь, прежде чем вы вообще сможете столкнуться с такими проблемами.

Answer 5

Серьезная преждевременная оптимизация. Просто дайте базе данных выполнить свою работу, возможно, с некоторыми изменениями конфигурации (особенно если это MySQL, который имеет несколько типов и настроек кэша).

Answer 6

Ваш запрос в 10K строках наиболее вероятно использует HASH SORT UNIQUE.

Поскольку 10K наиболее вероятно вписывается в db_buffers и hash_area_size, все операции выполняются в памяти, и вы не заметите никакой разницы.

Но если запрос будет использоваться как часть более сложного запроса или будет заменен другими данными, вам может потребоваться disk I/O для доступа к данным, что замедлит ваш запрос.

Выполните ваш запрос в цикле за несколько сеансов (столько сеансов, сколько будет подключено пользователей), и посмотрите, как он будет работать в этом случае.

Answer 7

Для будущих планов и для масштабируемости вы можете захотеть взглянуть на службу индексирования, которая использует чистую память или что-то более быстрое, чем прием в обход БД TCP. Многие люди (включая меня) используют Lucene для достижения этой цели путем нормализации данных в виде плоских файлов.

Lucene имеет встроенный индексатор каталогов Ram Drive, который может создавать индекс все в памяти - устраняя зависимость от файловой системы и значительно увеличивая скорость.

В последнее время я спроектировал системы, которые имеют один индекс диска Ram, обернутый веб-сервисом. Затем у меня есть Ajax-подобный выпадающий запрос в этот Web-сервис для обеспечения высокой доступности и высокой скорости - без уровня БД, без файловой системы, только с чистой памятью и со скоростью удаленного tcp пакета.

Answer 8

Если у вас есть индекс для столбца, то все значения находятся в индексе, и БД никогда не должны смотреть в таблицу. Это просто выглядит в индексе, который просто имеет 10 записей. Если это в основном данные только для чтения, то кэшируйте их в памяти. Кэширование помогает масштабируемости и многое, освобождая базу данных от работы. Быстрый запрос к базе данных без пользователей может работать плохо, если одновременно выполняется 30 запросов.