Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
FreeBard Member Откуда: Сообщений: 223 |
Всем доброго времени суток! На собеседовании задали вопрос - какие есть особенности проектирования и создания базы под очень большие объемы данных. Не нашелся что ответить. Кто в теме, просветите по вопросу на будущее..) Интересуют ответы и со стороны dba и со стороны разработчика |
27 дек 18, 22:25 [21775292] Ответить | Цитировать Сообщить модератору |
SERG1257 Member Откуда: Сообщений: 2828 |
https://en.wikipedia.org/wiki/Very_large_database
|
||
27 дек 18, 22:49 [21775306] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
FreeBard, Я б решил, что это вопрос с подвохом. Возможно они хотели от вас встречных вопросов по поводу определения "очень большие объемы данных". Например вопрос о способе работы с этими данными: будет ли это dwh или oltp или смешанная система. Какие ожидания по скорости доступа/задержкам. Что им надо от базы собственно из CAP и так далее. |
27 дек 18, 22:51 [21775307] Ответить | Цитировать Сообщить модератору |
FreeBard Member Откуда: Сообщений: 223 |
Возможно. Я как разработчик не нашелся что ответить..) решил что в основном это в компетенции dba - планирование, какие то предварительные действия с заделом на последующий объем данных. |
||
27 дек 18, 23:10 [21775310] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
FreeBard, Мне кажется, что работы для dba тут много в любом случае, но основные методики и good practices более менее известны и стандартизованы. С точки зрения dbd тут уже сложнее, так как надо смотреть на конкретные требования задачи, предлагать решения и обсуждать плюсы и минусы конкретных реализаций. |
27 дек 18, 23:30 [21775318] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Делать так, чтобы работало за приемлемое время и при 100 записях, и при 100 млрд. записей. Желательно сразу. |
27 дек 18, 23:33 [21775322] Ответить | Цитировать Сообщить модератору |
londinium Member Откуда: Киев Сообщений: 1194 |
А есть какой-то достойный доверия и уважения компендиум по настройке MS SQL Server для очень больших БД? |
||
27 дек 18, 23:50 [21775329] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
Сообщение было отредактировано: 28 дек 18, 00:02 |
||||
28 дек 18, 00:01 [21775333] Ответить | Цитировать Сообщить модератору |
PizzaPizza Member Откуда: Сообщений: 417 |
Думаю, что тут скорее речь не о настройке сервера, а о таких вещах как кластеры репликации alwayson кубернетис схд you-name-it. Когда что имеет смысл применять и как настраивать. |
||||
28 дек 18, 00:13 [21775338] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Со стороны разработчика - активное использование секционирования больших таблиц и файловых групп. Со стороны DBA - раскладка "архивных" секций крупных таблиц на диски HDD и "свежих" секций на диски SSD, отдельный том (и LUN на дисковой полке) для журнала транзакций, отдельный том под tempdb (самый скоростной), выбивание из руководства бюджета на лицензии SQL Enterprise Edition, подготовка AlwaysOn AvGroups или отказоустойчивого кластера (FCI), регулярное чтение MSDN и согласованное с разработчиками накатывание свежих SP и CU, разворачивание мониторинга с отрисовкой важных показателей, согласованных с разработчиками, на дашбордах и предоставление доступа к ним для разработчиков и службы Service Desk. Внимательная настройка совместно с разработчиками Resource Governor и разделение всех пользователей такой крупной БД на группы с различным приоритетом доступа к ресурсам сервера. Для DBA - мониторинг свободного места на томах со всеми файлами БД, включая служебные базы инстанса MSSQL, и рассылка регулярных почтовых уведомлений, в том числе разработчикам (не все смотрят дашборды, а служебную почту читают все). |
||
28 дек 18, 00:18 [21775340] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Поскольку наверняка такая БД будет в группе AlwaysOn - нужно будет заранее продумать, кому к каким репликам давать доступ. И самое главное - минимизировать использование триггеров (потом скажете спасибо еще не один раз). |
||
28 дек 18, 00:20 [21775343] Ответить | Цитировать Сообщить модератору |
FreeBard Member Откуда: Сообщений: 223 |
Andy_OLAP, Спасибо! |
28 дек 18, 00:35 [21775346] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34664 |
Никаких особенностей нет. Может кроме одной - если не сделаешь индексы, работать не будет вообще |
||
28 дек 18, 08:14 [21775412] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1403 |
Любую БД нужно проектировать с учетом вероятного существенного роста. Заложить возможности прозрачной урезки/архивации данных без потери функциональности. |
||
28 дек 18, 10:34 [21775499] Ответить | Цитировать Сообщить модератору |
StarikNavy Member Откуда: Москва Сообщений: 2396 |
с другой стороны эти же требования можно выставить и к работе с мимальной базюлькой, но с архиважной информацией или просто высоконагруженной ) |
||
28 дек 18, 10:38 [21775505] Ответить | Цитировать Сообщить модератору |
Александр Гладченко Member Откуда: Сообщений: 10765 Блог |
AlwaysOn с трудом тянет даже большие базы (~10Tb), а уж очень большие - большой вопрос. Почитайте про ограничения REDO. Автору топика: SQL Server - дело тонкое..., а когда базы превышают десятки Терабайт, всё становиться на порядок сложнее, и нужно уделять пристальное внимание даже мелочам (в понимании обычных размеров). Очень многих вещей просто не станет, как то высокой доступности и (зачастую) готовности. Придётся всё "пилить", масштабировать и держаться подальше от виртуализации ;) Сообщение было отредактировано: 28 дек 18, 11:25 |
||
28 дек 18, 11:25 [21775546] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8340 |
Мое мнение - разработчику разрабатывать как обычно, вопросы большой базы относятся на 99% к архитектору, а не к разработчику. Если работодатель не видит разницы, то лучше откажитесь от этой работы, ибо превратитесь у такого работодателя из специалиста в разнорабочего на подхвате. |
28 дек 18, 13:12 [21775670] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1403 |
Речь шла о том, кто разрабатывает конкретную БД. |
||
28 дек 18, 13:28 [21775683] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8340 |
L_argo, в каком смысле умничание? Если вы чего-то не знаете, что это не значит, что остальные также глупы. Требования к компетенциям архитектора БД разительно отличаются от требованиям к разработчику кода и такое понятие, как "разработчик БД", существует лишь на проектах уровня SOHO, но там больших баз нет и в помине. |
28 дек 18, 13:31 [21775692] Ответить | Цитировать Сообщить модератору |
Danion Member Откуда: Москва Сообщений: 242 |
L_argo, На мой взгляд - действительно структуру создаваемой базы продумывает архитектор. Разработчик реализовывает идеи в плане кода, от админа баз данных нужны рекомендации по отказоустойчивости, настройка бекапирования, мониторинга, настройка идей архитектора по параметрам БД. Но чаще таких должностей нет. И все настраивается: ок, далее, далее ок. |
28 дек 18, 13:36 [21775699] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4807 |
Если речь идет о OLTP, то смотрите в сторону Микросервесной архитекруты, если речь о ХД смотрите в сторону Data Vault и Anchor Model И такие вещи как партиционирование, колоночные индексы становятся актуальными Вообще лучше решение не делать одной большой БД |
||
28 дек 18, 13:44 [21775714] Ответить | Цитировать Сообщить модератору |
FreeBard Member Откуда: Сообщений: 223 |
Это был вопрос скорее на "замер глубины понимания и общей компетенции" )) |
||
28 дек 18, 13:55 [21775732] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
"какие есть особенности проектирования и создания базы под очень большие объемы данных. Не нашелся что ответить" - автору темы нужно было бы ответить "После назначения меня на должность главного разработчика по созданию базы под очень большой объем данных первым делом я найму себе в заместители Воронина". |
||||
28 дек 18, 13:58 [21775736] Ответить | Цитировать Сообщить модератору |
FreeBard Member Откуда: Сообщений: 223 |
В следующий раз так и сделаю..!;)) |
||||
28 дек 18, 14:04 [21775741] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34749 Блог |
Тонкостей много, например: Если БД очень большая, то у компании скорее всего имеется тестовая среда, а часто и не одна. Поэтому нужно продумать размещение данных по ФГ заранее, чтобы оставить на тесте только маленький кусочек данных (например, последние 2 года). Иначе тестовая среда станет золотой по дисковому пространству. При административных операциях нужно очень сильно обдумать их последствия, иначе можно просто заблочить все на несколько часов. Но вообще, oltp системы стараются до такого не доводить, просто обрезают их через год-два-пять, а старье отправляется в архив. Поэтому скорее всего вопрос был про отличие oltp-систем и хранаищ данных. |
30 дек 18, 00:35 [21776742] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |