Насколько подходит выбор RethinkDB вместо традиционного SQL для JSON API?

Я создаю back-end для своего веб-приложения; он будет действовать как API для front-end, и он будет написан на Python (точнее, в фляге).

После принятия некоторых решений относительно проектирования и реализации я получил часть базы данных. И я начал думать, может ли хранение данных NoSQL быть более подходящим для моего проекта, чем традиционные базы данных SQL. Ниже приведено базовое функциональное описание, которое должно обрабатываться базой данных, а затем список плюсов и минусов, которые я мог бы предложить относительно того, какой тип хранилища я должен выбрать. Наконец, некоторые слова о том, почему я рассмотрел RethinkDB над другими хранилищами данных NoSQL.

Основные функции API

API состоит всего из нескольких моделей: Artist, Song, Suggestion, User и UserArtists.

Я хотел бы добавить User с некоторыми связанными данными и связать с ним Artist. Я хотел бы добавить Song в Artist по запросу, а также сгенерировать a Suggestion для a User, который будет содержать Artist и Song.

Возможно, одной из наиболее важных частей является то, что Artist будет периодически связан с User (а также Artist может быть удален из системы - следовательно, из User тоже), если они не удовлетворяют некоторым критериям). Song также будет динамически добавляться к Artist s. Все это означает, что User не имеет фиксированного набора Artist, а также Artist не имеет фиксированного набора Song - они будут постоянно обновляться.

Pros

для NoSQL:

  • Гибкая схема, так как не каждый Artist будет иметь FacebookID или Song SoundcloudID;
  • В то время как JSON API, я считаю, что я выиграю от того, что записи хранятся как JSON;
  • Я считаю, что число Song s, но особенно Suggestion будет увеличиваться совсем немного, поэтому NoSQL будет делать здесь лучшую работу;

для SQL:

  • Фиксированная схема может пригодиться в отношениях между моделями;
  • Флажок имеет поддержку SQLAlchemy, которая очень полезна при определении моделей;

против

для NoSQL:

  • Отношения сложнее реализовать и обновить модели транзакций, например, немного кода;
  • Flask не имеет никакой обертки или модуля для облегчения вещей, поэтому мне нужно будет внедрить какую-то оболочку, чтобы помочь сделать код более читаемым при выполнении операций с базой данных;
  • У меня нет никакой уверенности в том, как хранить мои записи, особенно UserArtist s

для SQL:

  • Операции громоздки, я должен определить схемы, проверить, имеют ли столбцы значения по умолчанию, назначать значения по умолчанию, проверять данные, начинать/совершать транзакции - я считаю, что это слишком много хлопот для чего-то простого, как API;

Почему RethinkDB?

Я рассмотрел RehinkDB для возможной реализации NoSQL для моего API из-за следующего:

  • Он выглядит более простым и легким, чем другие решения;
  • У него есть встроенная поддержка Python, которая является большим плюсом;
  • Он реализует объединения таблиц и другие вещи, которые могут пригодиться в моем API, который имеет некоторые отношения между моделями;
  • Это довольно ново, и я вижу много последствий и любви от сообщества. Там также будет постоянно добавлять новые вещи, которые используют взаимодействие с базами данных.

Все, что мы рассмотрим, я был бы рад услышать любые советы о том, подходит ли NoSQL или SQL для моих нужд, а также любой другой pro/con для этих двух, и, конечно, некоторые исправления в отношении вещей, которые я прихожу Правильно указано.

Ответы

Ответ 1

Я работаю в RethinkDB, но это мой непредвзятый ответ как веб-разработчик (по крайней мере, настолько непредвзятый, насколько я могу).

  • Гибкая схема хороша с точки зрения разработчика (и в вашем случае). Как вы сказали, с чем-то вроде PostgreSQL вам придется отформатировать все данные, которые вы извлекаете из третьих сторон (SoundCloud, Facebook и т.д.). И хотя это не очень сложно сделать, это не что-то приятное.

  • Возможность присоединиться к столам - для меня естественный способ делать вещи (например, для пользователя /userArtist/artist ). Хотя у вас может быть структура, в которой пользователь будет содержать художников, это будет неприятно для использования, когда вам нужно будет найти художников и для каждого из них список пользователей.

Первая точка - это что-то общее в базах данных NoSQL, в то время как операции JOIN - это больше база данных SQL. Вы можете увидеть RethinkDB как нечто, обеспечивающее лучшее из каждого мира.

Я считаю, что разработка с помощью RethinkDB проста, быстра и приятна, и то, что я ищу в качестве веб-разработчика.

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

И, как вы сказали, в то время как RethinkDB является новым, сообщество удивительно, и мы - в RethinkDB - очень заботимся о наших пользователях.

Если у вас будет больше вопросов, я буду рад ответить на них:)