Какие методы наиболее эффективны для работы с миллионами записей?

Question

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

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

Answer 1

См Why MySQL could be slow with large tables и COUNT(*) vs COUNT(col)

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

Answer 2

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

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

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

Answer 3

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

Answer 4

То, что вы запрашиваете с помощью «ВЫБРАТЬ СЧЕТ (*)», непросто.

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

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

точно, сколько записей есть в этой таблице в моей сделки?

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

Я собираюсь второй @Mark Baker и скажу, что вам нужно создавать индексы на ваших столах.

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

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