Блог

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

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

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

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

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

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