Comments 23
Исходно вопрос о противостоянии схем баз данных никогда не ставился — в теории рассматривались три базовых вида; сетевые, иерархические и реляционные.
Последние приобрели большую популярность в силу создания программных продуктов, использующих реляционную модель вместе с языком SQL запросов.
Но другие модели также использовались с меньшей популярностью в обычной пользовательской среде.
В настоящее время развитость информационных технологий, расширение областей применения этих технологий и возросший массовый уровень профессионализма специалистов по информационным технологиям естественно расширили области применения всех моделей данных.
Поэтому, как и указано, решать надо по месту какую модель использовать.
Последние приобрели большую популярность в силу создания программных продуктов, использующих реляционную модель вместе с языком SQL запросов.
Но другие модели также использовались с меньшей популярностью в обычной пользовательской среде.
В настоящее время развитость информационных технологий, расширение областей применения этих технологий и возросший массовый уровень профессионализма специалистов по информационным технологиям естественно расширили области применения всех моделей данных.
Поэтому, как и указано, решать надо по месту какую модель использовать.
No-SQL == Not only SQL
А почему у Ana в «друзьях» числится Lucy в SQL-варианте? )
Вопрос поставлен неверно изначально. Как и под итог:
БД должна выбираться не под проект, а под задачи. Так или иначе, в одном проекте могут использоваться как реляционные БД, так и так называемые NoSQL.
Вот признаки проектов, для которых идеально подойдут SQL-базы:
БД должна выбираться не под проект, а под задачи. Так или иначе, в одном проекте могут использоваться как реляционные БД, так и так называемые NoSQL.
Вроде как не маленькая статья, а ни о чем.
При выборе базы данных первый вопрос не что и как хранить, вы на него потом найдете ответ, а что вам надо с данными делать.
Если вам ничего с ними делать не надо, то и хранить их не надо. База данных не нужна.
Если вам надо посмотреть на них справа, потом сверху, потом посчитать вхождение «этого» в «то», средние, промежуточные итоги — то без SQL это очень затруднительно. Как минимум закончится изобретением миниSQL на коленке.
Если вам надо записать много данных, а потом их просто показать, целиком или кусками — то можно пробовать NoSQL. Но как только у вас появятся дополнительные требования к фильтрованию и связям — то вы постепенно начнете смотреть в сторону SQL — там уже есть ответы на многие ваши ещё не заданные вопросы.
Характерно, что сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами и не надо заморачиваться быстродействием — положил базу в память и все.
Истина посредине. Для хранилища котиков подойдет NoSQL, т.к. зачастую записей будет больше, чем чтения. При этом взаимосвязи авторов котиков будут храниться в SQL, а сам SQL ещё разделится на горячие и холодные данные.
Кроме этого, NoSQL, как и другие не типизированные средства разработки, выполняет социальную функцию — легкий вход в программирование широких масс населения, оставляя вопросы типов и структур данных для тех, кто прошел идиотентест простых ответов на простейшие вопросы.
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там? По сути, под каждый кейс данных писать парсер и распознавать содержимое.
При выборе базы данных первый вопрос не что и как хранить, вы на него потом найдете ответ, а что вам надо с данными делать.
Если вам ничего с ними делать не надо, то и хранить их не надо. База данных не нужна.
Если вам надо посмотреть на них справа, потом сверху, потом посчитать вхождение «этого» в «то», средние, промежуточные итоги — то без SQL это очень затруднительно. Как минимум закончится изобретением миниSQL на коленке.
Если вам надо записать много данных, а потом их просто показать, целиком или кусками — то можно пробовать NoSQL. Но как только у вас появятся дополнительные требования к фильтрованию и связям — то вы постепенно начнете смотреть в сторону SQL — там уже есть ответы на многие ваши ещё не заданные вопросы.
Характерно, что сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами и не надо заморачиваться быстродействием — положил базу в память и все.
Истина посредине. Для хранилища котиков подойдет NoSQL, т.к. зачастую записей будет больше, чем чтения. При этом взаимосвязи авторов котиков будут храниться в SQL, а сам SQL ещё разделится на горячие и холодные данные.
Кроме этого, NoSQL, как и другие не типизированные средства разработки, выполняет социальную функцию — легкий вход в программирование широких масс населения, оставляя вопросы типов и структур данных для тех, кто прошел идиотентест простых ответов на простейшие вопросы.
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там? По сути, под каждый кейс данных писать парсер и распознавать содержимое.
Я, скорее, склюняюсь к тому, что ваш комментарий ни о чем.
Вы что-то путаете…
по вашему, работа с NoSQL базой на уровне приложения это отправка и получение строки?
все-таки, основной поток это как раз те, кого перестали устраивать текущие решения
сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами
Вы что-то путаете…
взаимосвязи авторов котиков будут храниться в SQL…
как же вы с данными работать будете если не знаете что там
по вашему, работа с NoSQL базой на уровне приложения это отправка и получение строки?
легкий вход в программирование широких масс населения
все-таки, основной поток это как раз те, кого перестали устраивать текущие решения
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там?
А зачем хранилищу данных работать с данными? Его дело их получать, хранить и отдавать. Для этого схема не нужна особо, разве что для оптимизаций.
В тытруба есть хорошая лекция о «больших данных».
www.youtube.com/watch?v=SzNr5LXvAv0
Там очень хорошо объясняется для чего и где используется SQL и NoSQL БД.
www.youtube.com/watch?v=SzNr5LXvAv0
Там очень хорошо объясняется для чего и где используется SQL и NoSQL БД.
| Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность)
Вообще то под Durability в ACID обычно понимается «надежность».
Вообще то под Durability в ACID обычно понимается «надежность».
Я к недостаткам SQL в быстро развивающейся системе еще добавил бы непредсказумость нагрузки на сервер БД. Любой разработчик кастомного отчета, веб-сервиса и т.п. начинает писать SQL запросы в меру своего опыта и разумения. Следствие — падение производительности. Как уже отмечено в статье, отмаштабировать это в случае SQL практически невозможно.
А почему бы не сделать отчет с реплики? Или вообще получать отчеты с OLAP модели? И не с помощью «SQL запросов в меру своего опыта», а с помощью специальных инструментов генерации отчетов.
Как минимум это дополнительные ресурсы (и финансовые, и человеческие), которые средней руки разработчик и оценить-то толком не может (кроме реплики разве что), не говоря о убедительной демонстрации преимуществ бизнесу, чтобы он согласился эти ресурсы тратить.
Честно говоря, буквально недавно столкнулся когда администраторы достаточно серьезной бизнес-системы, столкнувшись с продолжительной и ресурсно-затратной генерацией отчетов, на мое предложение использовать реплику, спросили «а что это такое». Это я к тому, что таки да, не все даже знают, что СУБД могут самостоятельно «копировать» данные с одного сервера на другой. С другой стороны, смотреть как в настоящее время люди мучаются с SQL запросами вместо того, чтобы использовать современные и доступные инструменты, основанные на in-memory и прочих Tabular model, тоже как-то грустно. Да, требуются определенные скилы. Но это точно, не rocket science и гораздо проще в плане «интеллекто-емкости» работы разработчика по проектированию.
Мучаются, скорее всего, не из-за информированности (поищите, например, по Хабру OLAP). Либо, как вариант, из-за отсутствия нормальных FOSS инструментов для отчётов по данным из FOSS СУБД, прежде всего MySQL и PostgreSQL. Беглый гуглеж говорит только о теории, либо продуктах Microsoft и Oracle.
В ваших силах, кстати, повысить информированность, написав посто или серию о подобных инструментах :)
Т.е. если любой разработчик начнет писать запросы в силу своего опыта и разумения к NOSQL это не приведет к деградации производительности?
ИМХО при идентичных требованиях к данным масштабирование SQL и NOSQL может быть выполнено в равной мере( ограничением станут только блокировки, с ними тоже можно работать, но это значительно повышает требования к квалификации ). Если мы можем расшарить данные по нескольким узлам, мы можем это сделать и там и там. Просто в NOSQL в силу парадигмы данные низкосвязные, а использование SQL как правило приводит к высокой связности данных, но это лишь практика использования не более того( если не считать требования нормализации непреложным законом вселенной ).
Никто не мешает развязать данные и в SQL, но при этом многие плюшки SQL станут вам недоступны( которых собственно говоря в NOSQL просто нет ).
ИМХО при идентичных требованиях к данным масштабирование SQL и NOSQL может быть выполнено в равной мере( ограничением станут только блокировки, с ними тоже можно работать, но это значительно повышает требования к квалификации ). Если мы можем расшарить данные по нескольким узлам, мы можем это сделать и там и там. Просто в NOSQL в силу парадигмы данные низкосвязные, а использование SQL как правило приводит к высокой связности данных, но это лишь практика использования не более того( если не считать требования нормализации непреложным законом вселенной ).
Никто не мешает развязать данные и в SQL, но при этом многие плюшки SQL станут вам недоступны( которых собственно говоря в NOSQL просто нет ).
Насколько я понимаю, в NOSQL разработчику прсото не сможет написать слишком сложный запрос (например с кучей join и встроенных функций), и ему придется писать несколько простых, после чего агрегировать данные на уровне приложения. Простые же запросы с некотрой вероятностью еще и будут кэшироваться, не доходя до СУБД.
Даже в монге есть агрегированные запросы, на которых можно такого намутить, что плакать хочется.
Некоторые NoSQL базы позволяют исполнять на стороне СУБД полноценные функции на ЯП общего назначения типа JavaScript или Erlang, выдавая в приложение ровно то, что ему нужно без дополнительных агрегаций, соединений и т. п.
По своему опыту могу сказать, очень сложно, если вообще возможно реализовать систему которая будет быстрее современных СУБД при оперировании множествами. Да, для каждого отдельного очень узкого случая как правило можно придумать велосипед, но не для общего случая.
Большая статья, полная воды и фактических ошибок. «Вариант b показывает, как те же данные можно представить в структурированном виде, типичном для SQL» — автор вообще знаком с принципами декомпозиции данных, «типичными для SQL»? Или «SQL-индексы представлены в виде B-деревьев, которые отражают иерархическую структуру реляционных данных» — что-что? Иерархическую структуру реляционных данных? А если я свой линейный массив ключей-чисел сложил в B-дерево, то оно тоже будет отражать иерархическую структуру, которой отродясь не было в моем линейном массиве чисел?
О выборе SQL-баз данныхНу в некоторых NoSQL тоже есть и транзакции и структра и джойны с псевдо-SQL, и где тут преимущество у SQL базы? Или называть такие БД как реляционная NoSQL? А вот например в OrientDB есть ссылки, данные могут ссылаться друг на друга, это как раз то что «доктор прописал» для построения реляций, а в SQL БД этого нет. Т.е. OrientDB более реляционен?
Пора уже выбирать базы по фичам, а не делить на 2 лагеря. Да и вообще, хранить таблицами не эффективно для 80% случаев в которых используется SQL субд.
А про индексы, как уже отметили выше, автор бред написал.
Sign up to leave a comment.
SQL или NoSQL — вот в чём вопрос