G>Вы даже не понимаете на что ссылаетесь.
G>Эти люди делают Data Warehouse, куда грузят тонны данных для дальнейшей аналики (read-only доступа). Внезапно на время загрузки выгодно отключить проверку FK, потому что она избыточна и не дает распараллеливать операции.

G>Чтобы отключить FK должно выполниться сразу три условия:
G>1) Загрузка данных из системы, где FK есть.
G>2) Отключать FK в продакшене, но на этапе проектирования использовать FK для самокотроля
G>3) Запись большого объема за один раз.

спасибо кэп ! но у меня вопрос, зачем писать эти банальности мне ? ты это напиши Sinclair, который заявил

такие "трюки" применяются по невежеству

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

Ops>>Т.е. каждый житель США каждые 20 секунд обращается к амазону?
C>300 миллионов запросов в секунду — это около 15 миллионов просмотров страниц в секунду. Американцев и канадцев — около 350 миллионов.

Ок, каждые 23 секунды. Каждый. Без сна и отдыха. По 3700 страниц в день.

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

V>Пофик, тут степенная ф-ия от вероятности "застрять".
Это если рандом. Но подозреваю, что реальные системы не совсем случайно работают, и может возникнуть ситуация, когда несколько потоков висят заметно долго.
V>Т.е. вероятность того, что поток не продвинется на следующем такте очень быстро стремится к 0-лю с каждым заходом на новый круг.
Формулировка — . Случайное событие не зависит от предыдущих случайных событий.
Но с тем, что ты хотел сказать, пусть и получилось криво, в принципе согласен, с предыдущей оговоркой.

Здравствуйте, Ballista, Вы писали:
B>спасибо кэп ! но у меня вопрос, зачем писать эти банальности мне ? ты это напиши Sinclair, который заявил
B>

B>такие "трюки" применяются по невежеству

Восстанавливаем целостность мысли после фигурной резьбы по цитатам:

Как правило, такие "трюки" применяются по невежеству

А если ещё немножко вверх отмотать, то выясняется, что отключение FK предлагается не как решение для одного специфичного сценария, а как общий рецепт "для повышения быстродействия".
И прикол как раз в том, что убирание FK повышает не всякое быстродействие.
"Согласование" таблиц в RDBMS — это не просто гиря на ногах, дополнительные проверки на модифицирующие операции, но и семантическая оптимизация и улучшение предсказаний селективности.

B>>спасибо кэп ! но у меня вопрос, зачем писать эти банальности мне ? ты это напиши Sinclair, который заявил
B>>

B>>такие "трюки" применяются по невежеству

S>Восстанавливаем целостность мысли после фигурной резьбы по цитатам:
S>

S>Как правило, такие "трюки" применяются по невежеству

и как твои банальности опровергают то что как правило отключают люди хорошо знакомые с темой ?

S>А если ещё немножко вверх отмотать, то выясняется, что отключение FK предлагается не как решение для одного специфичного сценария, а как общий рецепт "для повышения быстродействия".
S>И прикол как раз в том, что убирание FK повышает не всякое быстродействие.
S>"Согласование" таблиц в RDBMS — это не просто гиря на ногах, дополнительные проверки на модифицирующие операции, но и семантическая оптимизация и улучшение предсказаний селективности.

и снова банальности, которые и так были в моей цитате.

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

V>А если система принципиально способна давать ответы со скоростью их поступления, и если кривая быстродействия положительная (а она обязана быть положительной у грамотно спроектированной системы) — там "класть" физически нечего. Нет механизма "кладки".
Ты серьезно утверждаешь, что NoSQL имеет бесконечную производительность? Типа dev/null ?
Огонь, жги дальше )))

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

G>Ага, clustered columnstore и json в MS SQL

Не, совсем не в ту калитку. Вот скажем у нас колонок потенциально десятки тысяч, причём в каждой строке заполнен от силы десяток колонок (и больше — не будет чисто по бизнес-причинам). Что скажет товарищ Маузер? (который SQL Server)

G>FTS в MS SQL

Полнотекстовый поиск по блобам — опять сильно мимо. Ведь случись необходимость формировать древовидную вложенность документов с поиском а-ля XPath — опять всё ручками на уровне приложения.

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

G>На самом деле вопросов много
G>1) Зачем жертвовать скоростью чтения, если по оценке корпоративное приложение имеет соотношение чтения к записи 98 к 2, а некоторые системы, типа OLAP, по сути вообще readonly?

тут каждый говорит о своем, судя по всему, лично я в основном работаю с аналитикой, которая собирается непрерывно и с вебом, где приходится писать тоже много, корпоративное приложение это что вообще?
readonly база? а зачем она, можно же просто файлы на диске.. :D

G>2) Кто мешает поставить несколько дисков, чтобы ускорить запись? Даже отдельные серверы не нужны. Если мы хотим ускорять запись, то зачем вообще ставить любую БД, просто писать файлы на диск, а в фоне обрабатывать.

Потому что не поможет, попробуй запиши кликстрим в РСУБД, где у тебя по миллиону вставок в секунду прилетает. У тебя один мастер, т.е. один сервер должен все обработать. Если ты знаком с access methods в РСУБД, то знаешь, что write amplification там огого какой, типичная РСУБД пишет очень много на диск (в лог, потом в хип файл, потом в индекс на btree, который по сути случайная запись в несколько разных мест). Ну а HBase просто допишет данные в wal и потом, когда-нибудь запишет это все на диск.

G>2) Кто мешает создать write-optimised таблицы в РСУБД, там где нужна скорость записи?

это как?

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

MD>Не, совсем не в ту калитку. Вот скажем у нас колонок потенциально десятки тысяч, причём в каждой строке заполнен от силы десяток колонок (и больше — не будет чисто по бизнес-причинам).

Дизайн через не то место

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

Ops>>>Т.е. каждый житель США каждые 20 секунд обращается к амазону?
Или каждый 20й житель обращается к амазону в одну и ту же секунду. Точнее, если одна страница это пара десятка запросов — то каждый четырёхсотый житель.

C>>300 миллионов запросов в секунду — это около 15 миллионов просмотров страниц в секунду. Американцев и канадцев — около 350 миллионов.
Ops>Ок, каждые 23 секунды. Каждый. Без сна и отдыха. По 3700 страниц в день.
Полагаю идёт речь о пиковой нагрузке, а ты, похоже, предполагаешь, что нагрузка равномерная. Если 15 млн человек начнут лихорадочно щёлкать по страницам в час X (чёрная пятница), то это нелегко выдержать, даже если через 1 минуту все пойдут спать и отдыхать.

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

G>Сервак был один.
Это — ключевое. Вам повезло, что с вашей нагрузкой может справиться один сервер. Однако, это не всегда так.

G>Когда собрали статку по нагрузке оказалось что один MS SQL эквивалентен примерно 6 монговским.
В это охотно верю. Вопрос — сколько MS SQL-ей будут эквивалентны 600 монговским сервакам и как там будет обстоять дело с ACID и CAP?

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

·>Полагаю идёт речь о пиковой нагрузке, а ты, похоже, предполагаешь, что нагрузка равномерная. Если 15 млн человек начнут лихорадочно щёлкать по страницам в час X (чёрная пятница), то это нелегко выдержать, даже если через 1 минуту все пойдут спать и отдыхать.

Да пусть пиковая. Пусть остальное даже 1/100 от этого. Ты серьезно веришь, что каждый житель, включая младенцев, каждый день хотя бы 50 страниц амазона посещает?

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

Ops>·>Полагаю идёт речь о пиковой нагрузке, а ты, похоже, предполагаешь, что нагрузка равномерная. Если 15 млн человек начнут лихорадочно щёлкать по страницам в час X (чёрная пятница), то это нелегко выдержать, даже если через 1 минуту все пойдут спать и отдыхать.

Ops>Да пусть пиковая. Пусть остальное даже 1/100 от этого. Ты серьезно веришь, что каждый житель, включая младенцев, каждый день хотя бы 50 страниц амазона посещает?
Причём тут "каждый день"? Это же средняя нагрузка. Он написал "15 миллионов просмотров страниц в секунду" — это в течение первых секунд чёрной пятницы на сайт припёрлось неск. миллионов человек и все начали лихорадочно тыкать на всё подряд в поисках распродаж повкуснее — запросто верю.
Кстати, у амазона ещё api есть, который могут использовать продавцы, партнёры, другие магазины. Надо уточнить у Киберакса насколько тяжел этот трафик и как он учитывается.

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

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

G>>Сервак был один.
·>Это — ключевое. Вам повезло, что с вашей нагрузкой может справиться один сервер. Однако, это не всегда так.
Во-первых "это" чаще так, чем не так для тех проектов, с которыми работают все пишущие в этой теме. Например stackoverflow работает на одном сервере. У него огромная нагрузка по сравнению тем, что вы могли видеть.
Во-вторых шардинг и использование множества серверов обычно требует локальности данных по группам ключей и хитрых алгоритмов обработки распределенных данных. Все тоже самое относительно несложно реализовать поверх обычных СУБД.

G>>Когда собрали статку по нагрузке оказалось что один MS SQL эквивалентен примерно 6 монговским.
·>В это охотно верю. Вопрос — сколько MS SQL-ей будут эквивалентны 600 монговским сервакам и как там будет обстоять дело с ACID и CAP?
Понятия не имею. Не видел в жизни задачи, для которой нужно 600 монговских серверов.

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

G>Все данные достаточно структурированные, чтобы положить их в РСУБД. Иначе с такими данными не получится работать никакими средствами. Даже теорема есть на эту тему.

Что за теорема?

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

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

G>>Ага, clustered columnstore и json в MS SQL

MD>Не, совсем не в ту калитку. Вот скажем у нас колонок потенциально десятки тысяч, причём в каждой строке заполнен от силы десяток колонок (и больше — не будет чисто по бизнес-причинам). Что скажет товарищ Маузер? (который SQL Server)
Тогда так
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2015/12/21/designing-product-catalogs-in-sql-server-2016-using-json/

Еще и индексировать можно
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2015/12/21/indexing-data-in-json-product-catalogs/

G>>FTS в MS SQL
MD>Полнотекстовый поиск по блобам — опять сильно мимо. Ведь случись необходимость формировать древовидную вложенность документов с поиском а-ля XPath — опять всё ручками на уровне приложения.
Что?

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

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

G>>Все данные достаточно структурированные, чтобы положить их в РСУБД. Иначе с такими данными не получится работать никакими средствами. Даже теорема есть на эту тему.

S>Что за теорема?

Не помню уже. Изучали в универе на курсе Баз Данных, что есть терема (лемма или хз чо еще), которая говорит что любые данные можно представить в виде набора таблиц с колонками.

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

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

G>·>Это — ключевое. Вам повезло, что с вашей нагрузкой может справиться один сервер. Однако, это не всегда так.
G>Во-первых "это" чаще так, чем не так для тех проектов, с которыми работают все пишущие в этой теме.
Ну "чаще" — может быть, на php тоже чаще пишут. Но что это доказывает?

G>Например stackoverflow работает на одном сервере. У него огромная нагрузка
stackoverflow сравнительно небольшой сайт, тут же вроде о всяких гуглах-амазонах рассуждали. Он популярный среди программистов (т.е. тебя) и прочих физиков, вот у тебя и сложилось впечатление что он большой и красивый. А спроси у своих друзей-родственников непрограммистов слышали ли они о таком сайте и оцени количество пользователей.
Кроме того, там основная нагрузка ложится вовсе не на mssql базу, а ВНЕЗАПНО на nosql штуковину ElasticSearch, и прочие redis-ы, проксяки-кеши.

G>по сравнению тем, что вы могли видеть.
Т.е. ты точно знаешь что кто мог видеть?

G>Во-вторых шардинг и использование множества серверов обычно требует локальности данных по группам ключей и хитрых алгоритмов обработки распределенных данных. Все тоже самое относительно несложно реализовать поверх обычных СУБД.
Тут [картинка про троллейбус из буханки] или "каша из топора" или банально карго-культ.

G>>>Когда собрали статку по нагрузке оказалось что один MS SQL эквивалентен примерно 6 монговским.
G>·>В это охотно верю. Вопрос — сколько MS SQL-ей будут эквивалентны 600 монговским сервакам и как там будет обстоять дело с ACID и CAP?
G>Понятия не имею. Не видел в жизни задачи, для которой нужно 600 монговских серверов.
Рад за тебя. Но что это доказывает?

Здравствуйте, Ballista, Вы писали:
B>и как твои банальности опровергают то что как правило отключают люди хорошо знакомые с темой ?
Ок, давайте проясним.
Во-первых, действительно, спорить о том, что "как правило", а что — "как исключение" — бессмысленно. В вашем окружении работают люди, хорошо знакомые с темой, а в моём — нет.
Я могу себе представить, что хорошие результаты достигаются там, где разработчики и эксплуатация тесно связаны между собой. В более традиционном сценарии разработка и эксплуатация находятся в разных юридических лицах, связанных между собой в лучшем случае контрактом на саппорт. В итоге разработчики питают разнообразные иллюзии по поводу того, как оно "на самом деле", а у эксплуатации нет доступа к коду и возможности экспериментировать.
В таком сценарии разработчики получают куцые обрывки сведений, прошедшие через саппорт тикет, и вынуждены принимать решения на авось. Возможности прогнать тяжёлые запросы на боевой базе с включенной трассировкой им никто не даст.

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

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

CK> Ну а HBase просто допишет данные в wal и потом, когда-нибудь запишет это все на диск.
Точно так же делает и любая вменяемая РСУБД. Более того, механизм wal как раз для РСУБД и был придуман, чтобы минимизировать задержки при записи, сохраняя требования согласованности. А если точнее, то С. Моханом, в недрах IBM, был придуман алгоритм ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) на основе WAL, где было формально доказано, что WAL, во-первых, обеспечивает максимально возможную скорость при гарантии ACID, а во вторых, подходит не только для записи табличных данных но и объектов любого типа. С тех пор используется не только в РСУБД, но и вообще где угодно, начиная от файловых систем, NTFS, например, и заканчивая изделиями типа Lotus. И так же, с тех пор, подсистеме хранения РСУБД совершенно пофиг что хранить, хоть таблицы, хоть JSON c XML-ем, хоть объекты произвольные.