MongoDB Is Web Scale

Автор оригинала: Garrett Smith
  • Перевод
Внимание: тег «юмор».

И в заключение. Мы пришли к выводу, что MySQL — это прекрасная база данных для нашего сайта. Вопросы?

Да, у меня есть вопрос. Почему вы не использовали MongoDB? MongoDB — это горизонтально масштабируемая база данных, она не использует SQL или JOINы, поэтому обладает высокой производительностью.

Это прекрасный вопрос. Мы изучили несколько NoSQL баз данных и поняли, что все варианты пока ещё незрелы для применения на работающих проектах. MySQL — это проверенная база данных, которая используется во всём мире и имеет все необходимые нам функции.

Но она не масштабируется. Все знают, что реляционные базы данных не масштабируются, потому что они используют JOINы и записывают на диск.


Масштабируемость — это сложный вопрос и неправильно делать общее заявление вроде этого.

Реляционные базы данных не были задуманы горизонтально масштабируемыми. MongoDB поддерживает горизонтальное масштабирование. Вы можете его включить и база данных автоматически масштабируется.

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

Реляционные базы данных имеют расфасование интерфейсов.

Я думаю, вы имели в виду "рассогласование".

MySQL медленнее черепахи. MongoDB может бегать кругами вокруг MySQL, потому что MongoDB — горизонтально масштабируемая.

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

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

Если вы настолько тупы, чтобы полностью игнорировать надёжность просто для того, чтобы показать красивые результаты, я советую вам отправлять данные сразу в /dev/null. Это будет очень быстро.

Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?

Вы издеваетесь надо мной, да? Я просто пошутил. В смысле, если вам подходит записывать в базу данных, которая не даёт вам понимание, что ваши данные действительно записаны, лишь для того, чтобы получить хорошую производительность, почему бы сразу не писать в /dev/null. Он чертовски быстр.

А devnull поддерживает шардинг?

Ёлки-палки. Для собственного успокоения я предположу, что вы всего лишь троллите меня, а не действительно умственно отсталый. Вы хотя бы знаете, что такое шард?

Шарды — это секретный ингридиент в рецепте горизонтального масштабирования. Они просто работают.

Пожалуйста, скажите мне, что вы не зарабатываете на жизнь в IT.

Я — веб-программист.

Всё, я официально отказываюсь дальше работать разработчиком и ухожу в колхоз ассенизатором у свиней и главным по анальным свечкам для больных лошадей, потому что это в тысячу раз проще вытерпеть, чем работать в одной сфере с такими ушлёпками как вы. Вы прочитали последний пост на Хабре и теперь думаете, что вы, блин, можете спроектировать Google, повторяете как попугай фразы вроде «горизонтального масштабирования» и «шардинга», но вообще не понимаете, о чём говорите. Вы скоро обречёте какой-то проект на провал, потому что у вас нездоровый стояк, когда вы играете с программами будто с резиновыми куклами из секс-шопа или всерьёз пытаетесь выиграть в казино вулкан. Реляционные базы данных повсюду ещё с 70-х и это одна из самых зрелых технологий, которые можно найти. И всё же находятся умники, которым нужно всё переизобрести, потому что Google и Amazon опубликовали пару исследований. Если вам надо построить глобальный распределённый поисковик, который управляет петабайтами данных, хорошо, создавайте собственную базу данных. Но, если вы такие же как 99.9% компаний, то вам, вероятно, вполне хватит MySQL и может ещё memcache.

Redis надерёт memcache задницу. Он такой быстрый и масштабируемый.

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

MongoDB — это документоориентированная база данных, которая не нуждается в JOINах. Она использует map/reduce.

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

Используя отображение файлов в память, MongoDB может улучшить скорость записи в 10 раз.

Что за чёрт? Давайте забудем о транзакциях, согласованности, надёжности, достанем все критические данные и дадим им такую встряску, которую они никогда не забудут, не забыв пригласить похоронный оркестр. В смысле, кому какая разница, что мы действительно сохраняем, пока мы делаем это быстро. А, стоп. Точно. Я на ферме задыхаюсь от зловония тысяч испускающих газы коров. Но это приятнейший аромат, потому что я далеко от этого идиотского разговора.

MongoDB использует атомарные модификаторы для согласованности данных без потерь производительности.

Вот я подхватил какую-то смертельную заразу, чистя коровьи хлева от навоза и истекаю кровью. Я скоро умру, но это долгожданное облегчение. Ведь я не буду свидетелем краха мировой экономики, когда евангелисты NoSQL уговорят финансовые организации оставить прекрасно работающие хранилища данных потому что они не поддерживают долбанные распределённые map/reduce.

MongoDB хранит файлы любого размера, не требуя добавления новых технологий.

Спасибо за ваши вопросы. Это презентация закончена и я пошёл покупать билет на поезд в колхоз, чтобы начать новую карьеру.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +7
    MongoDB is a web scale! :)
      0
      спасибо, переименовал статью, а то была неузнаваемой.
      люди думали, что это всерьёз и минусовали.
        0
        просто предположение: может быть люди минусуют потому что смехуечка попала в три тематических хаба вместо Чулана, где ей место?
          0
          «Сказка – ложь, да в ней намёк, добрым молодцам урок»
          –2
          если бы не увидел тег Внимание: тег «юмор»., то минуснул бы…
          а так спасибо за юмор, с утра подняло настроение.
        +7
        Этот диалог необходимо смотреть в оригинальном исполнении, чтобы не потерять всех эмоций, которые передают актёры.
        mongodb-is-web-scale.com/
          +3
          <nerd> оригинал всё же — www.gar1t.com/blog/mongo-db-is-web-scale.html </nerd>
            +1
            Я имел в виду оригинальное исполнение, а не оригинальный первоисточник.
          0
          С сожалением, пришлось отказаться от Монго, так как он съедал память на моём единственном сервере. А выделенный сервер, это пока слишком жирно. Может есть способы его вернуть?
            +4
            если жалко выделенный сервер, то, наверное, решаемая задача не «web scale» и достаточно MySQL :)
              0
              Есть mongolab.com (500 Mb бесплатно).
              –7
              Браво, просто таки ошеломляющая победа над «чучелом Mongo».

              Очень не люблю фанатиков, и ОСОБЕННО ненавижу фанатиков древних как окаменевшее говно мамонта технологий. Нет, я уже недостаточно молод для "… до основанья, а затем..." и вполне признаю право устаревших технологий на продолжение своего существования, но фанатеть от них?

              Так как самым важным (и сложным) в программировании является управление сложностью создаваемых программ, то хороший язык программирования обязан:
              1. Предоставлять средства построения абстракций, позволяющие разбивать задачу на относительно независимые подзадачи.
              2. Предоставлять выразительные средства наиболее близкие к тому ЧТО хочет программист, а не к полному описанию алгоритма получения искомого результата. Данный пункт во многом перекликается с предыдущим (а в языках, поддерживающих создание синтаксических абстракций, полностью включен в него), но все таки стоит отдельно.

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

              В SQL мы имеем глобальные процедуры и функции (триггеры и отображения являются специализированными процедурами), из типов данных — пучок примитивных типов данных (нет беззнаковых целых, но есть двоично-десятичные дроби — кто вообще до сих пор считает это хорошей идеей?) плюс таблицы. Все. Это настолько примитивно, что даже некоторые ассемблеры более выразительны.
                +5
                ну, во-первых, напомню о теге «юмор» :)

                я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет.
                использую их только в консоли, чтобы быстро получить какой-то отчёт или для одноразовых bulk insert/update, когда это быстрее, чем писать скрипт.
                поэтому SQL для многих становится действительно аналогом ассемблера: оно есть, но напрямую всё реже пользуются и часто не знают всех тонкостей (плохо, конечно, но опять же — большинству не надо).

                MongoDB тоже люблю и использую.
                идея очень хороша, много всяких приятностей. но пока есть много недостатков, например, «locks on a per-database basis for most read and write operations» (до 2.2 было ещё хуже — один global lock на весь mongod instance).

                поэтому автор прав — большинству хватит и MySQL.
                не стоит хвататься за всё модное, если нет желания вникать как оно работает, а просто чувствовать себя в тренде.
                  –4
                  я активно использую MySQL лет 9, но SQL-запросы в коде не писал уже несколько лет

                  А как вы делаете запросы данных на стороне сервера? Как можно написать скрипт заменяющий MySQL запрос?
                    0
                    JPA или что нибудь подобное?
                      +6
                      Любая ORM
                      +1
                      Ну дык это и не Ваше творение — оригинальный автор похоже не шутил (вернее, скорее всего он считал, что насмехается над «фанатами» Mongo).

                      Да мепперы спасают до определенной степени (я по возможности пытаюсь выносить запросы в LINQ, оставляя саму базу практически без хранимых процедур), но они лишь явственно очерчивают проблему с SQL, а не решают ее (ну и приносят импеданс, про который упомянул автор, а вернее пару десятков оных). То есть по сути ORM-ы — тоже NoSQL.

                      От RDBMS остается фактически только хранение B-деревьев, с чем вполне справляются всякие BDB, да и все остальные БД — как SQL так и NoSQL (включая Mongo) используют B-деревья как основную структуру данных для хранения индексов.

                      Что же до Mongo — да, глобальный лок — ОЧЕНЬ спорное решение изначально, с другой стороны она таки действительно масштабируется горизонтально (и, как Вы отметили, этот самый лок разбивается на несколько — в каждом mongod свой). Ну и отлично понимая, что я — «нерепрезентативная выборка», но в моем личном опыте неосторожное обращение с констрейнтами убило больше производительности, чем глобальный лок в Mongo.
                        0
                        > То есть по сути ORM-ы — тоже NoSQL.

                        С какой это стати? Типичная ORM-выборка по связанным объектам транслируется в пачку джойнов. Да что там, в том же LINQ джойны даже явно фигурируют. И транзакции и прочее тоже вполне SQL-подобны.
                          +1
                          Ну, прежде всего, в ORM-ах нет реляционной алгебры (по крайней мере на объектном конце — именно поэтому нужен «меппинг»).

                          Если же говорить конкретно про LINQ, то join-ы в нем семантически больше похожи на таковые в XQuery: декартово произведение сущностей с фильтрацией зависимых (вместо генерации нового множества кортежей со значениями). То что некоторые LINQ провайдеры генерируют на выходе SQL — отнюдь не означает, что LINQ это и есть SQL (просто с другим синтаксисом) — между ними семантическая (а не синтаксическая — как раз синтаксис относительно близок) пропасть.
                          То есть образно говоря, LINQ настолько же не SQL, насколько, например, C++ — это не машинный код.
                          +1
                          ORM — NoSQL формально, но всё равно RDBMS.
                            +1
                            Нет, реляционной алгеброй в ORM-ах не пахнет. Все операторы реляционной алгебры отображают кортежи в кортежи. Любая агрегация (в смысле включения одних объектов и коллекций в другие, а не свертка набора значений в одно) — это уже очень существенно нереляционно (собственно говоря, это один из тех самых «impedance mismatch»-ей: O-часть ORM-а работает над графом зависимостей, а R-часть — над множествами кортежей).

                            Более того, тот факт что одна и та же модель может быть отображена в другую систему хранения (причем, например, отображение в document-based хранилища приводят к гораздо меньшему количеству «импедансов») говорит о том, что модель на O-конце не особо связана со своим R-концом.
                        0
                        I am too old for this shit
                        +1
                        Использую mysql, mongodb, redis, sqlite в разных проектах. Вопрос: что мне нужно выкинуть и срочно начать переписывать работающие приложения? Или может быть не имеет смысла абстрактно обсуждать что лучше/хуже…
                          –4
                          Отвечая на Ваш вопрос: Вам необходимо выкинуть sqlite и начать использовать более быструю levelDB которая спроектирована Гуглом как замена дальнейшего развития, исчерпавшего свои возможности, sqlite3
                            +2
                            Эээ, зачем? Вы уверены, что у автора предыдущего комментария проблема в скорости? Как вообще LevelDB относится к sqlite? Это 2 совершенно разные базы, одна реляционная с поддержкой sql, другая key-value хранилище, которая вроде как вообще не поддерживает никакого языка запросов. В общем как-то толсто, особенно не зная реальных условий проекта.
                              –1
                              А вот болт SQL раз Гугл решил с sqlite3 перейти на k-v LevelDB!
                              Я Эльф, опровергни!
                              Факт неоспорим, SQLite дальнейшего развития не получит.
                              Почему — на это есть веские причины по задачам.

                              Попробую угадать — SQLite как и все встраиваемые реляционные БД, например mnesia не рассчитаны на хранение большого объема информации потому что начинают тупить. Таким образом если мы сохраним пару томиков «Война и Мир» в SQLite он будет работать с другими запросами как черепашка, а этого не хочется. Таким образом любая встраиваемая БД должна обеспечить быстрый поиск, а быстрым он может быть только по n(1) хеш-таблицам, таким как Google bigTables.
                              Именно эта технология легла в основу levelDB. При встраивании мы не получаем просадок на объем информации и локи присутствующие в SQLite! разумеется подробности можно посмотреть тут symas.com/mdb/microbench/benchmark.html
                                0
                                1. С чего куда гугл решил перейти с sqlite? Он его использовал? Я только знаю в андроиде используется.
                                2. Зачем во встраиваемых база данных хранить большие объёмы?
                                3. Что такое n(1)? Это оценка временной сложности операции?

                                SQL базы дают большое преимущество, что в них стразу встроен язык запросов. Для многих приложений (например в том же андроиде) объём данных не такой большой, чтобы проблема упиралась в производительность базы, а наличие мощного языка запросов упрощает разработку, не надо изобретать самому велосипед. В общем мне кажется sqlite для определенного круга задач весьма хорошо подходит и нет смысла в них пытаться использовать levelDB.
                                  0
                                  Зачем во встраиваемых база данных хранить большие объёмы?

                                  Сейчас во встраиваемых объемов побольше чем в корпоративных лет 10 назад :)
                                  SQL базы дают большое преимущество, что в них стразу встроен язык запросов.

                                  Что дает оверхид на его парсинг как минимум. Плюс требуется хороший планировщик из-за неоднозначности порядка выполнения, ну или костыли в языке для его явного задания.
                            +9
                            Ничего не выкидывайте, просто циклически замените mysql->mongodb, mongodb ->redis, redis->sqlite, sqlite->mysql. О результатах напишите статью на Хабр.
                            +1
                            По стилистике напомнило видео «Хочу четвертый айфон»
                              0
                              Кстати, TokuMX использует lock per document и Fractal tree indexes вместо B-trees
                                +1
                                Люди немного побаиваются нестандартных решений и боятся прекращения поддержки, поэтому остаются на оригинальной Mongo и учатся жить с её особенностями.
                                +11
                                Было бы здорово, если бы в реляционных БД был интерфейс для программ.
                                А то как-то странно получается, сначала сделали интерфейс для человека (язык запросов, SQL), а теперь всякими ORM/querybuilder-ами подбиваются костыли
                                  0
                                  что-то в этом есть. вполне можно было бы не «переписывая всё с нуля» сделать это — например, написать php-extension, который работает как простой ORM или хотя бы как Model в CakePHP с find (там conditions мне нравятся), save, updateAll, delete, deleteAll.
                                    0
                                    Особого профита, думаю, не получится по сравнению со обычными ОРМ — так же отправлять SQL запросі текстом и так же парсить текстовый ответ.
                                      0
                                      всё-таки есть небольшой overhead :)


                                      источник: vincent-lecomte.blogspot.com/2011/01/web-php-zend-benchmark-pdo-vs-doctrine.html
                                        0
                                        Не думаю, что будет значительная разница если маппить сишным расширением. Быть-то то она будет, но сомнительно что будет большой профит. Хотя, если удастся преодолеть затык на рефлексии, то может и взлететь.
                                          0
                                          Можно без объектов — массивами, без указания списка полей. Так работает CakePHP.
                                          Это менее идеологически верно, но зато можно писать очень мало кода.

                                          Смысл в том, чтобы можно было писать:
                                          $AlmostNoSql->model('Customer')->find('all', [
                                              'fields' => ['id', 'name', 'MAX(Invoice.paid_date) as last_paid_date'],
                                              'contain' => ['Invoice' => ['paid_date', 'amount']],
                                              'conditions' => [
                                                  'Invoice.paid_date NOT' => null,
                                                  'Customer.account_expire_date <=' => date('Y-m-d'),
                                              ],
                                              'order' => 'Customer.last_login_date DESC'
                                          ]);


                                          а вернулся массив
                                          [
                                              [
                                                  'Customer' => ['id' => 1, 'name' => 'Jack', 'last_paid_date' => '2013-11-01'],
                                                  'Invoice' => [
                                                      ['paid_date' => '2013-11-01', 'amount' => 200],
                                                      ['paid_date' => '2013-10-01', 'amount' => 200]
                                                  ]
                                              ],
                                              [
                                                  'Customer' => ['id' => 2, 'name' => 'Jill', 'last_paid_date' => '2013-11-05'],
                                                  'Invoice' => [
                                                      ['paid_date' => '2013-11-05', 'amount' => 100]
                                                  ]
                                              ]
                                          ]
                                          
                                  +10
                                  > Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?

                                  Хорошо, когда твои конкуренты так «разбираются» в технологии.

                                  Плохо, когда в родной компании возникает такой «апологет новой эры» :)
                                    0
                                    Если devnull горизонтально масштабируется, я буду использовать его. Devnull горизонтально масштабируется?

                                    Вот эти парни доказали, что масштабируется.
                                      –1
                                      Извините, но мой внутренний граммар-наци, говорит что «Вы откладываете запись данных позже.» лучше заменить на «Вы откладываете запись данных „на потом“. » Поменяйте, а то глаза режет. :-)
                                        +5
                                        поменял, спасибо.
                                        но, вообще, по этикету хабра — такое лучше в личку, чтобы не отвлекать людей от чтения комментариев по существу ;)
                                          0
                                          Ок. Приму к сведению.
                                        +1
                                        А я использую PostgresSQL…
                                          –1
                                          Посоны, может вы мне поможете. Пытаюсь установить MongoBD, пишет старбакс драйвер не установлен. Что делать?

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое