iBase.ru Forum

Есть оч. большая таблица (15 Гигабай). Содержит данные за продолжительный период (~ 1.5 года). Устаревшие данные лежат "на всякий случай" и в повседневной работе не участвуют (нужны может быть раз в год или вообще не нужны).
Есть такой план действий:
1. выгружать данные помесячно во внешние таблицы и удалять их из основной таблицы
2. внешние таблицы паковать (кстати, очень хорошо пакует 7zip методом PPMd: в моём случае получилось в 11 раз) и складывать на DVD или ещё куда-нибудь.
3. В случае надобности таблицу распаковывать на винчестер и создавать для неё внешнюю таблицу. После пропадания надобности - удалять.

Вопрос: есть ли здесь какие-нибудь подводные камни (АКА "грабли")? Может быть есть более удобные варианты?

Andrew Sagulin писал(а):Вопрос: есть ли здесь какие-нибудь подводные камни

Нет нуллов - нет проблем

hvlad писал(а):Нет нуллов - нет проблем

Так я и знал - уж очень всё гладко получалось. А про null-то я и не подумал. А они есть.

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

Во времена не столь отделенные, когда работали с Paradox, мы практиковали хранение "старых" данных в отдельной БД, но ничего кроме головной боли это не дает. Живые БД имеют тенденцию не только пополняться данными, но и модифицировать метаданные. Сопровождать эти изменения и в актуально(живой базе) и в архивных накладно, а в сучае использования таких серверов, как FB/IB и при приведенных размерах БД и не нужно. Во всяком случае посоветовал бы подумать, прежде чем выводить что-то за пределы действующей БД. Это палка о двух концах и ударить может больно.

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

По закону данные должны храниться 1 год (биллинг). По понятиям руководству иногда требуются данные за 2 года (например, динамика объёма трафика по тому или иному направлению).
Места на винте навалом (80 гигабайт отдано целиком под БД). Вcя сложность в backup/restore. Backup на другой винт (сидит на другом контроллере - всё как положено) занимает 60-65 минут. А вот restore - около 12 часов. При таком раскладе быстрый "подъём" базы в случае чего просто не реален. А рекомендация проверять бекап, делая cледом restore, звучит как издевательство.
Я сейчас выхожу из положения тем, что перевожу базу в offline, и gzip-ом пакую файл БД. Бекап занимает 22 минуты, восстановление 8-9 минут. Но хотелось бы "по человечески", без извращений, т.е. стандартными средствами.

бухгалтерия (бумажная) хранится 3 года, если я не ошибся.

Andrew Sagulin писал(а):Backup на другой винт (сидит на другом контроллере - всё как положено) занимает 60-65 минут.
А вот restore - около 12 часов. При таком раскладе быстрый "подъём" базы в случае чего просто не реален. А рекомендация проверять бекап, делая cледом restore, звучит как издевательство.
Я сейчас выхожу из положения тем, что перевожу базу в offline, и gzip-ом пакую файл БД. Бекап занимает 22 минуты, восстановление 8-9 минут. Но хотелось бы "по человечески", без извращений, т.е. стандартными средствами.

Во-первых, ресторе таки лучше делать на другом компе. И страховую копию держать. Дурить-то ведь могут не только шпиндели с контроллером. А вообще-то я бы советовал дотерпеть до FB2 и взять на вооружение nbackup.

Andrew Sagulin писал(а):Вcя сложность в backup/restore. При таком раскладе быстрый "подъём" базы в случае чего просто не реален.

Угадай с трех раз что я посоветую?
Задействуй какой-нибудь репликатор на второй сервер. Время восстановления - от секунд до минут. Потери данных тоже минимальны.
Александр Пешков рассказывал что его клиенты держат shadow на соседнем сервере через гигабитный канал и nfs. Это вообще абзац.

Места на винте навалом (80 гигабайт отдано целиком под БД). Вcя сложность в backup/restore. Backup на другой винт (сидит на другом контроллере - всё как положено) занимает 60-65 минут. А вот restore - около 12 часов. При таком раскладе быстрый "подъём" базы в случае чего просто не реален. А рекомендация проверять бекап, делая cледом restore, звучит как издевательство.

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

Andrew Sagulin писал(а):Есть оч. большая таблица (15 Гигабай).
Содержит данные за продолжительный период (~ 1.5 года).
Устаревшие данные лежат...
Есть такой план действий:
1. выгружать данные помесячно во внешние таблицы и удалять их из основной таблицы
2. внешние таблицы паковать....
3. В случае надобности таблицу распаковывать .....

У меня К Примеру такая же проблема:
Предпологается к действующей Бд(торговой организации) добавить
данные(таблицу?! или ...) для хранения результатов торговой деятельности
сети 20-ти магазинов в виде Остатков каждого товара (8000)
в каждом магазине на каждый день и глубиной в максимум 4года(365*4=1460дней) итого

ВАРИАНТ1: в таблице с полями(
ключевое-integer,
дата-date,
код товара-integer,
код маг-на-integer,
остаток-NUM 9,3,
продано-NUM 9,3) получается записей 20маг-ов*8000товаров*1460дней=233 600 000. Ю...
Чего-то страшно судя по отзывам... создавать такую талицу в небольшой Бд.

Однако проблему решать как-то надо.

Есть ВАРИАНТ2: с кодированием Строки по схеме:
/код маг-на1(остаток:продано)код маг-на2(остаток:продано)код маг-на3(остаток:продано).../
следовательно таблица содержит поля(
ключевое-integer,
дата-date,
код товара-integer,
Строка-varchar(500)) получается записей 8000товаров*1460дней=11 680 000. Уже легче...
хотя с поиском не совсем удобно.

Есть ВАРИАНТ3 к которому и склоняюсь. Создать файлы Бд типа
MARKET2006.IB, MARKET2007.IB, MARKET2008.IB, MARKET2008.IB с одной таблицей(схема Варианта1) и программно клеить данные. И самое, что нравится так это ненадо b/r часто делать для
архивных Бд.
(когда-то такой вариант реализовывал на VB MS Excel50, файлов было куча зато фунциклировало нормально, а главное для меня так это НАДЕЖНО!)

ТАК ВОТ ХОТЕЛОСЬ БЫ УЗНАТЬ ВАШЕ ПРОФ.МНЕНИЕ на ВАРИАНТЫ 1,2,3 реализации этой практической задачи?!

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

Начальство'с требует....
да и методы "анализов" обязывают...

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