Cassandra вместо MySQL для приложения для социальных сетей
Я посреди создания нового приложения, которое будет иметь очень похожие функции к Facebook и хотя, очевидно, это, привычка когда-либо должна иметь дело с подобными 400 000 000 миллионам пользователей, это будет все еще использоваться существенной базой пользователей и большинством из них, потребует, чтобы это работало очень очень быстро.
У меня есть обширный опыт с MySQL, но социальное приложение предлагает сложности, какой MySQL не хорошо подходит также. Я знаю Facebook, Твиттер и т.д. двинули Cassandra для большого количества их данных, но я не уверен, как далеко пойти с ним.
Например, Вы сохранили бы такие вещи как пользовательские данные - имя пользователя, пароли, адреса и т.д. в Cassandra? Вы сохранили бы электронные письма, комментарии, обновления статуса и т.д. в Cassandra? Я также считал много, что что-то как neo4j намного лучше для представления друга отношения, используемые социальными приложениями, поскольку это - база данных графика. Я только что запускаю вниз маршрут NoSQL, таким образом, любое руководство значительно ценится.
Кто-либо смог бы консультировать меня по вопросам этого? Я надеюсь, что не являюсь слишком общим!
4 ответа
Например, будете ли вы хранить в Кассандре такие вещи, как пользовательские данные - имя пользователя, пароли, адреса и т. Д.?
Нет, поскольку это не гарантирует согласованности. Кассандра в конечном итоге последовательна . Конечно, не должно быть параллелизма в данных определенной учетной записи пользователя, но я бы не хотел на это делать ставку. Возможно, вам не понадобится единообразие в полнотекстовом поиске, почтовом ящике сообщений и т. Д., Но вам нужна согласованность во всем, что связано с безопасностью.
Я также много читал, что что-то вроде neo4j намного лучше для представления дружеских отношений, используемых социальными приложениями, поскольку это база данных графов.
Я большой поклонник правильного инструмента для правильной работы. Я не использовал neo4j, но я использовал db4o (это объектная база данных) и считаю его очень полезным. Это упрощает разработку с помощью инструмента, который изначально поддерживает ваши потребности. Поскольку вам нужны графики, а работа с графиками в SQL затруднительна, я бы рекомендовал взглянуть на него и оценить, соответствует ли он вашим конкретным потребностям.
Смешивание баз данных кажется мне хорошей идеей, если выбор является естественным (т.е. соответствующая база данных полезна для конкретных заданий, графические базы данных для графов, таблицы для таблиц, базы данных ACID для всего, что требует безопасности транзакций. , так далее...).
Facebook не двигался Кассандре они его создали. :) Насколько мне известно, СУБД noSQL не требует и даже не упоминает (благодаря mnemosyn за исправление, Facebook использует Oracle и Cassandra), работающие бок о бок с реляционной базой данных. Этот является противоположным примером (хранение информации о пользователе в базе данных noSQL).
Я бы сказал, что если Кассандра достаточно хороша для Facebook, она, вероятно, будет достаточно хороша для вашего проекта. Возможно, не помешает попытаться абстрагироваться от логики персистентности, чтобы у вас была возможность переключиться на что-то еще, если до этого дойдет.
Заявление об ограничении ответственности: у меня не было (пока?) Опыта работы с базами данных noSQL: все, что я знаю, я получил, прочитав об этом.
Я бы посоветовал провести некоторое тестирование с MySQL и Cassandra. Когда нам нужно было сделать выбор между PostgreSQL и MongoDB в одной из моих работ, мы сравнили время запроса на миллионы записей в обеих и обнаружили, что примерно с 10 миллионами записей Postgres предоставит нам адекватное время ответа.
Мы знали, что не доберемся до такого количества записей, по крайней мере, пару лет, и у нас был опыт работы с Postgres (в то время как MongoDB был еще не очень зрелым), поэтому мы выбрали Postgres.
Я хочу сказать, что вы, вероятно, можете взглянуть на тесты MySQL, провести некоторые тесты производительности самостоятельно, оценить размер вашего набора данных и то, как он будет расти, и таким образом принять обоснованное решение.
Что касается смешивания реляционных и нереляционных баз данных, мы тоже это рассматривали, но решили, что это будет слишком хлопотно, так как это будет означать поддержку двух типов программного обеспечения и написание небольшого количества связующего кода. чтобы получить данные от обоих. Я думаю, Кассандра вполне могла бы хранить все ваши данные.
Cassandra предоставляет хорошее распределенное решение и, вероятно, лучше для платформы, подобной Facebook, чем MySQL (если потребуется масштабирование). Но Cassandra не подходит для отношений данных, где у вас возникнет проблема отношений «многие ко многим». База данных графов, связанная с Cassandra, обеспечит как потребности в большом объеме, так и возможность очень быстрого запроса отношений. Мы работаем над чем-то, что объединяет две технологии, и всегда интересовались типами требований, которые будет предъявлять ваша платформа. Если у вас есть какие-либо вопросы о том, как решать определенные проблемы, связанные с данными, я хотел бы их услышать, возможно, мы сможем помочь в этом разобраться.