S>А можно чуть подробнее про невосстановимость при ECC и прочих избыточных кодах?
гугл когда-то проводил масштабное исследование https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/
S>Ну типа того, и в чем тогда проблема, если все это решается на уровне железа? Как можно битые данные получить?
может решается а может и нет.
сейчас уже большинство арендует железки в дата центрах, лично я не верю в их надежность, судя по демпинговым ценам....
Здравствуйте, rm822, Вы писали:
S>>Ну типа того, и в чем тогда проблема, если все это решается на уровне железа? Как можно битые данные получить? R>может решается а может и нет.
Ну выше написали, что в случае чего BSOD или kernel panic (?), а не битые данные пользователя.
S>Ну выше написали, что в случае чего BSOD или kernel panic (?), а не битые данные пользователя.
хрена с два там какой-то бсод происходит, в логе появляется событие о hard memory error и все продолжает работать как будто и не было ничего....
ах ну да, на серваке может загориться светодиод, ...если есть.... вот только когда еще на него кто посмотрит. а если посмотрит, то неизвестно что будет делать.
может просто сбросит алерт и всё. сервак-то в аренду сдан или выкуплен. на кой хрен какой-то гемор себе пока клиент не жалуется....
а в серваках подешевле вообще ничего не появляется. и гадай как хочешь
Здравствуйте, rm822, Вы писали:
S>>Ну выше написали, что в случае чего BSOD или kernel panic (?), а не битые данные пользователя. R>хрена с два там какой-то бсод происходит, в логе появляется событие о hard memory error и все продолжает работать как будто и не было ничего....
Вот казалось бы гугл с нами, "hard memory error" третий ссылкой выдаёт https://support.hpe.com/hpesc/public/docDisplay?docId=c03111253
Где расписано, что soft и hard memory error — это корректируемые ошибки и в чём между ними разница.
R>ах ну да, на серваке может загориться светодиод, ...если есть.... вот только когда еще на него кто посмотрит. а если посмотрит, то неизвестно что будет делать. R>может просто сбросит алерт и всё. сервак-то в аренду сдан или выкуплен. на кой хрен какой-то гемор себе пока клиент не жалуется....
Потому что hard memory error — это скорректированные ошибки, но их много и bios предупреждает, что модуль памяти желательно заменить, пока не начали возникать некорректируемые сбои и остановка системы.
R>а в серваках подешевле вообще ничего не появляется. и гадай как хочешь
Ну не знаю, что уж там за сервера подешевле, но некорректируемые ошибки памяти приводят к остановке системы даже для Supermicro и всё там с ECC памятью нормально.
PS. У меня есть лично возникает впечатление, что в силу недостатка знаний/опыта штатные ситуации, в которых ECC память защитила от сбоев трактуются как фейлы этой технологии. И порождают охоту на ведьм.
Ошибки возможны. Они могут быть не только в памяти, но и при передаче данных, и в процессоре и на HDD/SSD и т.д. Нет сквозной защиты, которая гарантировала бы на всех этапах 100% целостность данных. Кроме ECC есть куча мест где теми или иными способами идёт проверки на целостность — совокупно они не дают эти самые 100%, но вероятность при правильно эксплуатируемом серверном железе столкнутся с такими ошибками пренебрежительно мала.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, кубик, Вы писали:
К>>Кто работает с базами больше 2х террабайт, расскажите почему ваша база такая большая. Можно ли сделать ее поменьше за счет переноса части необновляемых данных по базам. К>>Например по годам рассортировать....
IT>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование.
А если не секрет, какая база (MS SQL, Oracle, Postgres, mysql), какое железо?
Здравствуйте, Lonely Dog, Вы писали:
IT>>У нас более 5 террабайт реляционных данных. Потому-что мы собираем много данных по банку и генерируем обобщённые, по которым делаем свои расчёты. Выносить в другие базы ничего не нужно. Нужно использовать партиционирование. LD>А если не секрет, какая база (MS SQL, Oracle, Postgres, mysql), какое железо?
MS SQL. Про железо подробностей не знаю. Знаю только, что оно большое и его много.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, paucity, Вы писали:
P>А в местах где FKs "выключены", как целостность обеспечивается?
Алгоритмами. Например, в случае падения многоступенчатого процесса, перед его перезапуском выполняется проверка на наличие и удаление недоданных. Где можно используются staging таблицы и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, paucity, Вы писали:
P>>А в местах где FKs "выключены", как целостность обеспечивается?
IT>Алгоритмами. Например, в случае падения многоступенчатого процесса, перед его перезапуском выполняется проверка на наличие и удаление недоданных. Где можно используются staging таблицы и т.п.
угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
обычно дальше идет вопрос, а правильно ли тогда использовать субд, если с определенных объемов уже ни целостность ни транзакционность не применить.
Здравствуйте, Gt_, Вы писали:
Gt_>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся. Зачем изобретать велосипеды? Отказ от транзакций происходит только, если это не возможно в принципе. Например, если данные генерируются разными процессами в разное время. Снятие флага CHECK CONSTRAINT с FK делается в основном из соображений производительности. Например, partition switching позволяет переносить данные из одной таблицы в другую в одно мгновение. В то время как обычный INSERT INTO и DELETE занимает в общей сложности минут 40. Стоит такая экономия усложнения обеспечения целостности, если учесть, что это только один из способов сэкономить?
Gt_>обычно дальше идет вопрос, а правильно ли тогда использовать субд, если с определенных объемов уже ни целостность ни транзакционность не применить.
По-твоему, субд — это только целостность и транзакционность? И какие альтернативы?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
Gt_>>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
IT>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся. Зачем изобретать велосипеды?
что бы не получить минусы из обоих миров. вы отключили констреинты, отказались от транзакций в пользу exchange partition, у клиента подозреваю и консистентно вычитать уже и не выйдет. но при этом вы остались с тяжелой прослойкой субд, которая слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
IT>По-твоему, субд — это только целостность и транзакционность?
ну да. ну еще может консистентная выборка.
IT>И какие альтернативы?
файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек показывает, внешние потребители в основной массе и не поймут, что там файлики, а не субд.
вот только колхозить и костылись заметно больше приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Здравствуйте, rm822, Вы писали:
R>если димм с ECC, то большинство будет восстановлено, будет ~1 невосстановимая ошибка в год. а в серваке у нас их пусть 48
Невосстановимая ошибка в нынешних Линуксах просто приведёт к извлечению страницы из памяти (если в кэше) или убийству процесса (если в памяти процесса).
В теории могут быть ошибки, которые не обнаруживаются ECC, но это уж очень редкое явление.
Здравствуйте, Gt_, Вы писали:
IT>>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся. Зачем изобретать велосипеды? Gt_>что бы не получить минусы из обоих миров.
Из каких "обоих" миров? Почему не всех трёх или сразу пятнадцати? Что за миры такие?
Gt_>вы отключили констреинты, отказались от транзакций в пользу exchange partition,
Не от транзакций, а от check constraint. Не отказались, а локально применили другое решение. Не в пользу exchange partition, а в пользу partition switching.
Gt_>у клиента подозреваю и консистентно вычитать уже и не выйдет.
Что, простите?
Gt_>но при этом вы остались с тяжелой прослойкой субд, которая слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
Мне сложно коментировать этот набор домыслов, т.к. по всей видимости он относится к твоей конкретной ситуации и требует расшифровки контекста именно твоей ситуации. Лично у меня никакой тяжести субд нет, слабых параллелей не замечено, и главное — цена не имеет значения.
IT>>По-твоему, субд — это только целостность и транзакционность? Gt_>ну да. ну еще может консистентная выборка.
Это какой-то новый термин "консистентная выборка"? Набрал в гугле — субд "консистентная выборка", получил — No results found for субд "консистентная выборка".
IT>>И какие альтернативы? Gt_>файлики, бигдата.
Понятно. Ты мне предлагаешь нереляционную файло/бигдата помойку.
Gt_>в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек показывает, внешние потребители в основной массе и не поймут, что там файлики, а не субд.
Зачем мне всё это? Файлики, уяйлики, кластеры, уястеры. Что за чушь?
Gt_>вот только колхозить и костылись заметно больше приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Т.е. альтернатива — колхозить и костылить
Если нам не помогут, то мы тоже никого не пощадим.
Gt_>>вы отключили констреинты, отказались от транзакций в пользу exchange partition, IT>Не от транзакций, а от check constraint. Не отказались, а локально применили другое решение. Не в пользу exchange partition, а в пользу partition switching.
partition switching = отказ от транзаций.
Gt_>>у клиента подозреваю и консистентно вычитать уже и не выйдет. IT>Что, простите?
гугли, что такое read consistency. блокировочный RC выдает неконсистентную кашу, а чтения на уровне транзакции RCSI partition switching завершает с ошибкой.
Gt_>>но при этом вы остались с тяжелой прослойкой субд, которая слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет. IT>Мне сложно коментировать этот набор домыслов, т.к. по всей видимости он относится к твоей конкретной ситуации и требует расшифровки контекста именно твоей ситуации. Лично у меня никакой тяжести субд нет, слабых параллелей не замечено, и главное — цена не имеет значения.
у тебя тот самый мсскл, что не масштабируется толком даже в пределах одной машины, заливка в одну партицию практически не параллелится, я уж не говорю о том что по узлам кластера вообще никак не масштабируется. из-за тормозов и сложностей масштабирования прослойки тяжелые заливки принято отдельными ETL инструментами делать.
IT>Это какой-то новый термин "консистентная выборка"? Набрал в гугле — субд "консистентная выборка", получил — No results found for субд "консистентная выборка".
термин из учебников: read consistency. подробней например тут statement/transaction level read consistency https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15
IT>Понятно. Ты мне предлагаешь нереляционную файло/бигдата помойку.
помойки не приживаются в фин и банковских секторах.
IT>Зачем мне всё это? Файлики, уяйлики, кластеры, уястеры. Что за чушь?
не знаю зачем ты про альтернативу спросил.
IT>Т.е. альтернатива — колхозить и костылить
да. по мне так интересней майкрософтского легаси. да и по деньгам бигдата интересней.
Здравствуйте, Gt_, Вы писали:
Gt_>файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек показывает, внешние потребители в основной массе и не поймут, что там файлики, а не субд.
А чем пользователи эти почти таблички смотрят? (к тому, что пользователям сами по себе таблички не нужны, им нужны отфильтрованные по разным условиям данные из разных табличек, сиречь joints)
Gt_>>файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек показывает, внешние потребители в основной массе и не поймут, что там файлики, а не субд.
P>А чем пользователи эти почти таблички смотрят? (к тому, что пользователям сами по себе таблички не нужны, им нужны отфильтрованные по разным условиям данные из разных табличек, сиречь joints)
поверх этих файликов mpp engine. у нас предпочитают cloudera impala, которая тяготеет к inmemory. там вполне навороченый SQL, понятно что с JOIN, с CTE, аналитическими запросами типа over() partition by, LEAD() и т.п.
еще популярен hive и spark sql. майкрософт как я понял spark sql сейчас любит, hadoop+spark недавно запихнули в mssql2019
Здравствуйте, Gt_, Вы писали:
Gt_>partition switching = отказ от транзаций.
Видимо ты думаешь, что у меня в системе две таблицы и моё приложение только и занимается тем, что тысячи раз в секунду переключает партиции между ними и одновременно открывает и закрывает транзакции. Уверяю тебя, это не так. Поэтому, в моём случае partition switching != отказ от транзаций.
Gt_>гугли, что такое read consistency. блокировочный RC выдает неконсистентную кашу, а чтения на уровне транзакции RCSI partition switching завершает с ошибкой.
У меня складывается такое впечатление, что ты пытаешься натянуть МОИ решения на ТВОЮ задачу, у тебя это не получается и я в этом очень сильно виноват. Я прав? В принципе, я такую логику часто встречаю, но у женщин. Ты — женщина?
Gt_>у тебя тот самый мсскл, что не масштабируется толком даже в пределах одной машины, заливка в одну партицию практически не параллелится, я уж не говорю о том что по узлам кластера вообще никак не масштабируется. из-за тормозов и сложностей масштабирования прослойки тяжелые заливки принято отдельными ETL инструментами делать.
Мадам, мы в течении дня генерируем около 250M записей, всё это зиливаем в базу без особых тормозов, сложностей масштабирования и отдельных ETL инструментов. Что мы делаем не так?
Gt_>термин из учебников: read consistency. подробней например тут statement/transaction level read consistency
Трудности перевода. Понимаю. Это переводится как 'согласованность чтения'.
IT>>Понятно. Ты мне предлагаешь нереляционную файло/бигдата помойку. Gt_>помойки не приживаются в фин и банковских секторах.
Ну почему же. Была у меня одна такая команда. У них данных было петабайты. Всё как тебе нравится — файлики, бигдаты. Сваливают туда всё без разбора, что касается legal. Вообще всё. На вопрос "парни, а как вы в этом ищите, если вам пришёл запрос?", ответ примерно "ну, за недельку-две найдём что-нибудь в нашей помоечке".
Т.е. на вопрос "это помойка?" ответ утвердительный.
На вопрос "это банк?" ответ тоже утвердительный.
"Всё это работает?" — "Вполне".
Вывод — помоечки в банке приживаются.
IT>>Зачем мне всё это? Файлики, уяйлики, кластеры, уястеры. Что за чушь? Gt_>не знаю зачем ты про альтернативу спросил.
Так я ожидал вменяемую альтернативу, а не это.
Если нам не помогут, то мы тоже никого не пощадим.
IT>У меня складывается такое впечатление, что ты пытаешься натянуть МОИ решения на ТВОЮ задачу, у тебя это не получается и я в этом очень сильно виноват. Я прав?
нет, не прав. ты сейчас злишься, прекрасно понимая, что задачи хранилища у всех одинаковые и я лучше твоего знаю что и как ты сделал и почему тебе пришлось приседать с partition switch и с контролем целостности. и дело не только в partition switch, в разные таблицы данные ты льешь в рамках несвязанных транзакций, ломая всю концепцию прослойки вокруг транзакции и read consistency.
IT>Мадам, мы в течении дня генерируем около 250M записей, всё это зиливаем в базу без особых тормозов, сложностей масштабирования и отдельных ETL инструментов. Что мы делаем не так?
не так то, что ты не убрал причину тормозов, а лишь отключил у прокладки некоторые из систем контроля. отключение FK и partition switch лишь отодвинули момент, когда задача не поместиться в одну машину.
IT>Вывод — помоечки в банке приживаются.
скорее что товарищи посмеялись над тобой. закон о защите данных не позволяет банку свалить что-то в сыром виде на потом.
IT>Так я ожидал вменяемую альтернативу, а не это.
майкрософт не та компания, какой интересно твое мнение. важно что майкрософт это считает альтернативой и hadoop+spark уже в mssql2019
Если нам не помогут, то мы тоже никого не пощадим.
