В SQL тоже не трудно потерять контроль над данными при неверном проектировании, просто в SQL вероятнее получить другую проблему — тормоза.
Тормоза = производительность хуже = дольше извлекаются данные. Или вы что-то другое имели в виду?
Во-вторых, чтобы показать комментарий + новость, к которой он был сделан + автора вам надо получить 3 строки/объекта, как вы это сделаете за 1 NoSQL запрос?
В третьих, проблемы ой как есть. Допустим, у Mongodb, одной из самых популярных NoSQL баз, нету практически никаких оптимизаций при чтении данных с диска. Я просто оставлю тут ссылки на 2 картинки:
А почему вы считаете, что NoSQL будет работать быстрее при выборках по первичным ключам? Почему 3 запроса (джоинов то нету) в NoSQL базу должны отработать быстрее, чем 1 запрос с джоинами на 3 таблицы, в каждой из которых будем по первичным ключам получать данные?
Особенно интересны ответы на эти вопросы в случае с объёмом данных, не влезающим в память.
Mongo иногда для разработки в разы быстрее. А ещё mongo иногда ломается в продакшене, когда делает перевыборы мастера под большой нагрузкой. И иногда при перевыборах мастера теряет данные. А интернет-магазинов с MySQL в качестве базы, на сколько я знаю, довольно много. Может быть, не так уж всё и плохо с разнородными товарами? Кстати, быстрее будет работать на mongo или на MySQL и почему?
Простите за некоторую корявость фразы, разработчики из SolidFire говорят, что они очень любят пользователей mongo.
Вы сами написали слова MariaDB, NoSQL и BigData рядом.
Дальше. ваша цитата:
NoSQL — это не мода, в hardcore IT нет понятия гламура. Это способ решения проблем, которые оказалось невозможным решить с помощью реляционных CУБД с вменяемыми затратами ресурсов.
Пусть будет какой нибудь форум. Какие проблемы есть у MySQL и как эти проблемы решил Mongo? не надо будет думать про таблички?
Есть одна контора под Денвером, SolidFire называется, занимаются созданием аппаратных систем-хранилищ данных с SSD. Говорят, что очень любят пользователей MongoDB, потому что они в какой-то момент понимают, что на обычных дисках их база уже неработает. Можно ли это назвать вменяемой затратой ресурсов?
Вы правы, только вот стек Hadoop+HDFS+HBase — это совсем не конкурент для MySQL. Та же самая Mongo в абсолютном большинстве случаев не решает никаких проблем, которые невозможно решить с помощью MySQL.
Будем честны, часто выбирают Mongo, а не MySQL, просто потому, что это модно.
Посмотрите на типичного представителя RDBMS в Big Data — Oracle.
Или вы что под этим имели в виду?
BigData — это действительно подход к обработке и хранению, а именно — горизонтальное масштабирование, map-reduce. И для работы с такими задачами появились решения — Google Bigtable, Hadoop+HDFS+HBase. Но они никак не подходят для работы обычных сайтов, для них выдвигаются совершенно другие требования.
В то, что у обычного сайта есть Bigdata — простите, слабо верится. Ну какие нафиг большие данные у того же хабра?
И, кстати, прочитайте в интернете, что такое execution plan cache.
Понятно. Я имел в виду именно современные ESP и стабилизации, типа как на бмв ставят. Тем более, что производителей крупных штук 5 всего, навскидку: Bosch, Delphi, Magneti-Marelli. Скажем, на свежих Alfa Romeo динамическая стабилизация не умеет подавлять лёгкий снос передней оси (впрочем, не все его заметят :) ). А антибукс регулярно мешает парковаться во дворе, когда ледяная колея есть :). К счастью, не приходилось оказываться в заносе на переднеприводной машине с антибуксами.
Системы стабилизации той же BMW X1 в нештатной ситуации пока не пробовал, только тот же антибукс на небольших скоростях, но это не особо интересно. Но есть теоретическое понимание, когда они начинают работать, что они могут сделать и чего сделать не могут.
На поведение машины, на самом деле, намного сильнее влияют настройки подвески в контексте недостаточной-нейтральной-избыточной поворачиваемости и сцепление резины с дорогой. ESP лишь чуть-чуть поможет отодвинуть предел комфортной управляемости машины. Современные машины едут гораздо лучше машин 20-летней давности не из-за электроники, а из-за существенно лучше просчитанной подвески и лучшей резины.
Зачем покупать много машин и воротить логику шардирования, когда можно хранить всё на одной машине?
У NoSQL проблему обычно вызывает то, что потребление памяти линейно зависит от количества ключей.
Классический Oracle — это НЕ BigData. В него можно положить сотни миллиардов записей в каждую табличку, сделать много таких табличек, делать join на них и всё будет работать. Но сотню терабайт данных туда никто не запихивает, и никаких map-reduce не запускает.
И адекватных альтернатив ораклу из мира NoSQL нету совсем. Куда можно положить сотню миллиардов записей, чтобы оно при этом нормально шевелилось и не занимало несколько десятков машин?
Как вы поддерживаете консистентность данных? Скажем, добавляется комментарий к посту и одновременно пост удаляется. Я не про конкретно пост+комментарии, а про любые 2 связанные сущности.
Вы знаете, наверное, у нас с вами разный опыт и разное понимание сложных ситуаций. Если вам интересно — я готов рассказать о случаях из своей практики, на которые я прикладываю этот автопилот и из чего делаю вывод о его недееспособности.
И вы слишком хорошо думаете о возможностях современных систем автоматического вождения. Даже самым лучшим из них далеко до опытного водителя. Неопытный же водитель, в отличие от роботов, способен быстро обучаться. В то, что на текущий момент можно сделать самообучающуюся систему — не верю, эта задача слишком близка к ИИ. Робокар audi tts от стенфорда, который по гоночному треку ездит, проигрывает человеку, хотя едет вполне себе неплохо. Понять, что в данный конкретный момент происходит с машиной — очень сложная задача, у человека при этом задействованы зрение, вестибулярный аппарат, осязание и слух + прогнозирование ситуации подсознанием. Пилоты обычно называют это «чувствовать жопой» :)
Всякие ESP и прочие системы динамической стабилизации тупые, из затачивают под конкретную модель (включая мощность двигателя и производительность тормозов) и никакого самообучения там быть не может, они только слегка откладывают момент потери контроля над автомобилем.
Допустим, это страница комментария, как в ЖЖ: надо показать новость, 1 комментарий, автора с аватаркой и прочими его атрибутами.
Комментарий, кстати, всё равно непонятно как показать вместе с новостью, даже если вашей новой схемой пользоваться.
А что там с главной страницей?
Тормоза = производительность хуже = дольше извлекаются данные. Или вы что-то другое имели в виду?
Во-вторых, чтобы показать комментарий + новость, к которой он был сделан + автора вам надо получить 3 строки/объекта, как вы это сделаете за 1 NoSQL запрос?
В третьих, проблемы ой как есть. Допустим, у Mongodb, одной из самых популярных NoSQL баз, нету практически никаких оптимизаций при чтении данных с диска. Я просто оставлю тут ссылки на 2 картинки:
www.mysqlperformanceblog.com/wp-content/uploads/2010/04/InnoDB_int.png
qanswers.files.wordpress.com/2012/06/p1.png
Кстати, если вы в монге не будете удалять данные — то вы будете тратить page cache на кеширование удалённых записей.
Особенно интересны ответы на эти вопросы в случае с объёмом данных, не влезающим в память.
Простите за некоторую корявость фразы, разработчики из SolidFire говорят, что они очень любят пользователей mongo.
Дальше. ваша цитата:
Пусть будет какой нибудь форум. Какие проблемы есть у MySQL и как эти проблемы решил Mongo? не надо будет думать про таблички?
Есть одна контора под Денвером, SolidFire называется, занимаются созданием аппаратных систем-хранилищ данных с SSD. Говорят, что очень любят пользователей MongoDB, потому что они в какой-то момент понимают, что на обычных дисках их база уже неработает. Можно ли это назвать вменяемой затратой ресурсов?
Будем честны, часто выбирают Mongo, а не MySQL, просто потому, что это модно.
Или вы что под этим имели в виду?
BigData — это действительно подход к обработке и хранению, а именно — горизонтальное масштабирование, map-reduce. И для работы с такими задачами появились решения — Google Bigtable, Hadoop+HDFS+HBase. Но они никак не подходят для работы обычных сайтов, для них выдвигаются совершенно другие требования.
В то, что у обычного сайта есть Bigdata — простите, слабо верится. Ну какие нафиг большие данные у того же хабра?
И, кстати, прочитайте в интернете, что такое execution plan cache.
Системы стабилизации той же BMW X1 в нештатной ситуации пока не пробовал, только тот же антибукс на небольших скоростях, но это не особо интересно. Но есть теоретическое понимание, когда они начинают работать, что они могут сделать и чего сделать не могут.
На поведение машины, на самом деле, намного сильнее влияют настройки подвески в контексте недостаточной-нейтральной-избыточной поворачиваемости и сцепление резины с дорогой. ESP лишь чуть-чуть поможет отодвинуть предел комфортной управляемости машины. Современные машины едут гораздо лучше машин 20-летней давности не из-за электроники, а из-за существенно лучше просчитанной подвески и лучшей резины.
У NoSQL проблему обычно вызывает то, что потребление памяти линейно зависит от количества ключей.
И адекватных альтернатив ораклу из мира NoSQL нету совсем. Куда можно положить сотню миллиардов записей, чтобы оно при этом нормально шевелилось и не занимало несколько десятков машин?
И вы слишком хорошо думаете о возможностях современных систем автоматического вождения. Даже самым лучшим из них далеко до опытного водителя. Неопытный же водитель, в отличие от роботов, способен быстро обучаться. В то, что на текущий момент можно сделать самообучающуюся систему — не верю, эта задача слишком близка к ИИ. Робокар audi tts от стенфорда, который по гоночному треку ездит, проигрывает человеку, хотя едет вполне себе неплохо. Понять, что в данный конкретный момент происходит с машиной — очень сложная задача, у человека при этом задействованы зрение, вестибулярный аппарат, осязание и слух + прогнозирование ситуации подсознанием. Пилоты обычно называют это «чувствовать жопой» :)
Всякие ESP и прочие системы динамической стабилизации тупые, из затачивают под конкретную модель (включая мощность двигателя и производительность тормозов) и никакого самообучения там быть не может, они только слегка откладывают момент потери контроля над автомобилем.