Cassandra вместо MySQL для приложения для социальных сетей

Question

Я нахожусь в процессе создания нового приложения, которое будет иметь очень похожие функции с Facebook, и, хотя, очевидно, ему никогда не придется иметь дело с 400 000 000 000 пользователей, оно все равно будет использоваться значительной базой пользователей и они потребуют, чтобы он бежал очень-очень быстро.

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

Например, вы могли бы хранить такие вещи, как пользовательские данные - имя пользователя, пароли, адреса и т. Д. В Cassandra? Будете ли вы хранить электронную почту, комментарии, обновления статуса и т. Д. На Кассандре? Я также много читал, что что-то вроде neo4j намного лучше для представления отношений друзей, используемых социальными приложениями, поскольку это графическая база данных. Я только начинаю движение по маршруту NoSQL, поэтому любые рекомендации очень ценятся.

Может ли кто-нибудь посоветовать мне это? Я надеюсь, что я не слишком общий!

Answer 1

Например, вы могли бы хранить такие вещи, как пользовательские данные - имя пользователя, пароли, адреса и т. Д. В Cassandra?

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

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

Я большой поклонник правильного инструмента для правильной работы. Я не использовал neo4j, но я использовал db4o (который является объектной базой данных) и считаю его очень полезным. Это облегчает разработку, используя инструмент, который изначально поддерживает ваши потребности. Поскольку вам нужны графики, а работа с графиками в SQL - это боль, я рекомендую взглянуть на них и оценить, соответствует ли это вашим конкретным потребностям.

Смешивание баз данных звучит для меня хорошей идеей, если выбор естественен (т.е. соответствующая база данных полезна для конкретных заданий, базы данных графов для графиков, таблицы для таблиц, базы данных ACID для всего, что требует безопасности транзакций , так далее...).

Answer 2

Я бы предложил провести некоторое тестирование с MySQL и с Cassandra. Когда нам пришлось выбирать между PostgreSQL и MongoDB в одном из моих заданий, мы сравнили время запроса по миллионам записей в обоих и выяснили, что примерно с 10 миллионами записей Postgres обеспечит нам адекватное время отклика.

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

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

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

Answer 3

Facebook не переместил в Кассандру, они его создали.:) Насколько мне известно, СУБД noSQL не требуют или даже не упоминают (благодаря mnemosyn для исправления, Facebook использует Oracle и Cassandra), работающие рядом с реляционной базой данных. Этот является одним противоположным примером (хранение информации о пользователе в БД noSQL).

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

Отказ от ответственности: у меня (еще?) Не было опытас базами данных noSQL: я знаю, что читал об этом.

Answer 4

Cassandra предоставляет хорошее распределенное решение, и, вероятно, лучше для платформы, подобной Facebook, чем для MySQL (если это потребуется для масштабирования). Но Cassandra не подходит для отношений с данными, где вам придется столкнуться с проблемой «многие ко многим». База данных графов, связанная с Cassandra, обеспечит как объемные потребности в объеме, так и очень быструю возможность запроса взаимосвязи. Мы работаем над тем, что объединяет две технологии, и всегда интересуемся типами требований, которые предъявляет ваша платформа. Если у вас есть какие-либо вопросы о том, как решать определенные проблемы, связанные с данными, я бы хотел их услышать, может быть, мы поможем разобраться.