Эти таблицы, слишком большие для SQL Server или Oracle

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

453 * 4 = 1812      # columns are 4 byte integers, row size is ~1.8k
453 * 255 = 115,515 # columns are VARCHAR(255), theoretical row size is ~112k

Практическое правило состоит в том, что размер строки не должен превышать размер блока диска, который обычно составляет 8 КБ. Как видите, ваша большая таблица не является проблемой в этом отношении, если она полностью состоит из 4-байтовых целых чисел, но если она состоит из 255-символьных столбцов VARCHAR, то вы можете значительно превысить лимит. Это ограничение в 8 КБ раньше было жестким ограничением в SQL Server, но я думаю, что в наши дни это просто мягкое ограничение и руководство по производительности.

Обратите внимание, что столбцы VARCHAR не обязательно потребляют память, соизмеримую с размером, который вы для них указываете. Это максимальный размер, но они потребляют ровно столько, сколько им нужно. Если фактические данные в столбцах VARCHAR всегда состоят из 3-4 символов, тогда размер будет аналогичен размеру целочисленных столбцов независимо от того, создали ли вы их как VARCHAR (4) или VARCHAR (255).

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

У Oracle есть еще одна потенциальная проблема, заключающаяся в том, что соединения ANSI имеют жесткое ограничение на общее количество столбцов во всех таблицах в объединении. Этого можно избежать, отказавшись от синтаксиса соединения Oracle ANSI. (Есть эквиваленты, которые не страдают от этой ошибки.) Я не помню, каков лимит или к каким версиям он применяется (я не думаю, что он еще исправлен).

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

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

Oracle 11g не имеет проблем с такими данными и структурой.

Дополнительная информация на: http://neworacledba.blogspot.com/2008/05/database-limits.html

С уважением.

Ограничения Oracle

Ограничения SQL Server

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

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

Основываясь на ваших комментариях в других ответах, я думаю, что я Я бы порекомендовал:

1) Изолируйте, какие данные действительно обновляются, а какие данные более или менее доступны только для чтения (или редко). 2) Переместите обновленные данные в отдельные таблицы, объединенные по идентификатору, в более крупные таблицы (удаление этих столбцов из больших таблиц) 3) Выполняйте транзакции OLTP с меньшими, более реляционными таблицами. 4) Используйте внутренние соединения, чтобы подключиться к большим таблицам для получения данных, когда это необходимо.

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

Должен работать либо SQL Server, либо Oracle. Я также использую данные переписи, и моя таблица giganto содержит около 300+ столбцов. Я использую SQL Server 2005, и он жалуется, что, если бы все столбцы были заполнены до предела, он бы превысил максимально возможный размер записи. Мы используем данные переписи в формате OLAP, поэтому иметь такое количество столбцов не так уж и важно.

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

Чаще всего приходится разделять операционную работу на базу данных OLTP, содержащую текущую активность. необходимы для операций (учетные записи, инвентаризация и т. д.) и использовать процесс ETL для заполнения хранилища данных (история, тенденции). DW, ориентированный на столбцы, превзойдет реляционную систему практически в любых обстоятельствах, поэтому я бы не стал отказываться от Sybase IQ так легко. Возможно, вы сможете спроектировать свою систему так, чтобы она имела рабочую сторону OLTP, используя выбранный вами реляционный продукт (я бы выбрал SQL Server, но я m) и оставьте ту часть OLAP, которая у вас есть.

Все ли столбцы во всех этих таблицах обновляются вашим приложением?

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

Просить одну БД действовать как операционная и складская система одновременно - это все еще непростая задача. Я бы подумал об использовании SQL-сервера или Oracle для операционной системы и наличия отдельного DW для отчетности и аналитики, вероятно, сохранив систему, которая у вас есть.

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

Если вам нужно быстро обновлять DW, вы можете рассмотреть подход EP для ETL , в отличие от стандартного (запланированного) ETL.

Учитывая Если вы находитесь на ранней стадии, обратите внимание на проект Microsoft Madison , который представляет собой автоматическое масштабируемое устройство DW до 100 ТБ. Они уже отгрузили некоторые установки.

У Sybase есть продукт под названием RAP, который объединяет IQ с находящимся в памяти экземпляром ASE (их реляционной базы данных), который предназначен для помощи в таких ситуациях.

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

Отказ от ответственности: я работаю на Sybase, но в настоящее время не на стороне ASE / IQ / RAP.