Означает ли больше данных более медленные запросы? - PullRequest
4 голосов
/ 10 марта 2009

Допустим, у меня есть одна таблица с 1000 строками и другая таблица с такой же структурой / индексом, но 10 миллионами записей. Будет ли выполнение операций CRUD на большой таблице медленнее, чем на меньшей? Спасибо.

Ответы [ 5 ]

2 голосов
/ 10 марта 2009

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

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

1 голос
/ 10 марта 2009

Это зависит. Создание, удаление и обновление в среднем будет немного медленнее, поскольку более вероятно, что структуры индекса придется реорганизовать. Кроме того, если из системы базы данных часто запрашивается больше данных, то менее вероятно, что данные, к которым вы пытаетесь получить доступ, кэшируются в ОЗУ и должны считываться с жесткого диска. Но эти различия не должны быть очень значительными для изменения запросов.

Выборка / чтение, конечно, будет медленнее. Совершенно очевидно, что выборка, фильтрация, сортировка и группировка больших объемов данных медленнее, чем то же самое для небольших объемов. Это особенно верно, если данные, над которыми вы работаете, слишком велики, чтобы поместиться в оперативную память машины.

0 голосов
/ 11 марта 2009

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

Почему ты спрашиваешь?

0 голосов
/ 11 марта 2009

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

Тип и количество индексов и используемый вами продукт SQL WILL оказывают заметное влияние

Таблица строк 10M с одним целочисленным индексом на последовательном ключе будет очень похожа на 1000 строк и 10M строк, так как каждая вставка или удаление будет изменять только одну страницу индекса (99,9% времени с полными страницами индексов), и обновления не будут иметь никаких изменений индекса. Страницы индекса для 10M строк поместятся в кеш большинства серверов

Но индекс для атрибута varchar (50) может быть во много раз медленнее с 10M строками по сравнению с 1000 строками, но это стоимость больших индексов

10 миллионов строк не о чем беспокоиться. Если длина строки составляет 100 байт, тогда вся таблица поместится в <2 ГБ ОЗУ </p>

Если вас беспокоит производительность, добавьте больше оперативной памяти, это дешевле, чем пытаться вручную оптимизировать базу данных

0 голосов
/ 10 марта 2009

Это зависит от многих факторов, о которых почти невозможно сказать. Пример: механизм БД хранит данные в виде строк, которые имеют указатели на строки. По какой-то причине ваша таблица 10M строк содержит только четыре разных строки. Таким образом, у вас есть 10 миллионов указателей на четыре строки.

Обновление для замены одной строки другой фактически заменяет только одну строку другой; указатели будут одинаковыми. Нет необходимости обновлять индексы. Одинаковая скорость, независимо от того, сколько у вас рядов.

Удаление будет медленнее, если только удаление не помечает строку как «удаленную». Процесс очистки, запущенный через некоторое время, затем фактически очистит таблицу. Но вы, как пользователь базы данных, не заметите: удаление возвращается немедленно.

Выбор будет медленнее, поскольку он должен возвращать больше данных. Время возврата первой строки будет во многом зависеть от конструкции движка и вашего запроса. Хорошо написанный запрос, выполняемый для таблицы 10M с правильно выбранными индексами, может быть быстрее, чем для таблицы 1K с плохими индексами. Это зависит от объема оперативной памяти на сервере (возможно, он может хранить всю базу данных в оперативной памяти), скорости диска (массив RAID с большим количеством дисков, которые могут работать параллельно, в отличие от медленного ПК с небольшим объемом оперативной памяти и одним диском).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...