Лучше ли использовать реляционную базу данных или базу данных на основе документов для такого приложения, как Wufoo?

Question

Я работаю над приложением, похожим на Wufoo, в котором оно позволяет нашим пользователям создавать свои собственные базы данных и собирать / представлять записи с автоматически сгенерированными формами и представлениями.

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

main-web-app-db (наше веб-приложение, содержащее таблицы для информации об учетной записи пользователя, биллинга и т. Д.)
user_1_db (baseball_cards_table)
user_2_db (recipes_table)
....

И так далее. Если пользователь хочет создать новую базу данных, чтобы отслеживать свою коллекцию DVD, мы бы сделали «создать базу данных» с помощью «создать таблицу ...». Если они введут некоторые данные, а затем решат, что хотят изменить столбец, мы сделаем «изменить таблицу ....».

Теперь, чем дальше я продвигаюсь в построении, тем больше похоже, что MySQL плохо подходит для этого.

1) Моя первая проблема заключается в том, что переключение баз данных при каждом запросе, сначала в базу данных нашего основного приложения для аутентификации и т. Д., А затем в личную базу данных пользователя, будет неэффективным.

2) Второе, что меня беспокоит, это ограничение количества баз данных, которые может разместить один сервер MySQL. Притворяясь, что это приложение имеет 500 000 пользовательских баз данных, MySQL предназначен для такой работы? Что если бы это был миллион или больше?

3) Наконец, этот метод станет кошмаром для поддержки и масштабирования? Я никогда не слышал об использовании MySQL таким образом, поэтому я беспокоюсь о том, как это влияет на такие вещи, как репликация и другие методы масштабирования.

Мне кажется, что MySQL не был создан для такого использования, но что я знаю. Я рассматривал базы данных на основе документов, такие как MongoDB, CouchDB и Redis, в качестве альтернативы, поскольку кажется, что бессхемный подход к этой конкретной проблеме имеет большой смысл.

Может кто-нибудь дать совет по этому поводу?

Answer 1

Поскольку вы оставляете схему на усмотрение пользователей, не имеет смысла использовать реляционную базу данных, которая заставляет вас определять схему.

Использовать NoSQL базу данных. Еще немного прочесть о переполнении стека.

Что такое NoSQL, как он работает и какие преимущества он дает?

Плюсы / минусы базы данных на основе документов и реляционной базы данных

Какая база документов лучше всего ориентирована?

Answer 2

Создание таблиц на лету, как вы описываете, очень плохая идея. Поддержка изменений схемы была бы кошмаром. Каждый раз, когда кто-то добавляет или удаляет поле, вам нужно будет выполнить команду ALTER TABLE ..., и если в таблице есть данные, это не быстрая операция, поскольку она в основном создает новую таблицу с новой схемой и перемещает все данные в новый. Не иди по этому пути.

Вы можете реализовать какое-то хранилище ключей / значений поверх MySQL без особой работы или использовать что-то вроде Friendly , но поиск подходящей базы данных документов, вероятно, гораздо более простой способ.

MongoDB будет моим выбором, но есть много вещей, которые следует учитывать, и другие могут сказать, что Кассандра будет лучше. С MongoDB очень легко начать работать, и его использование кажется довольно привычным для использования базы данных SQL. Индексирование выполняется более или менее одинаково, и запросы не слишком отличаются. Лучше всего, однако, вероятно, что вам не нужен ORM, ваши объекты хранятся более или менее как есть в базе данных. Чтение и запись могут быть сделаны очень близко к металлу, не требуя много картирования объектов и от них.