Возможности приложения Альтернативы постоянства - NoSQL или RDBMS? - PullRequest
Новая
       46

Возможности приложения Альтернативы постоянства - NoSQL или RDBMS?

2 голосов
/ 09 октября 2011

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

Давайте рассмотрим три основные функции системы:

  • Поток пользователя - Все активность пользователя в приложении будет записана, а затем отображена в профиле пользователя, это будет что-то вроде стены Facebook.Это будет одним из основных направлений работы приложения, и оно должно иметь максимально возможную производительность.
  • Журналы приложений и безопасности - здесь хранятся ошибки приложения и другие данные, относящиеся к пользователю, такие как: IP, геопространственное местоположение, журнал истории и т. Д. Эта часть будет использоваться в качестве дополнительного уровня безопасности.
  • Статистика приложения, пользователей и рекламы, отображаемых на нем.

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

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

Примечание: если вы можете улучшить заголовок вопроса, пожалуйста, не стесняйтесь.

1 Ответ

4 голосов
/ 09 октября 2011

Прежде чем приступить к использованию, NoSQL должен решить несколько проблем .Независимо от того, какие ответы вы получите здесь, подумайте над этими вопросами:

  • Ожидаете ли вы, что ваша система будет полагаться на BigData ?
  • Будет ли полезно быть Распределенным ?
  • Сколько Время простоя в порядке?
  • Вы бы предпочли поддержку 3 огромных блоков в разных центрах обработки данных или 300 небольших блоков?

Теперь к вашим случаям использования:

  • User Stream =>

NoSQL определенно может решить эту проблему, так как нет 100Требование согласованности% здесь.Сказав это, забавно, что вы упомянули Facebook, поскольку для решения этой проблемы они используют огромную ферму MySQL:)

  • Application and security logs =>

NoSQL - этоотлично подходит для хранения журналов, на самом деле многие структуры данных, которые некоторые из решений NoSQL построены поверх , структур, подобных журналам: Log-Structured Merge-Tree, который / использовался в Google BigTabe, Cassandra и других.Кроме того, журналы могут вырасти до огромных размеров, поэтому с NoSQL

  • Statistics of the application =>

вы не можете предоставить подробную информацию.Но NoSQL определенно может решить displaying stats.

Теперь к вашему вопросу о следует перейти на NoSQL .По правде говоря:

Если большинство гуру NoSQL снимет свои маски, они все согласятся с тем, что MOST проблем, которые разработчики решают изо дня в день, можно и скорее решить с помощьюSQL-решение, такое как PostgreSQL, MySQL и т. Д. С несколькими классными слоями Redis-кэша.И только небольшое подмножество проблем ДЕЙСТВИТЕЛЬНО выиграет от NoSQL.

Если вы решите перейти на NoSQL, я бы порекомендовал решения на основе Erlang (Riak, CouchDB), поскольку NoSQLОтказоустойчивая БД должна иметь чрезвычайно прочную, гибкую и естественно распределенную основу => такую ​​как Erlang OTP.Плюс простота - король.У них, конечно, есть клиенты для большинства языков, поэтому вам даже не нужно знать, как пишется Erlang, если вы не хотите.

...