Комментарии 12
Ну так и машина для восстановления использовалась не самая быстрая.
Замена процессора на xenon на 6-8 ядер позволила бы увеличить количество архиваторов без заметной потери производительности.
Увеличение памяти гиг до 32 и выше позволило бы обойтись без сбрасывания промежуточных sql скриптов на диск перед скармливанием их архиваторам. Достаточно сделать виртуальный RAM-диск, чтобы не менять программу.
И тогда бы мы приблизились к пределу в 6дней 8 часов.
Замена процессора на xenon на 6-8 ядер позволила бы увеличить количество архиваторов без заметной потери производительности.
Увеличение памяти гиг до 32 и выше позволило бы обойтись без сбрасывания промежуточных sql скриптов на диск перед скармливанием их архиваторам. Достаточно сделать виртуальный RAM-диск, чтобы не менять программу.
И тогда бы мы приблизились к пределу в 6дней 8 часов.
Это вообще достаточно забавная тема :) Во многих энтерпрайз приложениях база растет со временем. Так как это происходит постепенно, то размер так сильно не чувствуется. Но потом приходит время апргейда или сбой продукта или перенос на новое железо/версию базы и при этом иногда требуется пересоздать индексы. Вот тут и получается затык. Причем если с обычными индексами это время может часов, то с полнотекстовыми это может занимать дни или больше на больших базах. А это актуально, например телекоммуникационной компании с примерно 10м пользователей, база имейлов в саппорт растет около 2-4м сообщений в год (около 50-100гиг данных в год) которые надо полнотекстово индексировать.
А почему было просто не писать в bzip2 архивы через libpbz2? Одноврменно и многопоточность для ускорения записи, и не надо генерировать временный файл предварительно…
Идея хорошая, но на тот момент мы взяли то, что «лежало ближе» — и получилась схема с временными файлами.
В следующий раз рассмотрим и этот вариант, спасибо.
В следующий раз рассмотрим и этот вариант, спасибо.
Вот он, windows-подход :)
Куда уж ближе — берётся pbzip2, запускается, ему на вход кормится поток write'ами, он складывает результат в пакованный файл.
Просто использовать следует не zip а «поточный» архиватор.
К слову, даже в винде можно взять банальный rar:
И не нужны ни временные файлы, ни возня с библиотеками. Просто запустить процесс. Причем даже не надо будет разбираться с WinAPI, возьмите вот готовый: www.delphidabbler.com/software/consoleapp/main?mid=3.2
Куда уж ближе — берётся pbzip2, запускается, ему на вход кормится поток write'ами, он складывает результат в пакованный файл.
Просто использовать следует не zip а «поточный» архиватор.
К слову, даже в винде можно взять банальный rar:
-si[name] Read data from stdin (standard input), when creating an archive. Optional 'name' parameter allows to specify a file name of compressed stdin data in the created archive. If this parameter is missing, the name will be set to 'stdin'. This switch cannot be used with -v. Example: type Tree.Far | rar a -siTree.Far tree.rar will compress 'type Tree.Far' output as 'Tree.Far' file.
И не нужны ни временные файлы, ни возня с библиотеками. Просто запустить процесс. Причем даже не надо будет разбираться с WinAPI, возьмите вот готовый: www.delphidabbler.com/software/consoleapp/main?mid=3.2
На выбор метода также повлияло желание сделать удобнее обратный экспорт восстановленных данных из скриптов в базу. Поэтому zip, поэтому просто запакованные файлы.
bzip2 вроде работает медленнее чем zip (хотя и жмет лучше). Выше написали более простой способ с виртуальным RAM-диском.
Насколько восстановленные данные получились актуальными?
Допустим у нас есть две таблицы FioTable (ID, FIO) и EMailTable(ID, ID_FIO, Email). Связь один ко многим.
Ваша утилита восстановит все данные из таблицы EMailTable, но не восстановит часть данных из FioTable.
Какой прок от данных в EMailTable в таком случае?
Допустим у нас есть две таблицы FioTable (ID, FIO) и EMailTable(ID, ID_FIO, Email). Связь один ко многим.
Ваша утилита восстановит все данные из таблицы EMailTable, но не восстановит часть данных из FioTable.
Какой прок от данных в EMailTable в таком случае?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Терабайт — не предел. Восстановление данных сверхбольшого объема на примере испорченной базы Microsoft SQL Server