Я пытаюсь определить, сколько оперативной памяти потребуется для обработки миграции базы данных (компания желает приобрести для меня больше оперативной памяти). Факторы:
Мне любопытно узнать, есть ли какой-нибудь способ математически придумать формулу, или достаточно просто дополнительных 2 гига? У меня сейчас гиг ОЗУ.
Один гигабайт действительно очень мало для этого процесса без частой подкачки страниц на диск обоими SQL-серверами. Тем более, если так получилось, что оба сервера находятся на одной машине.
Конечный размер данных в MySQL (3 Гб) особо не беспокоит. С этим справится любой современный 32-битный настольный компьютер 3Gb. Запросы, выполняемые к исходным данным объемом 900 ГБ (Oracle), будут излишними.
Я понимаю, что сейчас вы беспокоитесь об оперативной памяти, но другими факторами, которые могут значительно повысить производительность, являются скорость жесткого диска и количество ядер процессора. Первое, потому что будет много обращений к жесткому диску, поскольку запросы переносят данные из базы данных на диск, второе потому, что оба сервера sql превосходно используют все преимущества многоядерных процессоров.
А вот что касается ОЗУ:
Чем больше у вас ОЗУ, тем больше данных запрос может извлечь с диска. Многие, многие, многие факторы будут влиять на то, насколько важной будет ОЗУ. Возможно, наиболее важным является то, будут ли ваши запросы включать подзапросы и аналогичные конструкции sql? Если это так, механизм Oracle будет извлекать данные с диска во временные таблицы памяти и выполнять дальнейшие запросы выше в своем плане выполнения. Чем больше данных может храниться в памяти, тем меньше раз Oracle потребуется повторять этот процесс, и тем меньше данных нужно будет выгружать обратно на диск для построения окончательного результата.
И тем не менее, масса вашей базы данных (мне не хватает правильного термина, но, по сути, насколько велики запрашиваемые таблицы в oracle) может снизить некоторые из требований, если так получилось, что запрашиваемые таблицы в oracle не являются чем-то большим, чем 1 или размером 2 ГБ.
Обязательно качество ваших запросов будет влиять на объем оперативной памяти, необходимой больше всего. Порядок работы здесь - это индексы, индексы и другие индексы. Избегайте полнотекстового поиска, как, например, чумы, и прибегайте к нему только тогда, когда это необходимо, а не когда можно. Избегайте и неиндексированного поиска, так как это задача миграции, которой вы занимаетесь) можно проиндексировать больше столбцов ваших таблиц, чем обычно. Помните, что вы будете читать только из Oracle. Наконец, вы должны убедиться, что в случае подзапросов вы оптимизировали их в меру своих возможностей, чтобы не извлекать слишком много ненужных строк.
Сколько оперативной памяти?
Боюсь, что точный объем оперативной памяти назвать невозможно. Только после того, как вы построите свои запросы и будете готовы начать процесс, вы сможете получить представление о количестве данных, обрабатываемых за одну транзакцию.
Выберите самую тяжелую транзакцию (та, которая, как вы знаете, будет генерировать наибольший объем данных во время обработки). Оцените, сколько строк будет сгенерировано во время наиболее интенсивной части плана выполнения. Получите общий объем памяти, необходимый для каждой строки (суммируйте объем памяти, необходимый для каждого столбца), и умножьте на количество строк. Это количество свободно ОЗУ вам в идеале понадобится, чтобы избежать подкачки.
Последняя оптимизация:
Транзакция может показаться вам хорошей практикой оптимизации. Но будьте осторожны. Вашим узким местом во всем этом процессе будет не то, насколько быстро вы сможете читать данные из базы данных размером 900 ГБ, а то, сколько данных вы сможете сохранить в памяти, прежде чем они будут выгружены. Поскольку транзакции будут выполняться как единое целое, потребуется дополнительная память для хранения временных результатов и данных отката. Избегайте транзакций по тем запросам, по которым вы будете работать с большими объемами данных.
Кроме того, извлекайте только необходимые столбцы в течение всего процесса. SELECT * действительно не лучшая идея, если она вам не нужна.
Вывод:
Я не смог дать вам объем оперативной памяти, как вы просили. Вы должны понимать, что поступить так будет несправедливо. Я бы солгал тебе. На необходимый вам объем ОЗУ влияет не только объем данных, обрабатываемых по каждому запросу, но даже (даже в меньшей степени) производительность вашего жесткого диска, поскольку в вашем случае допустимо, что произойдет подкачка некоторых данных.
Ваш процессор и операционная система также сообщают об объеме оперативной памяти, которую вы можете использовать. Как вы знаете, если они оба 32-битные, будет использоваться не более ~ 3,8. Если они 64-битные, вы можете втиснуть в него 1 терабайт оперативной памяти и больше не беспокоиться об этом.
Наконец, отделение сервера Oracle от сервера MySQL также значительно снизит ваши требования к оперативной памяти. Серверная машина Oracle становится вашим приоритетом, а серверная машина MySQL с 1 Гб оперативной памяти более чем успешно обрабатывает входящие данные.
Но одно я могу вам сказать: не пытайтесь делать это с 1 ГБ оперативной памяти. Если у вас 32-битная машина, обновите ее до 4 Гб.
Всего наилучшего.
При нынешних ценах на оперативную память ваша компания не делает здесь больших вложений.
Так что было бы нелепо пойти на 3 ГБ ОЗУ и обнаружить, что этого недостаточно.
Выберите 4 ГБ ОЗУ, хотя в 32-битной ОС видеокарта съест часть 4 ГБ.
Не с математической точки зрения, 4 ГБ должно быть достаточно. Если нет, то следующая инвестиция вашей компании должна быть в 64-разрядной операционной системе (и, возможно, в новом компьютере) с 8 ГБ.