Какие методы наиболее эффективны для работы с миллионами записей? - PullRequest
21 голосов
/ 08 октября 2008

Когда-то у меня была таблица базы данных MySQL, содержащая 25 миллионов записей, поэтому даже простой запрос COUNT(*) занимал минуту. Я закончил делать разделы, разделив их на пару таблиц. Я спрашиваю, есть ли какие-то шаблоны или методы проектирования для решения такого рода проблем (огромное количество записей)? MSSQL или Oracle лучше справляются с большим количеством записей?

P.S проблема COUNT(*), указанная выше, является лишь примером, на самом деле приложение выполняет грубую функциональность и несколько совокупных запросов (для отчетов), но на самом деле ничего сложного. Просто для выполнения некоторых этих запросов требуется некоторое время (минуты) из-за объема таблицы

Ответы [ 9 ]

8 голосов
/ 08 октября 2008

См. Почему MySQL может работать медленно с большими таблицами и COUNT (*) против COUNT (столбец)

Убедитесь, что у вас есть индекс для столбца, который вы считаете. Если на вашем сервере достаточно оперативной памяти, попробуйте увеличить размер буфера MySQL. Убедитесь, что ваши диски настроены правильно - DMA включен, нет общего диска или кабеля с разделом подкачки и т. Д.

7 голосов
/ 08 октября 2008

То, что вы спрашиваете с помощью «SELECT COUNT (*)», нелегко.

В MySQL нетранзакционный механизм MyISAM оптимизирует это, сохраняя количество записей, поэтому SELECT COUNT (*) будет очень быстрым.

Однако, если вы используете транзакционный движок, SELECT COUNT (*) в основном говорит:

Сколько именно записей существует в этой таблице в моей транзакции ?

Для этого движок должен сканировать всю таблицу; он, вероятно, приблизительно знает, сколько записей уже существует в таблице, но для получения точного ответа на конкретную транзакцию требуется сканирование. Это не будет быстрым с использованием MySQL innodb, это не будет быстрым в Oracle или чем-то еще. ДОЛЖНА быть прочитана вся таблица (за исключением вещей, хранящихся отдельно от движка, таких как BLOB)

Наличие всей таблицы в оперативной памяти сделает ее немного быстрее, но она все равно не будет быстрой.

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

Если ваше приложение полагается на частые, менее точные подсчеты, вы можете вести сводные данные с запланированной задачей (что может меньше повлиять на производительность других операций).

4 голосов
/ 08 октября 2008

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

Что касается вашего медленного счета (*) в огромной таблице, я бы предположил, что вы использовали тип таблицы InnoDB в MySQL. У меня есть несколько таблиц с более чем 100 миллионами записей, использующих MyISAM под MySQL, и счетчик (*) очень быстрый.

Что касается MySQL, в частности, существуют даже небольшие различия в индексировании таблиц InnoDB и MyISAM, которые являются двумя наиболее часто используемыми типами таблиц. Стоит понять плюсы и минусы каждого и как их использовать.

1 голос
/ 13 октября 2008

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

Для начала, вот некоторые основы базы данных:

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

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

В-третьих, не помещайте функции в предложения where, если это вообще возможно.

В-четвертых, используйте движок -ahem- RDBMS с качественным дизайном. Я с уважением утверждаю, что, хотя в недавнем прошлом ситуация значительно улучшилась, mysql не подходит. (Приношу извинения тем, кто хочет утверждать, что в последнее время он наконец получил оценку.) Больше нет необходимости выбирать между высокой ценой и качеством; Postgres (он же PostgreSql) доступен с открытым исходным кодом и по-настоящему фантастичен, и в нем есть все плагины для удовлетворения ваших потребностей.

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

1 голос
/ 08 октября 2008

Я ответил на аналогичный вопрос в Эта публикация Stackoverflow в некоторых деталях, описывающая достоинства архитектур обеих систем. В некоторой степени это было сделано с точки зрения хранилища данных, но многие различия также имеют значение для транзакционных систем.

Однако 25 миллионов строк не являются VLDB, и если у вас проблемы с производительностью, вам следует обратиться к индексации и настройке. Вам не нужно обращаться в Oracle для поддержки базы данных с 25 миллионами строк - вам нужно пройти порядка 3 порядка, прежде чем вы действительно окажетесь на территории VLDB.

1 голос
/ 08 октября 2008

Является ли подсчет (*) на всей таблице чем-то, что вы часто делаете?

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

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

Любая другая база данных будет иметь аналогичные компромиссы между скоростью извлечения и скоростью вставки; они могут или не могут быть лучше для вашего приложения. Но я бы сначала посмотрел на правильные индексы и, возможно, переписал ваши запросы, прежде чем пробовать другие базы данных. Из-за того, что это стоит, мы выбрали MySQL первоначально, потому что мы нашли, что это работало лучше всего.

Обратите внимание, что таблицы MyISAM в MySQL хранят общий размер таблицы. Они поддерживают это, потому что в некоторых случаях это полезно для оптимизатора, но побочным эффектом является то, что подсчет (*) для всей таблицы действительно быстрый. Это не обязательно означает, что они работают быстрее, чем InnoDB.

1 голос
/ 08 октября 2008

Какой доступ к данным вам нужен? Я использовал HBase (на основе Google BigTable), загруженный огромным количеством данных (~ 30 миллионов строк), в качестве бэкэнда для приложения, которое может возвращать результаты в течение нескольких секунд. Тем не менее, это не совсем уместно, если вам нужен доступ в режиме реального времени, то есть для питания веб-сайта. Его ориентированный на столбцы характер также является довольно радикальным изменением, если вы привыкли к ориентированным на строки СУБД.

0 голосов
/ 08 октября 2008

Индексирование является ключом к производительности с таким количеством записей, но то, как вы пишете запросы, также может иметь большое значение. Конкретные методы настройки производительности различаются в зависимости от базы данных, но в целом, избегайте возврата большего количества записей или полей, чем вам действительно нужно, убедитесь, что все поля объединения проиндексированы (а также часто встречаются поля предложений), избегайте курсоров (хотя я думаю, что это менее верно в Oracle, чем SQL Server я не знаю о MySQL).

Аппаратное обеспечение также может быть узким местом, особенно если вы работаете на том же компьютере, кроме сервера базы данных.

Настройка производительности - это очень техническая тема, и в таком формате на нее трудно ответить. Я предлагаю вам взять книгу по настройке производительности и прочитать ее. Вот ссылка на один для MySQL http://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716

0 голосов
/ 08 октября 2008

Я иду на секунду @ Марк Бейкер и скажу, что вам нужно построить индексы на ваших таблицах.

Для запросов, отличных от того, который вы выбрали, вы также должны знать, что использование таких конструкций, как IN (), быстрее, чем последовательность операторов OR в запросе. Есть много маленьких шагов, которые вы можете предпринять, чтобы ускорить отдельные запросы.

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