Являются ли эти таблицы слишком большими для SQL Server или Oracle?
Я не большой гуру баз данных, поэтому я хотел бы получить совет.
Фон
У нас есть 4 таблицы, которые в настоящее время хранятся в Sybase IQ. В настоящее время у нас нет выбора по этому поводу, мы в основном застряли на том, что кто-то другой решил для нас. Sybase IQ - это ориентированная на столбцы база данных, которая идеально подходит для хранилища данных. К сожалению, мой проект нуждается в значительном обновлении транзакций (мы больше работаем с базой данных), поэтому я ищу более распространенные альтернативы.
Вопрос
Учитывая размеры этих таблиц, будет ли кто-нибудь рассматривать SQL Server или Oracle как жизнеспособную альтернативу?
- Таблица 1: 172 столбца * 32 миллиона строк
- Таблица 2: 453 столбца * 7 миллионов строк
- Таблица 3: 112 столбцов * 13 миллионов строк
- Таблица 4: 147 столбцов * 2,5 миллиона строк
Учитывая размер данных, что меня должно беспокоить с точки зрения выбора базы данных, конфигурации сервера, памяти, платформы и т. Д.?
10 ответов
Да, оба должны иметь возможность обрабатывать ваши таблицы (если ваш сервер подходит для этого). Но я бы немного пересмотрел вашу базу данных. Даже в хранилище данных, где вы денормализуете свои данные, таблица с 453 столбцами - это ненормально.
Это действительно зависит от того, что в столбцах. Если есть много больших столбцов 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-байтовых целых чисел, но если она состоит из столбцов VARCHAR с 255 символами, вы можете существенно превысить ограничение. Этот предел в 8 КБ был жестким ограничением в SQL Server, но я думаю, что в наши дни это просто мягкий предел и руководство по производительности.
Обратите внимание, что столбцы VARCHAR не обязательно потребляют память, соразмерную размеру, указанному для них. Это максимальный размер, но они потребляют столько, сколько им нужно. Если фактические данные в столбцах VARCHAR всегда имеют длину 3-4 символа, то размер будет аналогичен целочисленным столбцам независимо от того, были ли они созданы как VARCHAR(4) или VARCHAR(255).
Общее правило заключается в том, что вы хотите, чтобы размер строки был небольшим, чтобы в каждом блоке диска было много строк, что уменьшает количество операций чтения с диска, необходимых для сканирования таблицы. Как только вы превысите 8 Кб, у вас будет два чтения в строке
У Oracle есть еще одна потенциальная проблема, заключающаяся в том, что объединения ANSI имеют жесткое ограничение на общее количество столбцов во всех таблицах в объединении. Вы можете избежать этого, избегая синтаксиса соединения Oracle ANSI. (Есть эквиваленты, которые не страдают от этой ошибки.) Я не помню, каков предел или к каким версиям он применяется (я не думаю, что это было еще исправлено).
Количество строк, о которых вы говорите, не должно быть проблемой, если у вас достаточно оборудования.
С подходящим по размеру оборудованием и подсистемой ввода-вывода для удовлетворения ваших потребностей обе вполне адекватны - если у вас много столбцов, то количество строк действительно очень мало - мы регулярно используем наборы данных, выраженные в миллиардах, а не миллионах. (Только не пробуйте на SQL 2000:))
Если вы знаете свои требования к использованию и вводу / выводу, большинство поставщиков ввода / вывода переведут это в спецификации оборудования для вас. Память, процессоры и т. Д. Опять же зависят от рабочих нагрузок, которые могут моделировать только вы.
Oracle 11g не имеет проблем с такими данными и структурой.
Более подробная информация на: http://neworacledba.blogspot.com/2008/05/database-limits.html
С уважением.
На основании ваших комментариев в других ответах, я думаю, что я бы порекомендовал:
1) Определите, какие данные фактически обновляются, и какие данные более или менее доступны только для чтения (или нечасто). 2) Переместите обновленные данные в отдельные таблицы, объединенные по идентификатору, в таблицы большего размера (удалив эти столбцы из больших таблиц). 3) Выполните ваши транзакции OLTP с меньшими, более реляционными таблицами. 4) Используйте внутренние объединения, чтобы подключиться к большим таблицам для извлечения данных при необходимости.
Как уже отмечали другие, вы пытаетесь заставить БД выполнять и OLTP, и OLAP одновременно, и это сложно. Настройки сервера должны быть изменены по-разному для любого сценария.
SQL Server или Oracle должны работать. Я также использую данные переписи, и моя таблица гигантов содержит около 300 столбцов. Я использую SQL Server 2005, и он жалуется, что если бы все столбцы были заполнены до их емкости, это превысило бы максимально возможный размер записи. Мы используем наши данные переписи в режиме OLAP, поэтому не так уж и сложно иметь такое количество столбцов.
Вы можете быть близко к SQL Server, в зависимости от того, какие типы данных у вас есть в этой таблице столбцов 453 (обратите внимание на ограничение количества байтов на строку, но также прочитайте сноску). Я знаю, что вы сказали, что это нормализовано, но я предлагаю взглянуть на ваш рабочий процесс и подумать, как уменьшить количество столбцов.
Кроме того, эти таблицы достаточно велики, поэтому аппаратные соображения являются основной проблемой производительности. Вам понадобится опытный администратор баз данных, чтобы помочь вам в спецификациях и настройке сервера с любой RDBMS. Правильная настройка вашей дисковой подсистемы будет жизненно важной. Вы, возможно, также захотите рассмотреть разбиение таблиц среди прочего, чтобы повысить производительность, но все это зависит от того, как именно используются данные.
Требование одной БД действовать одновременно как операционная и складская система - все еще непростая задача. Я хотел бы рассмотреть возможность использования SQL-сервера или Oracle для операционной системы и наличия отдельного DW для отчетов и аналитики, возможно, сохраняя систему, которую вы используете.
Ожидается, что некоторая перестройка и нормализация таблиц произойдут на оперативной стороне, чтобы соответствовать ограничениям в одну строку на страницу для хранилища на основе строк.
Если вам необходимо быстро обновить DW, вы можете рассмотреть подход EP для ETL, а не стандартный (запланированный) ETL.
Учитывая, что вы находитесь на начальном этапе, взгляните на проект Microsoft Madison, который представляет собой автоматически масштабируемое устройство DW до 100 ТБ. Они уже отправили некоторые установки.
Я бы очень внимательно рассмотрел вопрос о переходе от базы данных, ориентированной на столбцы, к реляционной. Базы данных, ориентированные на столбцы, действительно не подходят для оперативной работы, поскольку обновления выполняются очень медленно, но их более чем достаточно для поддержки отчетности и бизнес-аналитики.
Чаще всего приходится разбивать операционную работу на базу данных OLTP, содержащую текущую деятельность, необходимую для операций (учетные записи, инвентаризация и т. Д.), И использовать процесс ETL для заполнения хранилища данных (история, тенденции). DW, ориентированный на столбцы, будет бить руки по реляционному принципу практически в любых обстоятельствах, поэтому я бы так легко не отказался от Sybase IQ. Возможно, вы можете спроектировать свою систему так, чтобы она работала на стороне OLTP, используя выбранный вами реляционный продукт (я бы выбрал SQL Server, но я предвзято), и сохранить часть OLAP, которая есть у вас сейчас.
Все ли столбцы во всех этих таблицах обновлены вашим приложением?
Вы могли бы подумать о том, чтобы витрины данных (оперативные или онлайн-хранилища данных АКА) обновлялись в течение дня, а затем новые записи переносились в основное хранилище ночью? Я говорю это потому, что строки с огромным количеством столбцов будут медленнее вставлять и обновлять, поэтому вы можете подумать о том, чтобы адаптировать свою конкретную онлайн-архитектуру к требованиям обновления вашего приложения.
У Sybase есть продукт под названием RAP, который объединяет IQ с экземпляром ASE в их памяти (их реляционная база данных), который предназначен для помощи в таких ситуациях, как эта.
Ваши данные не настолько обширны, что вы не могли бы подумать о переходе на базу данных, ориентированную на строки, но, в зависимости от структуры данных, вы могли бы в конечном итоге использовать значительно больше дискового пространства и замедлить многие виды запросов.
Отказ от ответственности: я работаю на Sybase, но в настоящее время не на стороне ASE/IQ/RAP.