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

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


mysql cluster-computing partitioning sharding
person Ben    schedule 02.05.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person Justin Swanhart    schedule 08.05.2011

arrow_upward
0
arrow_downward

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

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

person H6.    schedule 02.05.2011