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

Question

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

• Cassandra
• MongoDB
• Redis
• CouchDB

Все они кажутся (или утверждают) быстрее, чем реляционные БД, такие как MySQL.
Я использую Ruby on Rails и есть клиенты для всего вышеперечисленного, поэтому это не должно быть проблемой.

Моя модель данных проста по большей части, которая сосредоточена на пользовательском объекте (с богатым профилем и предпочтениями), связанным с различными элементами, такими как фотографии, видео, записи ... и т. Д., И каждый из них имеет один тег или больше.

Тот факт, что эти базы данных являются новыми, кажется, не слишком много ресурсов для них в Интернете. Кроме того, они в некотором смысле структурно отличаются друг от друга, поэтому будет не так просто переключаться между ними позже.

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

Tam

Answer 1

Шаг 1) Создайте свой дизайн, используя любую технологию, с которой вы наиболее сильны.

Шаг 2) Освободите свою социальную сеть, начните исследовать нереляционные базы данных и осваивайте то, что вам наиболее удобно.

Шаг 3) Рефакторинг уровня данных, чтобы вы могли быстро и легко заменить MySQL на новую технологию БД.

Шаг 4) Дождитесь, пока ваш сайт станет настолько большим, что возникнет необходимость заменить MySQL и начнете закрывать дыры.

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

Answer 2

Существует также Токийский кабинет , который используется некоторыми крупными сайтами.

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

То, что вам нужно сделать, это посмотреть на преимущества, которые вы получаете от СУБД, и взвесить это с ее скоростью, а затем сделать то же самое в обратном направлении для базы данных типа nosql.

СУБД дают вам стандарт, они дают вам безопасность, целостность и язык общего назначения на основе наборов, чтобы упростить манипулирование данными. Однако, если вам не нужна вся эта структура или ее часть, вы теряете скорость.

До SQL был CODASYL и сетевые базы данных. SQL победил из-за переносимости и переносимости навыков и т. Д. Но я думаю, что мир мобильной проводной связи меняет это, и его стоило бы исследовать.

Answer 3

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

Для чтения часто, писать редко, это работает удовольствие.

Теперь вам не нужна «база данных документов», чтобы сделать что-то подобное. MySQL и др. Будут отлично работать с первичным ключом и полем CLOB (текст) / BLOB для хранения документа.

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

Кроме того, поскольку CouchDB - это HTTP, он хорошо работает с современными кэшами и такими, которые доступны, что может помочь вам в масштабировании, особенно при повторном чтении тяжелых операций.

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