Регистрация Дебаты Добро пожаловать на последнюю дебату о регистрации, в которой писатели обсуждают темы технологий, а вы, читатель, выбираете победный аргумент.
Формат простой: мы предлагаем предложение, аргументы за предложение были рассмотрены в понедельник и сегодня, а аргументы против — во вторник и завтра. В течение недели вы можете проголосовать за ту сторону, которую вы поддерживаете, используя встроенный ниже опрос, выбрав, за или против. Окончательный результат будет объявлен в пятницу, и он покажет, какой аргумент был самым популярным.
Наши писатели должны убедить вас проголосовать за их сторону.
Движение этой недели:
Базы данных графов, в которых связи изначально хранятся вместе с элементами данных, не дают значительного преимущества по сравнению с реляционными базами данных с хорошей архитектурой для большинства тех же вариантов использования.
Спорить ДЛЯ предложение еще раз, с контрапунктом к вчерашним утверждениям Джима Уэббера, Энди Павлодоцент кафедры баз данных Университета Карнеги-Меллона.
Это все веселье и игры, пока все не станет … Относительно
Мой уважаемый коллега скромничает, утверждая, что он не знает, что такое “хорошо спроектированная” СУБД. Тем не менее позвольте мне напомнить ему о ключевых характеристиках такой системы. Я сосредоточусь на аналитических запросах по графам, поскольку именно в этом графовые СУБД утверждают, что они лучше, чем реляционные СУБД. Мой список ниже также вдохновлен этим документом CIDR 2023. [PDF] исследователями CWI.
- Быстрое сканирование типизированных данных. Движение NoSQL ввело разработчиков в заблуждение, полагая, что база данных без схемы (т. е. без схемы) является хорошей идеей. Это необходимо для некоторых сценариев, и большинство реляционных СУБД теперь поддерживают типы данных JSON. Но для быстрого копирования данных, если СУБД знает о схеме и типах данных, она устраняет косвенность и повышает производительность сканирования.
- Хранилище по столбцам. Хранение данных по столбцам имеет несколько преимуществ, в том числе сокращение дискового ввода-вывода и непроизводительных затрат памяти из-за пропуска ненужных столбцов для запроса. Столбчатые данные также имеют меньшую энтропию, чем данные, ориентированные на строки, что делает их более подходящими для схем сжатия, которые не требуют, чтобы СУБД сначала распаковывала их.
- Выполнение векторизованного запроса — использование векторизованной модели обработки. [PDF] (в отличие от модели кортежа за раз) повышает производительность СУБД для аналитических запросов в 10-100 раз. Пакетная обработка данных также позволяет СУБД использовать векторизованные инструкции ЦП (SIMD) для дальнейшего повышения производительности.
- Явный контроль над памятью. СУБД требуется полный контроль над распределением памяти. Это означает отказ от использования «управляемой» среды выполнения с памятью (например, JVM, Erland), где фрагментация и сборка мусора вызовут проблемы с производительностью, а также не позволять ОС определять, какие данные следует удалить из кэша (например, MMAP). СУБД также должна иметь мелкозернистое размещение данных, чтобы связанная информация располагалась близко друг к другу для повышения эффективности ЦП.
Энди Павло: «Ошибка, которую они совершили, заключалась в том, что они проигнорировали историю базы данных и попытались заново изобрести колесо, отказавшись от реляционной модели».
Есть некоторые дополнительные оптимизации, специфичные для графов, которые необходимо включить в реляционную СУБД:
- API-интерфейсы запросов, ориентированные на графы. Стандарт SQL: 2023 вводит запросы графов свойств (SQL/PCG) для определения и обхода графов в реляционной СУБД. SQL/PCG — это подмножество нового стандарта GQL. Таким образом, SQL/PCG еще больше сужает функциональную разницу между реляционными СУБД и СУБД с собственным графом.
- Усовершенствования выполнения запросов. Хорошо спроектированная реляционная СУБД должна включать усовершенствования, специально предназначенные для оптимизации графовых запросов, включая многосторонние оптимальные соединения для наихудшего случая (WCOJ), компактные эфемерные структуры данных (например, сжатые разреженные строки) и факторизованную обработку запросов. . Хотя их добавление требует нетривиальной разработки, такие усовершенствования хорошо сочетаются с существующими исполнительными механизмами реляционных СУБД и не требуют написания нового механизма с нуля.
В качестве доказательства того, как хорошо спроектированная реляционная СУБД работает с графовой СУБД, я ссылаюсь на документ CIDR 2023 от CWI. [PDF]. Они расширили встроенную аналитическую реляционную СУБД DuckDB, добавив поддержку SQL/PCG и вышеупомянутые усовершенствования. Затем они сравнили его с ведущей графовой СУБД с помощью стандартного отраслевого эталонного теста графов. Их результаты показывают, что DuckDB с указанными выше расширениями превосходит СУБД с собственным графом до 10 раз. Это самые современные результаты января 2023 года, а не пятилетней давности.
И хотя в команду CWI входят одни из лучших в мире исследователей систем баз данных, они не привлекли сотни миллионов долларов для достижения таких результатов.
Что касается ссылки моего коллеги на основополагающую статью Стоунбрейкера 2006 года, которая опровергает «универсальные» архитектуры СУБД, то их анекдот о том, что Neo4j возник в результате их попытки использовать реляционную СУБД в 2000-х годах для графоориентированных рабочих нагрузок, является доказательством аргумента Стоунбрейкера. Но ошибка, которую они допустили, заключалась в том, что они проигнорировали историю базы данных и попытались заново изобрести колесо, отказавшись от реляционной модели. Я призываю заинтересованных читателей также прочитать трактат Стоунбрейкера 2006 года. [PDF] на неспособность альтернативных моделей данных заменить реляционную модель данных с момента ее изобретения в 1969 году. другие в прошлом).
Наконец, я поддерживаю свою публичную ставку на 2021 год о будущем рынка графовых баз данных. Я заменю свою официальную фотографию CMU на одну из них в рубашке с надписью «Графические базы данных №1». Я буду использовать это фото до тех пор, пока не уйду на пенсию, меня не уволят или бывший студент не зарежет меня ножом. ®
Отдайте свой голос ниже. Мы закроем опрос в четверг вечером и опубликуем окончательный результат в пятницу. Вы можете отслеживать ход дебатов здесь.
Страницы AMP не поддерживают показ опроса. Вместо этого смотрите историю без AMP.
