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

Question

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

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

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

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

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

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

Answer 1

Прежде чем приступить к использованию, 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 снимет свои маски, они все согласятся с тем, что большинство проблем, которые разработчики решают изо дня в день, могут, а точнее, могут быть решены с помощью SQL-решения, такого как PostgreSQL, MySQL и т. Д., С небольшим кешем Redis. слой поверх него. И только небольшая часть проблем ДЕЙСТВИТЕЛЬНО выиграет от NoSQL.

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