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