Здравствуйте, vdimas, Вы писали:
V>Но где она вполне достижима при наличии квалификации.
Ну да, например, если положить вниз нормальную СУБД с ACID =)
V>Пытаешься съехать?
Это ты пытаешься наехать ) но как всегда не очень уклюже
V>Ошибаешься.
Нет, я не умею )
V>По этому срезу РСУБД не видно и под микроскопом на фоне NoSQL.
Ну так приведи циферки, я достану свой микроскоп и проверим )
V>Судя по твоим рассуждениям всё ровно наоборот — РСУБД нужна для людей без квалификации.
Нет, это судя по твоим рассуждениям ) Точнее не рассуждениям, а фантазиям.... Так что иди себе в угол, фантазировать и не мешай людям разговаривать =)
V>Боюсь, в нашей реальности ровно наоборот — для наколенных проектов берут проверенные простенькие решения, навроде MS SQL.
Да, это страшная реальность, такую действительно стоит бояться. =)
V>Меня заносит куда и всегда — в называние вещей своими именами. V>Если РСУБД сама не умеет нормально кешировать данные, то ей нужны подпорки.
Да, тебя занесло куда и всегда — в полный бред. Прямо даже интересно, как долго ты будешь отстаивать этот тезис и до чего в итоге договоришься )
V>Заметь, эту тему начал опять ты.
Я? Ты себя вообще хоть читаешь? ))
Здравствуйте, IB, Вы писали:
IB>Как известно, когда в руках молоток, то все вокруг кажетя гвоздями )) Но нет, не то что не победил, а занял свою, довольно узкую нишу и подсдулся. IB>Тут совсем недавно как раз пробегал график частоты использования различных баз в проектах и там хорошо видно, что самая популярная Монга, даже не приблизилась к MSSQL, не говоря уже о мускуле и оракле. Более того, реляционки типа постгри — активно растут, а NoSQL в лучшем случае вышли на плато. И это при том, что та же монга с редисом как правило используются тупо в качестве
Как бы очевидно, что NoSQL нишевой продукт и он не от хорошей жизни появился. Для большинства проектов RDBMS оптимальный выбор а вот скажем хранить исторические данные по всем операциям и показывать аналитику тут уже никакой MySql не сдюжит а Druid сможет.
Сейчас работаю с Google Spanner он как бы и SQL и как бы NoSQL местами. Но очень капризное пока, пилить и пилить его до ума.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
CK>>>Но зато в некоторых РСУБД появились некоторые фишки NoSQL, например поддержка JSON в посгресе. Кто бы мог подумать, что не всем подходит чистая реляционная модель? :D G>>С каких пор тип данных в столбцах не соответствует реляционной модели?
S>В реляционной модели речь идет о примитивных типах, если не ошибаюсь.
А что такое «примитивный тип»? Строка — примитивный тип?
Здравствуйте, gandjustas, Вы писали:
S>>В реляционной модели речь идет о примитивных типах, если не ошибаюсь. G>А что такое «примитивный тип»? Строка — примитивный тип?
Типа того, оператор like сущ. с незапамятных времен. json тоже будет такой строкой. Там какой-то минимум операций с json возможен, но про типизацию я не уверен. Т.е. тупо строка.
GIV>Как бы очевидно, что NoSQL нишевой продукт и он не от хорошей жизни появился. Для большинства проектов RDBMS оптимальный выбор а вот скажем хранить исторические данные по всем операциям и показывать аналитику тут уже никакой MySql не сдюжит а Druid сможет.
Приводить MySQL в сравнение, когда речь о взрослых РСУБД — моветон.
В MS SQL Server есть clustered columnstore indexes. Друид и прочие "column oriented written in java" неврно курят в сторонке.
И это еще "детский" уровень. Потому что у взрослых РСУБД есть в свои системы аналитики, рядом с которыми Druid выглядит как поделка.
Еще раз повторю: на сегодня все взрослые РСУБД обзавелись полезными фичами NoSQL.
Здравствуйте, vdimas, Вы писали:
V>Если РСУБД сама не умеет нормально кешировать данные, то ей нужны подпорки.
Давай с этого места поподробнее.
Что ты имеешь ввиду под "нормально кешировать данные" и какая РСУБД этого не умеет?
Здравствуйте, IB, Вы писали:
V>>Угу, узкую нишу большого объема данных и высокой производительности. IB>Нишу, где целостность данных не очень критична. )
Где конкретно, например, в Амазоне не критична целостность?
V>>Наверно на большинстве детсадовских сценариев подобные инструменты банально не нужны? IB>Совершенно верно, поскольку у NoSQL порог входа сильно ниже, чем во взрослую БД (в РСУБД все-таки нужна хоть какая-то квалификация)
Это совершенно не так. В РСУБД разберётся любая обезьяна, а "волшебно работающие" транзакции позволяют не думать о CAP и прочем. Правильное использование NoSQL — это намного более сложная задача, где часто нужны всякие хитрые решения с идемпотентностью, reconciler'ами и прочим.
Здравствуйте, Слава, Вы писали:
C>>Ну так он победил РСУБД и стал обычным инструментом. С>К сожалению, не все NoSQL одинаково полезны. С>https://syslog.ravelin.com/you-probably-shouldnt-use-dynamodb-89143c1287ca
DDB — это не самая удачная БД, её сложно использовать правильно.
С>Я с DynamoDB работаю наверное полгода, и до сих пор плююсь от того, что вместо краткого и ясного языка вроде SQL, для DynamoDB (по слухам, физически работающей поверх уймы обычных СУБД) нужно писать преразвесистые реквесты со словарями, которые вдобавок не проверяются в compile-time.
DynamoDB работает поверх физических узлов с MySQL, но база может быть распределена между сотнями узлов, поэтому большинство запросов SQL смысла не имеет.
Запросы внутри одного hash-ключа сейчас собираются немного улучшить, но там тоже жёсткие ограничения — нельзя допускать очень дорогие операции.
Здравствуйте, gandjustas, Вы писали:
CK>>РСУБД по прежнему не могут в шардинг в автоматическом режиме, не могут в автоскейлинг. G>Что значит "шардинг в автоматическом режиме" ? G>Выбрать инстанс на который писать данные в зависимости от параметров — это вообще не задача СУБД, это задача клиентской библиотеки и подобный решений вагон и маленькая тележка.
С чего бы? А кто будет обеспечивать переходные процессы, при resharding'е или failover'у?
G>Автоматически перераспределить данные при появлении нового шарда — это какая из NoSQL баз умеет?
Все? Mongo, DynamoDB — точно.
G>Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться?
Да. Чтобы при повышении нагрузки приложение не тормозило. Новые узлы берутся из облака или пула свободных хостов (если on-premise).
G>Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
Нет.
G>Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. Мамкин хайлоад с базой на 30 гб, где большая денормализованная таблица и джоины силами приложения, там и рядом не валялся.
TPC-C — это вообще смех на палочке. Я уже привёл примеры масштаба — у Амазона хранилище выдерживает миллионы запросов в секунду. Это почти на три порядка больше, чем лучший результат TPC-C.
Здравствуйте, Слава, Вы писали:
C>>ВНЕЗАПНО оказалось, что overhead от синхронизационного трафика, нужного для обеспечения ACID, растёт почти экспоненциально с числом пишущих узлов. С>Есть хорошее выражение "вы не Гугл". Кстати, а на IBM'овских мейнфреймах амазон пытался работать? Вряд ли, но интересно же.
Была специальная команда, которая посмотрела все существовавшие тогда решения на рынке.
Ну и мэйнфреймы — это вообще разводилово. Тормозное и дорогое.
Здравствуйте, IB, Вы писали:
V>>Но где она вполне достижима при наличии квалификации. IB>Ну да, например, если положить вниз нормальную СУБД с ACID =)
Замечательно! Можно показать РСУБД, которая выдержит нагрузку типичного проекта в Амазоне?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Cyberax, Вы писали:
R>>>>NoSQL разве сдулся? S>>>О нем уже не говорят. Ну да, свою нишу заняло, но воплей уже нет. C>>Ну так он победил РСУБД и стал обычным инструментом. WH>А NoSQL уже научился ACID? Или всё так же данные теряет?
Я вас удивлю, но жесткий диск далеко не единственный способ оставить свои данные в сохранности. Более надежная фишка — сеть. Т.е. вместо того чтобы писать на медленный диск. Вы отправьте инфу по сети 100 нодам. Даже если 90 нод потеряет ее (что невероятно с точки зрения теории вероятности) вы сохраните информацию. Причем на 10 нодах. А не на одном паршивом диске. Скорость при этом небо и земля. Просто неспопоставимы по скорости диск и сеть. Сеть быстрее. И зачем нужен этот ваш ACID?
Здравствуйте, paucity, Вы писали:
C>>На РСУБД оно не работает. Амазон пробовал все существующие, включая самый дорогой в мире кластер на Oracle RAC. Этот кластер отвалился в день Чёрной Пятницы. P>У Амазона все время что-то отваливается / валится (ага прошлая неделя) P>Видно дело не в бобине
Там была интересная проблема, на самом деле. Не относящаяся к хранилищу данных. Тем не менее, после первых часов (почти) всё заработало.
Собсно, почти всегда доступ к big data — это доступ исключительно по-чтению.
И весь этот многоуровневый ACID, живущий в современных РСУБД, она для такого сценария натуральный оверкилл.
Здравствуйте, vdimas, Вы писали:
V>Что тут происходит с высоты птичьего полёта? — NoSQL показывает надобность специального покрытия тех сценариев, в которых 99.99% всех обращений к данным read only.
Для таких сценариев sqlite есть, особливо с опцией in-memory А вот сколько он гигибайет может вместить -- Но думаю до 10 Гб будет ок.
С другой стороны, это же обычный файл, поэтому надо см. ограничения ос.
Здравствуйте, IB, Вы писали:
C>>Ну так он победил РСУБД и стал обычным инструментом. IB>Как известно, когда в руках молоток, то все вокруг кажетя гвоздями ))
См.: РСУБД.
IB>Тут совсем недавно как раз пробегал график частоты использования различных баз в проектах и там хорошо видно, что самая популярная Монга, даже не приблизилась к MSSQL, не говоря уже о мускуле и оракле.
Ага, и самый популярный язык — PHP.
На РСУБД можно делать проекты, где не важна скорость и масштабируемость, или нужны просто тонны индусов, которых за 3 дня обучили писать SELECT * FROM Table.
IB>И вообще, как уже неоднократно говорилось, с тех пор как к NoSQL-ю прилепили SQL в качестве языка запросов, а реляционки поддержали JSON, разница между ними только в том, что у NoSQL подсистема хранения написана через жопу. )
В большинстве NoSQL нет полноценного SQL, так как он там банально не нужен.
Здравствуйте, IB, Вы писали:
V>>Но где она вполне достижима при наличии квалификации. IB>Ну да, например, если положить вниз нормальную СУБД с ACID =)
Для такого сценария квалификация не нужна.
Достаточно ПТУ по специальности "администратор выч. техники".
V>>По этому срезу РСУБД не видно и под микроскопом на фоне NoSQL. IB>Ну так приведи циферки, я достану свой микроскоп и проверим )
А где я тебе возьму, например, циферки по хранению BigData в MS SQL?
Сама MS использует HDInsight для интеграции РСУБД и BigData...
Но чтобы саму эту Big Data хранить в MS SQL — до этого даже в MS не додумались.
V>>Судя по твоим рассуждениям всё ровно наоборот — РСУБД нужна для людей без квалификации. IB>Нет, это судя по твоим рассуждениям
По моим наблюдениям за твоими "аргументами".
Ничего сложнее "инструкции для пользователей" ты сюда еще не транслировал.
Но всегда с таким видом, будто Америку открыл.
В этом месте, уж не обессудь, реакция одна и та же: Ы-Ы-Ы.
Ну или "вы точно дверью не ошиблись?".
V>>Боюсь, в нашей реальности ровно наоборот — для наколенных проектов берут проверенные простенькие решения, навроде MS SQL. IB>Да, это страшная реальность, такую действительно стоит бояться. =)
Какой ты скользский, однако:
большинство NoSQL как раз для "на коленных" проектов
Фигню спорол и ну давай стрелки переводить.
Я уже хотел тебя ткнуть в один такой "наколенный" проект — в Azure Cloud, но ты резко в кусты.
Скучно...
V>>Заметь, эту тему начал опять ты. IB>Я? Ты себя вообще хоть читаешь? ))
Я читаю тебя и вижу избыток аллегорий из разряда "кривые", "жопа" и т.д.
Выглядит так, будто ты уверен в некоей особой магии убедительности таких слов.
Детсад.
Здравствуйте, Sharov, Вы писали:
V>>Что тут происходит с высоты птичьего полёта? — NoSQL показывает надобность специального покрытия тех сценариев, в которых 99.99% всех обращений к данным read only. S>Для таких сценариев sqlite есть, особливо с опцией in-memory
Не хватит никакой мемори для террабайтных данных. ))
В общем, BigData — оно или про чудовищный объем, или про чудовищную нагрузку (кол-во одновременных запросов).
И тот и другой вопрос решаются распределением по железкам.
S>С другой стороны, это же обычный файл, поэтому надо см. ограничения ос.
Здравствуйте, gandjustas, Вы писали:
G>И это еще "детский" уровень. Потому что у взрослых РСУБД есть в свои системы аналитики, рядом с которыми Druid выглядит как поделка.
Подавятся "взрослые" СУБД объемами хадупа.
Мы уже победили, просто это еще не так заметно...
