Являются ли эти таблицы слишком большими для SQL Server или Oracle?

Question

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

Фон

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

Вопрос

1. Учитывая размеры этих таблиц, будет ли кто-нибудь рассматривать SQL Server или Oracle как жизнеспособную альтернативу?

   • Таблица 1: 172 столбца * 32 миллиона строк
   • Таблица 2: 453 столбца * 7 миллионов строк
   • Таблица 3: 112 столбцов * 13 миллионов строк
   • Таблица 4: 147 столбцов * 2,5 миллиона строк

2. Учитывая размер данных, что меня должно беспокоить с точки зрения выбора базы данных, конфигурации сервера, памяти, платформы и т. Д .?

Answer 1

Да, оба должны иметь возможность обрабатывать ваши таблицы (если ваш сервер подходит для этого). Но я бы немного пересмотрел вашу базу данных. Даже в хранилище данных, где вы денормализуете свои данные, таблица с 453 столбцами - это ненормально.

Answer 2

Это действительно зависит от того, что в столбцах. Если есть много больших столбцов 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).

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Более подробная информация по адресу: http://neworacledba.blogspot.com/2008/05/database-limits.html

С уважением.

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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