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

Question

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

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

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

Может кто-нибудь посоветует мне об этом? Надеюсь, я не слишком генерал!

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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