Плоские данные с типом структуры и хранилище документов

Question

Я знаю, что это «мягкий» вопрос, который обычно не одобряется в SO, но я использовал BigQuery для анализа (очевидно) плоских данных, которые содержат как структуры, так и повторяющиеся данные. Давайте просто возьмем очень простой пример c, строка может выглядеть так:

• ID
• Title (str)
• ReleaseYear (int)
• Жанры (str[])
• Кредиты (struct[])

Пример данных может выглядеть так:

{
    "ID": "T-1997",
    "Title": "Titanic",
    "ReleaseYear": 1997,
    "Genres": ["Drama", "Romance"],
    "Credits": {
        "Actors": ["Leonardo DiCaprio", "Kate Winslet"],
        "Directors": ["James Cameron"]
    }
}

Мой вопрос в основном заключается в том, какие операции или запросы можно выполнять в собственном хранилище документов, таком как MongoDB или CouchBase, чего нельзя было сделать в реляционной БД, поддерживающей произвольно вложенные данные. Другими словами, мое предположение (и я надеюсь, что я ошибаюсь или ошибаюсь) заключается в том, что, пока БД поддерживает структуры, она может делать все, что может делать хранилище документов. Если нет, то в каких местах это: (1) что-то, что можно сделать в MongoDB (или любом другом хранилище документов), чего нельзя сделать в BigQuery (или любой другой базе данных, поддерживающей структуры)? и (2) что-то, что может быть намного проще в MongoDB, чем в реляционной БД?

Answer 1

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

Даже если действительно поддерживает произвольную вложенность данных, BigQuery допускает ограниченную вложенность по сравнению с MongoDB. MongoDB поддерживает больше уровней вложенности. В BigQuery ваша схема не может содержать более 15 уровней вложенных структур. MongoDB поддерживает до 100 уровней вложенности для документов BSON.

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

Не совсем так - вложенные столбцы - это столбцы внутри столбцов. Но сегментирование в РСУБД - сложная задача по сравнению с базой данных № SQL, такой как Mon go. Технически вы можете это сделать, но это не было предназначено для той же цели. Это все равно, что использовать гаечный ключ вместо молотка - конечно, можно, но его назначение было совсем другим. Вы должны использовать правильный инструмент для правильной цели.

Если нет, то в каких местах он находится: (1) что-то, что можно сделать в MongoDB (или в любом другом хранилище документов) что нельзя сделать в BigQuery (или любой другой базе данных, поддерживающей структуры)? и (2) что-то, что можно сделать в MongoDB намного проще, чем в реляционной БД?

Суть вопроса в том, что РСУБД может использовать функции, которые «технически» позволяют вам делать некоторые вещи, которые вы можете делать в базе данных № SQL. Но это не значит, что он может работать так же хорошо. Например, из-за функций, которые делают РСУБД РСУБД (соответствие ACID, транзакции и т. Д. c), всегда будет дополнительное снижение производительности по сравнению с базой данных No SQL. Если СУБД удаляет эти функции, то она больше не является СУБД!

Этот ответ показывает, как MongoDB обеспечивает лучшую производительность, поскольку ему не нужно поддерживать функции СУБД:

https://softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-a-relational-dbms

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

Еще одна особенность - это сегментирование - сегментирование проще с mongodb, потому что ему не нужно поддерживать многие функции, которые делают РСУБД РСУБД, например соответствует требованиям ACID. Напротив, сегментирование является сложной задачей для РСУБД, поскольку РСУБД должна оставаться совместимой с ACID.

Взгляните на следующие два изображения:

The speed boat would out perform the "amphibious car" in the water 10/10 times. The amphibious car technically can navigate in water, but it wasn't designed to, hence is much slower and unsuited for its purpose.

введите описание изображения здесь

Как и в случае с, посмотрите на разницу в аэродинамике скоростного катера и этого милого автомобиля. Даже если вы прикрепите колеса к лодке, она не будет работать так же хорошо, как эта машина на суше. (По аналогии вы могли бы сказать, что базы данных No SQL не выполняют объединения - вы должны реализовать их самостоятельно. - но будет ли он работать лучше, чем РСУБД для тяжелых операций объединения?)

Пункт I. Я провожу аналогии, заключается в том, что каждый вид базы данных изначально был разработан для конкретной c цели, и со временем были добавлены функции, чтобы попытаться решить проблемы, для которых он не был разработан (следовательно, он не работает это, а также что-то специально разработанное для этой цели).

Следовательно, в вашем вопросе, даже если BigQuery или какая-то СУБД может что-то делать , , это не означает, что вы должны используйте их для работы . То же самое касается баз данных № SQL. Вам следует использовать лучший инструмент для работы.

Answer 2

Заявление об отказе от ответственности: у меня нет опыта работы с MongoDB или CouchBase. Мой ответ основан на возможностях BigQuery в отношении STRUCT.

• Производительность

  BigQuery STRUCT оптимизирован для запросов. Например, если вы запрашиваете select a.nested_b.nested_c.nested_d from table_t, запрос сканирует данные только для левого поля STRUCT nested_d, это быстро и дешево.

• Удобство использования

  Если ваши данные предназначены для однократной записи или только для добавления, тогда столбец STRUCT сопоставим с хранилищем документов AFAIK.

  Но если вы хотите обновить только определенное вложенное поле позже, вложенный STRUCT делает это довольно сложно, потому что там Невозможно обновить отдельный элемент в поле REPEATED, вам нужно загрузить весь массив, сканировать и изменять, а также переупаковывать для обновления столбца. Вы напишете что-то вроде:

UPDATE table
SET Credits.Actors = (SELECT ARRAY_AGG(...) FROM UNNEST(Credits.Actors) WHERE ...)
WHERE ... 

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