Внимание: тег «юмор».
И в заключение. Мы пришли к выводу, что 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 хранит файлы любого размера, не требуя добавления новых технологий.
Спасибо за ваши вопросы. Это презентация закончена и я пошёл покупать билет на поезд в колхоз, чтобы начать новую карьеру.
И в заключение. Мы пришли к выводу, что 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 хранит файлы любого размера, не требуя добавления новых технологий.
Спасибо за ваши вопросы. Это презентация закончена и я пошёл покупать билет на поезд в колхоз, чтобы начать новую карьеру.
