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

Ответ 1

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

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

Ответ 2

То, что вы запрашиваете с помощью "SELECT COUNT (*)", непросто.

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Чтобы начать работу, вот некоторые основы базы данных:

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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