нужна помощь в выборе правильного метода разбиения, кластеризации или разбиения базы данных mysql

Question

Я разрабатываю приложение, которое будет использовать три таблицы.1 - 1 миллион рядов продуктов.2 - 500 миллионов строк пользователей.3 - 10 миллиардов строк продуктов, которые нравятся пользователям.таблицы будут расти со временем, но останутся в пределах этих чисел.Я хочу выбрать правильный метод для этого вида БД.Я действительно не знаю много о шардировании, кластеризации или разбиении, но если кто-то из вас скажет мне лучшее решение для этой проблемы, я сосредоточусь на нем, и это будет огромной помощью.Я хочу только методы, которые поддерживают MySQL, и если мне нужно несколько серверов для этого вида БД?спасибо.

Answer 1

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

Если вы будете часто обновлять дату (пользователи могут «отличаться»), то вам, вероятно, стоит взглянуть на шардинг.Вот пример реализации шардинга: Shard-Key-Mapper .Вы можете выполнять распределенные параллельные запросы по набору данных (например, map / проводить для SQL) здесь: Shard-Query .

Если вы разделяете на части, я должен предложить разделить на user_id и сохранить таблицу продуктов в качестве «разделяемой» таблицы, которая дублируется на каждом фрагменте.Вы должны использовать метод шардинга на основе каталога, который позволяет перемещать пользователя между шардами.Вся информация об одном пользователе и информация о том, что ему нравится, будет храниться вместе на одном осколке.

Answer 2

Я думаю, что если вам действительно не нужно решение NoSQL, такое как Hadoop, вы не можете не получить несколько серверов баз данных (здесь: MySQL). И репликация MySQL не обеспечивает, по моему мнению, достаточную масштабируемость для такого рода данных, потому что мастер станет узким местом. Я также не специалист по масштабируемости, но в настоящее время я также думаю о хорошем решении аналогичной проблемы на моей стороне. Я думаю, что я пойду с решением шардинга, где я делю свои данные на несколько узлов. Я просто думаю об интеллектуальном способе создания отображения из данных в шард. Но это зависит от вашего приложения, как вы хотите сделать это. Я думаю, что ваши данные о продуктах являются хорошим кандидатом для разделения, потому что они такие огромные.

Кстати: интересная статья против шардинг: http://37signals.com/svn/posts/1509-mr-moore-gets-to-punt-on-sharding