Привет друзья.

Кто работает с базами больше 2х террабайт, расскажите почему ваша база такая большая. Можно ли сделать ее поменьше за счет переноса части необновляемых данных по базам.
Например по годам рассортировать....

Здравствуйте, кубик, Вы писали:

К>Кто работает с базами больше 2х террабайт, расскажите почему ваша база такая большая. Можно ли сделать ее поменьше за счет переноса части необновляемых данных по базам.
К>Например по годам рассортировать....

У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.

К>Кто работает с базами больше 2х террабайт

Мы.

К>расскажите почему ваша база такая большая

Потому что в ней лежит много данных.

К>Можно ли сделать ее поменьше за счет переноса части необновляемых данных по базам

Можно.

К>Например по годам рассортировать

Мы и сортируем "по годам". Только без разнесения данных по разным базам, а внутри одной базы с использованием упомянутого выше партиционирования.
Но, несмотря на это, в безусловной и всепокрывающей верности утверждения "выносить в другие базы ничего не нужно" я не уверен.

Здравствуйте, Аноним931, Вы писали:

А>Но, несмотря на это, в безусловной и всепокрывающей верности утверждения "выносить в другие базы ничего не нужно" я не уверен.

Так это и не безусловно. Все зависит от бизнес- и "техно"- процессов и требований.

Здравствуйте, IT, Вы писали:

IT>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
Как обеспечиваете целостность данных на таких объёмах?

Здравствуйте, kov_serg, Вы писали:

IT>>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
_>Как обеспечиваете целостность данных на таких объёмах?

Используем СУБД.

Здравствуйте, kov_serg, Вы писали:

IT>>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
_>Как обеспечиваете целостность данных на таких объёмах?

А в чем проблема? Если речь про реляционные БД и целостность ссылок, то поиск в таблице по индексу среди миллиона записей и среди миллиарда, будет почти не отличаться по времени и ресурсам. А без индекса будут проблемы уже на ста тысячах.

Здравствуйте, IT, Вы писали:

IT>Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
дак партицирование это по сути вынос части данных в другую таблицу.
вообще интересно, а есть ли смысл в партицировании? партицирование имеет смысл когда есть поле например — дата операции
и записи за разные например года в разных таблицах. но зачем? если в условии отбора будет указан диапазон дат по этому полю, то при наличии индекса (особенно кластерного)
выборка записей попадающих в этот диапазон итак будет быстро. зачем партцирование?

Здравствуйте, кубик, Вы писали:

К>Привет друзья.

К>Кто работает с базами больше 2х террабайт, расскажите почему ваша база такая большая.
до двух терабайт дело не дошло. было два редизайна когда они (баз много) начали к терабайту подбираться.
в обоих случаях по разным причинам

в одном случае произошел переход на колумнстор, а во втором — выброс части неизменяемых и редко используемых данных в облако
без редизайнов наверное терабайт 5 было бы, а так в пределах 200-300ГБ

Здравствуйте, fmiracle, Вы писали:

F>А в чем проблема? Если речь про реляционные БД и целостность ссылок, то поиск в таблице по индексу среди миллиона записей и среди миллиарда, будет почти не отличаться по времени и ресурсам. А без индекса будут проблемы уже на ста тысячах.

Я про сбои в самих данных даже если они иногда переезжают в озу и обратно можно словить не ожиданные изменения. Т.к. надёжность оборудования всё же конечная и на больших объёмах вероятность получить битые данные гораздо выше несмотря на все контрольные суммы, коды Рида-Соломона и регулярные бэкапы. Или целиком доверяем субд и волевым решением приравниваем вероятность ошибок к 0.

Здравствуйте, MadHuman, Вы писали:

IT>>Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
MH>дак партицирование это по сути вынос части данных в другую таблицу.

Это вынос части данных в отдельную файлгруппу, но не обязательно.

MH>вообще интересно, а есть ли смысл в партицировании? партицирование имеет смысл когда есть поле например — дата операции

Совершенно верно. Не все таблицы можно эффективно партиционировать. Для этого нужно соблюсти одно условие. У тебя должна быть колонка (можно вычисляемая), которую ты используешь абсолютно во всех запросах в качестве фильтра. Если такое условие не выполняется, то партиционирование не имеет смысла.

MH>и записи за разные например года в разных таблицах. но зачем? если в условии отбора будет указан диапазон дат по этому полю, то при наличии индекса (особенно кластерного) выборка записей попадающих в этот диапазон итак будет быстро. зачем партцирование?

При наличии у тебя в таблице ну скажем пары-тройки сотен миллионов записей деградация производительности при массовой вставке/удалении данных становится заметной, а при приближении к полумиллиардам может убить твоё приложение совсем. Да и при селектах одно дело сканировать 10 миллиардов записей, другое — 10 миллионов. Даже по ключу.

К этому можно добавить ещё следующие возможности:

— ребилд идексов и статистики для отдельно взятой партиции.
— компрессия отдельных партиций.
— хранение отдельных партиций на разных носителях, например, более свежих данных на SSD, старых и не очень используемых на HDD (и ещё можно их поджать)
— truncate отдельных партиций.
— partition switching — мгновенный перенос данных из одной таблицы в другую.

У нас деградация производительности началась примерно к тремстам миллионам записей в основных таблицах. Добавили портиционирование. Сейчас в одной таблице у нас как раз те самые 10 миллиардов и никакой деградации не наблюдается. Всего у нас сейчас порядка 750 партиций. Т.е. физически эти 10 BN разбиты на 750 частей, в каждой по 10-15 M записей, что делает работу с ними вполне адекватной.

Здравствуйте, kov_serg, Вы писали:

_>Я про сбои в самих данных даже если они иногда переезжают в озу и обратно можно словить не ожиданные изменения. Т.к. надёжность оборудования всё же конечная и на больших объёмах вероятность получить битые данные гораздо выше несмотря на все контрольные суммы, коды Рида-Соломона и регулярные бэкапы.

А какая связь между объемом данных и отказаустойчивостью железа? Что там может не так сработать в отличие от small dat'ы? Можно подробнее про неожиданные изменения?

Здравствуйте, IT, Вы писали:


IT>При наличии у тебя в таблице ну скажем пары-тройки сотен миллионов записей деградация производительности при массовой вставке/удалении данных становится заметной, а при приближении к полумиллиардам может убить твоё приложение совсем.
вот это странно, если добавляются скажем так последние операции (допусти разбиение по дате операции) и дата операции кластерный индекс, то данные фактически будут вставляться
в конец, какая разница сколько их там в начале? то есть в моем понимании по сути это всё равно что дописывать в конец большого файла, это не зависит от того сколько в нем данных.
допустим даже не в конец (вставка в середину периода), то за счет страничной организации данных, где-то будет сплит и указатель на новые вставляемые данные, которые фактически будут дописываться в конец файла.
также замедляет производительность перестройка индексов. тут важно их кол-во. но насколько я понимаю, значительно меньшую роль играет его размер, тк опять же при вставке в индекс
будет модифицироваться какой-то его локальный кусок и неважен полный его размер.


IT>Да и при селектах одно дело сканировать 10 миллиардов записей, другое — 10 миллионов. Даже по ключу.
дак в том то и дело, что из-за колонки "которую ты используешь абсолютно во всех запросах в качестве фильтра" сканиться будет вполне конкретный кусок
и одинаковый в обоих случаях. то есть за счет индекса мы выйдем на начало участка записей и далее линейно (если ключ кластерный) сканим. что это партиция что часть большой таблицы разницы не должно быть.


IT>К этому можно добавить ещё следующие возможности:
IT>- ребилд идексов и статистики для отдельно взятой партиции.
IT>- компрессия отдельных партиций.
IT>- хранение отдельных партиций на разных носителях, например, более свежих данных на SSD, старых и не очень используемых на HDD (и ещё можно их поджать)
IT>- truncate отдельных партиций.
IT>- partition switching — мгновенный перенос данных из одной таблицы в другую.
это да.


IT>У нас деградация производительности началась примерно к тремстам миллионам записей в основных таблицах.
непонятна природа деградации, если всегда использовать фильтр по ключу.

Здравствуйте, MadHuman, Вы писали:

MH>вот это странно, если добавляются скажем так последние операции (допусти разбиение по дате операции) и дата операции кластерный индекс, то данные фактически будут вставляться

В этом индексе не одно поле. И, кстати, в случае партиционирования, эту ключ-солонку можно из индекса убрать.

MH>в конец, какая разница сколько их там в начале? то есть в моем понимании по сути это всё равно что дописывать в конец большого файла, это не зависит от того сколько в нем данных.
MH>допустим даже не в конец (вставка в середину периода), то за счет страничной организации данных, где-то будет сплит и указатель на новые вставляемые данные, которые фактически будут дописываться в конец файла.

Видимо даже в этом случае ковыряться в 10 M записях проще, чем в 10 BN.

MH>также замедляет производительность перестройка индексов. тут важно их кол-во. но насколько я понимаю, значительно меньшую роль играет его размер, тк опять же при вставке в индекс
MH>будет модифицироваться какой-то его локальный кусок и неважен полный его размер.

Вообще-то индекс в процессе должен балансироваться и когда-нибудь придётся перебалансировать все 10 BN записей.

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

Это только в теории. Если у тебя запрос простой и оптимизатор решил всё правильно. У нас частой ошибкой разрабов бало написание такого SQL:

select *
from partitioned_table1 t1
join partitioned_table1 t2 on t.key_column = t2.key_column
where t1.key_column = 10

Казалось бы у оптимизатора есть вся информация и он для t2 может легко вычислить значение ключ-колонки. Но нет. Не всегда. Не на всех версиях сервера. При потере статистики и т.д. Добавление условия по t2 в явную всегда решало проблему. Если здесь вообще убрать партиционирование, то в сложных запросах пути оптимизатора окажутся совсем неисповедимы.

MH>и одинаковый в обоих случаях. то есть за счет индекса мы выйдем на начало участка записей и далее линейно (если ключ кластерный) сканим. что это партиция что часть большой таблицы разницы не должно быть.

Как это нет? Просканить 10 миллиардов записей вообще-то не очень хорошая затея.

IT>>У нас деградация производительности началась примерно к тремстам миллионам записей в основных таблицах.
MH>непонятна природа деградации, если всегда использовать фильтр по ключу.

Думаю там у них под партиционирование много чего заточено внутри. Особенно последние версии SQL сервера ведут себя ну очень грамотно. Мой пример на последней версии всегда работает корректно, я его пока не смог сломать. Поэтому скорее всего если таблица партиционированная и есть ключ-колонка в фильтре, то решения принимаются ещё на ранних стадиях, а учитывая, что даже статистика на партиции отдельная на каждую, то запрос можно построить гораздо эффективнее, чем на всю таблицу целиком.

S>А какая связь между объемом данных и отказаустойчивостью железа? Что там может не так сработать в отличие от small dat'ы? Можно подробнее про неожиданные изменения?
память бьется. типично в одном диме 1 ошибка в мес
если димм с ECC, то большинство будет восстановлено, будет ~1 невосстановимая ошибка в год. а в серваке у нас их пусть 48
и опаньки — уже 4 невосстановимые ошибки в мес
понятно что в основном оперативка используется как кэш, и должны сойтись звезды чтобы битая страница кэша была модифицирована и отправлена на запись, но серваки не перегружают по много месяцев.
Серьезные производители ловят событие от железа, и перечитывают битую страницу.
Короче это реально происходит, пару раз натыкался.

Здравствуйте, rm822, Вы писали:


S>>А какая связь между объемом данных и отказаустойчивостью железа? Что там может не так сработать в отличие от small dat'ы? Можно подробнее про неожиданные изменения?
R>память бьется. типично в одном диме 1 ошибка в мес
R>если димм с ECC, то большинство будет восстановлено, будет ~1 невосстановимая ошибка в год. а в серваке у нас их пусть 48
R>и опаньки — уже 4 невосстановимые ошибки в мес

А можно чуть подробнее про невосстановимость при ECC и прочих избыточных кодах?

R>понятно что в основном оперативка используется как кэш, и должны сойтись звезды чтобы битая страница кэша была модифицирована и отправлена на запись, но серваки не перегружают по много месяцев.
R>Серьезные производители ловят событие от железа, и перечитывают битую страницу.

Ну типа того, и в чем тогда проблема, если все это решается на уровне железа? Как можно битые данные получить?

Здравствуйте, rm822, Вы писали:

R>память бьется. типично в одном диме 1 ошибка в мес
У тебя статистика не правильная
Какой техпроцесс, какая частота, какой объем, какой производитель и т.д.....
Плюс учитывай, что есть разница между сбоем в банке памяти и кучей систематических ошибок, к которым он привёл и случайной ошибкой (последние, как считается, случаются реже).

R>если димм с ECC, то большинство будет восстановлено, будет ~1 невосстановимая ошибка в год. а в серваке у нас их пусть 48
R>и опаньки — уже 4 невосстановимые ошибки в мес
Есть предел восстановления, а есть предел обнаружения. Однобитные ошибки исправляются, многобитные (до определенного предела) — обнаруживаются и сервер вываливается в синий экран.
Если идти твоими расчетами, то будет не "~1 невосстановимая ошибка в год/4 невосстановимые ошибки в мес", а BSOD из-за неккоректируемой ошибки памяти.

R>понятно что в основном оперативка используется как кэш, и должны сойтись звезды чтобы битая страница кэша была модифицирована и отправлена на запись, но серваки не перегружают по много месяцев.
Да нет, просто ECC это маленький кусочек. Есть штуки вроде SDDC / Online Spare / Mirror Memory / Fast Fault Tolerance / Memory scrubbing — и куча всего остального. От банального зеркалирования половины памяти во вторую половину — когда для сбоя неккоректируемый ECC сбой должен возникнуть одновременно в одних и тех же ячейках разных модулей, до хитрых мапингов адресов когда bios/os маркирует область памяти как lockstep и не используют из-за потенциальной возможности возникновения ошибок.

R>Серьезные производители ловят событие от железа, и перечитывают битую страницу.
Это далеко не всегда возможно и сложно писать ПО которое адекватно работает с такими событиями, поэтому обычно стараются не доводить.

R>Короче это реально происходит, пару раз натыкался.
ИМХО в реальном Enterprise, на хорошем и корректно настроенном железе вероятность стремится к нулю. Но есть, 100% защита отсутствует, всё мирятся с ничтожной вероятностью столкнутся вживую.

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

Здравствуйте, кубик, Вы писали:

К>Кто работает с базами больше 2х террабайт, расскажите почему ваша база такая большая. Можно ли сделать ее поменьше за счет переноса части необновляемых данных по базам.
К>Например по годам рассортировать....

Честно, лично — не работаю. Но наблюдал коллег. Базы у них такие большие, просто потому что так можно. Ну т.е. в одну базу совать всё, что не попадя, любым образом, лишь бы было удобно программировать поверх этого. И поскольку по рукам никто не бьет, железо дают, то какими-то переносами, сортировками или даже партицированием тупо не заморачиваются... Пользователь подождёт.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, kov_serg, Вы писали:

IT>>>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
_>>Как обеспечиваете целостность данных на таких объёмах?

IT>Используем СУБД.

с включенными FK ?

Здравствуйте, Gt_, Вы писали:

IT>>Используем СУБД.
Gt_>с включенными FK ?

Местами