Определенные пользователем значения MySQL - EAV vs Sharding with Many tables

Question

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

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

Когда я занимаюсь математикой, если у меня 1000 арендаторов, в среднем по 5 типов каждый (5000 типов). Каждый тип имеет 1000 записей, например (5 000 000 записей). Каждая запись имеет в среднем 5 полей, что дает мне всего 25 000 000 строк на самом низком уровне модели EAV.

Процесс нисходящего потока также будет привязывать каждую отдельную информацию пользователей к сетке jquery, поэтому первая выборка этих данных и перенос данных просто мне так дорого. что происходит, когда у вас есть 10 тыс. арендаторов или 50 тыс. арендаторов ... Я понимаю, что MySQL может обрабатывать такие вещи при оптимизации, однако кажется, что я стреляю себе в ногу.

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

Мое предложение.

1. Осколок системы, использующей разделение домена таким образом, что существует максимальный набор арендаторов в любом конкретном осколке. В главном каталоге будет указываться, какой арендатор принадлежит тому, чей осколок
2. Для каждого Осколка, когда пользователь определяет тип, создайте новую таблицу для хранения этого типа. Держите таблицу отображения в осколке, которая связывает пользователя с его определенными типами (пользовательские таблицы).

Это, по сути, означает, что у меня будет несколько основных таблиц в одном осколке и 1000 таблицах.

Теперь мне, обычно, что многие таблицы в базе данных обычно говорят мне, что что-то не так с схемой или что-то было создано неправильно, но для этого сценария мне просто интересно узнать, приемлемый подход. В моем предыдущем примере это означало бы, что у меня 5000 таблиц в осколке, всего по 1000 строк. что для меня кажется лучшим подходом, чем использование EAV. Основываясь на пользователе, вы находите Type и привязываете данные к сетке.

Некоторые замечания рассмотреть

1. архитектура позволяет Многоквартирный пользователям иметь свои собственные пользователей. Так что потенциально у меня 1000 подписчиков, но 5000 пользователей. Таким образом, необходимо подключать соединения с базой данных. Удастся ли я решить проблемы с управлением соединениями?

2. Будет ли я сталкиваться с проблемами кэширования таблиц? У меня будут проблемы с промывными столами?

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

4. Разработка уже началась, не просите меня перейти на базу данных NoSQL!

Другое предложение было также продолжать использовать EAV, но внутри осколка. Что вы думаете об этой идее?

Пожалуйста, не тяните никакие удары! Мне нужно все это услышать. Спасибо заранее.

Answer 1

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

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

Таблицы каталога действительно хороши для ввода в кеш (например, memcached), потому что отображение пользователя в экземпляр shard изменяется очень редко. Это уменьшит нагрузку на каталог.

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