Поясните пожалуйста, я прав в своих рассуждениях или ошибаюсь:
На заре компьютеров RAM и HDD было дорогим, его нужно было экономить, поэтому появились реляционные БД, где главное, чтобы информация не повторялась. Когда RAM и HDD стали дешевле труда разработчиков, то популярными стали документо-ориентированные БД, избавленные от необходимости выполнять затратные join'ы и имеющие неоспоримые преимущества в горизонтальном масштабировании на современном оборудовании.
Здравствуйте, Barlog M., Вы писали:
BM>Поясните пожалуйста, я прав в своих рассуждениях или ошибаюсь: BM>На заре компьютеров RAM и HDD было дорогим, его нужно было экономить, поэтому появились реляционные БД, где главное, чтобы информация не повторялась.
Неповторяемость информации нужна не столько из-за RAM и HDD, а из-за аномалий редактирования и т.п.
BM>Когда RAM и HDD стали дешевле труда разработчиков, то популярными стали документо-ориентированные БД
Здравствуйте, Barlog M., Вы писали:
BM>Поясните пожалуйста, я прав в своих рассуждениях или ошибаюсь:
Чушь практически в каждом слове. Это просто попытка, зная два-три факта, "довообразить" остальное.
Что касается мифической популярности NoSQL, то позволю себе высказать неочевидную вещь: основной её причиной стал постепенный сдвиг задач ИТ в сторону работы с малоценными данными. Принципы ACID, на которых традиционно строятся реляционные базы, предназначены для работы с ценными данными, когда каждый потерянный байт дорого стоит. Как следствие надёжности, обработка этого байта тоже недёшево стоит. Сейчас появился пласт задач — скажем, условно, комментарии в фейсбуке или клики на сайте — в которых отдельный байт и даже отдельный комментарий не стоит вообще ничего. Ценность имеют только данные в совокупности, даже если похерить из них пять или десять процентов. И идёт поиск инструментов более эффективной работы с такими данными.
Здравствуйте, Barlog M., Вы писали:
BM>Поясните пожалуйста, я прав в своих рассуждениях или ошибаюсь:
BM>На заре компьютеров RAM и HDD было дорогим, его нужно было экономить, поэтому появились реляционные БД, где главное, чтобы информация не повторялась. Когда RAM и HDD стали дешевле труда разработчиков, то популярными стали документо-ориентированные БД, избавленные от необходимости выполнять затратные join'ы и имеющие неоспоримые преимущества в горизонтальном масштабировании на современном оборудовании.
Открою тайну. NoSQL популярны, потому воспринимаемая сложность ниже. Примерно как javascript проще java или c#. Правда инструменты вроде ef в c# позволяют получить воспринимаемую сложность даже ниже nosql.
Все остальные доводы — чушь полнейшая. NoSQL базы в среднем на порядок проигрывают SQL, особенно платным. Только в сценариях чтения по ключу NoSQL может хоть как то выиграть, но это ничем не лучше sql+кеширование
Здравствуйте, Barlog M., Вы писали:
BM>Поясните пожалуйста, я прав в своих рассуждениях или ошибаюсь:
BM>На заре компьютеров RAM и HDD было дорогим, его нужно было экономить, поэтому появились реляционные БД, где главное, чтобы информация не повторялась. Когда RAM и HDD стали дешевле труда разработчиков, то популярными стали документо-ориентированные БД, избавленные от необходимости выполнять затратные join'ы и имеющие неоспоримые преимущества в горизонтальном масштабировании на современном оборудовании.
Вы неправы насчёт популярности NoSQL. За цифры не ручаюсь, но скорее всего близко к правде:
* Есть 1% программистов, решающих специфические задачи — для них NoSQL иногда бывает решением проблемы.
* Есть 2% программистов, уверенных, что решают специфические задачи (на самом деле — нет) — они просто используют NoSQL, думая, что в этом есть смысл. (Эти 2% создают 90% шума про NoSQL во всяких блогах)
* Есть 97% программистов, которые продолжнаю спокойно использовать реляционные СУБД, а про всякие NoSQL читают в блогах.
Здравствуйте, gandjustas, Вы писали:
G>Примерно как javascript проще java или c#.
А вот с этим бы я поспорил. Лично мне C# ввиду своей целостности, продуманности и использованию классической ООП модели воспринимается гораздо легче, чем весь из себя гибкий javascript, в котором изучающему сразу с порога называется ряд понятий, которые "Гоги, это ниувазможно понять, это нада запомнить".
Здравствуйте, D.Lans, Вы писали:
DL>Здравствуйте, gandjustas, Вы писали:
G>>Примерно как javascript проще java или c#.
DL>А вот с этим бы я поспорил. Лично мне C# ввиду своей целостности, продуманности и использованию классической ООП модели воспринимается гораздо легче, чем весь из себя гибкий javascript, в котором изучающему сразу с порога называется ряд понятий, которые "Гоги, это ниувазможно понять, это нада запомнить".
Блин, только хотел написать про сомнительность данного утверждения...
javascript ничуть не проще java или c#. Ногу там можно отстрелить себе только так.
Хотя js изящнее, кмк.
Здравствуйте, gandjustas, Вы писали:
G>Все остальные доводы — чушь полнейшая. NoSQL базы в среднем на порядок проигрывают SQL, особенно платным. Только в сценариях чтения по ключу NoSQL может хоть как то выиграть, но это ничем не лучше sql+кеширование
Здравствуйте, Barlog M., Вы писали:
BM>Здравствуйте, gandjustas, Вы писали:
G>>Все остальные доводы — чушь полнейшая. NoSQL базы в среднем на порядок проигрывают SQL, особенно платным. Только в сценариях чтения по ключу NoSQL может хоть как то выиграть, но это ничем не лучше sql+кеширование
BM>В чём они проигрывают? В CRUD В масштабировании?
Надежность и скорость работы. Масштабирование у nosql тоже сомнительное (зависит от движка).
Здравствуйте, Softwarer, Вы писали:
S>Чушь практически в каждом слове. Это просто попытка, зная два-три факта, "довообразить" остальное.
Действительно, RDBMS гораздо требовательнее к памяти, чем NoSQL. Не понимаю, почему я об этом не подумал. Теперь получается, что RDBMS — тупиковая ветвь.
S>Что касается мифической популярности NoSQL, то позволю себе высказать неочевидную вещь: основной её причиной стал постепенный сдвиг задач ИТ в сторону работы с малоценными данными.
Что не так с надёжностью у NoSQL? Разве нет NoSQL баз данных, гарантирующих целостность данных?
Здравствуйте, Barlog M., Вы писали:
BM>Здравствуйте, Softwarer, Вы писали:
S>>Чушь практически в каждом слове. Это просто попытка, зная два-три факта, "довообразить" остальное.
BM>Действительно, RDBMS гораздо требовательнее к памяти, чем NoSQL. Не понимаю, почему я об этом не подумал. Теперь получается, что RDBMS — тупиковая ветвь.
Rdbms гораздо менее требовательны к памяти, чем nosql.
S>>Что касается мифической популярности NoSQL, то позволю себе высказать неочевидную вещь: основной её причиной стал постепенный сдвиг задач ИТ в сторону работы с малоценными данными.
BM>Что не так с надёжностью у NoSQL? Разве нет NoSQL баз данных, гарантирующих целостность данных?
Есть, но мало, платные, и не лучше sql в среднем.
Здравствуйте, Barlog M., Вы писали:
BM>Что не так с надёжностью у NoSQL? Разве нет NoSQL баз данных, гарантирующих целостность данных?
Можете считать, что нет. Есть такая штука — теорема Брюера — которая говорит о том, что требования "целостности", "доступности" и "распределённости" не могут быть выполнены одновременно. RDBMS — это класс систем, реализующих "целостность" и "доступность" ценой "распределённости". NoSQL — это класс систем, реализующих "доступность" и "распределённость" ценой "целостности".
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Barlog M., Вы писали:
BM>>Что не так с надёжностью у NoSQL? Разве нет NoSQL баз данных, гарантирующих целостность данных?
S>Можете считать, что нет. Есть такая штука — теорема Брюера — которая говорит о том, что требования "целостности", "доступности" и "распределённости" не могут быть выполнены одновременно. RDBMS — это класс систем, реализующих "целостность" и "доступность" ценой "распределённости". NoSQL — это класс систем, реализующих "доступность" и "распределённость" ценой "целостности".
Здравствуйте, gandjustas, Вы писали:
G>Это неверно. Вообще брюера в сравнении sql vs nosql применят бессмысленно. Читайте http://habrahabr.ru/post/231703/
Пост говорит о том, что попытка его формального доказательства сделана с не очень осмысленными определениями. А применять... вопрос не в сравнении, это просто наглядное описание разницы в подходах. ACID — одно, BASE — другое.
Здравствуйте, Barlog M., Вы писали:
Q>>Неповторяемость информации нужна не столько из-за RAM и HDD, а из-за аномалий редактирования и т.п. BM>Уникальный ID не сразу придумали что-ли?
Человек, у которого аномалии редактирования данных связаны в мозгу с уникальными ИД, пытается рассуждать
о SQL vs NoSQL? Без обид, но может сначала в теме чуть-чуть разобраться следует?
Здравствуйте, _ABC_, Вы писали:
_AB>Человек, у которого аномалии редактирования данных связаны в мозгу с уникальными ИД, пытается рассуждать _AB>о SQL vs NoSQL? Без обид, но может сначала в теме чуть-чуть разобраться следует?
Никаких обид, я с удовольствием попробую разобраться в теме. Дайте ссылку пожалуйста? Пишу в гугле "аномалии редактирования" и получаю ссылки совершенно не относящиеся к БД.
Здравствуйте, Qbit86, Вы писали:
Q>Попробуй запрос «аномалия обновления».
То есть для кривого дизайна, когда данные нельзя обновить в одном месте, чтобы из любого другого запроса к БД они были тоже обновлённые даже термин придумали уже? Ох... Благодарю. Жаль, материться нельзя.
