Что больше влияет на производительность базы данных Access: тысячи таблиц или миллионы записей?

Question

Мы используем базу данных Access в качестве серверной части нашего программного продукта.Программа проходит альфа / бета-тестирование в компании уже около 2 лет, и мы отметили, что одна из наших таблиц была заполнена более чем сотней тысяч записей за это время.Вероятно, это не пример интенсивного использования нашего продукта, и мы обеспокоены производительностью 5-10 лет в будущем.

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

Answer 1

Базы данных, как правило, оптимизированы для работы с большим количеством строк;вопрос в том, сможете ли вы поддерживать тысячи почти идентичных таблиц?(Мало кто может, это сложно для кодирования)

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

Если вы обнаружите, что у вас есть проблемы с размером таблицы, и ваши наборы данных можно разделить на менее используемые (более старые?) И последние данные, я бы предложил разделить таблицы на две части: table и table_archived (который содержит менее часто используемые / более старые записи),Это может быть разумным компромиссом между размером таблицы и управляемостью.

Answer 2

Вопрос - это вопрос схемы, и если рассматриваемое разбиение таблицы не соответствует естественным фактическим данным, это усугубит проблемы с производительностью, а не улучшит их.Что касается ограничения размера файла в 2 ГБ, то, по-видимому, не имеет значения, как вы нарезаете и копируете данные - если вы приближаетесь к этому пределу (в пределах 50% от него, я бы сказал), вам действительно нужно иметьИмеется в виду путь увеличения.

По вопросу о хранилище данных Jet / ACE я бы сказал, что любое приложение, имеющее таблицы с сотнями тысяч записей, уже является тем, которое следует оценивать на предмет увеличения.Если возможно / возможно иметь миллионы записей, я бы сказал, что это не сложно - увеличение размера.

Это не из-за какой-либо неадекватности Jet / ACE, просто потому, что с изменением требований, подходящей технологииизменения.Супружеская пара может найти Mini Cooper в порядке, когда они поженятся, и это может приспособить их первого ребенка просто отлично, но если они рассматривают еще пару детей, они должны действительно серьезно рассмотреть вопрос о приобретении автомобиля большего размера - не потому, что что-то не такс Mini Cooper, но потому что они переросли то, для чего это лучше всего.

Answer 3

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

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

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

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

Answer 4

Я собираюсь избегать вступления в дискуссию о доступе к серверу SQL в этой теме и вместо этого просто отвечу на вопрос ОП.

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

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

Answer 5

Программа прошла альфа / бета тестирование в компании около 2 лет

Последние 10 лет Microsoft советует людям НЕ использовать Access в качестве базы данных, а использовать SQL Server в различных версиях.

и мы обеспокоены производительностью 5-10 лет спустя

Учитывая развитие событий лат - хм - 10 лет я бы не стал. Я был бы серьезно обеспокоен, действительно ли Access все еще способен хранить данные в течение 10 лет в будущем, или же этот вызов является «программой для сервера SQL» в какой-то момент между ними.

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

Access вполне способен обрабатывать миллион или 5 миллионов записей. SQL Server хорошо вписывается в МИЛЛИАРДЫ записей. В тот момент, когда вы сталкиваетесь с проблемами с Access, в основном вы зарабатываете любые проблемы, возникающие на основе - и я действительно не вижу способа сказать это более красиво - огромное невежество даже при попытке использовать доступ к серьезной базе данных, поскольку - как я уже сказал - MS препятствует этому в течение последних 10 лет.

ТЫСЯЧИ таблиц разделять таблицы неразумно; Базы данных SQL не предназначены для этого. Даже использование кластеризованных таблиц в SQL Server Enterprise (делая именно это) на самом деле не предназначается для вас с десятками тысяч разделов.

Вы НАМНОГО более склонны просто умереть при доступе - доступ просто не является сервером базы данных. Вернуться к чертежной доске.

Тем не менее, Access около 18 лет назад или около того добавил некоторую технологию, приобретенную с FoxPro, позволяющую легко обрабатывать таблицы с миллионами записей (не десятками, а сотнями миллионов), так что вы в настоящий момент в полной безопасности (кроме кошмара). попытки восстановления базы данных, резервного копирования и т. д. на что-то подобное, или даже кошмар запуска многопользовательского приложения через сетевой ресурс.

SQL Server, ооо, у меня в настоящее время есть таблица с 650 миллионами записей, которая вырастет до 10-20 миллиардов в следующие 6 месяцев, когда начнется загрузка данных, и никаких проблем пока нет.