Здравствуйте, IB, Вы писали:
IB>Ну, если можно нагружать до тех пор пока не ляжет, то разницы между реляционкой и NoSQL опять-таки нет, положить не рассчитаной нагрузкой все что угодно можно ))
Попытка натянуть РСУБД-сов на глобусы... ))
"Положить" что-либо можно лишь из-за разности быстродействия подсистем одной системы при наблюдающейся отрицательной кривой быстродействия в зависимости от нагрузки.
Самый очевидный пример — РСУБД.
При "перегрузке" в ней начинает копиться очередь запросов, одновременно с этим в общем случае ухудшается параллелизм, общее быстродействие системы заметно падает.
А если система принципиально способна давать ответы со скоростью их поступления, и если кривая быстродействия положительная (а она обязана быть положительной у грамотно спроектированной системы) — там "класть" физически нечего. Нет механизма "кладки".
Здравствуйте, Слава, Вы писали:
S>>Типа того, оператор like сущ. с незапамятных времен. json тоже будет такой строкой. Там какой-то минимум операций с json возможен, но про типизацию я не уверен. Т.е. тупо строка.
С>Можно делать индексацию по части JSON, Постгрес это умеет.
И FTS умеет (причем вполне прилично), а это уже совсем не like.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, gandjustas, Вы писали:
G>Правильная архитектра РСУБД почти всегда упирается сначала в диски.
Это безбожно устаревшие данные. ))
Сейчас можно поставить RAID-ы, которые будут работать в несколько раз быстрее, чем это принципиально нужно реляционным БД.
Более 1 ГБ/с MSSQL не прокачивает ни на каком RAID, а его собратья NoSQL качают 4-5 Гиг/сек легко.
В общем, реляционки когда-то были разработаны как способ борьбы с медленными внешними хранилищами.
Если внешнее хранилище быстрое, то реляционка начинает смотреться убого.
Здравствуйте, Cyberax, Вы писали:
S>>>>Вы точно уверены, что Амазон держит полмиллиарда запросов в секунду? C>>>Да. В этом году примерно столько и было. G>>То есть каждый житель США делал более 1 запроса в секунду? Чето мне кажется весь земной шар не генерирует такое количество запросов. C>На один просмотр страницы может приходиться около пары десятков запросов.
Т.е. каждый житель США каждые 20 секунд обращается к амазону?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>Так суть NoSQL решений по большей части в том, что все данные умещаются в памяти. Когда это не так — начинает сосать как валютная проститутка. РСУБД при этом вполне нормально работают при объеме данных в разы превышающих объемы ОП.
CK>Смотря какой NoSQL, есть такая штука, RUM conjecture называется, которая в общем приближении описывает как БД себя ведет в ситуации ограниченности ресурсов. Согласно RUM, если у тебя размер базы сильно больше RAM, ты будешь жертвовать либо скоростью чтения (HBase, Cassandra) либо скоростью записи (привет MSSQL). Но пользователь HBase, в случае слишком медленного чтения просто поднимет еще несколько region серверов. Пользователь MSSQL же, в случае слишком медленной записи попал.
Куда, простите, попал?
На самом деле вопросов много
1) Зачем жертвовать скоростью чтения, если по оценке корпоративное приложение имеет соотношение чтения к записи 98 к 2, а некоторые системы, типа OLAP, по сути вообще readonly?
2) Кто мешает поставить несколько дисков, чтобы ускорить запись? Даже отдельные серверы не нужны. Если мы хотим ускорять запись, то зачем вообще ставить любую БД, просто писать файлы на диск, а в фоне обрабатывать.
2) Кто мешает создать write-optimised таблицы в РСУБД, там где нужна скорость записи?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Один сервер не означает что он единственный и никак не зеркалируется.
AB>Ну т.е. уже размен начинается уже не 1:6, а исходя из того, о чем ты не договариваешь.
А NoSQL не надо зеркалить? Размен был ровно 1-к-6. То есть для того чтобы покрыть (даже без запаса) один сервер с MS SQL надо было иметь 6 аналогичных по железу серверов MongoDb.
Зеркало это или мастер — не важно.
g>> Так суть NoSQL решений по большей части в том, что все данные умещаются в памяти. g>> Когда это не так — начинает сосать как валютная проститутка. AB>У тебя столько железа не будет, чтобы данные NoSQL <используемого по назначению> в памяти уместить.
У меня нет, поэтому использую РСУБД. А те кто в облаках живут — у них есть. Потому что в облаке память еще дешевле, а диски еще дороже.
g>> Вот и получается что для NoSQL нужен или масштаб амазона, где РСУБД гарантированно не справится AB>Конечно, у компаний масштабов "амазона" NoSQL используется и в хвост и в гриву. Но для получения профита совершенно не обязательно быть такими большими.
AB>Например, любая более-менее крупная торговая сеть уездного города M может использовать (и есть те, кто использует) возможности технологии для "аналитики по чекам" (не помню как оно у них правильно называется) и построения тех же ML моделей. Для ML например, берем чек, берем соответствующего человека на кассе с камер наблюдения, проводим его по раскадровке в обратном порядке по торговому залу, сохраняем трэк движения, пробуем добавить к трэку вероятностную мета-информацию о поле, возрасте, MAC и названии мобильного устройства, etc. Пробуем связать полученную информацию с другими трэками — опа, у очень похожего трэка засветился "ребенок начальных классов". А сколько у нас вообще посетителей с такими детьми в магазин ходят? А каким маршрутом и к каким кассам они ходят чаще? В этот момент смышленый директор по продажам (а глупые подобные системы не строят) уже начинает отбирать у тебя клавиатуру...
А при чем тут NoSQL вообще? Чеки хранятся в РСУБД, они никогда в NoSQL не попадут по понятным причинам. Записи камер тупо на дисках. Рисование трека по магазину никаким образом к СУБД не относится. ML по сути тоже.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, gandjustas, Вы писали:
G>>Что значит "шардинг в автоматическом режиме" ? G>>Выбрать инстанс на который писать данные в зависимости от параметров — это вообще не задача СУБД, это задача клиентской библиотеки и подобный решений вагон и маленькая тележка. MD>Смешались мухи. Клиента вообще не должно интересовать, сколько инстансов и куда он пишет. Есть некий фасад, куда можно постучаться, а далее это уже чистой воды серверная задача: сделать раутинг запроса, исполнить его на подходящем инстансе, дать ответ.
Мы про какого клиента? Который деньги платит или про программиста, который запросы пишет. Если все-таки программиста, то почему не должно интересовать? Ему не будет интересно почему запрос выполняется так, а не иначе?
G>>Что значит "автоскейлинг" ? G>>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться? MD>Железо — либо физически уже готовое в резерве, либо мы на клауде, где резерв обеспечен датацентром. Далее одна-единственная команда "добавить", поданная человеком или условным крон-скриптом.
У MS SQL в облаке так и есть. А на земле проще сразу отдать под базу нужные мощности, ведь если их выдавать всем подряд по запросу, то может в неожиданный момент под базу не хватить.
G>>Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
MD>Классические сценарии — это разреженные данные высокой размерности (колоночные NoSQL), или работа со слабоструктурированными исходными данными (документ-ориентированные NoSQL).
Ага, clustered columnstore и json в MS SQL
MD>Классический подход на РСУБД даст либо крайне неэффективный в индексировании property bag (для первого случая), либо впихивание документов в BLOB с пред-парсингом ключевых параметров
FTS в MS SQL
MD>и при смене модели данных этот пред-парсинг надо будет прогонять заново по всей базе, что крайне дорого (для второго случая).
А что, можно поменять разметку, но при этом данные не обрабатывать по новой? Какой в этом смысл?
G>>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. MD>А зачем стэк-оверфлоерам NoSQL? У них строго структурированный блок данных: сообщение-юзер-метаданные.
Все данные достаточно структурированные, чтобы положить их в РСУБД. Иначе с такими данными не получится работать никакими средствами. Даже теорема есть на эту тему.
MD>Да и по размеру — ввиду продуманной реализации — серверов у них по пальцам пересчитать в одной стойке, и вся БД аж на двух серваках, если склероз не склерозит, и то с целью быстрого переключения в случае сбоя (master-slave). Т.е. переход на NoSQL им не даст ничего кроме лишней головной боли "зачем же мы всё поломали".
Верно. При этом это сайт, который имеет нагрузку больше, чем у 99.99% стартапов, использующих NoSQL.
Вы даже не понимаете на что ссылаетесь.
Эти люди делают Data Warehouse, куда грузят тонны данных для дальнейшей аналики (read-only доступа). Внезапно на время загрузки выгодно отключить проверку FK, потому что она избыточна и не дает распараллеливать операции.
Чтобы отключить FK должно выполниться сразу три условия:
1) Загрузка данных из системы, где FK есть.
2) Отключать FK в продакшене, но на этапе проектирования использовать FK для самокотроля
3) Запись большого объема за один раз.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Итак простой пример зачем нужен ACID:
G>>Вот ты такой умный собрал систему как описал выше. Система для продажи билетов в кино\театр\еще куданить...
S>Такие системы строятся с ключевой системой, выполняющей роль шедулера. Все запросы, прилетают шедулеру, как бы параллельно они не приходили, они всегда выстроятся в очереди на выполнение у шедулера последоватльно. Щедулер не выполняет преобразований, сохранений и прочей грязной работы, он только содержит метаинформацию всей системы и ставит задачи, с учётом этой метаинформации, задачи параллельно выполянются на нодах.Чтоб не возникакло конфликтов на нодах-это обеспечиваетcя на уровне шедулера.
То есть если шедулер падает, то вся система встает, да еще и в не консистентном состоянии? (деньги списали, а билеты не проданы)
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Правильная архитектра РСУБД почти всегда упирается сначала в диски.
V>Это безбожно устаревшие данные. ))
Да ладно?
Ты сам ниже пишешь про 4-5 гб\сек, что на два порядка ниже скорости памяти.
V>Сейчас можно поставить RAID-ы, которые будут работать в несколько раз быстрее, чем это принципиально нужно реляционным БД.
А сколько "принципиально" нужно реляционым БД ? B-tree имеет какую-то верхнюю границу скорости записи?
V>Более 1 ГБ/с MSSQL не прокачивает ни на каком RAID, а его собратья NoSQL качают 4-5 Гиг/сек легко.
Доказательства твоим словам есть?
Это заявление в духе "FK замедляют запросы". Которому нет ни одного доказательства, кроме статьи с частным случаем 10-летней давности. И о там на проверку вина разработчика.
V>В общем, реляционки когда-то были разработаны как способ борьбы с медленными внешними хранилищами.
Откуда ты это взял вообще?
V>Если внешнее хранилище быстрое, то реляционка начинает смотреться убого.
Ну давай пример в студию как MS SQL не смог нагрузить RAID с 5гб\с пропускной способности.
Здравствуйте, Ops, Вы писали:
V>>В этом цикле может крутиться несколько потоков одновременно. V>>За один оборот как минимум один поток продвигается. Ops>Но гарантий для любого конкретного потока, что он вообще когда-нибудь продвинется, нет.
Пофик, тут степенная ф-ия от вероятности "застрять".
Т.е. вероятность того, что поток не продвинется на следующем такте очень быстро стремится к 0-лю с каждым заходом на новый круг.
Здравствуйте, gandjustas, Вы писали:
G>То есть если шедулер падает, то вся система встает, да еще и в не консистентном состоянии? (деньги списали, а билеты не проданы)
Упасть может что угодно, оракел тоже падает. Остальная система завершает назначенные задачи, отдаёт результаты клиенту, и переходит в ожидание новых. Шедулер поднимается, считывает с журнала состояние очереди перед падением, продолжает работу дальше.
Здравствуйте, gandjustas, Вы писали:
G>>>Правильная архитектра РСУБД почти всегда упирается сначала в диски. V>>Это безбожно устаревшие данные. )) G>Да ладно? G> Ты сам ниже пишешь про 4-5 гб\сек, что на два порядка ниже скорости памяти.
Из будущего вещаешь? ))
В этой реальности DDR4 даёт 12-18 гиг/сек на канал.
PCI-e v.4 даёт до 16 гиг/сек на канал.
V>>Сейчас можно поставить RAID-ы, которые будут работать в несколько раз быстрее, чем это принципиально нужно реляционным БД. G>А сколько "принципиально" нужно реляционым БД ?
Я же написал — более гига в секунду не умеют.
Т.е. база не упирается в диски, она упирается в саму себя.
Упирается в не оптимальную разметку хранимых данных — не оптимальную для случая быстрых дисков.
Эта разметка исходила из разницы быстродействия дисков и оперативки на пару порядков и в случае быстрого хранилища является натуральнейшим идиотизмом. ))
Ну, т.е., если поставить задачу разметить объекты для хранения в оперативке, то никто бы в здравом уме не додумался бы хранить данные так, как хранит их MS SQL.
Никто бы в здравом уме при обработке данных не формировал бы из них "проекции" (че за бред ваще? ), как это делается сейчас в ответ на запросы SQL и т.д. до бесконечности.
С т.з. современных ср-в это всё гимн идиотизму, ес-но.
Т.е. да, в мейнстриме еще остаётся "классика" медленных дисков, но уже отсюда хорошо видно, что совсем скоро эта классика тупо испарится за ненадобностью.
G>Это заявление в духе "FK замедляют запросы".
В несколько раз замедляет, а что? Новость для кого-то?
G>Которому нет ни одного доказательства
А у самого руки не оттуда растут, чтобы померить?
V>>В общем, реляционки когда-то были разработаны как способ борьбы с медленными внешними хранилищами. G>Откуда ты это взял вообще?
Из самой теории, причин её появления и становления рынка СУБД в 80-90-е.
V>>Если внешнее хранилище быстрое, то реляционка начинает смотреться убого. G>Ну давай пример в студию как MS SQL не смог нагрузить RAID с 5гб\с пропускной способности.
Странно ты так формулируешь свои вопросы, что подойдёт вообще любой пример.
Хотя, согласно логики спора, интереснее было бы посмотреть на обратное.
Как найдёшь — поделись.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>То есть если шедулер падает, то вся система встает, да еще и в не консистентном состоянии? (деньги списали, а билеты не проданы)
S>Упасть может что угодно, оракел тоже падает. Остальная система завершает назначенные задачи, отдаёт результаты клиенту, и переходит в ожидание новых. Шедулер поднимается, считывает с журнала состояние очереди перед падением, продолжает работу дальше.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>>>Правильная архитектра РСУБД почти всегда упирается сначала в диски. V>>>Это безбожно устаревшие данные. )) G>>Да ладно? G>> Ты сам ниже пишешь про 4-5 гб\сек, что на два порядка ниже скорости памяти.
V>Из будущего вещаешь? )) V>В этой реальности DDR4 даёт 12-18 гиг/сек на канал. V>PCI-e v.4 даёт до 16 гиг/сек на канал.
Да, просчитался что-то. Но суть это не меняет.
V>>>Сейчас можно поставить RAID-ы, которые будут работать в несколько раз быстрее, чем это принципиально нужно реляционным БД. G>>А сколько "принципиально" нужно реляционым БД ?
V>Я же написал — более гига в секунду не умеют.
Твои слова имеют отрицательную степень доверия. То есть то что ты сказал скорее будет неправдой, чем правдой. Поэтому или конкретику — ссылки, примеры, или просто не фантазируй.
G>>Это заявление в духе "FK замедляют запросы". V>В несколько раз замедляет, а что? Новость для кого-то?
Это они только у тебя замедляют.
G>>Которому нет ни одного доказательства V>А у самого руки не оттуда растут, чтобы померить?
Мне лениво этим заниматься, да и нет у меня таких дисков. А верить тебе — не уважать себя.
V>>>Если внешнее хранилище быстрое, то реляционка начинает смотреться убого. G>>Ну давай пример в студию как MS SQL не смог нагрузить RAID с 5гб\с пропускной способности.
V>Странно ты так формулируешь свои вопросы, что подойдёт вообще любой пример.
"Не смог" != "не было необходимости"
V>Хотя, согласно логики спора, интереснее было бы посмотреть на обратное. V>Как найдёшь — поделись.
Понятно, слился.
PS. Зачем вообще этот и предыдущий коммент написал?
Здравствуйте, gandjustas, Вы писали:
V>>В этой реальности DDR4 даёт 12-18 гиг/сек на канал. V>>PCI-e v.4 даёт до 16 гиг/сек на канал. G>Да, просчитался что-то. Но суть это не меняет.
Меняет кардинально.
Почему-то та часть баррикад, которая топит за классику РСУБД, она поголовно демонстрирует укушенность "медленными дисками" и "медленной сетью", не в состоянии избавиться от того шаблона, что любые операции в оперативке происходят со скоростью света. ))
Так вот, давно уже дудки.
Утилизировать современную пропускную способность сети и дисковых подсистем классические подходы банально не в состоянии.
V>>>>Сейчас можно поставить RAID-ы, которые будут работать в несколько раз быстрее, чем это принципиально нужно реляционным БД. G>>>А сколько "принципиально" нужно реляционым БД ? V>>Я же написал — более гига в секунду не умеют. G>Твои слова имеют отрицательную степень доверия.
Это для твоей стороны баррикад.
Ваша страна эльфов всегда демонстрировала лишь навыки тщательного убегания от объективной реальности.
Голову всегда в песок.
G>>>Это заявление в духе "FK замедляют запросы". V>>В несколько раз замедляет, а что? Новость для кого-то? G>Это они только у тебя замедляют.
У всех.
У тебя тоже, ес-но.
Просто тебе облом взять и измерить.
G>>>Которому нет ни одного доказательства V>>А у самого руки не оттуда растут, чтобы померить? G>Мне лениво этим заниматься
За это над вами и ржут.
Лень ума, неспособность признать свою инженерную недееспособность.
G>да и нет у меня таких дисков.
У меня зато есть.
Ощущения непередаваемые, рекомендую.
G>А верить тебе — не уважать себя.
Однако же, пока всё сбывалось.
Конкретно я-то тут не при чём — это боль от треска шаблонов.
V>>>>Если внешнее хранилище быстрое, то реляционка начинает смотреться убого. G>>>Ну давай пример в студию как MS SQL не смог нагрузить RAID с 5гб\с пропускной способности. V>>Странно ты так формулируешь свои вопросы, что подойдёт вообще любой пример. G>"Не смог" != "не было необходимости"
Ниче не понял.
Эй, раз-два, принём, принём, вы еще с нами?
V>>Хотя, согласно логики спора, интереснее было бы посмотреть на обратное. V>>Как найдёшь — поделись. G>Понятно, слился.
Пока что понятно, что ты не в состоянии привести пример, когда MS SQL даст хорошую скорость на запись на диск или чтение с него.
Я тоже не могу.
И никто не может.
По крайней мере пока речь идёт об "обычных" для РСУБД данных, т.е. структурированных.
Т.е. я не пробовал заливать в него бесконечные по размерам блобы, измеряя пропускную способность, бо это было бы маразмом для целей подобного тестирования. ))
Здравствуйте, Ops, Вы писали:
C>>На один просмотр страницы может приходиться около пары десятков запросов. Ops>Т.е. каждый житель США каждые 20 секунд обращается к амазону?
300 миллионов запросов в секунду — это около 15 миллионов просмотров страниц в секунду. Американцев и канадцев — около 350 миллионов.
Здравствуйте, gandjustas, Вы писали:
G>Вы даже не понимаете на что ссылаетесь. G>Эти люди делают Data Warehouse, ....
G>Чтобы отключить FK должно выполниться сразу три условия: G>1) Загрузка данных из системы, где FK есть. G>2) Отключать FK в продакшене, но на этапе проектирования использовать FK для самокотроля G>3) Запись большого объема за один раз.
+
4) обеспечить поддержку ссылочной целостности процессами загрузки (etl, elt, ... whatever)
Здравствуйте, vdimas, Вы писали:
V>По-другому еще не было ни разу, так что, предлагаю доморощенному манипулятору малость расслабиться и не смущать неподготовленного читателя всякой ахинеей. V>"Трюкач" помнишь?
Я предупреждал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
), как это делается сейчас в ответ на запросы SQL и т.д. до бесконечности.
