Мы изучаем возможность переноса нашего приложения на мультитенантную базу данных. В настоящее время приложение работает с одной базой данных на каждого клиента. Сейчас здесь около 400 арендаторов. В совокупности самая большая таблица будет иметь около 1 миллиарда строк и будет расти по мере добавления клиентов. Размер в зависимости от арендатора сильно различается: только один арендатор имеет 180 миллионов записей в этой таблице, а у некоторых менее миллиона. Есть несколько других таблиц из сотен миллионов, в большинстве таблиц их гораздо меньше. Мои основные опасения связаны с планированием масштабируемости для больших таблиц, и я сосредоточусь на самой большой. Параметры для него заключаются в том, что это таблица связывания / многие-ко-многим с базовыми c полями аудита для созданной и созданной даты (хотя я сомневаюсь, что они вообще необходимы для этого). Дата и время не имеют отношения к этому, это таблица назначений, которая применяется всегда. Записи можно удалять или вставлять, но не обновлять, иногда массово, возможно, не часто, но это может произойти в любое время. Я думаю, что мощность данных будет относительно высокой для обоих внешних ключей, хотя я не уверен, что составляет высокую мощность по отношению к общему количеству записей. С некоторой точки зрения, клиент с 180 миллионами записей имеет около 100 000 отдельных записей для одного внешнего ключа и 165 000 для другого. Между тем, у другого клиента около 180 000 записей, из которых 500 различных значений в одном поле и 5000 - в другом. Итак, как я уже сказал, большая вариативность.
Будет ли та таблица, которую я описал выше (миллиарды строк, большое количество данных, не по времени, сегментированный клиент, массовая вставка / удаление в любое время) в какой сценарий, который я описал (более 400 клиентов с различным объемом данных), может быть хорошим кандидатом для разделения? Причина, по которой меня это беспокоит сейчас, заключается в том, что я читал в ряде мест, что разделение - это то, с чем может быть гораздо менее болезненно иметь дело, если вы планируете его заранее, а не пытаетесь разделить позже после таблицы. огромен и с ним труднее работать, не требуя простоев или прыжков через обручи. На данный момент меня больше всего беспокоит не столько запросы к данным: я тестировал таблицу с 1 миллиардом записей и при правильном выборе индекса запросы выполняются очень быстро. Меня больше беспокоит параллелизм с чтением / записью / удалением, блокировка из-за блокировок и т. Д. c. Если разбиение на разделы оправдано, какова будет хорошая стратегия? Разделение по арендатору? Просто разделите большие и храните меньшие вместе?