«[MySQL] Соединения злые» - Кэл Хендерсон

Question

Кэл Хендерсон из Flickr дал ключевой адрес для DjangoCon 2008 . Он кратко коснулся использования в запросах объединения таблиц в запросах, утверждая: «Вы не используете объединения, когда достигаете определенного масштаба». Я ожидаю, что Хендерсон знает все это до мозга костей, но кто-нибудь знает, какова вероятная причина его утверждения?

Answer 1

Я немного преувеличиваю, когда говорю, что они злые.

Для очень больших наборов данных, даже если они вписываются в одну базу данных, объединение является дорогой операцией (много непоследовательного ввода-вывода). При типичной загрузке веб-приложения (90/10 для чтения / записи) ваше чтение должно быть как можно более дешевым, в то время как вы можете тратить больше времени на запись (и во многих случаях лениво реплицировать записи). В типичном высокопроизводительном веб-приложении вы захотите выполнить все операции ввода-вывода базы данных в течение пары сотен миллисекунд, так что это ваш первый предел. Во-вторых, вы хотите иметь возможность выполнять множество параллельных запросов. Это указывает на возможность собирать записи прямо из индекса для больших таблиц. Кто-то уже упоминал, что вам не нужно отправлять тонну данных в браузер, поэтому выполнять объединение по всему набору данных не нужно, но рассмотрите порядок: если вы не можете получить записи в правильном порядке прямо из индекс, вам нужно выполнить все объединение, прежде чем упорядочить результаты.

Для данных с несколькими компьютерами применимы те же проблемы, но в большем масштабе. Обычное решение - материализованные представления (сглаживание данных), позволяющие выполнять запросы, подобные соединению, выполняя множественные записи во время вставки / обновления / удаления (или лениво после) и используя очень простые индексированные выборки.

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

И особая претензия к Django заключается в том, что из-за негибкости в изменении моделей существующих данных людям рекомендуется создавать сопоставляемые таблицы 1-к-1, которые только когда-либо объединяются, вместо добавления столбцов в существующие таблицы.

Answer 2

Все большие масштабируемые системы должны обходиться без объединения. Причина в том, что базы данных с высокой степенью распределения, такие как BigTable, которые использует Google, настолько велики, что они выходят за пределы одной машины. Объединение двух таблиц размером в ГБ никак не масштабируется. Фактически, если вы сделаете много объединений, вы увидите около 5 миллионов строк, в которых ваша СУБД начнет зависать, сильно полагаясь на индексы. Ну и индексы также намного сложнее в распределенных базах данных и документах, таких как mongodb, couchdb и т. Д.

Будущее - это хорошая архитектурная модель в качестве базы, затем копии данных и после вставки очередей обновлений для создания плоских объединяемых таблиц и обновления по мере изменения каждого набора строк. Большие СУБД в MSSQL, Oracle и т. Д. - все это приводит к тому, что хранилище данных и выравнивание данных необходимы для создания отчетов о скоростях и высоких масштабируемых потребностях, таких как Интернет.

Когда мы получим терабайты данных, объединение уйдет в прошлое.

Answer 3

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

Такие понятия, как денормализация, для массивных наборов данных имеют свои достоинства. В наши дни мы склонны воспринимать слова крупных разработчиков веб-приложений (смотри Facebook, MySpace и т. Д.) Как евангелие, не задумываясь о контексте.

Хорошо оптимизированное объединение с индексами и внешними ключами будет в порядке, если вы не превысите отметку в 300-400 миллионов строк (я не могу говорить о большем, поскольку речь идет о пределе того, где мы начинаем архивирование на самое большое приложение, над которым я сейчас работаю).

Answer 4

Я склонен не соглашаться, потому что, если вы хорошо спроектируете свою базу данных, вы можете получить производительность. У нас есть многотерабайтное хранилище данных, смоделированное по схеме звезды Кимбалла, и вы должны присоединить факты к измерениям, чтобы выполнить любой вид анализа, и он выполняет (потому что он разделен и проиндексирован). Но я должен произвести 200-метровые строки итогового вывода за один процесс. Такой объем информации просто не будет выдвигаться на пользователя.

Однако, к какому количеству вы присоединяетесь к типичным веб-приложениям для клиентов, которые возвращают ограниченный объем данных при каждом поколении страниц? Вместо этого ваш сервер приложений мог запрашивать строки, затем запрашивать связанные строки и т. Д. Когда реляционная база данных не была доступна на портативном устройстве небольшой модели 80K 8086, запрограммированном на C, у нас была библиотека ISAM, и мы должны были искать и читать в одном таблицы, а затем искать и читать в другой таблице. Если вы не имеете дело с большим количеством данных, то так же легко выполнить работу самостоятельно.

Но это больше программирования, а больше кода означает больше ошибок. Это также означает довольно слабую защиту базы данных и модель ограничений / реляционной целостности. Без JOIN вы будете совершать больше поездок в базу данных. В лучшем случае вы будете возвращать такое же количество информации с сервера базы данных на веб-сервер. Это может ухудшиться, если веб-сервер ожидает фильтрации строк по предыдущим полученным строкам. По сути, веб-сервер все еще выполняет JOIN, но, разумеется, немного проще масштабировать веб-серверы и требуется меньше знаний по оптимизации механизма отношений.

Answer 5

По мере увеличения вы начинаете выбрасывать возможности, потому что они чего-то стоят. Сначала подзапросы; потом со временем даже присоединяется. Это позволит вам делать с таблицами и индексами все, что вам нужно - например, Google.

Базы данных SQL обычно построены на isams - которые представляют собой не что иное, как таблицы и индексы. Так что он просто говорит, что становится ближе к металлу. Думаю, это MyISAM. Таким образом, вы избавляете оптимизатор от необходимости самим его выяснять. И я уверен, что идти оттуда. Но первым шагом ИМХО было бы избавиться от накладных расходов на анализатор / оптимизатор SQL и напрямую манипулировать таблицами и индексами. Как раньше в foxpro и т. Д.

Answer 6

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

Answer 7

Соединения - это стоимость. Вы по-прежнему объединяете или группируете данные и оплачиваете их, но переносите стоимость на более дешевый уровень приложений, где его легче масштабировать.