Тогда предлагаю как то кластеризовать ссылки
то есть создаем таблицу ссылок в этой таблице поле с номером хранилища (например номер репозитория 1,2,3,4,5)
и разделяем хранение по 5 актуальным таблицам
и соответственно 5 архивным таблицам
Тогда Вы от проблемы бэкапирования не избавитесь - но сможете в архиве держать больше данных в архиве
П.С.
Блин 9 триллионов строковых значений это у Вас диски раньше закончатся, чем Вы начнете что то анализировать
al_gon: Есть вопрос - как реализовать "Умное сравнение" ?
и есть уже встроенный механизм от майкрософт
Неужели надо изобретать велосипед ?
К тому же я упомянул - что есть и другие готовые решения помимо майкрософту (например у Оракле несколько таких утилит)
И все самодельные алгоритмы на голову проигрывают решениям от крупных корпораций - это объективная реальность в которой мы живем
Так сделать можно,
но точно сказать где там настройках линованного сервера это настраивается - непомню
потыкайте , там вариантов не так уж много :)
То ли имперсонлизация толи еще чего ... непомню
Но точно знаю что можно
Правой кнопкой на линке и там в настройках имперсонале указывается логин у которого есть доступ к этому линку
Ограничить права этого логина можно на втором сервере
могу ошибаться но думаю стоит попробовать использовать "Креденшенел" у которого на втором сервере нет особых прав
я так делаю чтобы SSIS запускать с другими правами чем у пользователей SQL базы
что бы запретить редактировать объекты на прилинкованном сервере надо убрать права у того логина под которым линкуется сервер
в Вашем кейсе - оставить только чтение
Повеселили :))))
использую SQL 2014
две таблицы с разными документами по 300 миллионов каждая
по две таблицы для Архивных документов 200 миллионов строк каждая
используются промежуточные таблицы отношений документа к тегам
По заданным параметрам выбирается любой документ меньше чем за секунду
группа документов в пределах двух недель (неважно сколько документов) выбирается не более 10 секунд
максимальное время выборки всех документов по всем тегам 20 минут
сервер почти дно - 1 проц 8 ядер, 58 Гб оперативки, при этом на это сервере еще 32 базы активно используются (только диски хорошие)
Учите мат часть
- Секционирование
- Индексы
- Файловые группы
- Инмемори
База 4 гига :))))) у меня эта база 700 ГБ и таблицы более 100 Гб ничего так нормальненько, очень даже быстро выбирается :)
Уверен на других платформах тоже можно оптимизировать
Блин!
База 4 Гига - Карл ! ты слышишь 4 Гига Карл !!!!
(при вашей задаче одни индексы должны были весть хз сколько, у меня индексы весят больше чем данные в 1,5 раза)
Андрей Шишкин:
1 - MS SQL - потому что быстрее сделаем :)))
2 - Да, статистику тоже надо смотреть при выборе индекса, хотя начиная с SQL 2012 можно профилировать данные в таблице - что позволяет делать эффективные фильтрованные индексы ;)
3 - Очень просто:
- если для получения данных какой то сущности (например сотрудника) вызывается процедурка (или вьюшка), которая лезит по таблицам и собирает данные. То нет ничего сложного в манипуляции с таблицами - просто надо будет переделать процедурки обращающиеся к этой сущности. То есть обходимся без переделки кода приложения, компиляций и всяких другий радостей.
- А если приложение само лезит в базу и начинает читать таблички - то тогда переделав таблицу - получается что надо и код переделывать, перекомпилировать сново тестить и тд.
Joysi75: Маловато как то будет
Если есть две системы - две базы данных
за такой функционал должности особо платить не стоит, а тем более нанимать сотрудника .... можно пригласить специалиста на недельку другую и все тут ....
