NoSQL и Big Data – обман трудящихся?

    imageНедавно нам удалось пообщаться с великим Монти — Майклом Видениусом, автором оригинальной версии открытой СУБД MySQL, который в настоящее время работает над ее ответвлением, MariaDB. (Кстати, обе эти базы поддерживаются в Jelastic.)

    Как известно, мир производит и обрабатывает все больше данных (так называемый феномен «Big Data»). Общепринято мнение, что данных теперь так много, что обрабатывать их с помощью традиционных баз данных и программных методов трудно или невозможно. Это вызвало волну нереляционных баз данных (NoSQL), в которых упор делается на высокую масштабируемость. Эксперт в области баз данных, Монти, поделился с нами своими мыслями о текущем и будущем состоянии SQL, NoSQL и Big Data. Некоторые его ответы были несколько неожиданными, так что мы с радостью приводим здесь русский перевод расшифровки нашей беседы:

    Не могли бы Вы рассказать нам немного об истории NoSQL и big data? Почему эта тема представляет такой интерес в последнее время?

    Все это «новое NoSQL движение» началось с поста в блоге от сотрудников Twitter, которые считали, что MySQL не был достаточно хорош для них. Они нуждались в «чем-то получше», в чем-то типа Cassandra.

    Основная причина проблем Twitter с MySQL — это неправильное использование самой базы. К тому же решение, которое они предлагали, можно было бы реализовать в MySQL так же легко, как и в Cassandra.

    Я не могу найти оригинальную статью, но я нашел чуть более позднее упоминание о том, что Cassandra заменит MySQL.

    Cегодня (спустя 3 года) Twitter все еще использует MySQL в качестве основного хранилища для твитов. Cassandra, в конечном итоге, не смогла заменить MySQL.

    Основной причиной такой популярности NoSQL является то, что, в отличие от SQL, Вы можете начать ее использовать без каких-либо дополнительных разработок. На самом деле, начать с NoSQL очень просто, но Вы заплатите за это позже, когда потеряете контроль над своими данными.

    Таким образом, основные преимущества (по крайней мере, до появления MariaDB) большинства NoSQL решений это:
    • Быстрый доступ к данным (если все данные помещаются в оперативной памяти),
    • Быстрая репликация / распределение данных между многими узлами,
    • Гибкая схема (можно добавлять новые столбцы мгновенно).

    Что Вы лично думаете о будущем NoSQL / Big Data? Ваши прогнозы?

    Я считаю, что большинство людей стремятся использовать NoSQL главным образом из-за «шумихи» вокруг этой технологии. Большинство компаний реально не имеют больших объемов данных, таких как у Facebook и Google, и они не смогут позволить себе нанять специалистов для настройки и постоянной разработки базы.

    Реляционные базы данных – SQL – никуда не денутся. NoSQL просто не сможет заменить их. Почти всем нужны связи (joins), чтобы использовать данные.

    Тем не менее, бывают ситуации, когда использование NoSQL имеет смысл. Я думаю, в будущем, мы увидим больше комбинированных решений, которые включают SQL и NoSQL.

    Именно поэтому мы расширяем функционал MariaDB, чтобы иметь возможность доступа к NoSQL базам данных, таким как Cassandra и LevelDB.

    Если NoSQL нужны только в редких случаях, почему люди до сих пор ими пользуются? Каковы основные причины?

    Потому что это всегда гораздо проще — начать с NoSQL. Вам не нужно учить SQL и определять схему базы данных, прежде чем начать ее использовать. Некоторые используют NoSQL, потому что верят, что она масштабируется лучше, чем SQL.

    Может ли SQL превзойти NoSQL? Какие уникальные преимущества делают SQL лучше, чем NoSQL?

    В случаях, когда данные начинают не помещаться в памяти, SQL, как правило, превосходит NoSQL.

    Есть также много других вещей, которые NoSQL просто не может сделать. Большинство NoSQL решений оптимизированы под одноключевой доступ. Для чего-нибудь большего, нужно писать программу. В этом случае очень трудно превзойти SQL оптимизатор для комплексных задач, особенно выборки, которые автоматически генерируются на основе запросов пользователей (этого требует большинство веб-сайтов).

    SQL также может превосходить NoSQL при работе с одиночной машиной. В кластере, где все находится в памяти, — наоборот, NoSQL обычно опережает SQL по ключевым запросам.

    Что Вы думаете о последнем объявлении Cloudera о привлечении инвестиций для коммерческого Hadoop?

    Главной проблемой Hadoop является то, что не существует известной модели ведения бизнеса, которая гарантировала бы инвесторам получение ожидаемой десятикратной прибыли. В связи с этим мне трудно понять, как Cloudera могут выжить в долгосрочной перспективе.

    Просто хорошого продукта мало, нужно уметь на нем зарабатывать.

    Кто сейчас активнее всего продвигает Big Data и NoSQL?

    Все поставщики NoSQL, конечно же;)

    Если все это просто обман, почему столько шумихи?

    Это обман не для всех. Есть много больших компаний и проектов, которые могут извлечь выгоду из Big Data.

    Тем не менее, я хочу сказать, что большинству не нужна ни Big Data, ни NoSQL, так как это обойдется дороже в долгосрочной перспективе, когда вы, наконец, обнаружите, что NoSQL не может решить все потребности вашего бизнеса.

    И, наконец, как MariaDB вписывается во все это?

    Мы стремимся к тому, чтобы сделать MariaDB своего рода мостом между NoSQL и SQL. Вот почему мы добавили сначала поддержку Cassandra и в настоящее время работаем над добавлением поддержки LevelDB.

    Мы осознаем, что NoSQL пытается удовлетворить некоторые действительно важные потребности, и именно поэтому добавили динамические столбцы (что делает SQL схему гибкой, как большинство NoSQL схем) и более быструю репликацию.

    В MariaDB 10.0 репликация будет еще быстрее, еще гибче и отказоустойчивей.

    Мы также тесно сотрудничаем с Galera, чтобы обеспечить мульти-мастер решение в MariaDB.

    Все это для того, чтобы лучше адаптироваться к меняющемуся миру и удовлетворять существующие потребности людей — возможно даже и надуманные потребности;)

    Расскажите, пожалуйста, о новом фонде MariaDB. Что это значит для разработчиков?

    Фонд MariaDB был создан для того, чтобы множество независимых компаний могли работать вместе над общей целью, активно развивать MariaDB, как проект с открытым исходным кодом. Фонд нанимает разработчиков, чтобы сделать все сборки, осуществить контроль качества, проверку патчей и т.д., все необходимое, чтобы проект двигался вперед.

    Большое спасибо, Монти! MariaDB продолжает оставаться очень популярной среди пользователей платформы Jelastic. Всего наилучшего!
    Jelastic
    Jelastic DevOps PaaS для хостеров и ISV
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 286

      +48
      а как же crudcomic.com/page/10?

        0
        А как же Redis?
          +1
          Redis лучше рассматривать как альтернативу MemcacheD/DB/Q — т.е. систему кэширования.
            0
            Redis это всё-таки как его определяли профи «in-memory data structures server».
              0
              Это вам кто сказал? Redis намного больше, чем кэширование. Давно на redis.io/commands не заглядывали.
                0
                Я знаю что там в полнюю версию включили репликацию и Lua скрипты, но ИМХО — превратить Redis в полноценную БД очень сложно, если модель данных умещается в парадигму кэшей — то все ОК, если нет — то все очень и очень печально.
                  0
                  Да, Redis не супер-функциональная база для любых задач, но уже далеко не лишь система кэширования.
                    0
                    Поясню на пальцах — если Вам/Ваша ORM больше укладывается в парадигму кэшей (ключ-значение) — то выбор Redis оправдан, если Вы хотите сделать что-либо сложнее — то на Redis это очень сложно, даже несмотря на то что уже есть поддержка Lua в мастре бранче и репликации более-менее юзабельны.
                      0
                      Я уже согласился выше. Я всё к фразе «Redis лучше рассматривать как альтернативу MemcacheD/DB/Q — т.е. систему кэширования.» придираюсь. Есть вещи, которые на Redis давно можно было сделать (без LUA), а на Memcache нет.
          +12
          Мммм… Есть мнение что SQL как таковой избыточен для 80% задач типичного веба. Предлагаю обсудить.
            +10
            сейчас SQL используется зачастую там, где нам нужно просто key-value хранилище. просто для того, чтобы упростить установку веб-приложения и не вводить новых компонент.
            действительно на базовом веб-сайте SQL нам необходим лишь в паре «модулей», в остальных NoSQL / Key-Value хранилищ будет с избытком.
            мне кажется именно с этим связано
            Я думаю, в будущем, мы увидим больше комбинированных решений, которые включают SQL и NoSQL.
              +2
              Так NoSQL-хранилище развернуть проще вроде бы.

              Я думал над этим вопросом и для веба, имхо, sql реально нужен только для какого-то сложного BI (OLAP, отчеты и тому прочее), для чего все равно разворачивается обычно отдельный инстанс, который не нагружен продакшном, либо для комплексных операций где нужны нормальные транзакции. Но по большей части это банальный CRUD.
                0
                OLAP это вообще отдельная история.
                SQL сложно использовать для сложных аналитических запросов.
                Для это существуют специальные языки MDX, и новое веяние от майкрософт — DAX.
                  +1
                  Спасибо за наводку, ушел читать ;)
                +2
                Хотя если уже существует инфраструктура, построенная на SQL, включая оборудование и специалистов, то внедрение NoSQL может оказаться дороже, чем поддержка и доработка существующего.
                  +1
                  Я думаю, в будущем, мы увидим больше комбинированных решений, которые включают SQL и NoSQL.
                  Такие на рынке есть уже давно.
                  Дореляционные СУБД (60/70-е гг.) тоже на месте не стоя́т.
                    +1
                    Cache — довольно занятная система.
                    Из боевых систем (про которые я в курсе) — используется в работе ДЛО
                      –1
                      Что такое ДЛО?
                        +1
                        кхм… если случайно навести мышку на аббревиатуру — то появится расшифровка.
                        Дополнительное Лекарственное Обеспечение
                        Грубо говоря — это льготное обеспечение лекарствами.

                        «ДЛО» — это дополнительное лекарственное обеспечение отдельных категорий граждан, имеющих право на государственную социальную помощь в виде набора социальных услуг».

                        Федеральный закон от 17 июля 1999 года № 178-ФЗ «О государственной социальной помощи» в редакции Федерального закона от 22 августа 2004 года № 122-ФЗ.
                        0
                        в какой части? там оракл всегда был.
                          0
                          В «клиентской» части, которая в аптеках ставилась.
                          «М-Аптека Льгота», если склероз не изменяет
                        0
                        Базовые классы тестовых данных там шикарны. Одно удовольствие потом наполнять базу тестовым контентом для проверки.
                        +6
                        >>действительно на базовом веб-сайте SQL нам необходим лишь в паре «модулей», в остальных NoSQL / Key-Value хранилищ будет с избытком.

                        Если нужно в паре модулей, то зачем в остальных плодить сущности и использовать еще одну базу данных? Мне трудно представить модуль в котором nosql облегчит разработку. Там где требуется key=>value интуитивно понятно будет использовать простые запросы, типа SELECT * from table WHERE `id` = '1'

                        >>Так NoSQL-хранилище развернуть проще вроде бы.
                        Mysql разворачивается в пару кликов в windows и немногим более в linux. А также присутствует практически на всех хостингах и предустанавливается бесплатно практически на всех VDS/VPS и выделенных серверах.
                          +12
                          «key-value»-базами NoSQL не ограничивается. Есть множество всяких специализированных БД — документо-ориентированные, объектно-ориентированные и так далее.

                          Там где требуется key=>value интуитивно понятно будет использовать простые запросы, типа SELECT * from table WHERE `id` = '1'


                          Встречный вопрос — ну и зачем для таких запросов городить реляционную (то есть со «связями») БД, если точно так же интуитивно понятно что-то типа
                          db.entity.find( { _id: 1 } );

                          Ну и если мы говорим о чем-то серьезном, то в любом случае ваш запрос будет скрыт за DAL в любой его форме.
                            0
                            Ну даже в простейшем бложике, может быть сортировка списка постов по дате к примеру, или автору, или количеству просмотров/комментов, плюс это может быть для разных разделов. А уже после этого выбор по id конкретного поста.
                              +9
                              db.entity.find({author:ObjectId(author_id)}).sort({date:-1}).skip(page*count).limit(count)
                                0
                                Я как бы не писал, что это невозможно :)
                                  +2
                                  SELECT * FROM posts WHERE author = &author ORDER BY date DESC LIMIT page*count, count

                                  Кажется, такой будет MySQL-аналог. Выглядит, на мой пристрастный взгляд, проще вашего. Ну, и у вас фильтр простой. А можете так же „все комментарии пользователей из группы «друзья» за сегодня“? Мне кажется, будет трудночитаемая каша.
                                    0
                                    Навскидку, что типа этого:
                                    db.comments.find({ author:{ $in:friends }, when:{ $gt:yesterday } })
                                    

                                    А как это будет на SQL?
                                      0
                                      Мм, не понял, у вас подразумевается, что список членов группы «друзья» уже выбран и передаётся как объект-список?
                                      Я подразумевал аналог примерно такого запроса (с выборкой из двух таблиц — комментариев и пользователей):
                                      SELECT * FROM comments JOIN users ON comments.author = users.id WHERE DATE(comments.date) = DATE(NOW()) AND users.group = 'friends'
                                        +1
                                        У вас запрос не полноценный — любой пользователь системы входит сразу в несколько групп, например он для Васи — друг, для Оли родственник, а для Пети просто знакомый.
                                        Я думаю что вам в запрос нужно добавить таблицу «Группы Пользователей».

                                        у вас подразумевается, что список членов группы «друзья» уже выбран и передаётся как объект-список?

                                        Да, группы пользователя — это личные списки пользователя, поэтому их можно хранить готовыми в объекте пользователя (что я и сделал в одном соц. проекте). Вот для получения «друзья друзей» нужно (не всегда, зависит от реализации) выполнить такой же запрос на вхождение.
                                          0
                                          Изначально речь шла о личном бложике, поэтому имелось в виду что «друзья» — это друзья его владельца. А так пусть группа будет «администраторы», например.
                                          +1
                                          Некоторые задачи решаются через MapReduce, что несколько сложнее, но зато можно сделать всё что угодно на обычном языке программирования, а не специализированным языком запросов.

                                          Схема соответствия SQL запроса и MapReduce

                                          Дело не в том, что это проще, а что это можно сделать, ну нужно учесть плюсы NoSQL решений, для многих проектов это было бы лучше, чем костылить на реляционной базе.
                                          +1
                                          Именно, что список уже выбран.
                                          Вы пытаетесь использовать нормализованные данные, это неправильный путь в случае с key-value хранилищами. Здесь лучше денормализовать данные, и, например, хранить список друзей пользователя прямо в его профиле, откуда он легко достается.
                                            0
                                            Я плохо пояснил — имелась в виду глобальная группа привилегированных пользователей (речь шла не о соц. сети, а о личном блоге)
                                              0
                                              Ну, достаем объект «группа» по id «friends», и вытаскиваем список пользователей оттуда, делов-то.
                                                +2
                                                В общем, мысль такова: нет ни одной задачи по выборке данных, которую можно было бы решить на MySQL, и нельзя было бы решить с помощью NoSQL. Возможно, придется самому поработать интерпретатором и оптимизатором запросов, но тем не менее, ничего невозможного. Разница между ними в другом — тут уже много говорили про это.
                                                  0
                                                  Мне кажется, так можно и в Мускуле реализовать что угодно из «Носкула». Будет сложно, костыльно, велосипедно и неоптимально, но будет.
                                                  Суть SQL (для меня) в простоте выборок жёстко структурированных данных из более чем одной таблицы. Суть NoSQL, как я для себя понял из этого обсуждения — в простоте выборок сложных объектов из не связанных отношениями списков.
                                    +11
                                    Меня смущает слово «городить», я бы заменил его на «использовать по назначению». Mysql жрать не просит, не требует ежедневных танцев с бубнами, подключается с помощью пары строк и довольно прост в применении.

                                    >>Ну и если мы говорим о чем-то серьезном, то в любом случае ваш запрос будет скрыт за DAL в любой его форме.
                                    Давайте определимся что такое базовый сайт. У меня ассоциации всплывают с блогами, информационными сайтами, интернет-магазинами и корпоративными сайтами. Большинство из них нет смысла создавать с помощью собственного велосипеда, достаточно напильником доработать один из сотни готовых движков, большинство из которых уже написаны с использованием той или иной sql. Миллионы посетителей и петабайты информации им не грозят и скорость sql если и является бутылочным горлышком, то лечится простым и дешевым апгрейдом сервера (намного более дешевым, чем поиск специалиста по nosql и переписывании кода).

                                    >>db.entity.find({author:ObjectId(author_id)}).sort({date:-1}).skip(page*count).limit(count)
                                    >>db.entity.find( { _id: 1 } );

                                    Выглядит как SQL-запрос, пропущенный, через обфускатор
                                      +1
                                      Полностью согласен. В довесок хотелось бы озвучить еще один момент.

                                      Я может быть ошибаюсь, но разве эта ваша монга научилась ограничивать себя по памяти?
                                      Раньше это было вопиющей проблемой, о которой все молчали, а доки стыдливо рекомендовали использовать отдельный сервер, сугубо под монгу.

                                      Больше всего меня удивляет как разработчикам подсовывают schema-less под видом того что они смогут работать быстрее, а разработчики не видят, что при этом им втюхивают дополнительные приключения на app уровне. Выглядит как банальный маркетинг (одна несетевая ололо-гридфс чего стоит).

                                      Извините, наболело.
                                        +3
                                        Зато если мне надо не один сервер, а больше, в монге вопросов нет. вообще.
                                        А в мускуле — чур меня, чур.
                                        Да и не было реально у меня никогда никаких проблем с памятью в монге, хотя вертится все на таком сервере, который и смартфоном-то не назовешь, по нонешним меркам :-)
                                        0
                                        Если задаваться вопросом «как из монги сделать мускуль» — то да, будет странновато. но возможно. а вот в обратку будет куда сложнее. если надо сбацать сложную нерегулярную структуру. Когда у объектов неопределенное количество неопределенных свойств, например.
                                        Ну и шардинг из коробки — это просто сказка и песня. Когда там в маше будет multimaster? Никогда?
                                          0
                                          Когда там в маше будет multimaster?

                                          It is possible to achieve a multi-master replication scheme beginning with MySQL version 3.23. MySQL Cluster supports conflict detection and resolution between multiple masters since version 6.3 for true multi-master capability for the MySQL Server.

                                          Используем в своём проекте, как и Redis.

                                          Все как-то разом забыли историю СУБД и то, что реляционные хранилища (выражающий отношение; связанный с выражением отношений между чем либо) пришли на смену нереляционным.
                                          История циклична и вправду.
                                            0
                                            Возможно, я неправ, и кластер (про который я, разумеется, слышал еще тогда :-) реально работает и так далее. Однако, о массовом его применении речь не идет. А вот в Монге — вполне. Вопрос же не только в том, что возможно сделать. Дело еще и в том, сколько придется затратить усилий… С монго, считай, и делать ничего не надо — мультимастер работает «из коробки». Если вы мне сейчас скажете, что я просто дремуч, и мультимастер с кластером — это такое же отлаженное и реально работающее бесплатное решение, как и сам мускуль — я, конечно, скажу спасибо и пойду читать.

                                            для понимания, из моих действующих проектов минимум пяток используют мускуль, два — монго, и один — редис.
                                            причем, один из проектов, где монго работает на отдачу, использует мускуль для дата-молотилки в бэкенде.
                                              0
                                              Мы же не про кластер говорим, а про реплики. Реплика с множеством мастеров поддерживается с дремучих времен и работает весьма неплохо.
                                              Перечитайте еще раз цитату.

                                              Мы тоже редис используем. Монгу я использовал в одном из прошлых проектов. Я не бешеный евангелист РСУБД, просто не нужно наговаривать :)
                                      +4
                                      Хранить древовидную структуру комментов в SQL это боль, а в докумето-ориентированных типа Couch, Mongo и Riak это элементарно и интуитивно.
                                        –1
                                        И в чем боль?
                                          0
                                          Хотя бы тем, что документы можно легко вкладывать в другой документ.
                                            0
                                            Если у вас есть нормальная ОРМ, то я даже не задумываюсь, над тем, как хранятся данные. В нашем случае нестед сеты автоматически поддерживаются ОРМ, мне же остается делать только что-то типа item.GetChildren() / item.GetParents() и т.п.
                                              0
                                              Далеко вы так не уедете. Нужно получать весь список сразу (все дерево или ветку).
                                                –1
                                                Еще как уеду. Просветитесь habrahabr.ru/post/153861/
                                                  0
                                                  … если дерево статическое
                                                    0
                                                    Знаю, давно уже «просветился». У каждого подхода есть недостатки.
                                                    На активно меняющемся дереве с большим количеством элементов NS не будет работать. Если небольшая менюшка, то да.
                                                      0
                                                      У нас отлично работает на десятках тысяч элементов, а деревья больше мало кому нужны
                                                        0
                                                        И сколько времени выполняется обновление записи и какой уровень изоляции?
                                                          0
                                                          Десятки миллисекунд, read committed snapshot
                                            0
                                            Вы и правы и не правы. Хорошая статья на тему.
                                              0
                                              Спасибо за ссылку. Интересно посмотреть на производительность всего этого дела по сравнению с noSQL. Запросы выглядят адово.
                                                0
                                                Запросы выглядят адово.


                                                Ну, тут уж приходится мириться — или простая вставка(id-parent), но долгая выборка, или сложная модификация, но быстрая выборка дерева.
                                                Не знаю что все так стремятся сравнивать не-реляционные хранилища с реляционными. Они не про скорость :)
                                                0
                                                А у вас нет примера как это дерево по алфавиту отсортировать на каждом уровне?
                                                  0
                                                    0
                                                    Т.е. без извращений никак.
                                                      0
                                                      Предложите ваш вариант решения этой проблемы для какой-нибудь нереляционной СУБД.
                                                        0
                                                        А я ими вообще не интересуюсь и не являюсь специалистом в данной области. Сам использую данный подход для хранения структуры меню, каталогов, комментариев и пр.; а вот когда список большой хочется отсортировать его для удобства поиска, и варианта два: либо сохранять/дублировать в нужном виде, либо тратить вычислительные ресурсы, я пока выбрал программно обходить дерево и выстраивать его в нужном виде.
                                                          0
                                                          Ясно. Обычно разного рода сортировки над сложными сущностями, если весь массив данных и так получаем, имеет смысл делать на стороне UI — тут и возможностей больше и нагрузки на хранилища меньше.
                                                          Мне кажется, что сортировка дерева что для NoSQL, что для SQL будет происходить программно.
                                                          0
                                                          В языке M/MUMPS — для такого достаточно Order
                                              0
                                              >на базовом веб-сайте SQL нам необходим лишь в паре «модулей», в остальных NoSQL / Key-Value хранилищ будет с избытком

                                              Можно поподробней?
                                              Я сичтаю, что на базовом сайте key-value хранилище нужно только для сессий и то не везде они нужны — сессии это зло.
                                              Остальное это как раз SQL (новости, комментарии, ордеры).
                                                +1
                                                И за что минусовали, можно комментарий? Если вы утверждаете что на базовом сайте очень надо NOSQL, просьба аргументировать где именно, поскольку я ещё не встречал в базовый сайтах NOSQL.
                                                Минус мне, это поддержка вашей идеи — обоснуйте, пожалуйста.
                                                  +1
                                                  На базовом сайте SQL тем более не нужен. А вот в зависимости от того что именно вы считаете базовым сайтом, подходящие технологии могут быть различными.
                                                    –2
                                                    Почему же SQL не нужен на базовом сайте?
                                                    Для меня базовый сайт, это:
                                                    — новости
                                                    — комментарии
                                                    — аутентификация
                                                    — какая-то специфика

                                                    Выбрать новости нужно джоинить новость с пользователем и с рубрикой, например или тегом.
                                                    Комментарии тоже нужен пользователь.
                                                    В NOSQL, правильно в статье замечено, вы рано или поздно потеряете контроль над своими данными, когда нужно будет удалить пользователся, например или собрать статистику. Да и делать такую избыточность ИМХО нет никакого смысла, когда это очень быстро решается в SQL.

                                                    NOSQL применяется в кешировании, сессиях, хранения прерасчитанных отчетов с избыточностью.
                                                      0
                                                      Я, к сожалению, не силён в NoSQL, спецы, при желании, поправят:

                                                      Пользователь(ЙДПользователь)= ИмяПользователя, пароль
                                                      +Индексы: ИмяПользователя => ЙДПользователь

                                                      Новость(Рубрика, Дата, ЙДНовость)= Тема, Пользователь, Тэги
                                                      +Индексы: Пользователь => его Новости, Тег => Новости

                                                      Комментарий(ЙдНовость, Дата, ЙдКомментарий)= Пользователь, Текст
                                                      + Индексы: Пользователь => его коментарии,

                                                      Физическое удаление пользователя и в SQL и в NoSQL вариантах — глупость. Надо выбрать наиболее подходящий под логику вариант, например пометка на удаление, login=false и т.п.

                                                      Какую именно статистику?

                                                      И SQL и NoSQL не являются панацеей. В SQL тоже не трудно потерять контроль над данными при неверном проектировании, просто в SQL вероятнее получить другую проблему — тормоза.

                                                        0
                                                        Т.е. базовые сайты вы делаете именно в такой схеме и до сих пор не сильны в NOSQL?
                                                        Контроль даже над собой можно потерять. Если структура база нормализированна, то ничего вы не потеряете.
                                                        Удаление это не глупость, а часть жизненного цикла объекта.

                                                        Статистика нужна для разных вещей: пользователей (топ каких-то, топ коментаторов), новостей (топ по комментариям) и т.д.

                                                          –1
                                                          нет, я вообще сайты не делаю. :( А в NoSQL не силён т.к. изучаю в свободное от работы время.

                                                          Полная нормализация — вещь вообще-то абсолютная. И в реальной применима на очень маленьких примерах. Вы вот например Фамилию пользователя будете хранить в одтельной таблице Фамилий?

                                                          Удаление логическое — да, а вот физическое не всегда.

                                                          Понятно. Пример наверно не очень удачный — его легко сделать на чём угодно. Разве, что на plain-text файлах повозится чуток придётся.
                                                          0
                                                          А почему вы считаете, что NoSQL будет работать быстрее при выборках по первичным ключам? Почему 3 запроса (джоинов то нету) в NoSQL базу должны отработать быстрее, чем 1 запрос с джоинами на 3 таблицы, в каждой из которых будем по первичным ключам получать данные?

                                                          Особенно интересны ответы на эти вопросы в случае с объёмом данных, не влезающим в память.
                                                            0
                                                            Во первых, я кажется не писал что будет гарантированно быстрее. Я писал что без всего можно обойтись.

                                                            Во вторых, в примере будет 1 NoSQL запрос. И в примере они уже будут как я решил отсортированы.

                                                            В третих, мне интересны только persistent NoSQL, и у них никаких проблем с поиском «вне памяти» нету.

                                                              0
                                                              Во-первых, вы писали:
                                                              В SQL тоже не трудно потерять контроль над данными при неверном проектировании, просто в SQL вероятнее получить другую проблему — тормоза.

                                                              Тормоза = производительность хуже = дольше извлекаются данные. Или вы что-то другое имели в виду?

                                                              Во-вторых, чтобы показать комментарий + новость, к которой он был сделан + автора вам надо получить 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 на кеширование удалённых записей.
                                                                0
                                                                Так не на таких же данных! Вы тут и NoSQL запутаь не сможете.

                                                                Именно это.

                                                                Я говорил про главную страницу.
                                                                А для примера «показать комментарий + новость, к которой он был сделан + автора» мне тоже достаточно 1го NoSQL запроса(но лучше сказать прохода). Но тогда я не верно спроектировал структуру.

                                                                Новость(Рубрика, Дата, ЙДНовость)= Тема, Пользователь, Тэги
                                                                Новость(Рубрика, Дата, ЙДНовость, Дата,)= ЙдКомментарий, Пользователь, Текст.

                                                                  0
                                                                  А путь до аватарки пользователя где хранится, в каждом комментарии? Как он её будет менять?

                                                                  Комментарий, кстати, всё равно непонятно как показать вместе с новостью, даже если вашей новой схемой пользоваться.

                                                                  А что там с главной страницей?
                                                                    0
                                                                    Тогда больше запросов нужно.

                                                                    это будет в терминах SQL выборка из одной таблицы с одним условием на ЙД новости в WHERE секции.

                                                                    Аналогично.
                                                                      0
                                                                      Я вообще не понимаю ваших ответов, если честно. Вы могли бы подробно описать в одном комментарии, какие данные и как хранятся, и как вы их извлекаете.

                                                                      Допустим, это страница комментария, как в ЖЖ: надо показать новость, 1 комментарий, автора с аватаркой и прочими его атрибутами.
                                                                        –1
                                                                        Вот вариант. Это сделано на M/MUMPS для GT.M.

                                                                        Данные
                                                                        Set ^Users("4dmonster","avatar")="/avatars/green_monster.png"
                                                                        Set ^Users("4dmonster","email")="4dmonster@gmail.com"
                                                                        Set ^Users("4dmonster","password")="********"
                                                                        Set ^Users("ANDcle","avatar")="/avatars/BigDollar.jpg"
                                                                        Set ^Users("ANDcle","email")="navel@whole.earth"
                                                                        Set ^Users("ANDcle","password")="i am the god of data"
                                                                        Set ^Users("YourSQL","avatar")="/avatars/HasNoFuture.bmp"
                                                                        Set ^Users("YourSQL","email")="over@the.sun"
                                                                        Set ^Users("YourSQL","password")="i can run SP"
                                                                        Set ^Users("internet","avatar")="/avatars/inet.jpg"
                                                                        Set ^Users("internet","email")="root@127.0.0.1"
                                                                        Set ^Users("internet","password")="***"
                                                                        
                                                                        Set ^News(1,"Author")="internet"
                                                                        Set ^News(1,"Caption")="RDBS vendors strikes back"
                                                                        Set ^News(1,"Section")="HolyWars"
                                                                        Set ^News(1,"Text")="RDBMS vendors are trying to catch the NoSQL train dispite their own bullshit  fire on opponents' technology."
                                                                        Set ^News(1,"comments",1,"author")="4dmonster"
                                                                        Set ^News(1,"comments",1,"date")=201302221604
                                                                        Set ^News(1,"comments",1,"text")="Тtrue story"
                                                                        Set ^News(1,"comments",1,"vote")=-2
                                                                        Set ^News(1,"comments",1,"vote","ANDcle")=-1
                                                                        Set ^News(1,"comments",1,"vote","YourSQL")=-1
                                                                        Set ^News(1,"comments",2,"author")="ANDcle"
                                                                        Set ^News(1,"comments",2,"date")=201302221605
                                                                        Set ^News(1,"comments",2,"text")="I'll sue you!"
                                                                        Set ^News(1,"comments",2,"vote")=0
                                                                        Set ^News(1,"comments",3,"author")="YourSQL"
                                                                        Set ^News(1,"comments",3,"date")=201302221608
                                                                        Set ^News(1,"comments",3,"text")="It wasn't me!"
                                                                        Set ^News(1,"comments",3,"vote")=1
                                                                        Set ^News(1,"comments",3,"vote","4dmonster")=1
                                                                        Set ^News(1,"picture")="/pics/Motaro_vs_ShangTsung.gif"
                                                                        Set ^News(1,"vote")=-1
                                                                        Set ^News(1,"vote","ANDcle")=-1
                                                                        Set ^News(1,"vote","YourSQL")=-1
                                                                        Set ^News(1,"vote","monster")=1
                                                                        


                                                                        Вот файл forHabr.m
                                                                        root@flexy:~/.fis-gtm/V6.0-001_x86_64/r# cat forHabr.m 
                                                                        
                                                                        ExampleNews(NewsId)
                                                                            write !,"=================================================",!
                                                                            write "Category       :",^News(NewsId,"Section"),!
                                                                            write "Caption        :",^News(NewsId,"Caption"),!
                                                                            write "Picture        :",^News(NewsId,"picture"),!
                                                                            write "Text           :",^News(NewsId,"Text"),!
                                                                            write "Author         :",^News(NewsId,"Author"),!
                                                                            write "Author's avatar:",^Users(^News(NewsId,"Author"),"avatar"),!
                                                                        
                                                                            write !,"Rating         :",^News(NewsId,"vote"),!    
                                                                            write "Voters: "
                                                                            set voter=""
                                                                            For  Do  Quit:voter=""
                                                                            .Set voter=$Order(^News(NewsId,"vote",voter))
                                                                            .Quit:voter=""
                                                                            .write voter,"(",^News(NewsId,"vote",voter),") "
                                                                        
                                                                            write !,!,"Comments: "
                                                                            set comm=""
                                                                            For  Do  Quit:comm=""
                                                                            .Set comm=$Order(^News(NewsId,"comments",comm))
                                                                            .Quit:comm=""
                                                                            .write !,"-----------------------------------------------"
                                                                            .write !,^News(NewsId,"comments",comm,"author"),"(",^News(NewsId,"comments",comm,"date"),") avatar:",^Users(^News(NewsId,"comments",comm,"author"),"avatar")
                                                                            .write !,": ",^News(NewsId,"comments",comm,"text")
                                                                            .write !,"Rating: ",^News(NewsId,"comments",comm,"vote")
                                                                            .write " Voters: "
                                                                            .set voter=""
                                                                            .For  Do  Quit:voter=""
                                                                            ..Set voter=$Order(^News(NewsId,"comments",comm,"vote",voter))
                                                                            ..Quit:voter=""
                                                                            ..write voter,"(",^News(NewsId,"comments",comm,"vote",voter),") "
                                                                        
                                                                            write !!,"===================================================",!
                                                                        


                                                                        Вот результат работы продедуры:
                                                                        GTM>Do ExampleNews^forHabr(1)
                                                                        
                                                                        =================================================
                                                                        Category       :HolyWars
                                                                        Caption        :RDBS vendors strikes back
                                                                        Picture        :/pics/Motaro_vs_ShangTsung.gif
                                                                        Text           :RDBMS vendors are trying to catch the NoSQL train dispite their own bullshit fire on opponents' technology.
                                                                        Author         :internet
                                                                        Author's avatar:/avatars/inet.jpg
                                                                        
                                                                        Rating         :-1
                                                                        Voters: ANDcle(-1) YourSQL(-1) monster(1) 
                                                                        
                                                                        Comments: 
                                                                        -----------------------------------------------
                                                                        4dmonster(201302221604) avatar:/avatars/green_monster.png
                                                                        : Тtrue story
                                                                        Rating: -2 Voters: ANDcle(-1) YourSQL(-1) 
                                                                        -----------------------------------------------
                                                                        ANDcle(201302221605) avatar:/avatars/BigDollar.jpg
                                                                        : I'll sue you!
                                                                        Rating: 0 Voters: 
                                                                        -----------------------------------------------
                                                                        YourSQL(201302221608) avatar:/avatars/HasNoFuture.bmp
                                                                        : It wasn't me!
                                                                        Rating: 1 Voters: 4dmonster(1) 
                                                                        
                                                                        ===================================================
                                                                        
                                                                        


                                                                        Теперь пояснения. Путь до аватарки я не стал класть в узел, а беру его из таблицы пользователя, это сделано для того, чтобы показать что так тоже можно и изобразить стиль отображения аватарок хабра а не ЖЖ.

                                                                        Код программы компилируется один раз и исполняется на сервере БД, т.е. это аналог не SQL запроса а хранимой процедуры.

                                                                        Обращение к ^News это как внутри хранимки открыть курсор таблицы без джойнов но со всеми данными в столбцах, кроме аватарок.

                                                                        Обращение к аватаркам это почти как обращение к полю по первичному кластерному индексу.

                                                                        А теперь представьте тоже самое для РСУБД, да ещё без денормализации.
                                                                          0
                                                                          В вашем варианте вы сэкономили ровно 2 похода в индексы — сразу извлекаете комментарии вместе со статьёй и её оценки. Это хорошо.

                                                                          Но при этом каждая запись в таблице новостей постоянно растёт. Здесь возникает тот самый вопрос нормализации-денормализации: а будет ли так быстрее? Может быть, вы потеряете больше, чем получите? Ведь тут встаёт вопрос об эффективности работы той части базы даных, что работает непосредственно с диском. Есть ли в базе данных возможность эффективно обновлять данные на диске, как эффективно она рабоатет в случае постоянно растущих по объёму записей? В зависимости от профиля нагрузки ваш вариант может оказаться как быстрее аналогичного в SQL базе, так и медленнее.

                                                                          Что касается консистентности — в случае такой схемы вам надо как-то решать проблему консистентности на уровне приложения. В одном потоке добавляете комментарий к статье, а в другом автор этого же комментария удаляется — что делать, если второй поток придёт чуть раньше первого?
                                                                            +1
                                                                            Удаление автора комментария вообще-то обычно не должно приводить к удалению комментария.
                                                                            Но вообще да — в подобных системах подразумевается, что согласованностью данных будет заниматься приложение.
                                                                            Эффективность работы с диском вполне может быть сравнимой с RDBMS — можно, например, максимально хранить данные в памяти, а на диск писать changelog. Учитывая то, что обычно у подобных систем нет проблем с шардингом, можно обеспечить вариант, когда диск используется только на случай отключения питания, а работа ведется с данными в памяти.
                                                                              –1
                                                                              Работать в памяти и изредка синкать — довольно дорого в случае больших объёмов. И почти наверняка по скорости не будет разницы с RDBMS просто потому, что всё остальное (шаблонизатор, бизнес-логика) будет работать существенно медленней. Да и накладно — 1 тебарайт данных потребует минимум 6 машин (на сколько я в курсе, за вменяемые деньги сейчас можно запихать не больше 192 гигабайт в один сервер), если делать репликацию — то уже 12 получается.

                                                                              Я к чему — дисковая подсистема в InnoDB в разы лучше большинства NoSQL, но никто этого не замечает. Зато все кричат, что MySQL плохо шардируется. Но, может, на 1 машинке со 192 гигабайтами памяти и 1 тебарайтом данных он будет работать не сильно хуже, чем NoSQL на 6 машинах с 192 гигами каждая, и шардировать то не надо?
                                                                                0
                                                                                А терабайт пытались с ленты восстановить, например? Это достаточно долго, в отдельных случаях подобная задержка недопустима (я недавно с таким сталкивался — как раз терабайт был, восстановление из бэкапа несколько часов шло). Так что уже в любом случае не один сервер нужен, а минимум два. Опять же, в случае смерти одного из зеркалируемых серверов получаем задержку (если это был мастер) на подъем слейва до мастера, потом значительное падение производительности (остался-то один сервер), а потом еще тратим время на синхронизацию, причем до полной синхронизации есть вероятность вообще все потерять, т.к. живой сервер только один. Так что добавляем еще третий сервер, падение производительности меньше, но все равно есть задержка на переключение мастера, например.

                                                                                И вот тут становятся понятны преимущества 16 маленьких дешевых шардированных серверов по сравнению с тремя большими и дорогими с репликацией — при шардинге подобный инцидент никто не заметил бы, кроме техников.

                                                                                Есть, конечно варианты — можно использовать, например, сетевое хранилище, общее для двух серверов, но это уже совсем другие деньги начинаются, а преимуществ (для типичных веб-задач) у шестнадцати серверов все равно больше.
                                                                                  0
                                                                                  Вы сейчас репликацию с шардированием в одну кучу свалили и перемешали.

                                                                                  1. Все сервера одинаковые, по 192 гигабайта памяти в каждом. Вы сами предложили 1 терабайт в память положить, итого надо 6 серверов в реплике для NoSQL и 1 сервер в реплике для MySQL.

                                                                                  2. Если добавляем реплики — то добавляем в обоих вариантах, получается 12 против 2 серверов или 18 против 3. Повторюсь, сервера одинаковые.

                                                                                  3. Репликация. Если Master-Slave, то в обоих случаях переключение не моментально и есть риск потери данных. Если Master-Master синхронный — то переключение незаметно совсем, но производительность на запись ниже. У MySQL для этого есть Galera, возможно, есть что-то и для вашей любимой NoSQL базы.

                                                                                  Почему вы сравниваете 16 (почему именно 16?) маленьких дешёвых шардированных серверов (маленький — это сколько?) с 3 мощными машинами, где есть 3 реплики — непонятно. Кстати, по деньгам разница тоже не очевидна.
                                                                              0
                                                                              Напишите SQL вариант для приведённого выше вывода результата. И, возможно, тогда поймёте самостоятельно где вы ошиблись.

                                                                              Почему вы голословно утверждаете о худших алгоритах работы с диском???

                                                                              Да, консистентность отдана в ведение приложения. Кроме того, для статистики в примере придётся создавать индексы. И их поддерживать придётся тоже самому приложению. Но это, согласно исследованиям, не скажеться ни на скорости работы (вроде как в «6 раз быстрее оракла») ни на скорости написания приложения(тоже «в несколько раз быстрее чем на других языках/технологиях»).

                                                                              M/MUMPS, внезапно, поддерживает и транзакции и нормальную работу с LOCK. Соответственно мне достаточно решить во время написания кода, что делать в ситуации когда автор сохраняемого в базу коментария удалён.
                                                                                0
                                                                                Рядышком уже предлагали один из вариантов:
                                                                                SELECT n.Category, n.Caption, n.Picture, n.Text, n.Author, u.avatar FROM news AS n JOIN users AS u ON n.author = u.id AND id = &NewsId
                                                                                
                                                                                SELECT * FROM comments WHERE comments.newsId = &NewsId JOIN users ON users.id = comments.author ORDER BY comments.date
                                                                                

                                                                                там разве что надо добавить выдачу аватарки из таблицы users. Где именно, по-вашему, я не прав? Вы экономите на походы в индекс в таблицу comments и на поход в индекс в таблицу votes. В users ходить в любом случае придётся. В news — тоже. Если таблицы не очень здоровые — индексы всосутся в память и работать будут быстро.

                                                                                Что касается диска. Я не заявлял голословно, что одно будет быстрее другого. Я рассуждал о вариантах хранения, можете присоединиться и поправить, если я где-то не прав.

                                                                                В случае того же MySQL запись о новости один раз укладывается в buffer pool, после этого уже не изменяется. Комментарии добавляются в другие пулы, но тоже не изменяются. Писать очень быстро, читать — не очень, зато есть продвинутая система кеширования и дефрагментации.

                                                                                В случае хранения комментариев как куска самой новости у вас запись постоянно растёт в размере. Соответственно, вам надо будет либо перетаскивать её с места на место, либо преаллокейтить заранее сколько-то места (непонятно, сколько), либо хранить её кусками. в первом случае записывать совсем долго, зато быстро читать. В третьем случае читать долго (по сути — новость и комментарии хранятся отдельно), зато писать удобно. Второй случай — промежуточный, но требует эвристик. Как именно реализовано в GT.M — я не знаю. Вы знаете? Если да — расскажите, мне интересно.

                                                                                Наличие настоящих транзакций — это здорово, поддерживать в этом случае консистентность действительно не так уж напряжно. Далеко не все NoSQL системы могут этим похвастать.
                                                                                  0
                                                                                  Вы написали кусочек того что я написал в примере. Напишите Все запросы. Вы ведь видели что выводится гораздо больше. И рейтинги и кто как голосовал.

                                                                                  «я не знаю. Вы знаете? Если да — расскажите, мне интересно.» — именно и есть определение голословного утверждения.

                                                                                  На самом деле консистентность там можно поддерживать и без транзакций — при помощи нормальных блокировок LOCK. А традиционное для РСУБД явное управление транзакциями было внесено в стандарт по «просьбам» клиентов.
                                                                                    0
                                                                                    Я в тексте написал про таблицу votes. Вы не читали? Или мне обязательно надо было дописать ещё 1 запрос и один джоин? Я же вроде сразу написал, что да, в случае SQL базы надо будет больше запросов. Вопрос в том, в сколько походов на диск они превратятся.

                                                                                    Пока что это вы обвиняете меня в том, что я не говорил. А именно: я не говорил, что GT.M хуже работает с диском, чем InnoDB. Я предположил 3 варианта, как это может быть сделано, указал их плюсы и минусы. Вы продолжаете настаивать на том, что я что-то голословно утверждал? Тогда прочитайте мой комментарий выше, про InnoDB и большинство NoSQL. Большинство != все. Судя по вашим ответам, как именно работает с диском GT.M вы тоже не знаете. Более того, именно вы в своём комментарии в верху этого тредика написали, что в SQL базе вероятность получить тормоза больше, чем в NoSQL.
                                                                              0
                                                                              А теперь представьте тоже самое для РСУБД, да ещё без денормализации.
                                                                              Не могу понять, в чём разница. Ну, кроме того, что в РСУБД, обычно, форматирование вывода не запихивают.
                                                                              Будет несколько запросов такого вида:
                                                                              SELECT n.Category, n.Caption, n.Picture, n.Text, n.Author, u.avatar FROM news AS n JOIN users AS u ON n.author = u.id AND id = &NewsId

                                                                              SELECT * FROM comments WHERE comments.newsId = &NewsId JOIN users ON users.id = comments.author ORDER BY comments.date

                                                                              А потом вывод формируется в приложении из этих данных. Если канал приложение↔СУБД узок, то можно чуть-чуть сэкономить, запрашивая список данных пользователей отдельным от комментариев запросом.
                                                                                0
                                                                                Форматирование я сделал чтобы коменты в коде не писать — из самого кода понятно что выводится. Можно было и в JSON и в HTML и в XML запихать вывод.

                                                                                Вы тоже не стали полностью пример повторять — поэтому всё стало примитивнее.

                                                                                Приведите полный код для повтора вывода моего примера. Вместе с кодом приложения или хранимкой, тогда станет понятнее.

                                                                                  0
                                                                                  из самого кода понятно что выводится
                                                                                  Вы это серьёзно? Очевидно для людей, которые M[UMPS] впервые видят? (а иначе бы у вас не спрашивали)
                                                                                  Скрытый текст
                                                                                  Второй день смотрю, не могу понять, что значит
                                                                                  For  Do  Quit:comm=""
                                                                                  Судя по For — цикл. Потом сразу Do? До условия цикла? Бесконечно повторять? Но что тогда значит Quit после него с каким-то присваиванием — выход с пустым значением? «И сразу выход!» Условие выхода из цикла? Тогда почему второй же строчкой после идёт опять Quit? Теперь это безусловный выход? Тогда почему форматирование точками продолжается, как будто оно ещё идёт? По два раза каждый цикл проверять voter? Брр, раскопал доки — да, цикл без счётчика — for<пробел><пробел>do<пробел><пробел>quit:(условие выхода), но зачем каждый цикл условие выхода проверяется по два раза?

                                                                                  Код приложения чуть попозже напишу. Надо ещё решиться, на чём писать.
                                                                                    0
                                                                                    Синтаксис действительно непривычный. Но если учесть почти пятидесятилетний возраст языка — становится понятно, что всё было направлено на скорость интерпритации([байт]компилироваться он позже научился). Я кстати код брал из «книжного примера программы» википедии. А так как все команды имеют ещё и краткую форму можно писать «пример реальной программы» где уже что-то понять могут только мумпсеры.

                                                                                    В $order — получение очередного значение, если "" — значит кончились и выход.

                                                                                    Буду ждать. Надеюсь структура вывода будет такая-же.

                                                                                    Вообще было бы неплохо реально сравнить оба подхода на одном и том же примере. А в идеале ещё и на скорость работы проверить.
                                                    +1
                                                    Ок, давайте обсудим. Во-первых, как я понял речь идет все таки о РСУБД, а не об SQL. SQL — всего лишь один из языков запросов. Во-вторых, не очень понятно, о каких задачах идет речь. Если вы говорите о визитках, интернет магазинах и корпоративных сайтах, то обычно самой сложной частью таких приложений является CMS. Таким образом, можно говорить о том, что большинство задач типичного веба требуют реализации CMS (либо взять готовую). Задача уже подразумевает некоторую предметную область включающую как минимум пользователей, роли и ресурсы. ИМХО, реляционные таблицы — вполне адекватный инструмент для такой задачи.
                                                      0
                                                      Нет, я говорю о веб-приложениях в целом. CMS — тоже веб-приложения. Их необходимость для сайтов-визиток и вообще тема «конструкторы vs конкретные системы» — тема отдельного холивара ;)

                                                      Речь идет не о РСУБД, а о реляционных базах данных как таковых, если уж быть точным. В контексте термина NoSQL, термин SQL вполне понятен, имхо.
                                                        0
                                                        Ну так ответьте тогда на вопрос, что такое «80% задач типичного веба»?
                                                          0
                                                          Это CRUD по атомарным сущностям:
                                                          1. Добавить сущность.
                                                          2. Отфильтровать список сущностей.
                                                          3. Обновить сущность.
                                                          4. Удалить сущность.
                                                            +6
                                                            Ни разу в жизни не встречал коммерческий веб-проект функциональность которого ограничивалась бы только тем что вы написали. Есть у меня сомнения по поводу того, что 80% веб-приложений реализуют только голый crud и больше ничего.
                                                              +1
                                                              Я вообще думал, что мы говорим о задачах СУБД в рамках веб-приложения, а не о задачах приложения.
                                                              +3
                                                              Сгруппировать, отфильтровать, саггрегировать циферки, добавить данных из разных сущностей… ;)
                                                          +1
                                                          Ну и если говорить о системах управления контентом, то есть такие документо-ориентированные БД, которые тоже входят в группу NoSQL.
                                                            0
                                                            Я не говорю о том, что для реализации CMS нельзя использовать документо-ориентированные базы, я защищаю реляционные базы в том смысле, что их использование мне кажется вполне оправданным на тех самых 80% проектов. Я бы скорее сказал, что документо-ориентированные базы — это в некотором смысле оверкилл для типичных задач. Их 100% удобно использовать там где имеешь дело с неструктурированными данными и нечеткой схемой, но в большинстве случаев, этого как раз и не требуется.
                                                              +1
                                                              Посмотрите структуру базы данных какого-нибудь Drupal.
                                                                +1
                                                                Смотрел неоднократно, что я там увидеть должен?
                                                                  +1
                                                                  Большинство таблиц не несут самих данных, а нужны лишь для связи множества объектов друг с другом, причём зачастую эти связи реализованы не по правилам реляционных баз, но это уже не проблема самих баз, а лишь разработчиков. Видно же, что впихнули не туда свою разработку. В документной базе данных было бы гораздо легче разработать такого уровня CMS, что в недалёком будущем и произойдёт, надеюсь, когда разработчики научатся работать не только с «SQL базами данных».
                                                                    +2
                                                                    Любая нормализованная схема будет содержать кучу связей если предметная область чуть чуть более чем тривиальна. И не важно, в каких терминах мы ее проектируем, документами или реляционными таблицами.
                                                                    NoSQL поощряет денормализацию, и это кстати один из минусов, т.к. делаться она должна очень аккуратно, что не всегда происходит в реальности.
                                                                      +7
                                                                      Некоторая денормализация — это не всегда плохо.
                                                                        0
                                                                        нормализация это метод исключения логических аномалий в реляционной модели данных. что тут делает NoSQL вообще — он, типа, поощряет в данных логическую противоречивость?)
                                                                        0
                                                                        Большинство таблиц не несут самих данных, а нужны лишь для связи множества объектов друг с другом
                                                                        разве может быть как-то иначе?) реляционная модель это навороченная логика на самом деле. в ней выражаются логические связи между данными, а так же реализуются операции над ними.
                                                                    +6
                                                                    Большинство CMS как-раз таки реализуют разнообразные костыли для поддержки нечетких схем поверх реляционных баз.
                                                                      +2
                                                                      Мм… не совсем верно, конечно, гибкость в настройке требует очень глубокой нормализации, например для того, чтобы создавать новые типы данных ручками, но при эксплуатации обычно используется статичная реляционная модель. Никаких eav и прочих извращений, которые всем своим видом намекают на использование документов.
                                                                        +1
                                                                        Причем тут нормализация?

                                                                        Я говорю о диком оверхеде тупо по количеству сущностей, которые нужно поддерживать и количестве связей.
                                                                          0
                                                                          а оверхед это и есть следствие очень глубокой нормализации. а очень глубокая нормализация получается из требований к универсальности модели данных («нечеткости схем»), в купе с необходимостью обеспечивать, при всем при этом, их логическую непротиворечивость.
                                                                +5
                                                                Считаю, что надежный рабочий инструмент должен быть избыточен.
                                                                Толщина гаечного ключа избыточна, но так как-то надежнее :)
                                                                  +3
                                                                  … пока вам не приходится таскать на спине ящик с сотней гаечных ключей, из которых реально нужен только один — под конкретную гайку.
                                                                    +6
                                                                    Странная аналогия, кому мешает mysql установленный на веб-сервере?
                                                                      0
                                                                      Он мешает не на веб-сервере, он мешает разработчику. Особенно, если эти «гаечные ключи» начинают использовать «потому что можно».
                                                                        0
                                                                        Он же памяти как сволочь жрет, на VPS-ках это действительно важно.
                                                                        Брать полгига оперативки, когда все может сносно крутится на 128 — оверкилл.
                                                                          +1
                                                                          Наверное потребление ОЗУ зависит от параметров конфигурации, как думаете?
                                                                            +1
                                                                            Зависит. В дефолтной конфигурации mysqld занимает около 70 мегабайт RAM.
                                                                            Меньше можно, да.

                                                                            Я о том, что ставить mysqld на каждый веб-сервер, потому что он никому не мешает — слишком. Я не против SQL, но для большинства моих задач MySQL — оверкилл.
                                                                              +1
                                                                              хм, вот сейчас глянул — на рабочем сервере занято всего 75mb оперативки из них 45 — mysqld. Ну многовато, да. Но учитывая что там БД весит 25мб и она вся естественно в памяти — не очень.

                                                                              Думаете какой mongodb ел бы сильно меньше памяти?
                                                                                +1
                                                                                Я не работал с NoSQL в привычном виде (т.е. Redis/Mongodb), я пользуюсь ZODB в данный момент.
                                                                                Ничего не имею против SQL-баз, но мне просто глубоко неприятен сам MySQL, я постоянно с ним натыкался на какой-нибудь геморрой — неясные падения производительности, оверхед по памяти, нагрузка на диск, раньше были проблемы с кодировками, не знаю, как сейчас с этим. Postgres и SQLite мне больше нравятся по подходу.
                                                                                  0
                                                                                  Не знаю как сейчас, но пару-тройку лет назад postgre был заметно медленнее… А sqlite вообще не конкурент, оно совсем для других сфер применения ведь.
                                                                                    +1
                                                                                    Насчет производительности — я не уверен на 100%, но MySQL сливает при выборке из разных таблиц по связям, Postgres сливает, если выборка из одной таблицы. По крайней мере, раньше было так.

                                                                                    Да, я знаю, что SQLite не конкурент. Но для маленькой базы я предпочту его, чем ставить что-то мощное.
                                                                          +2
                                                                          Эм, а давно MySQL является составной частью ОС?
                                                                      +2
                                                                      Как вы поддерживаете консистентность данных? Скажем, добавляется комментарий к посту и одновременно пост удаляется. Я не про конкретно пост+комментарии, а про любые 2 связанные сущности.
                                                                        0
                                                                        атомарный LOCK например.
                                                                        UPD: я понял что вы не про механизм программирования спрашивали, а намекали на отсутствие изкоробочной-повсеместной поддержки сылочной целостности.
                                                                          +1
                                                                          Да, я про это.
                                                                            0
                                                                            А если у вас сотни серверов по всему миру? Так просто LOCK вы уже не сделаете.
                                                                              +1
                                                                              Но РСУБД такое просто не потянут. А вот NoSQL на такое можно запрограммировать. Правда одним LOCK уже явно не отделаться.
                                                                                +1
                                                                                Ну тут собственно CAP теорема во всей красе. В вебе вроде как почти всегда можно пожертвовать связностью ради доступности. То есть позволить добавить комментарий к удалённому посту, это потом можно будет всегда починить. А вот РСУБД это всегда связность взамен доступности. Для банков это, безусловно, наиважнейшее свойство.

                                                                                One size doens't fit all.

                                                                                В couch вообще никакого лока не надо, оно само починится при синхронизации, time to relax :)
                                                                                  0
                                                                                  РСУБД это всегда связность взамен доступности


                                                                                  Внезапно! Кто мешает в РСУБД сохранить несогласованные данные и привести их в соответствие по тому же принципу, что в нереляционной системе? В то же время реляционная позволяет задействовать контроль целостности, там где нереляционная просто не обладает соответствующей функциональностью «by design».

                                                                                  «Само» — это те ещё «подводные грабли»
                                                                                0
                                                                                Если у вас равноправные датацентры, вы никуда не денетесь от большого трафика между ними и задержек, связанных с синхронизацией. Так что для поддержания консистентности можно просто использовать любое кластерное решение, поддерживающее распределённые блокировки, например, zookeeper.
                                                                            +2
                                                                            Судите сами. Для исполнения каждого SQL запроса необходимо:
                                                                            1) Распарсить SQL-запрос.
                                                                            2) Проверить синтаксис
                                                                            3) Проверить наличие соответствующих таблиц и полей, имена которых используются в запросе.
                                                                            4) Представить запрос в виде, пригодном для оптимизации.
                                                                            5) Провести оптимизацию
                                                                            6) Преобразовать оптимизированный граф в последовательность команд для исполнения.
                                                                            7) И собственно выполнить команды…

                                                                            Большинство NoSQL баз обычно переходят сразу к пункту 7. Все оптимизации разработчик делает сам, исходя из задачи и здравого смысла…
                                                                            Не знаю как вам, а мне очевидно.
                                                                              0
                                                                              П. 1-6 в современных СУРБД делаются один раз и кэшируются если что.
                                                                              Вопрос в другом — нафига тащить за собой (и покупать за деньги) все те наслоения функциональности и легаси, которые понапихали в тот же оракл за эпоху двузвенок?
                                                                                0
                                                                                Любопытно… Как вы будете кешировать пп. 1-3?.. 0_о
                                                                                    +2
                                                                                    Сами-то читали? Я эти разделы документации MуSQL в своё время раз по десять на дню читал…

                                                                                    Особенно query cache хорошо написано. 70% текста описывает в каких случаях кеш запросов не работает. Например, при каждом INSERT или UPDATE кеш сбрасывается… При использовании в SQL-запросе функций состояния типа timestamp() кеш игнорируется… В общем серьезное подспорье, без сомнения…

                                                                                    И всё равно парсить запрос придется…
                                                                                0
                                                                                Хорошая статья на эту тему — Query Execution Basics на примере MySQL. Не так негативно, как вы описали.
                                                                                Большинство NoSQL баз обычно переходят сразу к пункту 7.

                                                                                Не знаю как вам, а мне очевидно.

                                                                                Не холивара ради, но вы исходники того же Mongo читали? Там тоже есть индексы, query cache, parser, query optimizer и еще много страшных слов :)
                                                                                  0
                                                                                  Читал, и более того использую mongodb на практике… Для того, чтобы декларативный SQL преобразовать в конкретный код, требуется куда больше затрат чем даже js-код MongoDB. Про прямые библиотечные вызовы я даже не говорю…
                                                                                    0
                                                                                    Для того, чтобы декларативный SQL преобразовать в конкретный код, требуется куда больше затрат чем даже js-код MongoDB.

                                                                                    Согласен с такой формулировкой.Но вы были не правы, про то, что запросы монго прямо вот так с ходу исполняются. И чем больше фишек будет обретать эта СУБД, тем больше будет overhead.
                                                                                      +1
                                                                                      Конкретно Mongodb, да, согласен. Там есть предобработка…

                                                                                      Но mongodb — хоть и популярный но никак не представитель core NoSQL. Он скорее засланный казачок от NoSQL в стан реляционных баз данных и играет на их традиционной территории. И играет, надо сказать, неплохо…
                                                                                0
                                                                                Нет, не так. В вебе отдельные запросы редко когда бывают очень уж сложными и требующими большой производительности, но зато их очень много. И тогда экономически более выгодно становится делать много маленьких и дешевых серверов вместо одного мощного и дорогого. Это требует соответствующих подходов в разработке.
                                                                                RDBMS на такую ситуацию не рассчитаны, а NoSQL-системы (которые здесь в основном обсуждают) как раз для этого и создавались. В этом весь смысл NoSQL, а вовсе не в избыточности RDBMS.
                                                                                  0
                                                                                  Что вам мешает натыкать много маленьких мускулов и перенести логику шардинга в DAL слоя приложения?
                                                                                    0
                                                                                    А зачем?
                                                                                    В смысле, при таком подходе от mysql ничего не останется, то есть не будет разницы между ним и, скажем, mongodb в плане функционала. Плюс, придется самому дополнительно пилить логику шардинга, которая уже реализована в mongo из коробки.
                                                                                      0
                                                                                      Ну я примерно тот же вопрос и задаю в первом комментарии ;)
                                                                                        +1
                                                                                        Ну я про то, что не SQL избыточен, его просто не получается использовать на таких задачах. Если бы был удобный способ использовать SQL в таких условиях — я был бы только за, но пока я не видел таких решений.
                                                                                +4
                                                                                Быстрый доступ к данным (если все данные помещаются в оперативной памяти),

                                                                                В случаях, когда данные начинают не помещаться в памяти, SQL, как правило, превосходит NoSQL.

                                                                                С чего бы это? NoSQL-решения не используют файловых индексов?
                                                                                  +3
                                                                                  Ситуации бывают разные, но готов предположить, что товарищи, которые занимались десять лет разработкой пылесоса для сухой уборки, сделают его лучше для сухой уборки, чем ребята, которые «позавчера» сделали ультрасос для сухой и влажной уборки и любых поверхностей.
                                                                                  Материала по этому вопросу очень много, вот просто с ходу:
                                                                                  mysqlha.blogspot.ru/2010/09/mysql-versus-mongodb-fetch-by-secondary.html
                                                                                  mysqlha.blogspot.ru/2010/09/mysql-versus-mongodb-update-performance.html
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      0
                                                                                      В тесте рассматривается Монго 1.7, актуальная версия — 2.2.
                                                                                      0
                                                                                      Думаю, что Монти в контексте имел конкретное NoSQL решение
                                                                                      +1
                                                                                      В этом случае очень трудно превзойти SQL оптимизатор для комплексных задач, особенно выборки, которые автоматически генерируются на основе запросов пользователей (этого требует большинство веб-сайтов).


                                                                                      А вот этот тезис вообще очень и очень спорный. Он может быть верен для каких-нибудь универсальных корпоративных баз знаний, где действительно запросы могу генерироваться пользователями (хотя та еще спорная практика). Но вот в вебе запросы всегда одинаковые за исключением значений аргументов.
                                                                                        +1
                                                                                        Нет, конечно. Ну, например, фильтры подбора товара в интернет-магазинах электроники или там в яндекс.маркете. Вот там хороший оптимизатор может очень ускорить выборку. Скажем, поиск по производителю «Гнусмас» возвращает 20000 строк, поиск по цвету «черный» скажем 30000 строк, а поиск по цвету «нежно-лиловый» возвращает 3 строки. В случае, если юзер ищет нежно-лиловый Гнусмас, планировщик запросов может показать себя во всех красе.
                                                                                          +4
                                                                                          Это называется «фасетный поиск».

                                                                                          И MS SQL, например, под реальной нагрузкой на этой задаче радостно ложится поспать. Поэтому под него используют, например, тот же Sphinx.
                                                                                            +1
                                                                                            Вы написали: «но вот в вебе запросы всегда одинаковые». Вам привели контр-пример. Вот вам еще один: всякие хитрые ACL для «подзамочных постов», закрытых разделов форумов и т.п. — там тоже вполне себе монструозные SQL-запросы в части WHERE. Писать всё это вручную на key-value storage — ад и содомия.
                                                                                            Про большую нагрузку, способную положить MS SQL, речь как-то не шла.
                                                                                              +1
                                                                                              Вы привели пример с которым я сталкивался непосредственно и с которым планировщик не справился. При том, что все остальное вполне себе продолжает крутится на ms SQL server.

                                                                                              С ACL тоже сталкивался, в силу того что они всегда забираются блоком их вообще можно хранить в XML каком-нибудь, что и было прекрасно реализовано.

                                                                                              Приведите более конкретный пример, пожалуйста.
                                                                                                0
                                                                                                Эммм ACL в XML? Не, я про всякие социальные сайты. Ну, знаете там, «эту глубокомудрую запись могут видеть только мои друзья и друзья друзей». И вот вам нужно сгенерировать страницу юзера со всем самым новым, к чему он имеет доступ в соответствии с текущим социальным графом, учитывая репосты.
                                                                                                А насчет MSSQL — я не фанат этой системы, но вообще либо вы её плохо приготовили, либо у вас было слишком слабое железо для вашей нагрузки.
                                                                                                  0
                                                                                                  Я тоже про социальные сайты.
                                                                                            0
                                                                                            chainik,

                                                                                            Была статья на Хабре на похожую тему.
                                                                                            Помимо прочего там автором использовалась неполная и нечёткая предметная область, информация о которой дополняется в процессе использования системы (подобие EAV только для NoSQL).
                                                                                            Ссылка на реальный проект, указанная автором статьи немного устарела, здесь более новая (внизу страницы есть логотип Caché).
                                                                                            Кстати, с версии Caché 2012.2 можно BI использовать и над неструктурированными данными.

                                                                                            Я не слышал, чтобы какие-то современные NoSQL-системы имели встроенную поддержку SQL, не говоря уже о MDX над живыми данными.
                                                                                            +2
                                                                                            Согласен. Даже более того, я считаю, это откровенное лукавство со стороны Видениуса.

                                                                                            Как минимум, оптимизатор работает не мгновенно. Данные, на основе которых производится оптимизация, получаются с помощью тех же запросов к базе данных и имеют вполне конкретную сложность. Утвержать, после этого, что это быстрее чем NoSQL…

                                                                                            И лишнее тому подтверждение, это интеграция MariaDB с NoSQL решениями. Это позиционируется чуть ли не как основная фишка MariaDB. Если преимущество NoSQL спорно и неочевидно, то зачем это Видениусу тогда?

                                                                                            NoSQL — это не мода, в hardcore IT нет понятия гламура. Это способ решения проблем, которые оказалось невозможным решить с помощью реляционных CУБД с вменяемыми затратами ресурсов.

                                                                                            Посмотрите на типичного представителя RDBMS в Big Data — Oracle. Всем, кто более-менее в теме баз данных уже очевидно, что это тупик и разводилово на бабло денежных мешков…

                                                                                              0
                                                                                              Гы, правда всем? Я вот не представляю, как бы мы обходилисись без Oracle при всей его монструозности.
                                                                                              А почему он стал вдруг тупиком? Что из коробки потянет таблицы на десятки терабайт с полноценной поддержкой транзакций и прочих ништяков?
                                                                                                0
                                                                                                Терабайты из коробки, ништяки? Вы просто не в теме… Сертифицированные специалисты по Oracle не зря свой хлеб получают, уж поверьте… И им их жизнь сладкой не кажется.
                                                                                                Тюнинг Oracle под конкретную схему и под конкретное железо — отдельная тема… И стоит это совершенно невменяемые деньги…
                                                                                                0
                                                                                                Комменты к топику только подтверждают слова, что повальное увлечение NoSQL лишь мода. Почти все ответы без аргументов. В кучу смешали все виды приложений от сайтов на коленках до энтерпрайза, все NoSQL решения. И только РСУБД для 90% отметившихся тождественно MySQL. Что за бред делать культ из инструментов и не смотреть по сторонам.

                                                                                                Чем заслужила немилость БД оракла? Или вы про NoSQL решение от них же (которое вероятно единственное сейчас с полной поддержкой ACID)? Цены да, кусаются. Только продукты от оракла направлены на крупные промышленные решения со сложной инфраструктурой и интеграцией. Ну не для сайтиков оно и не лезет в эту нишу.

                                                                                                Вы уж извините, но издержки РСУБД, вами описанные, полный бред. Единственное, что из списка и влияет сильно на производительность, то hard parse. Да и то, это будет уже явным признаком говнокода. Причины более быстрых операций в NoSQL совершенны иные, также как и задачи, для которых созданы NoSQL.
                                                                                                  +1
                                                                                                  Говорить про моду в СУБД может только человек, который не занимался серьезной разработкой и задач сложнее сайтиков не решал… Никто не будет тратить тысячи человека-часов на разработку СУБД не имеющую явных преимуществ перед существующими решениями, и без ясных коммерческих перспектив.

                                                                                                  Возьмите для моды напишите NoSQL CУБД, хотя бы сравнимую по производительности с MySQL. Потом поговорим про говнокод… С задачами для которых создавались NoSQL, реляционные базы очевидно не справились.

                                                                                                  Про Оracle пусть расскажут те кто с ним реально работает. Например операторы сотовой связи из большой тройки. Пусть расскажут, как у них там всё гладко с Ораклом и сколько стоят контракты на поддержку… Обычный стартап себе такие деньги вряд ли сможет позволить…
                                                                                                    0
                                                                                                    Какая-то абстрактная чушь. Зачем мне писать СУБД? Вы хоть понимаете для чего нужны NoSQL и для чего реляционные базы?

                                                                                                    И с ораклом по работе имею дело постоянно. И видел картину творящегося у одного из опсосов большой тройки. Все проблемы там из-за некачественной разработки отечественного девелопера, никак не из-за реляционных баз.
                                                                                                      +1
                                                                                                      Чтобы вы поняли, что СУБД — это не бижутерия. Их «по моде» не пишут. Их вынуждены писать под реальные задачи, которые не получается решить доступными на тот момент средствами…

                                                                                                        –1
                                                                                                        Речь вовсе не про создание новой БД. Речь про использование инструментов к месту. Вы зачем-то прокляли все реляционки, а оракл еще и клеймили. Возвели в ранг панацеи NoSQL. Аргументов конкретных при этом не привели. Сплошная демагогия.
                                                                                                          0
                                                                                                          Перечитайте еще раз, pls… Говорил о лукавстве Видениуса. И уж точно не проклинал и не клеймил, как вы пишите, RDBMS. Свои задачи RDBMS решают, и решают неплохо… И будут еще долго решать.
                                                                                                  +1
                                                                                                  Классический Oracle — это НЕ BigData. В него можно положить сотни миллиардов записей в каждую табличку, сделать много таких табличек, делать join на них и всё будет работать. Но сотню терабайт данных туда никто не запихивает, и никаких map-reduce не запускает.

                                                                                                  И адекватных альтернатив ораклу из мира NoSQL нету совсем. Куда можно положить сотню миллиардов записей, чтобы оно при этом нормально шевелилось и не занимало несколько десятков машин?
                                                                                                    0
                                                                                                    И адекватных альтернатив ораклу из мира NoSQL нету совсем.
                                                                                                    А как же Oracle NoSQL Database?
                                                                                                      0
                                                                                                      У вас есть цифирки, что в него можно запихать сотни миллиардов объектов, да ещё и с индексами, и оно будет работать на одной машине?
                                                                                                        0
                                                                                                        Не использую.

                                                                                                        А разве должны быть проблемы?
                                                                                                        100млрд записей по 32 байта вполне умещаются на один «честный» 4Тб HDD.

                                                                                                        В своё время на Caché делал тесты на 500млн записей (сколько позволил мой HDD) с bitmap-индексами. Скорость была вполне приемлемой.

                                                                                                        Если не секрет: зачем хранить 100млрд на одной машине, а не раскидать по нескольким?
                                                                                                          0
                                                                                                          Зачем покупать много машин и воротить логику шардирования, когда можно хранить всё на одной машине?
                                                                                                          У NoSQL проблему обычно вызывает то, что потребление памяти линейно зависит от количества ключей.
                                                                                                            0
                                                                                                            Зачем покупать много машин и воротить логику шардирования, когда можно хранить всё на одной машине?
                                                                                                            1. одна мощная машина как правило сто́ит дороже нескольких попроще
                                                                                                            2. размазывание данных как правило приводит к увеличению скорости вследствие распараллелизации запроса
                                                                                                            3. надёжность (помните про яйца и корзину?)
                                                                                                            4. применительно к Caché логика шардирования задаётся администратором прозрачно для приложения
                                                                                                            У NoSQL проблему обычно вызывает то, что потребление памяти линейно зависит от количества ключей.
                                                                                                            В СУБД Caché сколько выделите памяти, столько и будет использовать.
                                                                                                            Данные хранятся на диске довольно компактно, индексы тоже, особенно bitmap.
                                                                                                              0
                                                                                                              Ок, сколько машин и какой конфигурации необходимо для хранения 100 миллиардов строк/объектов, с парой индексов? Размер объекта пусть будет 200 байт.
                                                                                                                0
                                                                                                                Подсчитаем:
                                                                                                                100000000000*200/1024/1024/1024/1024 ~ 19 Тб (без учёта индексов, так как их размер не указан)

                                                                                                                Вы задаёте вопрос, не указав никаких параметров железа. Сервера ведь разные бывают и системы хранения тоже.

                                                                                                                Кроме хранения данных Вам, наверное, потом понадобится и поиск по ним?
                                                                                                                Здесь тоже непонятно: какие данные, какие запросы, какие максимально допустимые лимиты времени выполнения на конкретный запрос.
                                                                                                                От этого и нужно отталкиваться.
                                                                                                                  0
                                                                                                                  Давайте я попробую узнать реальные цифры, потому что придуманные не особо интересны в контексте сравнения с реальным ораклом.
                                                                                                      +2
                                                                                                      Читайте внимательней, pls. Не перевирайте мои слова… Oracle — это субд. А BigData — это большие объемы данных, и подходы к их обработке.
                                                                                                      И что NoSQL это адекватная замена Oracle, я никогда не говорил. Я говорил о том. что есть ряд значимых задач, где реляционные базы перестали справляться со своей задачей, и именно поэтому появились NoSQL-решения…

                                                                                                      NoSQL — это не мода, а назревшая потребность. Видениус неявно это признает., но пытается делать хорошую мину при плохой игре…
                                                                                                        0
                                                                                                        Цитата из вашего поста:
                                                                                                        Посмотрите на типичного представителя RDBMS в Big Data — Oracle.

                                                                                                        Или вы что под этим имели в виду?

                                                                                                        BigData — это действительно подход к обработке и хранению, а именно — горизонтальное масштабирование, map-reduce. И для работы с такими задачами появились решения — Google Bigtable, Hadoop+HDFS+HBase. Но они никак не подходят для работы обычных сайтов, для них выдвигаются совершенно другие требования.

                                                                                                        В то, что у обычного сайта есть Bigdata — простите, слабо верится. Ну какие нафиг большие данные у того же хабра?

                                                                                                        И, кстати, прочитайте в интернете, что такое execution plan cache.
                                                                                                          +1
                                                                                                          Я имел ввиду, что до NoSQL эпохи считалось непреложными фактом, что для хранения и обработки больших объемов нужен Оracle и майнфреймы. Конкурентами были IBM AS/400 c их DB2. И стоило это очень большие деньги…

                                                                                                          Сейчас многие задачи BigData решаются NoSQL решениями на стандартных, я бы даже сказал, бюджетных серверах, за совершенно несравнимые деньги.

                                                                                                          Нadoop используется в очень приличных поисковых движках cайтов solr и elasticsearch. Не bigdata, но в этом качестве он очень эффективен. Для полнотекстового поиска MySQL адекватно работает только с помощью sphinx.

                                                                                                          Мне не надо читать по execution plan cache. CУБД это моя основная специальность… Хотя мне тут ниже уже дали пару ссылок про то как правильно писать запросы, чтобы в этот кэш попадать. Видимо полагают, что я должен ознакомить с этим пользователей, прежде чем они ведут поисковый запрос… ))
                                                                                                            –1
                                                                                                            Вы правы, только вот стек Hadoop+HDFS+HBase — это совсем не конкурент для MySQL. Та же самая Mongo в абсолютном большинстве случаев не решает никаких проблем, которые невозможно решить с помощью MySQL.

                                                                                                            Будем честны, часто выбирают Mongo, а не MySQL, просто потому, что это модно.
                                                                                                              0
                                                                                                              Вот ей богу… С тем же успехом вы можете сравнить фольксваген жук с железнодорожным составом. Они тоже между собой такие же конкуренты, как и хардкорный стек NoSQL для обработки больших массивов данных и популярная РСУБД нижнего сегмента…

                                                                                                              MongoDB это не модно, это удобно… Вы похоже просто не знаете какие проблемы решает MongoDB.

                                                                                                              MySQL в абсолютном большинстве случаев не решает никаких проблем, которые невозможно решить с помощью, программы написанной на С. Но все почему-то пользуются MySQL. Мода, наверное…
                                                                                                                0
                                                                                                                Вы сами написали слова MariaDB, NoSQL и BigData рядом.

                                                                                                                Дальше. ваша цитата:
                                                                                                                NoSQL — это не мода, в hardcore IT нет понятия гламура. Это способ решения проблем, которые оказалось невозможным решить с помощью реляционных CУБД с вменяемыми затратами ресурсов.

                                                                                                                Пусть будет какой нибудь форум. Какие проблемы есть у MySQL и как эти проблемы решил Mongo? не надо будет думать про таблички?

                                                                                                                Есть одна контора под Денвером, SolidFire называется, занимаются созданием аппаратных систем-хранилищ данных с SSD. Говорят, что очень любят пользователей MongoDB, потому что они в какой-то момент понимают, что на обычных дисках их база уже неработает. Можно ли это назвать вменяемой затратой ресурсов?
                                                                                                                  0
                                                                                                                  У MySQL есть проблемы с горизонтальным масштабированием. У Mongo таких проблем нет, т. к. она изначально на это рассчитана.