Предмет: Математика и информатика (834 вопросов)
Тип вопроса: Вопрос с одним правильными вариантом
Вопрос задан: 15 Октябрь 2016 20:17 Анонимный пользователь
На вопрос ответил(а): 15 Октябрь 2016 20:17 Астафьева Любовь
мы знаем, что MS Access database engine "дросселирован", чтобы позволить максимальный размер файла 2 ГБ (или, возможно, внутренне проводной, чтобы быть ограниченным менее чем некоторой мощностью 2 из 4KB страниц данных). Но что это означает на практике?
чтобы помочь мне измерить это, можете ли вы сказать мне максимальное количество строк, которые могут быть вставлены в таблицу MS Access database engine?
чтобы удовлетворить определению таблицы, все строки должны быть уникальными, поэтому уникальное ограничение (например, PRIMARY KEY , UNIQUE , CHECK , макрос данных и т. д.) является требованием.
EDIT: я понимаю, что есть теоретический предел, но то, что меня интересует, является практическим (и не обязательно сроки), предел реальной жизни.
8 ответов
Jet/ACE файлы организованы в страницах данных, что означает, что есть определенное количество свободного места, когда ваши границы записи не выровнены со страницами данных.
блокировка на уровне строк значительно сократит количество возможных записей, так как она заставляет одну запись на страницу данных.
в Jet 4 Размер страницы данных был увеличен до 4KBs (с 2KBs в Jet 3.икс.) Как Jet 4 был первым Jet версия для поддержки Unicode это означало, что вы можете хранить 1 ГБ двухбайтовых данных (т. е. 1,000,000,000 двухбайтовых символов), а при включенном сжатии Unicode-2 Гб данных. Таким образом, количество записей будет зависеть от того, включено ли сжатие Unicode.
поскольку мы не знаем, сколько места в файле Jet/ACE занимают заголовки и другие метаданные, а также сколько места занимает хранилище индекса, теоретический расчет всегда будем под тем, что практично.
чтобы получить максимально эффективное хранилище, вы хотите использовать код для создания базы данных, а не пользовательский интерфейс доступа, потому что Access создает определенные свойства, которые не нужны pure Jet. Это не значит, что их много, так как свойства, установленные по умолчанию для доступа, обычно не устанавливаются вообще (свойство создается только при изменении его значения по умолчанию — это можно увидеть, проехав по полю коллекция свойств, т. е. многие свойства, перечисленные для поля в конструкторе таблиц доступа, отсутствуют в коллекции свойств, поскольку они не были установлены), но вы можете ограничить себя типами данных, специфичными для Jet (например, поля гиперссылки-только для доступа).
Я просто потратил час, возясь с этим, используя Rnd() для заполнения 4 полей, определенных как тип byte, с составным PK на четырех полях, и потребовалась вечность, чтобы добавить достаточно записей, чтобы получить до любой значительной части 2GBs. На более чем 2 миллиона записей, файл был под 80MBs. Я, наконец, бросить после достижения просто 700K 7 млн. записи и файл уплотнены до 184MBs. Количество времени, которое потребуется, чтобы встать рядом с 2GBs просто больше, чем я готов инвестировать!
вот моя попытка:
Я создал один столбец ( INTEGER ) таблица без ключа:
вставленные целые числа в последовательности, начинающейся с 1.
Я остановил его (произвольно после многих часов), когда он вставил 65,632,875 строк. Размер файла составил 1,029,772 КБ.
Я сжал файл, который уменьшил его очень немного до 1,029,704 КБ.
что увеличило размер файла до 1,467,708 КБ.
это предполагает, что максимум где-то около 80 миллионов марок.
Как заявили другие, это комбинация вашей схемы и количества индексов.
у друга было около 100,000,000 исторических цен на акции, ежедневные котировки закрытия, в MDB, который приблизился к пределу 2 Гб.
Он вытащил их, используя некоторый код, найденный в статье базы знаний Microsoft. Я был довольно удивлен, что какой бы сервер он ни использовал, он не отключил его после первых 100k записей.
Он мог просмотреть любую запись в второй.
прошло несколько лет с тех пор, как я последний раз работал с Access, но большие файлы базы данных всегда имели больше проблем и были более склонны к коррупции, чем меньшие файлы.
Если файл базы данных не доступен только одному человеку или хранится в надежной сети, вы можете обнаружить, что это проблема до достижения предела размера базы данных 2GB.
мы не обязательно говорим о теоретических ограничениях здесь, мы говорим о реальных ограничениях максимального размера файла 2GB и схемы базы данных.
- является ли ваш db одной таблицей или несколько?
- сколько столбцов имеет каждая таблица?
- какие типы данных?
схема находится на четной основе с количеством строк в определении того, сколько строк вы можете иметь.
мы воспользовались Доступ к MDBs для хранения экспорта данных MS-SQL для статистического анализа некоторыми нашими корпоративными пользователями. В этих случаях мы экспортировали нашу основную структуру таблиц, обычно четыре таблицы с 20 до 150 столбцами, варьирующимися от ста байтов в строке до более 8000 байтов в строке. В этих случаях мы сталкивались с несколькими сотнями тысяч строк данных, допустимых для MDB, которые мы отправляли.
Итак, я просто не думаю, что этот вопрос имеет ответ в отсутствие вашего схема.
все зависит от того. Теоретически, используя один столбец с типом данных 4 байта. Можно хранить 300 000 строк. Но, вероятно, есть много накладных расходов в базе данных еще до того, как вы что-либо сделаете. Я читал некоторые, где вы могли бы иметь 1.000.000 строк, но опять же, все зависит..
вы также можете связать базы данных вместе. Ограничьте себя только дисковым пространством.
Practical = ‘полезно на практике’ — так что лучшее, что вы собираетесь получить, это анекдотический. Все остальное-просто прототипы и результаты тестирования.
Я согласен с другим — при определении максимального количества записей полностью зависит от схемы — таблицы # поля # индексы#.
еще один анекдот для вас: недавно я ударил размер файла 1.6 GB с 2 первичными хранилищами данных (таблицами), 36 и 85 полей соответственно, с некоторыми копиями подмножеств в 3 дополнительных таблицах.
кого волнует, уникальны данные или нет-только материал, если контекст говорит об этом. Данные-это данные, если дублирование не влияет на обработку индексатором.
общее количество строк, составляющих 1,6 Гб, составляет 1,72 м.
при работе с 4 большими таблицами Db2 я не только нашел предел, но это заставило меня выглядеть очень плохо для босса, который думал, что я могу добавить все четыре таблицы (каждая с более чем 900 000 строк) к одной большой таблице. реальный результат жизни заключался в том, что независимо от того, сколько раз я пробовал таблицу (которая имела ровно 34 столбца — 30 текстовых и 3 целых), выплюнет какое-то загадочное сообщение "не удается открыть базу данных непризнанного формата или файл может быть поврежден". Итог меньше, чем 1,500,000 записи и чуть больше, чем 1,252,000 с 34 строками.
Я разрабатываю программное обеспечение, которое хранит много данных в одной из таблиц базы данных (SQL Server версии 8, 9 или 10). Скажем, около 100 000 записей вставляются в эту таблицу в день. Это около 36 миллионов записей в год. Опасаясь, что я потеряю производительность, я решил создать новую таблицу каждый день (таблицу с текущей датой в ее названии), чтобы уменьшить количество записей в таблице.
не могли бы вы сказать мне, была ли это хорошая идея? Есть ли предел записи для Таблицы SQL server? Или вы знаете, сколько записей (более или менее) может быть сохранено в таблице, прежде чем производительность значительно снизится?
12 ответов:
трудно дать общий ответ на это. Это действительно зависит от ряда факторов:
- какой размер вашей строки
- какие данные вы храните (строки, блобы, цифры)
- что вы делаете со своими данными (просто храните их в архиве, регулярно запрашивайте)
- у вас есть индексы на таблице — сколько
- каковы ваши спецификации сервера
Как ответил в другом месте здесь, 100000 в день и, таким образом, за столом слишком много — я бы предложил ежемесячно или еженедельно, возможно, даже ежеквартально. Чем больше таблиц у вас есть, тем больше кошмар обслуживания/запроса он станет.
- размер базы данных: 524,272 терабайт
- базы данных на экземпляр SQL Server: 32 767
- файловые группы для каждой базы данных: 32 767
- файлы в базе данных: 32,767
- размер файла (данные): 16 терабайт
- размер файла (журнала): 2 терабайт
- строк в таблице: ограничено хранение
- таблицы в базе: ограничено количеством объектов в базе данных
У меня есть таблица из трех столбцов с чуть более чем 6 миллиардами строк в SQL Server 2008 R2.
мы запрашиваем его каждый день для создания поминутных диаграмм системного анализа для наших клиентов. Я не заметил никаких хитов производительности базы данных (хотя тот факт, что он растет
1 ГБ каждый день, делает управление резервными копиями немного более сложным, чем хотелось бы).
Обновление Июля 2016
24,5 миллиарда строк прежде чем резервные копии стали достаточно большими для нас, чтобы решить усечь записи старше двух лет (
700 ГБ, хранящиеся в нескольких резервных копиях, в том числе на дорогих лентах). Стоит отметить, что производительность не была существенным мотиватором в этом решении (т. е. он все еще работал отлично).
для тех, кто пытается удалить 20 миллиардов строк из SQL Server, я настоятельно рекомендую в этой статье. Соответствующий код в случае ссылки умирает (читайте статью для полного объяснения):
Обновление Ноябрь 2016
Если вы планируете хранить много данных в одной таблице не. Я настоятельно рекомендую вам рассмотреть возможность секционирования таблиц (вручную или с помощью встроенного в особенности, если вы работаете в версии Enterprise). Это делает удаление старых данных таким же простым, как усечение таблицы один раз в неделю/месяц/и т. д.). Если у вас нет предприятия (которого у нас нет), вы можете просто написать сценарий, который выполняется один раз в месяц, отбрасывает таблицы старше 2 лет, создает таблицу следующего месяца и восстанавливает динамическое представление, которое объединяет все таблицы разделов вместе для упрощения запросов. Очевидно, что "раз в месяц" и "старше 2 лет" должны быть определены вами на основе того, что имеет смысл для вашего случая использования. Удаление непосредственно из таблицы с десятками миллиардов строк данных будет а) занимать огромное количество времени и Б) заполнять журнал транзакций сотни или тысячи раз.
Я не знаю предела строк, но я знаю таблицы с более чем 170 миллионами строк. Вы можете ускорить его с помощью секционированных таблиц (2005+) или представлений, которые соединяют несколько таблиц.
Я не знаю MSSQL конкретно, но 36 миллионов строк не являются большими для корпоративной базы данных — работа с базами данных мэйнфреймов, 100 000 строк звучит как таблица конфигурации для меня :-).
пока я не большой поклонник некоторые из программного обеспечения Microsoft это не Доступ, о котором мы говорим здесь: я предполагаю, что они могут обрабатывать довольно значительные размеры баз данных со своими корпоративными СУБД.
Я подозреваю, что дни, возможно, были слишком тонким решением, чтобы разделить его вверх, если она вообще нуждается в разделении.
У нас есть таблицы в SQL Server 2005 и 2008 с более чем 1 миллиард строк в нем (30 миллионов добавляется ежедневно). Я не могу себе представить, как спуститься в крысиное гнездо, чтобы каждый день разбивать его на новый стол.
гораздо дешевле добавить соответствующее дисковое пространство (которое вам все равно нужно) и ОЗУ.
Это зависит, но я бы сказал, что лучше держать все в одной таблице для простоты.
100 000 строк в день на самом деле не так много из огромного количества. (В зависимости от вашего серверного оборудования). Я лично видел, как MSSQL обрабатывает до 100 м строк в одной таблице без каких-либо проблем. Пока вы держите свои индексы в порядке, все должно быть хорошо. Ключ должен иметь кучи памяти, так что индексы не должны быть заменены, чтобы диск.
с другой стороны, это зависит от того, как вы используете данные, если вам нужно сделать много запросов, и его маловероятные данные будут необходимы, что охватывает несколько дней (так что вам не нужно будет присоединяться к таблицам) это будет быстрее, чтобы разделить его на несколько таблиц. Это часто используется в таких приложениях, как управление промышленным процессом, где вы можете читать значение, скажем, 50 000 инструментов каждые 10 секунд. В этом случае скорость чрезвычайно важна, но простота есть не.
мы переполняли целочисленный первичный ключ один раз (который составляет
2,4 миллиарда строк) в таблице. Если есть предел строк, вы вряд ли когда-нибудь попадете в него всего лишь на 36 миллионов строк в год.
вы можете заполнить таблицу, пока у вас не будет достаточно места на диске. Для повышения производительности вы можете попробовать миграцию на SQL Server 2005, а затем разбить таблицу и поместить части на разные диски(если у вас есть конфигурация RAID, которая действительно может вам помочь). Секционирование возможно только в корпоративной версии SQL Server 2005. Вы можете посмотреть пример секционирования по этой ссылке: http://technet.microsoft.com/en-us/magazine/cc162478.aspx
также вы можете попробовать создать вид для наиболее часто используемых данных, что также является одним из решений.
надеюсь, что это помогло.
самая большая таблица, с которой я столкнулся на SQL Server 8 на Windows2003, была 799 миллионов с 5 столбцами. Но независимо от того,является ли это хорошей волей,следует измерять по отношению к SLA и случаю использования — например, загрузить 50-100 000 000 записей и посмотреть, работает ли он по-прежнему.